Nick Khamis
2013-Apr-09 18:23 UTC
[asterisk-users] [OpenSIPS-Users] 404 When BYE initiated by external callee
On Tue, Apr 9, 2013 at 1:22 PM, Bogdan-Andrei Iancu <bogdan at opensips.org>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 Developerhttp://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/users at lists.opensips.org/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: OpenSIPS > 192.168.2.10: Asterisk > 70.10.163.44: Public IP > 108.59.2.133: Service Provider > > > U 2013/04/09 12:17:02.920454 192.168.2.10:5060 -> 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:1001 at server.example.com>;tag=FCA0BFC0-B585477D. > To: <sip:15178342008 at server.example.com;user=phone>;tag=as0a76fcde. > Call-ID: 595ad334-f06e97fa-3bbc8137 at 192.168.2.11. > 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:15178342008 at 192.168.2.10: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;call_id> 595ad334-f06e97fa-3bbc8137 at 192.168.2.11;code=200;reason=OK > > U 2013/04/09 12:17:02.939608 192.168.2.5:5060 -> 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:1001 at server.example.com>;tag=FCA0BFC0-B585477D. > To: <sip:15178342008 at server.example.com;user=phone>;tag=as0a76fcde. > Call-ID: 595ad334-f06e97fa-3bbc8137 at 192.168.2.11. > 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:15178342008 at 192.168.2.10: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 -> 192.168.2.5:5060 > BYE sip:1001 at 70.10.163.44:5060 SIP/2.0. > Max-Forwards: 64. > To: "1001" <sip:1001 at 70.10.163.44>;tag=as4b40d9b4. > From: <sip:001110215178342008 at sbc.voxbeam.com>;tag=3574513019-870807. > Reason: Q.850;cause=16;text="". > Call-ID: 705605f129adbf5a38b5a0ff72de8f39 at 70.10.163.44: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:callee at 108.59.2.133;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:001110215178342008 at sbc.voxbeam.com > > U 2013/04/09 12:17:06.989421 192.168.2.5:5060 -> 108.59.2.133:5060 > SIP/2.0 404 Not here. > To: "1001" <sip:1001 at 70.10.163.44>;tag=as4b40d9b4. > From: <sip:001110215178342008 at sbc.voxbeam.com>;tag=3574513019-870807. > Call-ID: 705605f129adbf5a38b5a0ff72de8f39 at 70.10.163.44: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 -> 108.59.2.133:5060 > INVITE sip:001110215178342008 at sbc.voxbeam.com SIP/2.0. > Via: SIP/2.0/UDP 70.10.163.44:5060;branch=z9hG4bK75a764b9;rport. > Max-Forwards: 70. > From: "1001" <sip:1001 at 70.10.163.44>;tag=as234a7f7d. > To: <sip:001110215178342008 at sbc.voxbeam.com>. > Contact: <sip:1001 at 70.10.163.44:5060>. > Call-ID: 5a5fb47111cadd6146746c4446a1790c at 70.10.163.44: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 listUsers at lists.opensips.orghttp://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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20130409/0587e4ad/attachment.htm>
Joshua Colp
2013-Apr-09 18:31 UTC
[asterisk-users] [OpenSIPS-Users] 404 When BYE initiated by external callee
Nick Khamis wrote:> 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...Asterisk is not a SIP proxy, it does not forward or relay INVITEs. It is a back to back user agent. Each leg is individual. Cheers, -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: www.digium.com & www.asterisk.org