[asterisk-bugs] [JIRA] Commented: (ASTERISK-16912) Attended transfer failure

[Henning Holtschneider (JIRA)]

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

Henning Holtschneider commented on ASTERISK-16912:
--------------------------------------------------

RFC 3261 says that you have to wait for an INVITE message to be confirmed by the SIP UA before you may send another INVITE within the same dialog.

The way I understand chan_sip's state machine, this would not be trivial to achieve. chan_sip lacks a way to properly track the responses to the INVITE messages once the channel is in an established state.

I'm not sure if Asterisk would be allowed to reject the fatal 500 error with a retry later header.

Aastra is right in saying that Asterisk is doing something wrong and their phone behaves correctly. However, this does not explain why the phone only responds with the 500 error if a P-Asserted-Identity header is present. The phone seems to be less strict about non-ACK'ed INVITE messages under certain conditions.

> Attended transfer failure
> -------------------------
>
>                 Key: ASTERISK-16912
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-16912
>             Project: Asterisk
>          Issue Type: Bug
>          Components: Channels/chan_sip/Transfers
>            Reporter: Karsten Wemheuer
>         Attachments: issue-18254_directmedia.txt, issue-18254_nodirectmedia.txt, issue-att-transfer.log
>
>
> I set up an asterisk system (1.8 SVN revision 293886 checked out today) and do some testing in a SIP only environment.
> With three phones doing attended transfer I have some weird behaviour.
> phone1 calls phone2, phone2 sets call on hold and calls phone3. Then phone2 is doing an attended transfer. With Snom phones there seems to be no problem. With aastra phones the call is terminated on one side only. In the described scenario phone3 seems to be connected, whereas phone1 is idle (see issue-att-transfer.log). From Asterisk's point of view both legs are terminated.
> It doesn't matter, who is doing the transfer. If the original call (in the above senario phone1) is doing the transfer, there is also one party hung up while the other seems to be connected (on the phone side).
> This might be related to ASTERISK-16847, but the behaviour is different, so I make up a new ticket. The workaround fix from ASTERISK-16847 doesn't work (the logfile attached is from an original svn checkout, no patches applied).

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira