[asterisk-bugs] [JIRA] (ASTERISK-22436) No BYE to masqueraded channel on INVITE with replaces
Peter Jannesen (JIRA)
noreply at issues.asterisk.org
Sat Feb 15 19:05:03 CST 2014
[ https://issues.asterisk.org/jira/browse/ASTERISK-22436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=215275#comment-215275 ]
Peter Jannesen commented on ASTERISK-22436:
-------------------------------------------
In a mixed environment with multiple asterisk servers and sipxecs. We have a problem with transferring a call to a asterisk server.
After analyzing SIP traces I think that asterisk is the source of the problem.
RFC 5359 2.5 Transfer Attended gives sequence of sip messages for a attended transfer. (http://www.in2eps.com/fo-sip/tk-fo-sip-service-05.html)
In our case Alice = asterisk1, Bob = Sipxecs / tel100, Carol = asterisk2
The problem is that asterisk2 is not sending a ‘BYE’ (step 22)! So Bob (sipxecs / tel100) thinks that the transfer hangs.
If Alice and Carol are on the same asterisk server, asterisk sends a ‘BYE’!
(This is the reason that the problem only happens in a mixed environment).
This is the SIP trace (using tcpdump) of asterisk2
{noformat}
12:46:30.841478 IP (tos 0xb8, ttl 62, id 30444, offset 0, flags [none], proto UDP (17), length 1425)
sipxecs1.5060 > asterisk2.5060: SIP, length: 1397
INVITE sip:290 at asterisk2;sipxecs-lineid=6 SIP/2.0
Record-Route: <sip:sipxecs1:5060;lr;sipXecs-CallDest=UNK%2CCUST;sipXecs-rs=%2Aauth%7E.%2Afrom%7EYXM3NGI1OWQzMA%60%60%21a96cde46c4d9296fc16bc8af8b566cac>
Via: SIP/2.0/UDP sipxecs1;branch=z9hG4bK-XX-6a8ay0sqEMEg7wr3PB5qUjbieQ
Via: SIP/2.0/UDP sipxecs1;branch=z9hG4bK-XX-6a84WvyYTvnLCCxmGLtOh06DCQ~o9NK7RwdzsL13kThcGLS5Q
Via: SIP/2.0/UDP sipxecs1;branch=z9hG4bK-XX-6a7bICVjhq0LXNSxCLRsexUzGg~nbM4RjAJQR56Dqn3zdL5TQ
Via: SIP/2.0/UDP 10.31.84.41:5060;branch=z9hG4bK1a7bd0b9;rport=5060
Max-Forwards: 65
From: "PJannese" <sip:Unknown at 10.31.84.41>;tag=as74b59d30
To: <sip:290 at sipxecs1:5060>
Contact: <sip:Unknown at 10.31.84.41:5060;x-sipX-nonat>
Call-Id: 06bc46fd27fb13e447d28a6e60f57fd8 at 10.31.84.41:5060
Cseq: 102 INVITE
User-Agent: FPBX-2.9.0(1.8.17.0)
Date: Sat, 15 Feb 2014 11:46:30 GMT
Replaces: 7dda4502-d5ea9303-64f9de18 at 192.168.202.228;to-tag=as5e0e9abc;from-tag=D6F4F7B0-F96CE149
Require: replaces
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 237
Expires: 7200
v=0
o=root 1823065412 1823065412 IN IP4 10.31.84.41
s=Asterisk PBX 1.8.17.0-3
c=IN IP4 10.31.84.41
t=0 0
m=audio 15752 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
12:46:30.841958 IP (tos 0x60, ttl 64, id 5956, offset 0, flags [none], proto UDP (17), length 945)
asterisk2.5060 > sipxecs1.5060: SIP, length: 917
SIP/2.0 100 Trying
Via: SIP/2.0/UDP sipxecs1;branch=z9hG4bK-XX-6a8ay0sqEMEg7wr3PB5qUjbieQ;received=sipxecs1;rport=5060
Via: SIP/2.0/UDP sipxecs1;branch=z9hG4bK-XX-6a84WvyYTvnLCCxmGLtOh06DCQ~o9NK7RwdzsL13kThcGLS5Q
Via: SIP/2.0/UDP sipxecs1;branch=z9hG4bK-XX-6a7bICVjhq0LXNSxCLRsexUzGg~nbM4RjAJQR56Dqn3zdL5TQ
Via: SIP/2.0/UDP 10.31.84.41:5060;branch=z9hG4bK1a7bd0b9;rport=5060
Record-Route: <sip:sipxecs1:5060;lr;sipXecs-CallDest=UNK%2CCUST;sipXecs-rs=%2Aauth%7E.%2Afrom%7EYXM3NGI1OWQzMA%60%60%21a96cde46c4d9296fc16bc8af8b566cac>
From: "PJannese" <sip:Unknown at 10.31.84.41>;tag=as74b59d30
To: <sip:290 at sipxecs1:5060>
Call-ID: 06bc46fd27fb13e447d28a6e60f57fd8 at 10.31.84.41:5060
CSeq: 102 INVITE
Server: FPBX-2.9.0(1.8.17.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: <sip:290 at asterisk2:5060>
Content-Length: 0
12:46:30.842099 IP (tos 0x60, ttl 64, id 5957, offset 0, flags [none], proto UDP (17), length 1226)
asterisk2.5060 > sipxecs1.5060: SIP, length: 1198
SIP/2.0 200 OK
Via: SIP/2.0/UDP sipxecs1;branch=z9hG4bK-XX-6a8ay0sqEMEg7wr3PB5qUjbieQ;received=sipxecs1;rport=5060
Via: SIP/2.0/UDP sipxecs1;branch=z9hG4bK-XX-6a84WvyYTvnLCCxmGLtOh06DCQ~o9NK7RwdzsL13kThcGLS5Q
Via: SIP/2.0/UDP sipxecs1;branch=z9hG4bK-XX-6a7bICVjhq0LXNSxCLRsexUzGg~nbM4RjAJQR56Dqn3zdL5TQ
Via: SIP/2.0/UDP 10.31.84.41:5060;branch=z9hG4bK1a7bd0b9;rport=5060
Record-Route: <sip:sipxecs1:5060;lr;sipXecs-CallDest=UNK%2CCUST;sipXecs-rs=%2Aauth%7E.%2Afrom%7EYXM3NGI1OWQzMA%60%60%21a96cde46c4d9296fc16bc8af8b566cac>
From: "PJannese" <sip:Unknown at 10.31.84.41>;tag=as74b59d30
To: <sip:290 at sipxecs1:5060>;tag=as06c41dcb
Call-ID: 06bc46fd27fb13e447d28a6e60f57fd8 at 10.31.84.41:5060
CSeq: 102 INVITE
Server: FPBX-2.9.0(1.8.17.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: <sip:290 at asterisk2:5060>
Content-Type: application/sdp
Content-Length: 237
v=0
o=root 2079365558 2079365558 IN IP4 asterisk2
s=Asterisk PBX 1.8.17.0-3
c=IN IP4 asterisk2
t=0 0
m=audio 11386 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
12:46:30.884290 IP (tos 0xb8, ttl 62, id 30445, offset 0, flags [none], proto UDP (17), length 555)
sipxecs1.5060 > asterisk2.5060: SIP, length: 527
ACK sip:290 at asterisk2:5060 SIP/2.0
Via: SIP/2.0/UDP sipxecs1;branch=z9hG4bK-XX-6a91ST2tBteB34L13142KZ7mDA
Via: SIP/2.0/UDP 10.31.84.41:5060;branch=z9hG4bK542179db;rport=5060
Max-Forwards: 69
From: "PJannese" <sip:Unknown at 10.31.84.41>;tag=as74b59d30
To: <sip:290 at sipxecs1:5060>;tag=as06c41dcb
Contact: <sip:Unknown at 10.31.84.41:5060;x-sipX-nonat>
Call-Id: 06bc46fd27fb13e447d28a6e60f57fd8 at 10.31.84.41:5060
Cseq: 102 ACK
User-Agent: FPBX-2.9.0(1.8.17.0)
Content-Length: 0
Date: Sat, 15 Feb 2014 11:46:30 GMT
.....
12:47:27.493215 IP (tos 0xb8, ttl 62, id 30447, offset 0, flags [none], proto UDP (17), length 904)
sipxecs1.5060 > asterisk2.5060: SIP, length: 876
BYE sip:290 at asterisk2:5060 SIP/2.0
Via: SIP/2.0/UDP sipxecs1;branch=z9hG4bK-XX-6ac0ubbst47evIg`IrWHGf1Bgw
Via: SIP/2.0/UDP 192.168.202.228;branch=z9hG4bK8ab3cacb4B715980
From: "Peter Test1" <sip:301 at voip.XXXX.local>;tag=D6F4F7B0-F96CE149
To: <sip:290 at voip.XXXX.local;user=phone>;tag=as5e0e9abc
Cseq: 3 BYE
Call-Id: 7dda4502-d5ea9303-64f9de18 at 192.168.202.228
Contact: <sip:301 at 192.168.202.228;x-sipX-nonat>
User-Agent: PolycomSoundPointIP-SPIP_450-UA/3.2.6.0314
Accept-Language: nl-nl,nl;q=0.9,en;q=0.8
Max-Forwards: 69
Content-Length: 0
Date: Sat, 15 Feb 2014 11:47:27 GMT
12:47:27.493398 IP (tos 0x60, ttl 64, id 5959, offset 0, flags [none], proto UDP (17), length 603)
asterisk2.5060 > sipxecs1.5060: SIP, length: 575
SIP/2.0 481 Call leg/transaction does not exist
Via: SIP/2.0/UDP sipxecs1;branch=z9hG4bK-XX-6ac0ubbst47evIg`IrWHGf1Bgw;received=sipxecs1;rport=5060
Via: SIP/2.0/UDP 192.168.202.228;branch=z9hG4bK8ab3cacb4B715980
From: "Peter Test1" <sip:301 at voip.XXXX.local>;tag=D6F4F7B0-F96CE149
To: <sip:290 at voip.XXXX.local;user=phone>;tag=as5e0e9abc
Call-ID: 7dda4502-d5ea9303-64f9de18 at 192.168.202.228
CSeq: 3 BYE
Server: FPBX-2.9.0(1.8.17.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0
{noformat}
> No BYE to masqueraded channel on INVITE with replaces
> -----------------------------------------------------
>
> Key: ASTERISK-22436
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-22436
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Channels/chan_sip/General
> Affects Versions: 1.8.23.1
> Reporter: Eelco Brolman
> Assignee: Rusty Newton
>
> Consider the flow as in http://www.in2eps.com/fo-sip/tk-fo-sip-service-05.html. Carol is the asterisk server in this case, Alice and Bob 2 (external) sip phones (i.e. NOT registered with asterisk). Asterisk acts for example as an application server. Bob wants to attended transfer Alice to this application.
> When Bob refers Alice to Carol (asterisk), Carol (asterisk) correctly accepts the invite, and masquerades the channels into the new Invited channel.
> The original channel to Bob becomes a Zombie, which is Hangup (see logging), but Asterisk fails to send out the BYE to Bob (message 22 in http://www.in2eps.com/fo-sip/tk-fo-sip-service-05.html#fig22).
> This result in Bob assuming the transfer is not complete yet, and keeping the call as "on hold" on his phone.
> Any thought on this issue?
> {code}
> [Sep 2 14:11:33] DEBUG[7190] chan_sip.c: Trying to put 'SIP/2.0 200' onto UDP socket destined for 172.29.19.13:5060
> [Sep 2 14:11:33] DEBUG[7190] channel.c: Planning to masquerade channel SIP/alice-00000152 into the structure of SIP/bob-0000014f
> [Sep 2 14:11:33] DEBUG[7190] channel.c: Done planning to masquerade channel SIP/alice-00000152 into the structure of SIP/bob-0000014f
> [Sep 2 14:11:33] DEBUG[7190] channel.c: Putting channel SIP/alice-00000152 in alaw/alaw formats
> [Sep 2 14:11:33] DEBUG[7190] chan_sip.c: SIP Fixup: New owner for dialogue 2063187328: SIP/alice-00000152 (Old parent: SIP/bob-0000014f<ZOMBIE>)
> [Sep 2 14:11:33] DEBUG[7190] chan_sip.c: SIP Fixup: New owner for dialogue 54c78f06-534c5fb7-9fe652e0 at 172.30.19.102: SIP/bob-0000014f<ZOMBIE> (Old parent: SIP/alice-00000152)
> [Sep 2 14:11:33] VERBOSE[7190] chan_sip.c: Scheduling destruction of SIP dialog '54c78f06-534c5fb7-9fe652e0 at 172.30.19.102' in 6400 ms (Method: ACK)
> [Sep 2 14:11:33] DEBUG[7190] chan_sip.c: Session timer stopped: 68528 - 54c78f06-534c5fb7-9fe652e0 at 172.30.19.102
> [Sep 2 14:11:33] DEBUG[7190] channel.c: Done Masquerading SIP/alice-00000152 (6)
> [Sep 2 14:11:33] DEBUG[7190] res_rtp_asterisk.c: Not changing SSRC since we haven't sent any RTP yet
> [Sep 2 14:11:33] DEBUG[7190] channel.c: Hanging up zombie 'SIP/bob-0000014f<ZOMBIE>'
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the asterisk-bugs
mailing list