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

[Bogdan-Andrei Iancu]

Hi Nick,

I guess you simply have 2 calls in there.

The callid : 4737d441-5fb15ea7-7142c0d8 at 192.168.2.11   comes from
.11(phone) goes to .5(opensips)  and to .10 (asterisk) - this call is
not picked up  (there is only a trying from asterisk), so .11 fires a
CANCEL which ends the call.

I do not know what is about the replies with callid
1fbe6fb90553da7c52d72b60076030f5 at 192.168.2.10:5060 - they seems to
belong to another call, involving a party with public IP, but I do not
see the INVITE, just some replies.

Regards,

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


On 05/21/2013 08:19 PM, Nick Khamis wrote:
> Bogdan I am so sorry!!! 192.168.2.11 is actually a UAC polycom phone.
> The only asterisk box that is being used in the scenario right now is
> 192.168.2.10, as seen in the traces. Please forgive me! :)
>
> N.
>
> On 5/21/13, Bogdan-Andrei Iancu <bogdan at opensips.org> wrote:
>> Hello Nick,
>>
>> To be honest, I'm a bit confused - looking at the trace, I see the
>> INVITE comes from .11 (an aterisks), goes to .5 (opensipsIn) and then to
>> .10 (another asterisk)....This does not match the network diagram ..
>>
>> Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developer
>> http://www.opensips-solutions.com
>>
>>
>> On 05/17/2013 11:30 PM, Nick Khamis wrote:
>>> Bogdan,
>>>
>>> I see how busy you are with OpenSIPS so I will make it count.
>>> Yes OpenSIP-Out is the new box that we have put in place to:
>>>
>>> Bellow is a quick network diagram. The issue we are experiencing is
>>> that the 100s, 183s and 200s
>>> that come back from the carrier do not get processed or even responded
>>> to by OpenSIPS-In.
>>> The complete sip trace for OpenSIPS-In can be found at
>>> "http://pastebin.com/iGeWsc40".
>>> I did not include anything for "OUT" since it is performing as expected.
>>>
>>> Some things to notice are the changed CallID. This is done by asterisk
>>> (192.168.2.10):
>>>
>>> Initial: Call-ID: 4737d441-5fb15ea7-7142c0d8 at 192.168.2.11
>>> <mailto:4737d441-5fb15ea7-7142c0d8 at 192.168.2.11>.
>>> Modified: Call-ID: 1fbe6fb90553da7c52d72b60076030f5 at 192.168.2.10:5060
>>> <http://1fbe6fb90553da7c52d72b60076030f5@192.168.2.10:5060/>.
>>>
>>> And the vanishing of RR: Record-Route:
>>> <sip:192.168.2.5;lr;did=b82.180aabc6>.
>>> This is also due to asterisk's recreation of the initial INVITE.
>>>
>>> When it comes to network appliances, this is the last piece of the pie.
>>> From now on it's mainly business logic, which should be less of a
>>> learning
>>> curve for us!!!
>>>
>>> I decided to post my problem online with example values, so it would
>>> hopefully help someone
>>> in the future.
>>>
>>> Kind Regards,
>>>
>>> Nick.
>>>
>>> network.jpg
>>> <https://mail.google.com/mail/ca/?ui=2&ik=e9f48992ab&view=att&th=13eb42dafefa444e&attid=0.1&disp=inline&realattid=f_hgttk2a11&safe=1&zw>
>>>
>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users