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

Tue Apr 9 19:05:50 CEST 2013

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: 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20130409/8e1e4bce/attachment.htm>