Call transfer - call replaced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Nov 26, 2008 at 5:16 AM, Sasa Coh <sasacoh at gmail.com> wrote:

> Hi Gang!
>
> On Tue, Nov 25, 2008 at 5:22 PM, Gang Liu <gangban.lau at gmail.com> wrote:
>
>> As I remember, when one sip UA got REFER request, it will make a INVITE to
>> URI which at Refer-To header. And this INVITE will include replaces header
>> which has Call-ID, from-tag, to-tag for existing call. So on_call_replaced
>> callback is called at another UA(transfer target), not UA which got REFER.
>>
>
> Yes, that's all true. But when BYE request is received by UA (the one which
> got REFER) it destroys the "first" call and since my application knows
> nothing about the new session (it's handled by pjsip internally) it releases
> the one and only session. If the application would be notified that the
> "old" session was "replaced" by the new one it would change the indices
> (call ids) and continue normally. Ok, I (mis)used on_call_replaced because
> it did the job and it was only a minor change. Of course I'd be happier if
> it's possible without code changes.
>
>
pjsua didn't provide such api.
It has pjsua_call_xfer(), pjsua_call_xfer_replaces() function for transfor
to support blind/attend transfer.
It has callback on_call_transfer_status to let transfor can monitor result.
It has callback on_call_replace_request() and on_call_replaced() to for
transfer target.


>> Normally the transfor will drop the call after he know transfer is
>> finished(GOT NOTIFY).
>> So call on_call_replaced inside on_call_transfer is a wrong way because it
>> cause transfor can't know the transfer action result.
>> BTW, I didn't use pjsua api before. Just a guess from SIP transfer flow.
>>
>
> You're right, maybe the on_call_transfered is not the right place. But I
> think the application still has to be notified about call being replaced -
> somewhere after successful new session creation and before BYE request from
> transfer initiator. Any suggestions?
>
I think you can use on_call_state() callback to monitor transfer status at
UA which got REFER to know whether old call is disconnected.


>
> thanks & kind regards,
> sasa
>
>
>> regards,
>> Gang
>>
>> On Tue, Nov 25, 2008 at 9:09 PM, Sasa Coh <sasacoh at gmail.com> wrote:
>>
>>> Hi Benny!
>>> I'm testing some scenarios for a call transfer feature. In one case my
>>> application didn't respond correctly (BYE releases the "replaced" call). I
>>> looked into the code and found out that when the REFER is received an
>>> on_call_transfer_request callback is called but I'd need a on_call_replaced
>>> since it contains old and new call ids.
>>>
>>> For a test I put a call to
>>> pjsua_var.ua_cfg.cb.on_call_replaced(existing_call->index, new_call) into
>>> the end of on_call_transfered (pjsua_call.c). And this was enough for my
>>> application to change the call ids and handle subsequent SIP requests
>>> appropriately.
>>>
>>> What do you think? Is there any other way (in pjsua_app.c level) to let
>>> the application know about the call is being replaced?
>>>
>>> Thanks & Kind regards,
>>> Sasa
>>>
>>> _______________________________________________
>>> Visit our blog: http://blog.pjsip.org
>>>
>>> pjsip mailing list
>>> pjsip at lists.pjsip.org
>>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>>
>>>
>>
>> _______________________________________________
>> Visit our blog: http://blog.pjsip.org
>>
>> pjsip mailing list
>> pjsip at lists.pjsip.org
>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>>
>>
>
> _______________________________________________
> Visit our blog: http://blog.pjsip.org
>
> pjsip mailing list
> pjsip at lists.pjsip.org
> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20081126/5981d98d/attachment.html>


[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux