[asterisk-bugs] [JIRA] (ASTERISK-22436) No BYE to masqueraded channel on INVITE with replaces

[Jeremiah Gowdy (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-22436?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=223176#comment-223176 ] 

Jeremiah Gowdy commented on ASTERISK-22436:
-------------------------------------------

We found it.  I'll submit a diff tomorrow.  The bug is not the code Kristian has referenced above code, which triggers on the auto-destroy.  If you patch in a flag that fixes it for the auto-destroy case, all that does is hang up on the channel 30 seconds later when the scheduler gets around to it.  What we want is for the channel to be hung up after invite replaces does the masq.

To fix the bug we simply add an ast_hangup(p->refer->refer_call->owner) to the end up handle_invite_replaces after sip_pvt_lock(p) on line 24912.

I've been advised by Corey Farrell to run the test suite since it's a patch to chan_sip.c before submitting it.  So we'll do that and then make our diff for Asterisk 1.8 and Asterisk 11.  I looked at the handle_invite_replaces code in trunk and it looks a bit different so we'll have to see if the same patch works on that version.

Thanks to Alejandro Trujillo who debugged this issue with me today.

> 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
>         Attachments: asterisk-debug.log, atrujillo-asterisk1-full-log.txt, atrujillo-asterisk1-packets.pcap, atrujillo-asterisk2-full-log.txt, atrujillo-asterisk2-packets.pcap
>
>
> 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 was sent by Atlassian JIRA
(v6.2#6252)