Thanks,
Trevor Benson, Network Engineer
A1 Networks
Voice: 707-703-1041
For support issues please email supp...@a-1networks.com or call 707-703-1050
On Nov 29, 2012, at 10:41 PM, Trevor L Benson <tben...@a-1networks.com> wrote:
>
>
> On Nov 29, 2012, at 10:20 PM, Mircea Carasel <mirc...@ezuce.com> wrote:
>> Hi Alan,
>>
>> We had an attempt to implement call transfering through callcontroller, but
>> unfortunatelly this does not work properly. We will give another try post
>> 4.6 to make this working properly
>>
>> Here is how it should be done to accomplish a transfer (does not properly
>> work)
>>
>> 1)user1 calls user2 through callcontroller using INVITE
>> callcontroller/user1/user2?sipMethod=INVITE
>> (http://wiki.sipfoundry.org/pages/viewpage.action?pageId=4882956)
>> 2)user 1 would like to transfer the call to user3 so that user2 and user3 to
>> start talking:
>> /callcontroller/user1/user2?target=user3&action=transfer&agent=user1
>> 3)original call between user1 and user2 should automatically drop
>>
>> However what you can do is to just place a call from user1 to user 3 and the
>> original call between user1 and user2 will be put on hold:
>> This does not respect SIP transfer specifications, but does work, and maybe
>> it is useful to you:
>> 1)user1 calls user 2 through callcontroller using REFER
>> /callcontroller/user1/user2
>> 2)user1 places a call between user2 and user3
>> callcontroller/user2/user3?agent=user1&timeout=30&isForwardingAllowed=true
>> 3)original call between user1 and user2 will be put on hold
>
> Mircea,
>
> Does the difference between having two calls between internal users
> directly between endpoints, and a call with one internal user connected via
> sipXbridge to an external number make any difference in the ability to
> transfer? For the specific scenario we are looking at it would be almost
> entirely calls between an internal user and an external number via the
> sipXbridge.
>
Forgot to ask if you were referring to sipX 4.4 in general does not support
the RFC 3725 Call Flow IV from the wiki? Or was this comment specific to the
sipX 4.6 release?
I kind of made the assumption that (in sipX 4.4) RFC 3725 could have been
handled by the sipXbridge and that with an internal extension and external call
on the bridge this would function normally by asking the sipXbridge to handle
the "transfer" from one internal extension to another internal extension. It
appears that if the call was through the sipXbridge this would be a logical
point to handle the transfers from a callcontroller perspective as the
sipXbridge provides the B2BUA required for Call Flow IV, it just happens to
handle the media session in addition to the signaling. It would obviously have
its limitations in any call that the sipXbridge was not handling signaling for
would not allow transfer. I could see that an internal to internal call could
fail transfers via callcontroller if the endpoints normally take over the
signaling and media directly after talking to sipXproxy/registrar. So internal
calls would be problematic between endpoints handling their own signaling and
media without a separate callcontroller.
I still think this might provide most people with a viable solution if the
limitations were outlined in the wiki as to what type of calls could or could
not be transferred. Obviously if an entirely separate call controller is
created and the URI Parameters provide a way to request the callcontroller stay
in the path this would be a waste of effort.
Thoughts?
Thanks,
Trevor Benson
_______________________________________________
sipx-users mailing list
sipx-users@list.sipfoundry.org
List Archive: http://list.sipfoundry.org/archive/sipx-users/
