[OpenSIPS-Users] 404 When BYE initiated by external callee
Nick Khamis
symack at gmail.com
Wed Apr 10 18:07:47 CEST 2013
Sorry for the top post!!!!
N
On 4/10/13, Nick Khamis <symack at gmail.com> wrote:
> 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:001110215178392000 at sbc.voxbeam.com SIP/2.0.
> Call-ID: 58f65c9822f75d5a3da2992c0047c069 at 70.12.128.44: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:15178392000 at proxy.example.com:5060;user=phone SIP/2.0.
> Call-ID: ccc1a3e7-bcfc28f1-ed2257c4 at 192.168.2.11.
>
> 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: 58f65c9822f75d5a3da2992c0047c069 at 70.12.128.44: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: ccc1a3e7-bcfc28f1-ed2257c4 at 192.168.2.11.
>
> 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 <bogdan at opensips.org> 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
>>> <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.
>>
>
More information about the Users
mailing list