[Users] call transfer to asterik.. asterisk as an end point

[zm23]

>
> Hello All.
>      I am having some trouble with call transfers when asterisk is  
> the 2nd party called and I hope to benefit from your experience.
>
> I want to use asterisk for call park/pickup and have configured  
> openser to relay calls made to  ruri 700-720 to asterisk running on  
> localhost:5069
>
>
> Call flow:
>
> phone A calls  phone B  (both phones are polycom)
>
> Phone B answers
>
> then phone b user presses transfer and dials 700
>
> asterisk plays back 701 as the parking lot location
>
> phone B user presses transfer again.
>    at this time phone b is not disconnected from asterisk system
>    phone A is also connected to asterisk and hears 702 as the  
> parking lot location (as if asterisk places the user at priority 1  
> for that
> context)
>
>
>  From phone C calling 702 will connect phone C to phone A.
>
>
> This was a specific example but this transfer problem is not  
> limited to call park only. It happens any time asterisk is the  
> second party called in call transfer.
>
> Thanks in advance for your help.
>
> --
> Zahid
>
>
>
>
>
> On May 8, 2007, at 1:56 PM, Christian Schlatter wrote:
>
>
>
> I think I found out why this doesn't work as expected. After phone  
> 1 receives REFER from phone 2, it sends a new INVITE to the  
> asterisk server. This INVITE includes a Replaces: header that tells  
> the receiver (asterisk) to replace an existing SIP dialog with the  
> new one.
>
> RFC 3891 "The SIP Replaces Header", Section 3 "UAS Behavior", defines:
>
> "the UA attempts to accept the new INVITE, reassign the user  
> interface and other resources of the matched dialog to the new  
> INVITE, and shut down the replaced dialog."
>
> But your SIP trace shows that asterisk doesn't shut down the  
> replaced dialog (by sending a BYE), which is the reason why phone 2  
> does not get disconnected after hitting "transfer" the second time.
>
>
> Instead of creating a new call park slot (702) when phone 1 sends  
> the Replaces: INVITE to asterisk, asterisk should be intelligent  
> enough to figure out that this INVITE actually replaces the  
> existing SIP dialog with phone 2. And asterisk should not create a  
> new park slot 702 but directly put phone 1 on hold at park slot 701  
> and send a BYE to phone 2.
>
> Although asterisk supports the Replaces: header when used e.g. as a  
> gateway, I have some doubts that the call park/pickup  
> implementation does so too. Especially since it was designed to be  
> used in "PBX mode" where asterisk acts as B2BUA for all involved  
> call legs.
>
> Maybe this should be opened as a new feature/bug request on the  
> asterisk bug tracker. Or maybe there is a asterisk setting that  
> controls this behavior, I'm not really an asterisk expert myself ;-)
>
> --
>