Hello Bogdan, Sorry for the missing info. The topology is the simple
NAT Box <--> OpenSIPS <--> Asterisk (192.168.2.1) (192.168.2.5) 192.168.2.10) I have pointed the problem to the regenerated asterisk invite: U 2013/04/09 15:43:24.396204 192.168.2.10:5060 -> 108.59.2.133:5060 INVITE sip:[email protected] SIP/2.0. Call-ID: [email protected]:5060. Where the callid was changed, and the RR was lost. The original INVITE request from the UA was as follows: U 2013/04/09 15:44:00.549096 192.168.2.11:5060 -> 192.168.2.5:5060 INVITE sip:[email protected]:5060;user=phone SIP/2.0. Call-ID: [email protected]. Surely others with OpenSIPS/Asterisk integrations experienced this issue in the past? I have found little solutions outside of implementing top hiding. As mentioned earlier, asterisk has mapped the two Call-IDs together: U 2013/04/09 15:43:32.211016 108.59.2.133:5060 -> 192.168.2.10:5060 SIP/2.0 183 Session Progress. Call-ID: [email protected]:5060. U 2013/04/09 15:43:32.214127 192.168.2.10:5060 -> 192.168.2.5:5060 SIP/2.0 183 Session Progress. Call-ID: [email protected]. Would relaying the non-loose BYE to asterisk who has record of the newly created callid work? Thanks in Advance, N. On 4/10/13, Bogdan-Andrei Iancu <[email protected]> wrote: > Nick, > > I do not know what is the topology of your SIP network, but the idea is > that the BYE received by OpenSIPS does not contain proper routing > information - now, either the BYE was wrongly generated by the end > point, either it was wrongly changed on the way (if there are more hops > between that end point and opensips). > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developer > http://www.opensips-solutions.com > > > On 04/09/2013 09:23 PM, Nick Khamis wrote: >> On Tue, Apr 9, 2013 at 1:22 PM, Bogdan-Andrei Iancu >> <[email protected] <mailto:[email protected]>> wrote: >> >> Hi Nick, >> >> The BYE is not properly formed and rejected by script - in the 200 >> OK of the INVITE, you can see that your opensips is doing >> Record-Routing, but the BYE does not contain the corresponding >> Route hdr, so SIP routing is impossible. >> >> Regards, >> >> Bogdan-Andrei Iancu >> OpenSIPS Founder and Developer >> http://www.opensips-solutions.com >> >> >> On 04/09/2013 08:05 PM, Nick Khamis wrote: >>> Hello Everyone, >>> >>> I saw an earlier post about this issue: >>> http://www.mail-archive.com/[email protected]/msg23052.html >>> >>> And was wondering if there was anything we can do on our end to >>> fix this problem? It seems that providers are not obligated to >>> maintain RR? When the caller (internal) initiates the BYE >>> everything is ok, but not the case when the callee (external) >>> initiates the BYE. >>> >>> 192.168.2.5 <http://192.168.2.5>: OpenSIPS >>> 192.168.2.10 <http://192.168.2.10>: Asterisk >>> 70.10.163.44 <http://70.10.163.44>: Public IP >>> 108.59.2.133 <http://108.59.2.133>: Service Provider >>> >>> >>> U 2013/04/09 12:17:02.920454 192.168.2.10:5060 >>> <http://192.168.2.10:5060> -> 192.168.2.5:5060 >>> <http://192.168.2.5:5060> >>> SIP/2.0 200 OK. >>> Via: SIP/2.0/UDP >>> >>> 192.168.2.5;branch=z9hG4bKac2e.554c6e93.0;received=192.168.2.5;rport=5060. >>> Via: SIP/2.0/UDP >>> >>> 192.168.2.11:5060;rport=5060;received=192.168.2.11;branch=z9hG4bK42f3f16e7BC15DF1. >>> Record-Route: <sip:192.168.2.5;lr;did=392.62562fb2>. >>> From: "1001" <sip:[email protected] >>> <mailto:sip%[email protected]>>;tag=FCA0BFC0-B585477D. >>> To: <sip:[email protected] >>> >>> <mailto:sip%[email protected]>;user=phone>;tag=as0a76fcde. >>> Call-ID: [email protected] >>> <mailto:[email protected]>. >>> CSeq: 1 INVITE. >>> Server: Asterisk PBX UNKNOWN__and_probably_unsupported. >>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, >>> NOTIFY, INFO, PUBLISH. >>> Supported: replaces, timer. >>> Contact: <sip:[email protected]:5060 >>> <http://sip:[email protected]:5060>>. >>> Content-Type: application/sdp. >>> Content-Length: 312. >>> . >>> v=0. >>> o=root 1860889533 1860889534 IN IP4 192.168.2.10. >>> s=Asterisk PBX UNKNOWN__and_probably_unsupported. >>> c=IN IP4 192.168.2.10. >>> t=0 0. >>> m=audio 60646 RTP/AVP 18 101. >>> a=rtpmap:18 G729/8000. >>> a=fmtp:18 annexb=no. >>> a=rtpmap:101 telephone-event/8000. >>> a=fmtp:101 0-16. >>> a=silenceSupp:off - - - -. >>> a=ptime:20. >>> a=sendrecv. >>> >>> ACC: transaction answered: >>> >>> timestamp=1365524222;method=INVITE;from_tag=FCA0BFC0-B585477D;to_tag=as0a76fcde;[email protected] >>> <mailto:[email protected]>;code=200;reason=OK >>> >>> U 2013/04/09 12:17:02.939608 192.168.2.5:5060 >>> <http://192.168.2.5:5060> -> 192.168.2.11:5060 >>> <http://192.168.2.11:5060> >>> SIP/2.0 200 OK. >>> Via: SIP/2.0/UDP >>> >>> 192.168.2.11:5060;rport=5060;received=192.168.2.11;branch=z9hG4bK42f3f16e7BC15DF1. >>> Record-Route: <sip:192.168.2.5;lr;did=392.62562fb2>. >>> From: "1001" <sip:[email protected] >>> <mailto:sip%[email protected]>>;tag=FCA0BFC0-B585477D. >>> To: <sip:[email protected] >>> >>> <mailto:sip%[email protected]>;user=phone>;tag=as0a76fcde. >>> Call-ID: [email protected] >>> <mailto:[email protected]>. >>> CSeq: 1 INVITE. >>> Server: Asterisk PBX UNKNOWN__and_probably_unsupported. >>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, >>> NOTIFY, INFO, PUBLISH. >>> Supported: replaces, timer. >>> Contact: <sip:[email protected]:5060 >>> <http://sip:[email protected]:5060>>. >>> Content-Type: application/sdp. >>> Content-Length: 329. >>> . >>> v=0. >>> o=root 1860889533 1860889534 IN IP4 192.168.2.10. >>> s=Asterisk PBX UNKNOWN__and_probably_unsupported. >>> c=IN IP4 192.168.2.5. >>> t=0 0. >>> m=audio 31148 RTP/AVP 18 101. >>> a=rtpmap:18 G729/8000. >>> a=fmtp:18 annexb=no. >>> a=rtpmap:101 telephone-event/8000. >>> a=fmtp:101 0-16. >>> a=silenceSupp:off - - - -. >>> a=ptime:20. >>> a=sendrecv. >>> a=nortpproxy:yes. >>> >>> >>> >>> U 2013/04/09 12:17:06.988918 108.59.2.133:5060 >>> <http://108.59.2.133:5060> -> 192.168.2.5:5060 >>> <http://192.168.2.5:5060> >>> BYE sip:[email protected]:5060 >>> <http://sip:[email protected]:5060> SIP/2.0. >>> Max-Forwards: 64. >>> To: "1001" <sip:[email protected] >>> <mailto:sip%[email protected]>>;tag=as4b40d9b4. >>> From: <sip:[email protected] >>> >>> <mailto:sip%[email protected]>>;tag=3574513019-870807. >>> Reason: Q.850;cause=16;text="". >>> Call-ID: [email protected]:5060 >>> <http://[email protected]:5060>. >>> CSeq: 2 BYE. >>> Allow: INVITE, BYE, OPTIONS, CANCEL, ACK, REGISTER, NOTIFY, INFO, >>> REFER, SUBSCRIBE, PRACK, UPDATE. >>> Via: SIP/2.0/UDP 108.59.2.133;branch=z9hG4bK2deb.8bfd0b06.0. >>> Contact: <sip:[email protected] >>> <mailto:sip%[email protected]>;did=e9e.a6618961>. >>> Allow-Events: as-feature-event. >>> Allow-Events: call-info. >>> Allow-Events: presence. >>> Allow-Events: line-seize. >>> Allow-Events: dialog. >>> Allow-Events: refer. >>> Allow-Events: message-summary. >>> Content-Length: 0. >>> . >>> >>> Forcing RPORT: sip:[email protected] >>> <mailto:sip%[email protected]> >>> >>> U 2013/04/09 12:17:06.989421 192.168.2.5:5060 >>> <http://192.168.2.5:5060> -> 108.59.2.133:5060 >>> <http://108.59.2.133:5060> >>> SIP/2.0 404 Not here. >>> To: "1001" <sip:[email protected] >>> <mailto:sip%[email protected]>>;tag=as4b40d9b4. >>> From: <sip:[email protected] >>> >>> <mailto:sip%[email protected]>>;tag=3574513019-870807. >>> Call-ID: [email protected]:5060 >>> <http://[email protected]:5060>. >>> CSeq: 2 BYE. >>> Via: SIP/2.0/UDP >>> >>> 108.59.2.133;received=108.59.2.133;rport=5060;branch=z9hG4bK2deb.8bfd0b06.0. >>> Content-Length: 0. >>> >>> >>> Or is asterisk the culprit? Looking at the forwarded INVITE (on >>> the asterisk server), I see that the RR has been re-written, as >>> opposed to appended when contacting the provider: >>> >>> >>> U 2013/04/09 12:52:52.109611 192.168.2.10:5060 >>> <http://192.168.2.10:5060> -> 108.59.2.133:5060 >>> <http://108.59.2.133:5060> >>> INVITE sip:[email protected] >>> <mailto:sip%[email protected]> SIP/2.0. >>> Via: SIP/2.0/UDP 70.10.163.44:5060;branch=z9hG4bK75a764b9;rport. >>> Max-Forwards: 70. >>> From: "1001" <sip:[email protected] >>> <mailto:sip%[email protected]>>;tag=as234a7f7d. >>> To: <sip:[email protected] >>> <mailto:sip%[email protected]>>. >>> Contact: <sip:[email protected]:5060 >>> <http://sip:[email protected]:5060>>. >>> Call-ID: [email protected]:5060 >>> <http://[email protected]:5060>. >>> CSeq: 102 INVITE. >>> User-Agent: Asterisk PBX UNKNOWN__and_probably_unsupported. >>> Date: Tue, 09 Apr 2013 16:52:52 GMT. >>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, >>> NOTIFY, INFO, PUBLISH. >>> Supported: replaces, timer. >>> Content-Type: application/sdp. >>> Content-Length: 310. >>> . >>> v=0. >>> o=root 731333659 731333659 IN IP4 70.10.163.44. >>> s=Asterisk PBX UNKNOWN__and_probably_unsupported. >>> c=IN IP4 70.10.163.44. >>> t=0 0. >>> m=audio 30434 RTP/AVP 18 101. >>> a=rtpmap:18 G729/8000. >>> a=fmtp:18 annexb=no. >>> a=rtpmap:101 telephone-event/8000. >>> a=fmtp:101 0-16. >>> a=silenceSupp:off - - - -. >>> a=ptime:20. >>> a=sendrecv. >>> >>> >>> Can we get an externally initiated BYE working in an >>> OpenSIPS->Asterisk integration? If so, some suggestions would be >>> appreciated. Maybe just really the non-loose route BYE to asterisk? >>> Is adding topology hiding functionality a cumbersome task... >>> >>> Thanks in Advance, >>> >>> N. >>> >>> >>> _______________________________________________ >>> Users mailing list >>> [email protected] <mailto:[email protected]> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> >> >> Is our asterisk server not relaying the RR along with the INVITE? If >> so, can we configure the PBX to do so using one of it's variables? * >> Mailing list CC'ed in this email... >> >> >> N. > _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
