[OpenSIPS-Users] 404 When BYE initiated by external callee
Nick Khamis
symack at gmail.com
Wed Apr 10 18:06:46 CEST 2013
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