[OpenSIPS-Users] 404 When BYE initiated by external callee
Bogdan-Andrei Iancu
bogdan at opensips.org
Wed Apr 10 10:51:32 CEST 2013
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
> <bogdan at opensips.org <mailto: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 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 <mailto:Users at lists.opensips.org>
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20130410/ac5d67cd/attachment-0001.htm>
More information about the Users
mailing list