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

[Matt Jordan (JIRA)]

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

Matt Jordan commented on ASTERISK-16912:
----------------------------------------

Update from Karsten:

"I contacted vendor Aastra a few days ago, and they told me, that the
phone behaves correctly. They found out, that asterisk is sending two
re-invites in a short time frame and without waiting for an response of
the phone. According to RFCs the phone can respond with "500" and a
"Retry Later"-Header. 

So I think, asterisk should wait with the second re-invite or should act
upon the 500 with "retry later" in a way, that not terminates the call.

If You take a look at attachment "issue-18254_directmedia.txt", You'll
see in line 4364 the first INVITE sent to 192.168.10.202.
In line 4456 there is the second INVITE sent to the same phone. There
are no responses from the phone in between.
In line 4935 the 500 Error is received by asterisk."

> 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