[Jingle] Call forking

[Diana Cionoiu]

Hello Olivier,

On Mon, 12 Oct 2009, Olivier Cr?te wrote:

> On Mon, 2009-10-12 at 20:10 +0300, Diana Cionoiu wrote:
>> Hello,
>>
>> I do agree that forking is what user is expecting, but instead of doing
>> something like SIP fork, we are using inteligent jabber servers.
>> If i want to support fork, i will prefer to keep a list of user devices
>> and call each one.
>
> I agree
>
>> Let's assume i call you Justin and you have 2 devices. One device is
>> suppose to send me some early media telling me that you just went on a
>> very long kayaking trip and the second one doesn't have early media and
>> is sending ringing. Which one my client will play the important one or
>> the ringing one?
>
> Shouldn't the device that has something important to say just answer the
> call?.. Or maybe you want the user to be able to still answer from a
> different device? I guess you still have the problem if you get
> early-media ringing tone from more than one peer.

The real problem is that for example in Yate a user can have a Jingle 
device and a SIP device or multiple SIP devices including a PSTN number.

So we setup those priorities allowing the user to connect to a web 
interface and setup how him wants his devices to be called.
This allows the user to have different ringing algorithms like call 
jingle first, than sip and than pstn for example.

>> I do believe that forking it's a great idea, but implemented in the
>> server where the user can have a smart web interface to make decisions,
>> not a dumb fork in the protocol.
>
> How do you suggest implementing it in the server? Should the server just
> pick on device or should it notify both devices that there is a call?
> How exactly? Etc.

The point is to split the call in case you want to do that. And to keep 
2 call legs in the jabber server.
The major problem is not only early media, but what happends when 2 
devices are ringing for example and one it's answering. Then the other 
end which started the call will have to send a CANCEL (in SIP) to all 
the other devices. But the one that started the mess is the other Jabber 
server, so the initial Jingle client or gateway will have to implement 
the actual forking.

This is why in SIP forking it's almost always in the end implemented 
with inteligent servers, because the SIP gateways (like Yate) will have 
to implement forking while forking is the fault of a SIP proxy.


>> Regards,
>> Diana
>>
>> P.S. -1 for forking in jingle.
>>
> -- 
> Olivier Crête
> olivier.crete at collabora.co.uk

Diana