[OpenSIPS-Users] 404 When BYE initiated by external callee

Tue Apr 9 19:22:36 CEST 2013

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/users@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 <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:1001 at server.example.com 
> <mailto:sip%3A1001 at server.example.com>>;tag=FCA0BFC0-B585477D.
> To: <sip:15178342008 at server.example.com 
> <mailto:sip%3A15178342008 at server.example.com>;user=phone>;tag=as0a76fcde.
> Call-ID: 595ad334-f06e97fa-3bbc8137 at 192.168.2.11 
> <mailto: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 
> <http://sip:15178342008@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 
> <mailto: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 
> <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:1001 at server.example.com 
> <mailto:sip%3A1001 at server.example.com>>;tag=FCA0BFC0-B585477D.
> To: <sip:15178342008 at server.example.com 
> <mailto:sip%3A15178342008 at server.example.com>;user=phone>;tag=as0a76fcde.
> Call-ID: 595ad334-f06e97fa-3bbc8137 at 192.168.2.11 
> <mailto: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 
> <http://sip:15178342008@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 
> <http://108.59.2.133:5060> -> 192.168.2.5:5060 <http://192.168.2.5:5060>
> BYE sip:1001 at 70.10.163.44:5060 <http://sip:1001@70.10.163.44:5060> 
> SIP/2.0.
> Max-Forwards: 64.
> To: "1001" <sip:1001 at 70.10.163.44 
> <mailto:sip%3A1001 at 70.10.163.44>>;tag=as4b40d9b4.
> From: <sip:001110215178342008 at sbc.voxbeam.com 
> <mailto:sip%3A001110215178342008 at sbc.voxbeam.com>>;tag=3574513019-870807.
> Reason: Q.850;cause=16;text="".
> Call-ID: 705605f129adbf5a38b5a0ff72de8f39 at 70.10.163.44:5060 
> <http://705605f129adbf5a38b5a0ff72de8f39@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 
> <mailto:sip%3Acallee 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 
> <mailto:sip%3A001110215178342008 at sbc.voxbeam.com>
>
> 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:1001 at 70.10.163.44 
> <mailto:sip%3A1001 at 70.10.163.44>>;tag=as4b40d9b4.
> From: <sip:001110215178342008 at sbc.voxbeam.com 
> <mailto:sip%3A001110215178342008 at sbc.voxbeam.com>>;tag=3574513019-870807.
> Call-ID: 705605f129adbf5a38b5a0ff72de8f39 at 70.10.163.44:5060 
> <http://705605f129adbf5a38b5a0ff72de8f39@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 
> <http://192.168.2.10:5060> -> 108.59.2.133:5060 <http://108.59.2.133:5060>
> INVITE sip:001110215178342008 at sbc.voxbeam.com 
> <mailto:sip%3A001110215178342008 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 
> <mailto:sip%3A1001 at 70.10.163.44>>;tag=as234a7f7d.
> To: <sip:001110215178342008 at sbc.voxbeam.com 
> <mailto:sip%3A001110215178342008 at sbc.voxbeam.com>>.
> Contact: <sip:1001 at 70.10.163.44:5060 <http://sip:1001@70.10.163.44:5060>>.
> Call-ID: 5a5fb47111cadd6146746c4446a1790c at 70.10.163.44:5060 
> <http://5a5fb47111cadd6146746c4446a1790c@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 list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20130409/96d8a502/attachment-0001.htm>