25 okt 2012 kl. 13:20 skrev Andreas Granig <agra...@sipwise.com>:
> Hi,
>
> Sorry for hijacking this thread, but I've a similar but different
> question which bugs me since a while :)
>
> Is there a way in kamailio to statelessy forward a request without
> putting its own Via header into the message? Consider an example where a
> stateless load-balancer sends a request to a proxy A, which again
> statelessy forwards it to another proxy B, while it's not interested in
> staying in the path even for replies. It's not necessary either because
> the load-balancer, which would receive the replies from B then, can pass
> them along according to the Via path, so no tm or something is involved.
>
> This might break some RFC, but it would remove proxy A completely out of
> the path once the request got forwarded. In theory this seems possible
> if it's ensured that both the load-balancer and proxy A act strictly
> stateless, no?
>From the cookbook on the wiki:
/O
send
Send the original SIP message to a specific destination in stateless mode. No
changes are applied to received message, no Via header is added. Host can be an
IP or hostname. Used protocol: UDP
Parameter is mandatory and has string format.
Example of usage:
send("10.10.10.10:5070");
>
> Andreas
>
> On 10/25/2012 12:03 PM, Daniel-Constantin Mierla wrote:
>> You better use t_reply("487", "Cancelled") in a failure_route.
>>
>> Adding a proper Via header might be a tricky task.
>>
>> Cheers,
>> Daniel
>>
>> On 10/25/12 11:43 AM, Vassilis Radis wrote:
>>> I have a situation where a far end SIP provider doesn't behave
>>> properly when sending 487 replies. The scenario is this:
>>>
>>> I have a registered user calling into my kamailio which ,using lcr
>>> module, routes the call to a SIP provider. When the caller Cancels the
>>> call, my kamailio forwards the cancel message to the provider (along
>>> with a 200 Cancelling message to the caller). The problem is with the
>>> 487 sent by the provider to my kamailio: It does not contain all the
>>> two Via headers. It only contains the via header that names my
>>> kamailio. So when kamailio gets the 487, it removes its Via header and
>>> sends the 487 back to the caller, which now doesnt find any via header.
>>>
>>> Note that the far end provider, correctly sends all the Via Headers in
>>> other replies (183 etc).
>>>
>>> So now I am trying to "intercept" the 487 from this specific provider
>>> in the onreply route, and patch it with the header that the provider
>>> should have included. How can I do it? The problem is twofold:
>>> 1.I need to detect which header I should manually add (maybe store the
>>> Via Header set from the initial invites or the 183 replies, and get it
>>> from there? .I dont know how to do that)
>>> 2.I need to add it. (How can I manually add a Via header? .This seems
>>> easier
>>>
>>> Can anyone help me, maybe with another solution?
>>>
>>>
>>> _______________________________________________
>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>> sr-users@lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>> --
>> Daniel-Constantin Mierla - http://www.asipto.com
>> http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>> Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
>> Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 -
>> http://asipto.com/u/katu
>>
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users@lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users@lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
