[Home]

Summary:ASTERISK-23006: Fake NOTIFY in blind call transfer
Reporter:NITESH BANSAL (nbansal)Labels:
Date Opened:2013-12-16 04:18:13.000-0600Date Closed:2013-12-18 10:53:07.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/Transfers
Versions:11.4.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Debian lenny x86_64Attachments:
Description: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
Comments:By: Rusty Newton (rnewton) 2013-12-17 11:43:08.457-0600

Hi Nitesh!

Please attach a pcap of the scenario, along with an Asterisk debug log for the same call (that is, VERBOSE, DEBUG messages both set to 5 or above and showing up in the log)

Grab all that when testing using the latest SVN of your Asterisk branch if possible.

Attach a sanitized sip.conf and anything else relevant to the configuration.
By: Matt Jordan (mjordan) 2013-12-17 15:20:02.533-0600

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.
By: NITESH BANSAL (nbansal) 2013-12-18 03:14:08.521-0600

Thanks for your feedback Matt.
I'll keep your suggestion in mind when trying to find a solution for this customer.

Regards,
Nitesh
By: Rusty Newton (rnewton) 2013-12-18 10:53:07.346-0600

Based on Matt's comments it looks like this request would be an improvement and not a bug. Since most SIP new development work is going towards PJSIP/chan_pjsip and we don't have a patch for this behavior in chan_sip, then we'll close this out as not a bug. If someone decides they want to work on improving this behavior in chan_sip we can open it up again later on.