thr3ads.net - asterisk users - [asterisk-users] [OpenSIPS-Users] 404 When BYE initiated by external callee [Apr 2013]

If this information is useful, please help other people find it:
Share via:

Nick Khamis

2013-Apr-09 18:23 UTC

[asterisk-users] [OpenSIPS-Users] 404 When BYE initiated by external callee

On Tue, Apr 9, 2013 at 1:22 PM, Bogdan-Andrei Iancu <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 Developerhttp://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 at 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: OpenSIPS
> 192.168.2.10: Asterisk
> 70.10.163.44: Public IP
>  108.59.2.133: Service Provider
>
>
>  U 2013/04/09 12:17:02.920454 192.168.2.10:5060 -> 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>;tag=FCA0BFC0-B585477D.
> To: <sip:15178342008 at
server.example.com;user=phone>;tag=as0a76fcde.
> Call-ID: 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>.
> 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;code=200;reason=OK
>
>  U 2013/04/09 12:17:02.939608 192.168.2.5:5060 -> 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>;tag=FCA0BFC0-B585477D.
> To: <sip:15178342008 at
server.example.com;user=phone>;tag=as0a76fcde.
> Call-ID: 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>.
> 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 -> 192.168.2.5:5060
> BYE sip:1001 at 70.10.163.44:5060 SIP/2.0.
> Max-Forwards: 64.
> To: "1001" <sip:1001 at 70.10.163.44>;tag=as4b40d9b4.
> From: <sip:001110215178342008 at
sbc.voxbeam.com>;tag=3574513019-870807.
> Reason: Q.850;cause=16;text="".
> Call-ID: 705605f129adbf5a38b5a0ff72de8f39 at 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;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
>
>  U 2013/04/09 12:17:06.989421 192.168.2.5:5060 -> 108.59.2.133:5060
> SIP/2.0 404 Not here.
> To: "1001" <sip:1001 at 70.10.163.44>;tag=as4b40d9b4.
> From: <sip:001110215178342008 at
sbc.voxbeam.com>;tag=3574513019-870807.
> Call-ID: 705605f129adbf5a38b5a0ff72de8f39 at 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 -> 108.59.2.133:5060
> INVITE sip:001110215178342008 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>;tag=as234a7f7d.
> To: <sip:001110215178342008 at sbc.voxbeam.com>.
> Contact: <sip:1001 at 70.10.163.44:5060>.
> Call-ID: 5a5fb47111cadd6146746c4446a1790c at 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 listUsers at
lists.opensips.orghttp://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.digium.com/pipermail/asterisk-users/attachments/20130409/0587e4ad/attachment.htm>

Joshua Colp

2013-Apr-09 18:31 UTC

head link

[asterisk-users] [OpenSIPS-Users] 404 When BYE initiated by external callee

Nick Khamis wrote:> 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...
Asterisk is not a SIP proxy, it does not forward or relay INVITEs. It is 
a back to back user agent. Each leg is individual.

Cheers,

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at:  www.digium.com  & www.asterisk.org

Reasonably Related Threads

Search for more maybe matching threads

asterisk users - Apr 2013 - [OpenSIPS-Users] 404 When BYE initiated by external callee

[asterisk-users] [OpenSIPS-Users] 404 When BYE initiated by external callee

[asterisk-users] [OpenSIPS-Users] 404 When BYE initiated by external callee

Reasonably Related Threads