[Jingle] Call forking
diana-liste at null.ro
Tue Oct 13 10:53:42 CDT 2009
On Mon, 12 Oct 2009, Olivier Cr?te wrote:
> On Mon, 2009-10-12 at 20:10 +0300, Diana Cionoiu wrote:
>> 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.
>> P.S. -1 for forking in jingle.
> Olivier Crête
> olivier.crete at collabora.co.uk
More information about the Jingle