[OpenSIPS-Users] 404 When BYE initiated by external callee
Vlad Paiu
vladpaiu at opensips.org
Wed Apr 10 18:33:12 CEST 2013
Hi Nick,
You could try explicitly forcing the dialog matching, by using the
match_dialog function.
Then you'd use the validate_dialog() and the fix_route_dialog() [2]
functions to re-add the missing route headers that the upstream provider
mistakenly removes.
The OpenSIPS script would look like this :
if (loose_route() || match_dialog()) {
if ($DLG_status==NULL {
xlog("Failed to match the sequential request to a known
dialog\n");
} else {
if (!validate_dialog())
fix_route_dialog();
# continue your in-dialog requests processing as usual
}
}
[1] http://www.opensips.org/html/docs/modules/devel/dialog#id294238
[2] http://www.opensips.org/html/docs/modules/devel/dialog#id294238
Best Regards,
Vlad Paiu
OpenSIPS Developer
http://www.opensips-solutions.com
On 04/10/2013 07:07 PM, Nick Khamis wrote:
> 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.
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
More information about the Users
mailing list