[OpenSIPS-Users] Slight problem routing 100s and 183s

[Bogdan-Andrei Iancu]

Hello Nick,

Well, it is a must to have replies going back on the same path.

OpenSIPS (when using TM) matches replies against transactions - if it
does not match (and no stateless fwd in script), the reply id dropped -
see the disable_stateless_fwd core param:
   
http://www.opensips.org/Documentation/Script-CoreParameters-1-9#toc38

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com


On 05/23/2013 04:48 PM, Nick Khamis wrote:
> Hello Bogdan, thank you so much. The reason for that is the port
> forwarding that is from NAT to .5 for SIP and RTP traffic. Do we have
> any options to relay the .100 to .5? I tried to set some flags on .5
> (i.e., if(status=="183" || status="100")) in the reply_route, but
> could not catch the replies coming from .122, even though the sip
> trace shows the traffic coming in.
>
> Would opensips just ignore sip traffic with callids it is not aware
> of? Finally, could we not force the dialog matching for traffic coming
> in from the outside with new callids?
>
> Kind Regards,
>
> Nick.
>
> On 5/23/13, Bogdan-Andrei Iancu <bogdan at opensips.org> wrote:
>> Hi Nick,
>>
>> if INVITE goes .11 -> .5 -> .10 -> .20 -> .122, why the 100 reply from
>> .122 goes to .5 ??? replies have to be relaid back exactly on the same
>> path as the request.
>>
>> So, the 100 reply from .122 must go to .20, not to .5 !!!
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>>
>> On 05/22/2013 08:57 PM, Nick Khamis wrote:
>>> Hello Bogdan,
>>>
>>> Thank you so much for your response, and your time! The log is for the
>>> same call, only, the callid is getting changed by asterisk. What is
>>> happening is:
>>>
>>> 192.168.2.11 (UAC) -> 192.168.2.5 (OpenSIPSIn) INVITE
>>> Call-ID: 4737d441-5fb15ea7-7142c0d8 at 192.168.2.11
>>> <mailto:4737d441-5fb15ea7-7142c0d8 at 192.168.2.11>.
>>>
>>> 192.168.2.5 (OpenSIPSIn) -> 192.168.2.10 (Asterisk) INVITE
>>> Call-ID: 4737d441-5fb15ea7-7142c0d8 at 192.168.2.11
>>> <mailto:4737d441-5fb15ea7-7142c0d8 at 192.168.2.11>.
>>>
>>> 192.168.2.10 (Asterisk) -> 192.168.2.20 (OpenSIPSOut) INVITE
>>> Call-ID: 1fbe6fb90553da7c52d72b60076030f5 at 192.168.2.10:5060
>>> <http://1fbe6fb90553da7c52d72b60076030f5@192.168.2.10:5060>.
>>>
>>> 192.168.2.20 (OpenSIPSOut) -> 94.101.2.122 (Service Provider) INVITE
>>> Call-ID: 1fbe6fb90553da7c52d72b60076030f5 at 192.168.2.10:5060
>>> <http://1fbe6fb90553da7c52d72b60076030f5@192.168.2.10:5060>.
>>>
>>> 94.101.2.122:5060 <http://94.101.2.122:5060> (ServicProvider) ->
>>> 192.168.2.5:5060 <http://192.168.2.5:5060> (OpenSIPSIn) Giving a Try
>>> Call-ID: 1fbe6fb90553da7c52d72b60076030f5 at 192.168.2.10:5060
>>> <http://1fbe6fb90553da7c52d72b60076030f5@192.168.2.10:5060>.
>>>
>>> I am assuming because the callid coming into OpenSIPSIn from the
>>> service provider has been changed by asterisk, and OpensipsIn is not
>>> aware traffic with that callid, the 183 and 200s are being ignored?
>>>
>>> I experienced something similar with BYEs and 404, due to changed
>>> callid where Vlad solved the problem by explicitly forcing dialog
>>> matching using match_dialog. I am not sure if that is possible here too?
>>>
>>> http://lists.opensips.org/pipermail/users/2013-April/025322.html
>>>
>>> I also thought about trying to relay the 183 and 200s coming in from
>>> the service provider to asterisk. The reason for this is because
>>> asterisk has the two callid mapped, and can relay the traffic with the
>>> "original" callid back to the proxy.
>>>
>>> However, to limit the traffic going back and forth, if I can use the
>>> "match_dialog" approach again it would be perfect!!
>>>
>>> This is the last piece of the elephant!!! I hope I can put it together :)
>>>
>>> Kind Regards,
>>>
>>> Nick.