[asterisk-bugs] [JIRA] (ASTERISK-23006) Fake NOTIFY in blind call transfer

[Matt Jordan (JIRA)]

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

Matt Jordan commented on ASTERISK-23006:
----------------------------------------

Well... that's actually known about.

Asterisk in {{chan_sip}} has always sent a fake NOTIFY request during a transfer. It isn't smart enough to be able to watch the progress from the transfer and relay that back as NOTIFY requests.

We've managed to fix this in {{chan_pjsip}} in Asterisk 12. It actually is aware of the state of the blind transfer and conveys that to the transferer as the state changes. It's able to do this by virtue of being built on {{pjsip}} (which lent itself well to having an actual transaction state engine) and by Stasis, which can inform things of the progress of channels. All of this is possible due to the work that was done in 12 and really can't be used or backported in earlier versions.

I'm not sure how feasible it would be to try and hack this into {{chan_sip}}. I'd say it's very non-trivial, and prone to creating a lot of problems. As it is, I'd prefer to not try and change this behaviour in Asterisk 1.8/11.
                
> Fake NOTIFY in blind call transfer 
> -----------------------------------
>
>                 Key: ASTERISK-23006
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-23006
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_sip/Transfers
>    Affects Versions: 11.4.0
>         Environment: Debian lenny
> x86_64
>            Reporter: NITESH BANSAL
>            Assignee: NITESH BANSAL
>
> Hi
> I am having an issue with call transfer.
> This is how the call transfer call flow looks like. 
> Asterisk does:
> {noformat}
> U1(SIP)   Asterisk      U2(SIP)     U3(SIP)
> |         |       |       |            |
> ---INVITE------>|         |            | 
> |         |---INVITE----->|            |
> |         |<---200 OK-----|            |
> |         |----ACK------->|            |
> |-----REFER------->|      |            |
> |<---202 Accepted--|      |            |  
> |<------NOTIFY-----|      |            | 
> | w/ 183 Ringing   |      |            |
> |<------NOTIFY-----|      |            |
> | w/ 200 OK        |      |            |
> |         |                            |
> |         |------------SETUP-----------| 
> |         |                            |  
> {noformat}
> Asterisk notifies the transferer that the blind transfer is ringing and was performed successfully although it does not even have tried to contact the target. I would expect that NOTIFY with sipfrag 183/200 is only sent when the PROGRESS/CONNECT is received from the transfer target.
> This is becoming an interop issue for some of our customers, they are pushing for RFC compliance (http://tools.ietf.org/html/rfc5359#section-2.4) 
> call transfer behaviour.
> Awaiting your feedback on the same.
> Regards,
> Nitesh Bansal

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