Re: [Stox] core issues

[Daniel-Constantin Mierla <[e-mail]>]

On 8/21/13 9:03 PM, Paul Kyzivat wrote:
> On 8/21/13 3:17 AM, Daniel-Constantin Mierla wrote:
>>
>> On 8/21/13 1:50 AM, Paul Kyzivat wrote:
>
>>> You can make it sound easy by ignoring the details, but at the expense
>>> of quality of implementation.
>>>
>>> The problem is that you may get multiple early dialogs, with media. At
>>> that time you don't know which one will answer first. So what do you
>>> do with the media while awaiting a 2xx?
>>>
>>> You can't "pick one" without the risk that it is the wrong one.
>>>
>>> You can "pick one" and switch it if it turns out to be the wrong one.
>>> But unless you relay the media the xmpp side will see a change, and so
>>> there must be some plan for how that is handled.
>> My comments were for the remark related to multiple 200ok, I haven't
>> said sending BYE for additional early dialogs.
>
> They are tightly connected issues.

If you just look at parallel forking, but handling of them is totally 
different.

>
>> For multiple early dialogs, the gateway has to maintain all of them
>> until a 200ok. It's also implementation decision which of early media
>> streams is sent to xmpp/jingle (again, it looks like it's mostly the
>> first one from experiences out there).
>
> This is straightforward if the GW terminates/relays media.
> But that is a cost.
>
> A signaling-only GW can't easily or thoroughly prevent the multiple 
> early media streams from reaching the xmpp client. (It may be able to 
> send updates to all but one to stop their media, but that takes some 
> time, and not all will support it.)
>
> So either you mandate that the GW terminate the media, or else you 
> have to acknowledge the situation and warn the xmpp client to be 
> prepared.
 From what's being repeated here, the idea is not to change existing 
protcols by enforcing new behaviour/support for features. It would be 
easier and more logical if changes can be made in both sides, but again, 
it's out of defined scope. Thus I guess the gateway should do stripping 
of what is not supported on the other side.

Since the issue is for calls from xmpp to sip, perhaps the multiple 
early media streams issue can be overcome by initiating the SIP side 
call with INVITE without SDP. The gateway needs to hold the SDP for ACK, 
but that should be no problem as I guess it has to be transaction 
stateful at least.

Daniel

-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda