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

[Kristian Høgh (JIRA)]

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

Kristian Høgh commented on ASTERISK-22436:
------------------------------------------

When INVITE/Replaces is accepted, the old thannel should be hung up by sending BYE.

At line 4219 in chan_sip.c (in asterisk-1.8.23.1)
        } else if (p->refer && !p->alreadygone) {
                ast_debug(3, "Finally hanging up channel after transfer: %s\n", p->callid);
                stop_media_flows(p);
                transmit_request_with_auth(p, SIP_BYE, 0, XMIT_RELIABLE, 1);
                append_history(p, "ReferBYE", "Sending BYE on transferer call leg %s", p->callid);
                sip_scheddestroy(p, DEFAULT_TRANS_TIMEOUT);

The problem is it's the other way around.
The channel we want to hang up, is referred to by another channel.

a is talking to b.
c sends INVITE/Replaces.
p->refer->refer_call on c, is set to a.
a should be hung up, but a->refer is NULL


> 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
>
>
> 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)