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 <[email protected]> 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: [email protected] >>> <mailto:[email protected]>. >>> >>> 192.168.2.5 (OpenSIPSIn) -> 192.168.2.10 (Asterisk) INVITE >>> Call-ID: [email protected] >>> <mailto:[email protected]>. >>> >>> 192.168.2.10 (Asterisk) -> 192.168.2.20 (OpenSIPSOut) INVITE >>> Call-ID: [email protected]:5060 >>> <http://[email protected]:5060>. >>> >>> 192.168.2.20 (OpenSIPSOut) -> 94.101.2.122 (Service Provider) INVITE >>> Call-ID: [email protected]:5060 >>> <http://[email protected]: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: [email protected]:5060 >>> <http://[email protected]: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. _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
