Re: [MMUSIC] Comment on SIP Trickle ICE based on INFO draft

[Christer Holmberg <[e-mail]>]

Hi,

I have tried to understand the whole issue discussed here, with little success :)

So, rather than trying to come up with a solution, I think we first need to agree on some basic assumptions.

If we claim that Trickle ICE has no impact on the SDP O/A state, then:

1) There should be no need to figure out whether an INFO is sent before an UPDATE; and
2) There should be no need to include the o= line, or any other information that binds the INFO to a specific SDP O/A state.

Instead, Trickle ICE is only a mechanism to transport candidate information from one endpoint to another. Endpoints may of course add those candidates to subsequent Offer/Answers.


Regards,

Christer



________________________________________
From: Emil Ivov [[e-mail]]
Sent: Thursday, 27 March 2014 1:07 AM
To: Parthasarathi R
Cc: 'mmusic'; Christer Holmberg; 'Enrico Marocco (TiLab)'
Subject: Re: [MMUSIC] Comment on SIP Trickle ICE based on INFO draft

On 26.03.14, 19:44, Parthasarathi R wrote:
>  > > This race condition is very much possible during
>  > > early
>  > > dialog scenarios with UPDATE.
>  > >
>  > > Could you please explain how SIP trickle ICE using INFO works for
>  > >
>  > > 1) UPDATE from remote before Trickle ICE is completed
>
> This is analogous to an UPDATE that is received before regular 5245 ICE
> processing has completed.
>
> <Partha> No, in case UDPATE before the offer is completed, 491 response
> will send out whereas it will not happen in case of INFO </Partha>

I think you might be confusing "before ICE processing has completed" and
"before O/A has completed"

An UPDATE that is received while "vanilla ICE processing is in progress"
would have exactly the same effect as an UPDATE received while "trickle
ICE processing is in progress". If O/A has completed then the UPDATE
will NOT cause a 491 in either case.

>  > >     a) INVITE from local
>  > >     b) 183 session progress from remote
>  > >     c) PRACK from local
>  > >     d) INFO from local (relay candidates)
>  > >     e) UPDATE from remote
>  > >
>  > > Here, the remote has to consider whether INFO belongs to UPDATE or
>  > > INVITE as
>  > > it is possible for INFO to reach before 200 OK for UPDATE as well in
>  > > the
>  > > same sequence.
>
> And CSeq headers wouldn't help here because ....?
>
>  > > Also, RFC 2976
>
> which FWIW is obsoleted by RFC6086
>
> <Partha> Thanks..I still majorly interwork with RFC 2976 implementation
> :-( but please note that RFC 6086 does not change much in these SIP
> dialog or session aspects. The exact snippet of RFC 6086 is as follows:
>
> “Note that the INFO method is not used to update characteristics of a
>     SIP dialog or session, but to allow the applications that use the SIP
>     session to exchange information (which might update the state of
>     those applications).”

Trickle ICE does not update the characteristics of a SIP dialog and I
don't believe it violates the above in any way.

>  > > " - The extensions that use the INFO message MUST NOT rely on the
>  > >      INFO message to do anything that effects the SIP call state or the
>  > >      state of related sessions."
>
> And I don't believe that it does.
>
> <Partha> No, it is not possible to implement this draft without impact
> offer/answer state machine </Partha>

Please provide an example where you think it actually breaks something.
(It might be worth waiting until we submit the new version, which should
probably clarify a few things).

>  > > 2) Trickle ICE INFO with serial forking
>
> INFO requests are sent within a dialog. They will go through the prong
> associated with that dialog and would not be forked.
>
> <Partha> IOW, Trickle ICE INFO will be buffered till 18x response is
> received. So, INFO has no much advantage compare to UPDATE except for
> the non-reliable response scenario.

No advantage? INFOs can be send in both directions and arrive completely
asynchronously without ever causing glare or without having to worry
whose turn it is to send an offer or an answer because you need to
piggyback candidates on top of it.

We've been through this exact same argument several times already, you
haven't pointed out any flaws with this logic so I can't see a reason
why you keep coming back to it.

You claim you are worried about needing to modify the offer/answer state
machine in your implementation, but that is a very strange argument
since that implementation would be much more heavily impacted if you
were to try and trickle with offers and answers.

I think the source of the confusion might be the fact that the draft is
currently in a relatively poor state, which is my fault, and I am
hopeful that you may find many of your answers in the next version.

Emil

--
https://jitsi.org