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

[Vlad Paiu]

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<sym...@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:001110215178392...@sbc.voxbeam.com SIP/2.0.
Call-ID: 58f65c9822f75d5a3da2992c0047c069@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:15178392...@proxy.example.com:5060;user=phone SIP/2.0.
Call-ID: ccc1a3e7-bcfc28f1-ed2257c4@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@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@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<bog...@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
<bog...@opensips.org<mailto:bog...@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:1...@server.example.com
     <mailto:sip%3a1...@server.example.com>>;tag=FCA0BFC0-B585477D.
     To:<sip:15178342...@server.example.com

<mailto:sip%3a15178342...@server.example.com>;user=phone>;tag=as0a76fcde.
     Call-ID: 595ad334-f06e97fa-3bbc8137@192.168.2.11
     <mailto:595ad334-f06e97fa-3bbc8137@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@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@192.168.2.11
     <mailto:595ad334-f06e97fa-3bbc8137@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:1...@server.example.com
     <mailto:sip%3a1...@server.example.com>>;tag=FCA0BFC0-B585477D.
     To:<sip:15178342...@server.example.com

<mailto:sip%3a15178342...@server.example.com>;user=phone>;tag=as0a76fcde.
     Call-ID: 595ad334-f06e97fa-3bbc8137@192.168.2.11
     <mailto:595ad334-f06e97fa-3bbc8137@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@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@70.10.163.44:5060
     <http://sip:1001@70.10.163.44:5060>  SIP/2.0.
     Max-Forwards: 64.
     To: "1001"<sip:1001@70.10.163.44
     <mailto:sip%3A1001@70.10.163.44>>;tag=as4b40d9b4.
     From:<sip:001110215178342...@sbc.voxbeam.com

<mailto:sip%3a001110215178342...@sbc.voxbeam.com>>;tag=3574513019-870807.
     Reason: Q.850;cause=16;text="".
     Call-ID: 705605f129adbf5a38b5a0ff72de8f39@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@108.59.2.133
     <mailto:sip%3Acallee@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:001110215178342...@sbc.voxbeam.com
     <mailto:sip%3a001110215178342...@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@70.10.163.44
     <mailto:sip%3A1001@70.10.163.44>>;tag=as4b40d9b4.
     From:<sip:001110215178342...@sbc.voxbeam.com

<mailto:sip%3a001110215178342...@sbc.voxbeam.com>>;tag=3574513019-870807.
     Call-ID: 705605f129adbf5a38b5a0ff72de8f39@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:001110215178342...@sbc.voxbeam.com
     <mailto:sip%3a001110215178342...@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@70.10.163.44
     <mailto:sip%3A1001@70.10.163.44>>;tag=as234a7f7d.
     To:<sip:001110215178342...@sbc.voxbeam.com
     <mailto:sip%3a001110215178342...@sbc.voxbeam.com>>.
     Contact:<sip:1001@70.10.163.44:5060
     <http://sip:1001@70.10.163.44:5060>>.
     Call-ID: 5a5fb47111cadd6146746c4446a1790c@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@lists.opensips.org<mailto:Users@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@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users