Re: [Stox] core issues

[Paul Kyzivat <[e-mail]>]

On 8/21/13 3:28 PM, Daniel-Constantin Mierla wrote:
>
> 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.

That is indeed one way to solve the problem. But it will also be 
necessary to *not* support 100rel, or else the problem can still arise.

	Thanks,
	Paul