Subject: [MMUSIC] Fwd: New Version Notification for draft-ietf-mmusic-trickle-ice-sip-04.txt

From: Thomas Stach <[email-masked]>
Date: Tue, 17 May 2016 16:00:29 +0200

All,

the changes from draft-ietf-mmusic-trickle-ice-sip-03 include

- replaced reference to RFC5245 with draft-ietf-mmusic-rfc5245bis and 
draft-ietf-mmusic-ice-sip-sdp
- corrected Figure 10, credits to Ayush Jain for finding the bug
- referencing a=rtcp and a=rtcp-mux handling from 
draft-ietf-mmusic-ice-sip-sdp
- referencing a=rtcp-mux-exclusive handling from 
draft-ietf-mmusic-mux-exclusive, enhanced ABNF to support 
a=rtcp-mux-exclusive
- clarifying that draft-ietf-mmusic-sdp-mux-attributes applies for the 
application/trickle-ice-sdpfrag body

Currently there are no open issues in this draft. However, it could 
probably benefit from a thorough review.
So, comments welcome.

With respect to progressing this work, I think that it should go forward 
alongside with draft-ietf-ice-trickle since any updates of that document 
might influence the content of this draft.

Regards
Thomas

-------- Forwarded Message --------
Subject: 	New Version Notification for 
draft-ietf-mmusic-trickle-ice-sip-04.txt
Date: 	Tue, 17 May 2016 06:50:19 -0700
From: 	[email-masked]
To: 	Thomas Stach <[email-masked]>, Emil Ivov 
<[email-masked]>, Enrico Marocco <[email-masked]>, 
Christer Holmberg <[email-masked]>

A new version of I-D, draft-ietf-mmusic-trickle-ice-sip-04.txt
has been successfully submitted by Thomas Stach and posted to the
IETF repository.

Name:		draft-ietf-mmusic-trickle-ice-sip
Revision:	04
Title:		A Session Initiation Protocol (SIP) usage for Trickle ICE
Document date:	2016-05-17
Group:		mmusic
Pages:		36
URL:            https://www.ietf.org/internet-drafts/draft-ietf-mmusic-trickle-ice-sip-04.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-mmusic-trickle-ice-sip/
Htmlized:       https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-04
Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-trickle-ice-sip-04

Abstract:
    The Interactive Connectivity Establishment (ICE) protocol describes a
    Network Address Translator (NAT) traversal mechanism for UDP-based
    multimedia sessions established with the Offer/Answer model.  The ICE
    extension for Incremental Provisioning of Candidates (Trickle ICE)
    defines a mechanism that allows ICE agents to shorten session
    establishment delays by making the candidate gathering and
    connectivity checking phases of ICE non-blocking and by executing
    them in parallel.

    This document defines usage semantics for Trickle ICE with the
    Session Initiation Protocol (SIP).

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 17 May 2016 21:22:52 +0000

Hi,

I think there is some editorial work that needs to be done, but I'll skip that for now. Some technical comments, to kick off the discussions:

Q1:

The text in 3.3 says:

	"Such INFO requests do not impact the state of Offer/Answer, nor do they have an impact on the version number in the "o=" line."

I think we'll need more text than this, in order to avoid confusion. For example, if INFOs don't impact the state of Offer/Answer, does it mean that the candidates will NOT be included in subsequent offer/answer transactions? 

However, I assume that they WILL be impacted by an ICE re-start.

Q2:

Section 4.2 says:

	"INFO requests containing "a=ice-pwd:" and "a=ice-ufrag:" attributes that do not match those of the current ICE processing
   	session MUST be discarded."

This obviously applies if the INFO contains *OLD* pwd/ufrag values. But, I also assume that it is not allowed to provide *NEW* values in an INFO. If so, it needs to be clarified.

Q3:

Section 4.2 says:

	"Such "a=mid:" attributes MUST immediately precede the list of candidates for that specific "m=" line."

I don't think we need to say that. It is enough that the mid attribute is associated with the same m= line as the candidates. I.e. normal SDP procedures apply.

Alternatively, we could actually remove the m= line, and replace it with the mid attribute (in which case the attribute obviously need to precede the list of candidates).

Q4:

Section 4.2 says:

	"In every INFO request agents MUST include all local candidates they have previously signaled."

First, I don't think you want to include candidates that are no longer used, do you? 

Second, it is also unclear whether this includes candidates that have been signalled using Offer/Answer (I guess Q5 answers that).

Third, do we really want to include all candidates? If we want to regard INFOs as peer reflexive candidates, why not only include the new ones?

Q5:

Section 4.2 says:

  	"When receiving INFO requests carrying any candidates, agents will
   	therefore first identify and discard the SDP lines containing
   	candidates they have already received in previous INFO requests or in
   	the Offer/Answer exchange preceding them."

Where does the text says that INFOs shall carry candidates that have been signalled in Offer/Answer? The text in Q4?

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Thomas Stach
Sent: 17 May 2016 17:00
To: MMUSIC <[email-masked]>
Subject: [MMUSIC] Fwd: New Version Notification for draft-ietf-mmusic-trickle-ice-sip-04.txt

All,

- replaced reference to RFC5245 with draft-ietf-mmusic-rfc5245bis and draft-ietf-mmusic-ice-sip-sdp
- corrected Figure 10, credits to Ayush Jain for finding the bug
- referencing a=rtcp and a=rtcp-mux handling from draft-ietf-mmusic-ice-sip-sdp
- referencing a=rtcp-mux-exclusive handling from draft-ietf-mmusic-mux-exclusive, enhanced ABNF to support a=rtcp-mux-exclusive
- clarifying that draft-ietf-mmusic-sdp-mux-attributes applies for the application/trickle-ice-sdpfrag body

Currently there are no open issues in this draft. However, it could probably benefit from a thorough review.
So, comments welcome.

With respect to progressing this work, I think that it should go forward alongside with draft-ietf-ice-trickle since any updates of that document might influence the content of this draft.

Regards
Thomas

-------- Forwarded Message --------

Abstract:

The IETF Secretariat

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Thomas Stach <[email-masked]>
Date: Thu, 19 May 2016 20:34:45 +0200

Christer,

thanks for reviewing.
more inline

> I think we'll need more text than this, in order to avoid confusion. For example, if INFOs don't impact the state of Offer/Answer, does it mean that the candidates will NOT be included in subsequen…
No, in a subsequent offer/answer transaction you would include the 
actual set of candidates, i.e.  in case you use 100rel and do a second 
O/A before the 200OK to the INVITE, you would include in the offer the 
candidates present in the initial offer and all candidates there were 
trickled in the meantime.
> However, I assume that they WILL be impacted by an ICE re-start.
In case of a restart everything starts from scratch.
> This obviously applies if the INFO contains *OLD* pwd/ufrag values. But, I also assume that it is not allowed to provide *NEW* values in an INFO. If so, it needs to be clarified.
Correct, the current text does not allow this. I can clarify.
> I don't think we need to say that. It is enough that the mid attribute is associated with the same m= line as the candidates. I.e. normal SDP procedures apply.
You're right, it is not strictly needed. However, the current text was 
the outcome of a longer discussion with Paul Kyzivat. I would have to 
look up the details that lead to this format.
Additonally, as the grammar for the info-package is written in a way 
that prescribes the order of the attributes, I'd prefer to keep it as 
is, unless there is a real need for more flexibility.
Others?
> First, I don't think you want to include candidates that are no longer used, do you?
What do you mean by no longer used?
> Third, do we really want to include all candidates? If we want to regard INFOs as peer reflexive candidates, why not only include the new ones?
Always including the complete set of candidates (i.e. those from the 
initial offeror answer plus the ones that were trickled afterwards) is 
motivated by the infamous support for UDP transport in SIP. In order to 
have things simple we decided already in the early days of this draft to 
always have the complete set in the INFO. Then, you don't need to care 
about lost INFOs and can just drop any late arrivals.
> Where does the text says that INFOs shall carry candidates that have been signalled in Offer/Answer? The text in Q4?
Yes

Regards
Thomas
> To: MMUSIC<[email-masked]>
> To: 	Thomas Stach<[email-masked]>, Emil Ivov
> <[email-masked]>, Enrico Marocco<[email-masked]>,
> Christer Holmberg<[email-masked]>
>
>
>
> URL:https://www.ietf.org/internet-drafts/draft-ietf-mmusic-trickle-ice-sip-04.txt
> Status:https://datatracker.ietf.org/doc/draft-ietf-mmusic-trickle-ice-sip/
> Htmlized:https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-04
> Diff:https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-trickle-ice-sip-04
>
> Abstract:

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 19 May 2016 19:32:03 +0000

Hi,

See inline.

Q1:

>> I think we'll need more text than this, in order to avoid confusion. For example, if INFOs don't impact the 
>> state of Offer/Answer, does it mean that the candidates will NOT be included in subsequent offer/answer transactions?
>
> No, in a subsequent offer/answer transaction you would include the actual set of candidates, i.e.  in case you use 100rel 
> and do a second O/A before the 200OK to the INVITE, you would include in the offer the candidates present in the initial 
> offer and all candidates there were trickled in the meantime.

Well, then the INFO *does* impact the Offer/Answer state, doesn't it - assuming the set of candidates is part of the O/A state?

Also, assume candidates A, B and C are included in the offer/answer transaction, and then the INFO contains (for whatever reason) candidates A and B. What is the state of C? Can INFO be used to *remove* previously negotiated candidates`?

> In case of a restart everything starts from scratch.

Needs to be explicitly indicated.

> Correct, the current text does not allow this. I can clarify.

Ok.

Q3:

> You're right, it is not strictly needed. However, the current text was the outcome of a longer discussion with Paul Kyzivat. I would have to look up the details that lead to this format.
> Additionally, as the grammar for the info-package is written in a way that prescribes the order of the attributes, I'd prefer to keep it as is, unless there is a real need for more flexibility.

So, what happens if the mid attribute is NOT where it is supposed to be? Shall the receiver reject the trickled candidates(s)?

That brings up another question: how does a receiver reject received candidates? Remember that the receiver will always send 200 OK to the INFO request.

> What do you mean by no longer used?

Candidates that were used before a re-start, or have been removed/disabled using some other means.

>> Second, it is also unclear whether this includes candidates that have 
>> been signalled using Offer/Answer (I guess Q5 answers that).
>>
> Always including the complete set of candidates (i.e. those from the initial offeror answer plus the ones that were trickled afterwards) is motivated by the infamous support for UDP transport in SIP.

Infamous? Also keep in mind that STUN is transported over UDP, so peer reflexive candidates are in no better position.

> In order to have things simple we decided already in the early days of this draft to always have the complete set in the INFO.
> Then, you don't need to care about lost INFOs and can just drop any late arrivals.

Well, late arrivals should be dropped anyway.

>> Where does the text says that INFOs shall carry candidates that have been signalled in Offer/Answer? The text in Q4?

Ok.

Regards,

Christer

> has been successfully submitted by Thomas Stach and posted to the IETF 
> repository.
>
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 19 May 2016 15:38:27 -0400

On 5/19/16 2:34 PM, Thomas Stach wrote:

>> I don't think we need to say that. It is enough that the mid attribute
>> is associated with the same m= line as the candidates. I.e. normal SDP
>> procedures apply.
>> Alternatively, we could actually remove the m= line, and replace it
>> with the mid attribute (in which case the attribute obviously need to
>> precede the list of candidates).

I just looked back to refresh my mind what that discussion was. It was 
about sdpfrag. At the time it was just application/sdpfrag. My concern 
was a generic sdpfrag isn't useful, because arbitrary subsets of sdp 
lines are ambiguous. To make it unambiguous you need to include certain 
key features that make it so. I was arguing that what was needed was a 
application/trickle-ice-sdpfrag that specified the particular subset 
that is unambiguous.

That has now been done. And it always has the ice attributes preceded by 
as m=line and single a=mid. So the a=mid always does immediately precede 
the candidates.

Since the m=line is there, Christer's language should also work. I don't 
have a strong opinion either way. But I haven't read the draft recently, 
so I might be missing something.

	Thanks,
	Paul

---

From: Thomas Stach <[email-masked]>
Date: Fri, 20 May 2016 08:45:02 +0200

Christer,

> Well, then the INFO *does* impact the Offer/Answer state, doesn't it - assuming the set of candidates is part of the O/A state?
Well, this definition is probably the source of this discussion. The 
draft does not assume that the candidates are part of the O/A state.
Figure 2 tries to clarify that by using the  logical entities "O/A 
module" and "ICE agent".
The candidates just affect the state of the the latter.
This is also the reason for the comparison of trickled candidates with 
peer reflexive candidates.
Both are learned by the ICE agent without the need for an additional O/A 
exchange.

>
> Also, assume candidates A, B and C are included in the offer/answer transaction, and then the INFO contains (for whatever reason) candidates A and B.
This is an error
>   What is the state of C? Can INFO be used to *remove* previously negotiated candidates`?
No, this would need an ICE restart.
> Needs to be explicitly indicated.
Agreed
> So, what happens if the mid attribute is NOT where it is supposed to be?
This is an error case, which traditionally aren't covered in too much 
detail in RFCs.
You could think about a 488 or 606 or you could be liberal in what you 
receive.
> Shall the receiver reject the trickled candidates(s)?
>
> That brings up another question: how does a receiver reject received candidates?
Why would you need that? That was never a requirement before.

> Remember that the receiver will always send 200 OK to the INFO request.
No, you can also send an error response.

Regards
Thomas

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 20 May 2016 09:49:10 +0000

Hi,

>> Q1:
>>
>>>> The text in 3.3 says:
>>>>
>>>> 	"Such INFO requests do not impact the state of Offer/Answer, nor do
>>>>they have an impact on the version number in the "o=" line."
>>>>
>>>> state of Offer/Answer, does it mean that the candidates will NOT be
>>>>included in subsequent offer/answer transactions?
>>>actual set of candidates, i.e.  in case you use 100rel
>>> and do a second O/A before the 200OK to the INVITE, you would include
>>>in the offer the candidates present in the initial
>> Well, then the INFO *does* impact the Offer/Answer state, doesn't it -
>>assuming the set of candidates is part of the O/A state?

O/A state is more than the actual O/A transactions. In my opinion the
current SDP state is also part of the O/A state. Anyway, if that is not
the case, we need further clarification on what we really mean by ³O/A
state². If you only refer to the O/A transactions, then it should be
clearly stated.

>> Also, assume candidates A, B and C are included in the offer/answer
>>transaction, and then the INFO contains (for whatever reason) candidates
>>A and B.
>This is an error

So, what shall the receiver do if it happens? Discard the candidate(s)?

>No, this would need an ICE restart.

Needs to be clear. Perhaps there should be a ³ICE Restrictions² section,
or something similar.

>> Needs to be explicitly indicated.

Good :)

>> Q2:
>>
>>>> Section 4.2 says:
>>>>
>>>> 	"INFO requests containing "a=ice-pwd:" and "a=ice-ufrag:" attributes
>>>>that do not match those of the current ICE processing
>>> This obviously applies if the INFO contains *OLD* pwd/ufrag values.
>>>But, I also assume that it is not allowed to provide *NEW* values in an
>>>INFO. If so, it needs to be clarified.
>>>> I don't think we need to say that. It is enough that the mid
>>>>attribute is associated with the same m= line as the candidates. I.e.
>>>>normal SDP procedures apply.
>>> Additionally, as the grammar for the info-package is written in a way

Well, I think we need to have some text on error cases. See more below.

>No, you can also send an error response.

The INFO response is often sent by the SIP stack, before the Info Package
content has been handed to the application, and as long as the SIP stack
supports the Info Package as such, a 200 OK will be sent. If there is some
errors on the application level it needs to be dealt with some other way.
Please see section 4.2.2 of RFC 6086.

Regards,

Christer

>>>> Third, do we really want to include all candidates? If we want to
>>>>regard INFOs as peer reflexive candidates, why not only include the
>>>>new ones?
>>>motivated by the infamous support for UDP transport in SIP.
>> Infamous? Also keep in mind that STUN is transported over UDP, so peer
>>reflexive candidates are in no better position.
>>
>>> In order to have things simple we decided already in the early days of
>>>this draft to always have the complete set in the INFO.
>>>> Where does the text says that INFOs shall carry candidates that have
>>>>been signalled in Offer/Answer? The text in Q4?
>>> Yes
>> Ok.
>>
>> Regards,
>>
>> Christer
>>
>>> With respect to progressing this work, I think that it should go
>>>forward alongside with draft-ietf-ice-trickle since any updates of that
>>>document might influence the content of this draft.
>>>
>>> Regards
>>> Thomas
>>>
>>>
>>>

---

From: Thomas Stach <[email-masked]>
Date: Fri, 20 May 2016 15:34:05 +0200

> state². If you only refer to the O/A transactions, then it should be
A proposal for improved text:

old:

Such INFO requests do not
    impact the state of Offer/Answer, nor do they have an impact on the
    version number in the "o=" line.  In that regard they are actually
    comparable to Peer Reflexive candidates that ICE agents can discover
    during ICE processing.

new:

Such INFO requests do not impact the state of Offer/Answer other than providing additional candidates.
Consequently, they do not have an impact on the version number in the "o=" line.
In that regard trickled candidates are actually comparable to Peer Reflexive candidates that
ICE agents can discover during ICE processing without without the need for an additional O/A
exchange.

> So, what shall the receiver do if it happens? Discard the candidate(s)?
Actually this should already be covered at the end of 4.2

When receiving INFO requests carrying any candidates, agents will
    therefore first identify and discard the SDP lines containing
    candidates they have already received in previous INFO requests or in
    the Offer/Answer exchange preceding them.
...  After identifying and discarding known
    candidates, agents will then process the remaining, actually new
    candidates according to the rules described in
    [I-D.ietf-mmusic-trickle-ice 
<https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-04#ref-I-D.ietf-mmusic-trickle-ice>].

In said error case there aren't any remaining candidates, thus nothing 
to do. I can add a clarification at the end of 4.2
> Needs to be clear. Perhaps there should be a ³ICE Restrictions² section,
Why? There never was a candidate removal feature in ICE (nor 
Trickle-ICE) and I don't think that this document needs to specify 
anything along that lines.
> Please see section 4.2.2 of RFC 6086.
My interpretation of that section is that you MAY send an error since 
the INFO request from above  is not syntactically correct. However, 
200OK and dealing with content on application level would also be fine. 
I don't think that this document needs to say anything beyond RFC6086. 
Regards Thomas

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 21 May 2016 08:08:25 +0000

Hi,

Q1:

The text in 3.3 says:

I think we'll need more text than this, in order to avoid confusion.

For example, if INFOs don't impact the

module" and "ICE agent".

exchange.

clearly stated.

old:

   during ICE processing.

new:

exchange.

Is the statement regarding the "o=" line really true? For example, assume you send an O/A, with candidates A and B. Then, you use INFO to add candidate C. Then, you send a new O/A, with no other changes than candidate C added. Are you saying that the "o=" line shouldn't be updated, even if the Offer now contains candidate C? I am not sure that is described even if C was provided as a "real" peer-reflexive candidate, so perhaps it has to be updated in draft-ice-sip-sdp too.

Perhaps the O/A section needs to be re-structured, with a sub-section for each O/A property, where the impacts/non-impacts are described.

A and B.

This is an error

   [I-D.ietf-mmusic-trickle-ice<https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-04#ref-I-D.ietf-mmusic-trickle-ice>].
In said error case there aren't any remaining candidates, thus nothing to do.  I can add a clarification at the end of 4.2

It would have to be clear that a previously provided candidate, if missing (for whatever reason) in a subsequent INFO, does not mean the candidate has been "disabled" or "removed". The important thing are the NEW candidate(s), i.e. the candidates that the receiver haven't seen before - the rest is there just for information.

  What is the state of C? Can INFO be used to *remove* previously

negotiated candidates`?

or something similar.
Why? There never was a candidate removal feature in ICE (nor Trickle-ICE) and I don't think that this document needs to specify anything along that lines.

My assumption has been that, if you send a new O/A, where are previously provided candidate has been removed, it means that it has been removed. But, whether that is true or not, perhaps it needs clarification in 5245bid and/or draft-ice-sip-sdp.

...

Please see section 4.2.2 of RFC 6086.
My interpretation of that section is that you MAY send an error since the INFO request from above  is not syntactically correct. However, 200OK and dealing with content on application level would also be fine. I don't think that this document needs to say anything beyond RFC6086. Regards Thomas

The SIP stack MAY of course understand the content, but the whole idea of sending application layer data with INFO is that the SIP stack does NOT need to know anything about the semantics and syntax of that application layer data (the data could even be encrypted with a key that the SIP stack does not have access too, or encoded with some algorithm the SIP stack does not understand). So, you cannot make an assumption that the SIP stack will detect an error and send a non-200 response. The assumption has to be that, if the usage of the Info Package as such has been negotiated for the session, the sender will receive a 200 OK no matter if the application layer data is correct or not.

Regards,

Christer