Subject: [MMUSIC] Comment on SIP Trickle based on INFO draft

From: "Parthasarathi R" <[email-masked]>
Date: Tue, 18 Mar 2014 05:25:07 +0530

Hi all,

SIP Trickle INFO is projected as the back channel for collecting the
candidates in IETF-89 MMUSIC meeting. Unfortunately, it impacts Offer/answer
(RFC 3264) in case one another offer/answer started before SIP trickle INFO
is completed. The race condition between second offer/answer and earlier SIP
trickle INFO is not stated in the draft-ivov-mmusic-trickle-ice-sip. I have
explained those issues in
http://www.ietf.org/mail-archive/web/mmusic/current/msg12666.html and no
reply from you folks. 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

    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. Also, RFC 2976 clarifies that 

" - 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."

But SIP Trickle ICE state is depend upon the "state of related sessions" as
UPDATE would have change the state in the remote.   

2) Trickle ICE INFO with serial forking

  a) INVITE from local
  b) INVITE is forked by proxy to first remote destination
  c) 100 trying is reaching local
  d) INFO with Trickle ICE from local
  e) INFO is forward by proxy to first remote destination
  f) INVITE is forked by proxy to second remote destination
  g) Whether INFO has to be forked?

It is not mentioned in the draft whether INFO has to be forked to the second
remote destination as well. Could you please explain the expect behavior for
this scenario.

Thanks
Partha

---

From: "Parthasarathi R" <[email-masked]>
Date: Sun, 23 Mar 2014 16:29:53 +0530

Hi all,

The below mentioned UPDATE overlap with INFO usecase and INFO forking
scenario has to be clarified before adopting this draft as WG item as I'm
not seeing any solution with INFO based mechanism.

Thanks
Partha

> -----Original Message-----
> From: mmusic [mailto:[email-masked]] On Behalf Of
> Parthasarathi R
> Sent: Tuesday, March 18, 2014 5:25 AM
> To: 'Emil Ivov'; 'Enrico Marocco (TiLab)'; 'Christer Holmberg'
> Cc: [email-masked]
> Subject: [MMUSIC] Comment on SIP Trickle based on INFO draft
> 
> Hi all,
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Emil Ivov <[email-masked]>
Date: Sun, 23 Mar 2014 12:54:27 +0100

Hello,

On 23 Mar 2014 12:00 PM, "Parthasarathi R" <[email-masked]>
wrote:
> > is completed.

I am still not sure why you think that and exactly what you have in mind.

> > The race condition between second offer/answer and
> > earlier SIP
> > trickle INFO is not stated in the draft-ivov-mmusic-trickle-ice-sip.

No, indeed it hasn't but it has been mentioned in discussions many times: a
new offer answer would generally cause an ICE restart.

> > I
> > have
> > reply from you folks.

I am sorry, I don't understand the mail you point to above. It says it
raises issues in 3264 situations but then refers to BUNDLE and UPDATEs.

If the scenario below is the one you are worried about, then I'll answer
there.

> > This race condition is very much possible during
> > early

This is analogous to an UPDATE that is received before regular 5245 ICE
processing has completed.

> > same sequence.

And CSeq headers wouldn't help here because ....?

> > Also, RFC 2976

which FWIW is obsoleted by RFC6086

> > clarifies that

And I don't believe that it does.

> > UPDATE would have change the state in the remote.

I am not sure what you are saying or why it is a problem.

> > 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.

> >   d) INFO with Trickle ICE from local

No, this should't happen. We can't send the INFO before we have a dialog.

> >   g) Whether INFO has to be forked?

See above.

> > remote destination as well. Could you please explain the expect

I think the above commencts should answer your questions. We will make sure
we add those as clarifications before our next submission (hopefully as a
WG document)

Emil

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 23 Mar 2014 14:01:18 -0400

One comment

> And CSeq headers wouldn't help here because ....?

IIUC, the question is whether the remote can tell whether the INFO was 
sent before or after receiving the UPDATE.

CSeq values are independent in each direction. So they are useless to 
answer this question. Something else will be needed.

	Thanks,
	Paul

---

From: Emil Ivov <[email-masked]>
Date: Sun, 23 Mar 2014 19:53:00 +0100

> answer this question. Something else will be needed.

OK, I see. Then the easiest way to tackle this would be to mandate that 
all INFOs contain the ICE ufrag and pwd of the offer/answer they are 
pertaining to.

Does anyone see a problem with that?

Emil

-- 
https://jitsi.org

---

From: "Parthasarathi R" <[email-masked]>
Date: Wed, 26 Mar 2014 07:05:28 +0530

Hi Emil,

<snip> > OK, I see. Then the easiest way to tackle this would be to mandate
that
> Does anyone see a problem with that?
</snip>

I guess that your intention is to pass the corresponding Origin ("o") line
in each INFO message by which INFO will be identified for the corresponding
SDP by which the ICE candidates are passed. I'm saying so as there is no
purpose of passing ICE ufrag & pwd in each INFO message 

Thanks
Partha 

> From: mmusic [mailto:[email-masked]] On Behalf Of Emil Ivov
> Sent: Monday, March 24, 2014 12:23 AM
> To: Paul Kyzivat; [email-masked]
> Subject: Re: [MMUSIC] Comment on SIP Trickle ICE based on INFO draft
> 
> 
> 
> >>  > > 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.
> >>

---

From: Emil Ivov <[email-masked]>
Date: Wed, 26 Mar 2014 06:52:48 +0100

On 26 Mar 2014 2:35 AM, "Parthasarathi R" <[email-masked]>
wrote:
> SDP by which the ICE candidates are passed.

No, that wasn't my intention but sending the origin line would also work
indeed. Thanks for pointing it out!

We could actually make that a requirement of the sdpfrag format.

--sent from my mobile

> I'm saying so as there is no

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Mar 2014 10:31:22 -0400

On 3/26/14 1:52 AM, Emil Ivov wrote:
>
> On 26 Mar 2014 2:35 AM, "Parthasarathi R" <[email-masked]
> <mailto:[email-masked]>> wrote:
>  >
>  > Hi Emil,
>  >

There is a conflict between such rules and defining sipfrag as a generic 
format.  As a generic format, imposing a requirement that it include an 
origin line seems unreasonable. As a requirement for using this for 
trickle ICE it makes sense.

I suggest either:
- leave sipfrag generic, impose presence of origin line as an additional
   requirement when sipfrag is used for trickle ICE
or
- define a content type that is specific to trickle ICE,
   being much more specific about what it contains, and
   with a name appropriate to that usage.

	Thanks,
	Paul

---

From: "Parthasarathi R" <[email-masked]>
Date: Wed, 26 Mar 2014 23:19:34 +0530

Hi Emil,

Could you please clarify your intention of sending Origin "o" line or
ICE-ufrag & ICE-pwd in this INFO & UPDATE scenario.

I have mentioned  "o" line by which it will be trivial for everybody to
understand that offer/answer state machine is impacted by these INFO.

Thanks

Partha

From: Emil Ivov [mailto:[email-masked]] 
Sent: Wednesday, March 26, 2014 11:23 AM
To: Parthasarathi R
Cc: Paul Kyzivat; mmusic
Subject: RE: [MMUSIC] Comment on SIP Trickle ICE based on INFO draft

--sent from my mobile

---

From: "Parthasarathi R" <[email-masked]>
Date: Thu, 27 Mar 2014 00:14:38 +0530

Hi Emil,

Please read inline for more comments.

Thanks

Partha

From: Emil Ivov [mailto:[email-masked]] 
Sent: Sunday, March 23, 2014 5:24 PM
To: Parthasarathi R
Cc: mmusic; Christer Holmberg; Enrico Marocco (TiLab)
Subject: RE: [MMUSIC] Comment on SIP Trickle ICE based on INFO draft

Hello,

<Partha> As I mentioned in the another mail thread
(http://www.ietf.org/mail-archive/web/mmusic/current/msg13267.html),
offer/answer is impacted in case SIP ICE trickle INFO has to be implemented
</Partha>

<Partha> INFO & UPDATE example is one of the example for this discussion.
</Partha>

<Partha> Sorry in case BUNDLE confused the discussion. The main point is
that how 3264 offer/answer impacted by this INFO based Trickle ICE proposal.
Also, the mail thread points out the limitation in RFC 3264 to adapt Trickle
ICE. </Partha>

<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>

<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)."

 </Partha>

<Partha> No, it is not possible to implement this draft without impact
offer/answer state machine </Partha>

<Partha> By now, you would have realized that how offer/answer "o" line has
dependency in INFO trickle ICE </Partha>

<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. Please note that INFO is not possible to be
handled 491 scenario wherein offer/answer is impacted </Partha>

See above.

I think the above commencts should answer your questions. We will make sure
we add those as clarifications before our next submission (hopefully as a WG
document)

Emil

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Mar 2014 15:06:54 -0400

I think it makes sense to include the o= line. It will still require 
some text to fully explain what it means and how to use it.

Note that the values of o= are also independent in the two directions, 
so (like CSeq) can't be used directly to correlate messages in opposite 
directions.

However the O/A process does correlate pairs of o=, one from each side.

What we end up with is:

- a session has a series of O/A exchanges. Each O and A contains an
   SDP. And each SDP has has an o= line.
- From that you can identify a series of SDP pairs. Viewed from one
   side each pair has one local and one remote SDP.
- the version numbers in the o= lines of the local SDPs form a
   non-decreasing sequence. The same is true for the remote SDPs.
   (But two in a sequence may have the *same* version.)

What we are talking about is for the trickle ICE SDP fragments to 
contain the o= line from the SDP most recently sent in an offer or 
answer by the sender of the fragment.

If you receive a trickle ICE fragment, then you should compare the o= 
line to that of the most recent SDP received in an offer or answer. If 
those match, and you have no unanswered offer outstanding, then all is ok.

If they differ and you have no unanswered offer outstanding, then 
something is wrong. (I haven't thought through all the possibilities here.)

If they differ and you have an unanswered outstanding offer, then it may 
be that an answer is enroute and this trickle was intended to follow it.

Note that if you have an unanswered offer outstanding, it is possible 
that the answer will be identical to the prior offer, and that the 
trickle fragment was sent after the answer. I *think* this doesn't 
matter - treating it as if it was sent first will yield the same result.

	Thanks,
	Paul

On 3/26/14 1:49 PM, Parthasarathi R wrote:
> Hi Emil,
>
> Could you please clarify your intention of sending Origin “o” line or
> I have mentioned  “o” line by which it will be trivial for everybody to
> *From:*Emil Ivov [mailto:[email-masked]]
> *Sent:* Wednesday, March 26, 2014 11:23 AM
> *To:* Parthasarathi R
> *Cc:* Paul Kyzivat; mmusic
> *Subject:* RE: [MMUSIC] Comment on SIP Trickle ICE based on INFO draft
>
>
>  > > From: mmusic [mailto:[email-masked]
> <mailto:[email-masked]>] On Behalf Of Emil Ivov
>  > > To: Paul Kyzivat; [email-masked] <mailto:[email-masked]>
>  > > [email-masked] <mailto:[email-masked]>

---

From: Emil Ivov <[email-masked]>
Date: Wed, 26 Mar 2014 23:46:39 +0100

> some text to fully explain what it means and how to use it.

After reading your mail I am not so sure any more.

> matter - treating it as if it was sent first will yield the same result.

This is really great insight! Thanks Paul!

It does make me wonder however if o= is the best way to handle things 
here though. For example, it hadn't occurred to me that an O/A can 
increment the o=values without having an impact on ICE processing. This 
would happen if ice-ufrag and ice-pwd remain the same.

So all this makes me think that ufrag and pwd may still be the easiest 
and most straightforward way of matching INFOs to a specific ICE context.

Thoughts?
Emil

>>  > > >> This is analogous to an UPDATE that is received before regular
>> 5245
>>  > > ICE

-- 
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Thu, 27 Mar 2014 00:07:01 +0100

On 26.03.14, 19:44, Parthasarathi R wrote:
> <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.

> <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
>     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.

> 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).

> 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

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 30 Mar 2014 09:38:32 +0000

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 [[email-masked]]
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

Emil

--
https://jitsi.org

---

From: Emil Ivov <[email-masked]>
Date: Sun, 30 Mar 2014 22:30:29 +0200

> 1) There should be no need to figure out whether an INFO is sent before an UPDATE; and

That's not exactly true because, like ICE, trickle ICE does depend on 
O/A in order to operate. In other words: if you change your location and 
do a new Offer/Answer, you don't expect vanilla ICE to magically 
continue, blissfully ignorant of that fact. It needs to restart and so 
does Trickle ICE.

> 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.

The main reason you need that is so that you can drop stray INFOs that 
have been delayed and have arrived when the ICE processing context they 
were related to is no longer valid (i.e. after an ICE restart).

But I agree that an o= line is not the most convenient way to handle 
this and using ice-ufrag and ice-pwd would be better.

> Instead, Trickle ICE is only a mechanism to transport candidate information from one endpoint to another.

Agreed.

> Endpoints may of course add those candidates to subsequent Offer/Answers.

This should be clarified. I think it's not necessary. Basically an O/A 
can have the following two possible relations to trickle ICE:

1. ICE restart: (ice-ufrag and ice-pwd have changed). This basically 
means that your addressing situation has most likely changed and you 
need to start everything from scratch. So you do.

2. Non-ICE session modification: you are currently doing ICE and while 
you are at it, you change some aspect of your session that has 
no-relation to addressing. For example, you add formats, change the 
direction of a stream, or something like that. In this case trickle ICE 
continues with no modification.

Case 1 obviously doesn't need any of the trickle candidates but they can 
be included if the agent is comfortable reusing them. This is compatible 
with 5245 which says something like this:

    If ICE is restarting [...] the set of candidates MAY include some,
    none, or all of the previous candidates for that stream and MAY
    include a totally new set of candidates

Case 2 is less obvious to me. Requiring agents to include all currently 
known addresses sounds a bit risky to me because it's easy to get into 
situations where an agent receives a set of candidates that does not 
match its current view of the session:

Case 2.1: New candidates appear
Case 2.2: Some candidates are not there.

Case 2.1 is easy to handle: the new candidates are handled as if they 
were trickled.

Case 2.2 is kind of a headache. 5245 says that it MUST NOT happen but I 
don't think this can be guaranteed because various race conditions may 
cause trickled candidates to arrive before the O/A and make an agent 
believe that some of them are lacking.

I think the easiest way to handle this would be to say that, when using 
Trickle ICE, candidates and addressinf information from offers that DO 
NOT restart ICE MUST be ignored.

Thoughts?

Emil

--
https://jitsi.org

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 30 Mar 2014 22:00:33 +0000

Hi,

> continue, blissfully ignorant of that fact. It needs to restart and so

Ok, I hear what you are syaing. You need a way to indicate whether the trickled candidates are pre-restart or not.

> this and using ice-ufrag and ice-pwd would be better.

Or, some part of the o= line.

Keep in mind that you don't need to put everything in the INFO message body. You can also define parameters associated with the info package.

>NOT restart ICE MUST be ignored.

Well, you can't ignore the "ice completed" Offer, can you?

Regards,

Christer