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

[Nick Khamis]

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.

192.168.2.5 (OpenSIPSIn) -> 192.168.2.10 (Asterisk) INVITE
Call-ID: 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.

192.168.2.20 (OpenSIPSOut) -> 94.101.2.122 (Service Provider) INVITE
Call-ID: 1fbe6fb90553da7c52d72b60076030f5 at 192.168.2.10:5060.

94.101.2.122:5060 (ServicProvider) -> 192.168.2.5:5060 (OpenSIPSIn) Giving
a Try
Call-ID: 1fbe6fb90553da7c52d72b60076030f5 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20130522/f73ad5af/attachment.htm>