[asterisk-bugs] [JIRA] (ASTERISK-23006) Fake NOTIFY in blind call transfer
Walter Doekes (JIRA)
noreply at issues.asterisk.org
Mon Dec 16 08:01:04 CST 2013
[ https://issues.asterisk.org/jira/browse/ASTERISK-23006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Walter Doekes updated ASTERISK-23006:
-------------------------------------
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
was:
Hi
I am having an issue with call transfer.
This is how the call transfer call flow looks like.
Asterisk does:
U1(SIP) Asterisk U2(SIP) U3(SIP)
| | | | |
---INVITE------>| | |
| |---INVITE----->| |
| |<---200 OK-----| |
| |----ACK------->| |
|-----REFER------->| | |
|<---202 Accepted--| | |
|<------NOTIFY-----| | |
| w/ 183 Ringing | | |
|<------NOTIFY-----| | |
| w/ 200 OK | | |
| | |
| |------------SETUP-----------|
| | |
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
> 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
>
> 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
More information about the asterisk-bugs
mailing list