Subject: [MMUSIC] Some editorial (mostly) comments on draft-ietf-mmusic-trickle-ice-sip-11

From: Christer Holmberg <[email-masked]>
Date: Mon, 18 Dec 2017 12:32:33 +0000

Hi,

As I had some time to breath during the work to finalise BUNDLE, I noted some issues with trickle-ice-sip. They are mostly editorial, and I did check that Ben hadn’t given the same comments as part of his AD review (if he did, I missed it).

Q1_EDITORIAL:

The draft talks about “INVITE requests”, “18x responses” etc, but uses both “INFO messages” and “INFO requests". I suggest to only say “INFO requests”, in order to have consistent terminology.

Q2_TECHNICAL:

Section 4.1.3 says:

 "Section Section 4.1.1 applies to the Answerer with the roles of Offerer and Answer being swapped."

Does this mean that the answerer shall also, for each m- section where it has yet no candidates, use “audio”, port 9 and RTP/AVP, no matter what was used in the corresponding offer? If so, I believe that would require an update to RFC 3264.

Q3_ EDITORIAL:

Where is there no procedures for sub-sequent offers/answers?

Q4_EDITORIAL:

Related to Q3:

The text in section 4.2.2 says:

   "When sending the Answer in the 200 OK response to the INVITE request,
   the Answerer MUST repeat exactly the same Answer that was previously
   sent in the unreliable provisional response in order to fulfill the
   corresponding requirements in [RFC3264].  Thus, the Offerer needs to
   be prepared for receiving a different number of candidates in that
   repeated Answer than previously exchanged via trickling and MUST
   ignore the candidate information in that 200 OK response."

What about other answers? For example, there could be O/A transactions BEFORE the 200 OK is sent, using UPDATEs or PRACKs?

What about answerer sent later during the session?

Q5_EDITORIAL:

First, in section 7, in the initial offer example, there is no a=ice-options:trickle attribute. Is there a reason for that?

Second, in section 7, in the initial offer example, you don’t use the “audio”/port 9/“RTP/AVP” rule from section 4.1.1. If that is due to BUNDLE, I think you need to be more explicit about it.

Third, in section 7, in the INFO example, I assume the second m- section shall contain a bundle-only attribute?

Fourth, section 7 does contain the following text:

   "Except for bundle-only "m=" lines, a Half Trickle Offerer would have
   to send an offer with candidates for all bundled "m=" lines.  The
   additional flexibility, however, allows a Full Trickle Offerer to
   initially send only candidates for the "m=" line with the suggested
   Offerer BUNDLE address."

Not really sure how this fits with the example. Also, in the case of full trickle, I am not sure I understand why you only would have to include candidates in the m- section associated with the offerer BUNDLE address, if there are multiple non-bundle-only m- sections. Could you explain?

Regards,

Christer

---

From: Thomas Stach <[email-masked]>
Date: Mon, 18 Dec 2017 17:46:05 +0100

Christer,

thanks for the additional co-author review and your comments.

responses inline ..

On 2017-12-18 13:32, Christer Holmberg wrote:
> Hi,
>
> As I had some time to breath during the work to finalise BUNDLE, I 
> noted some issues with trickle-ice-sip. They are mostly editorial, and 
> I did check that Ben hadn’t given the same comments as part of his AD 
> review (if he did, I missed it).
>
>
> *Q1_EDITORIAL:*
>
> The draft talks about “INVITE requests”, “18x responses” etc, but uses 
> both “INFO messages” and “INFO requests". I suggest to only say “INFO 
> requests”, in order to have consistent terminology.
I also recognized that. I already started the alignment
> *Q2_TECHNICAL:*
> Does this mean that the answerer shall also, for each m- section where 
> it has yet no candidates, use “audio”, port 9 and RTP/AVP, no matter 
> what was used in the corresponding offer? If so, I believe that would 
> require an update to RFC 3264.
Good point.
Of course not. This will be clarified when I address a similar comment 
by Ben on section 4.1.1.

> *Q3_ EDITORIAL:*
That will be as for regular ICE. I'll add a section that refers to 
draft-ice-sip-sdp to make that explicit.
> *Q4_EDITORIAL:*
> What about other answers? For example, there could be O/A transactions 
> BEFORE the 200 OK is sent, using UPDATEs or PRACKs?
Good point.
Even more interesting is how the  offer looks like.
However, that should be covered by the  section on subsequent offers for 
regular ICE, even if we are in the middle of trickling.
There is the following text in 4.2.1.2.1 of ice-sip-sdp:
"An agent MUST include candidate attributes for all local candidates it 
had signaled previously for that media stream."
If a trickle-ice agent wants to use offers in PRACK/UPDATE in an early 
dialog, it just puts all already signaled candidates in that offer.
I'll mention that in the section for subsequent offers/answer.
> What about answerer sent later during the session?
as above
>
>
> *Q5_EDITORIAL:*
> *
> *
> First, in section 7, in the initial offer example, there is no 
> a=ice-options:trickle attribute. Is there a reason for that?
just an oversight
>
> Second, in section 7, in the initial offer example, you don’t use the 
> “audio”/port 9/“RTP/AVP” rule from section 4.1.1. If that is due to 
> BUNDLE, I think you need to be more explicit about it.
That rule in 4.1.1. was just a last resort, but there will be anyhow an 
adaptation based on a comment by Ben.
So, the SDP probably needs some  adaptations as well.
However, if you know your ports, codecs, etc. you will put that into the 
initial offer. There is nothing bundle-specific here.
Nevertheless, you have a point in that a host candidate could already go 
into this example offer.

>
> Third, in section 7, in the INFO example, I assume the second m- 
> section shall contain a bundle-only attribute?
Thanks for the reminder. -11 was produced before the latest changes in 
bundle.
> Not really sure how this fits with the example. Also, in the case of 
> full trickle, I am not sure I understand why you only would have to 
> include candidates in the m- section associated with the offerer 
> BUNDLE address, if there are multiple non-bundle-only m- sections. 
> Could you explain?
If my understanding of bundle is still correct (I haven't looked yet 
into the latest update), you would have to provide candidates for all 
non-bundle-only m-lines
as a fallback in case that bundle is rejected/not supported. These 
candidates were wasted, if bundle was accepted.
With trickle you can initially provide candidates just for the m-line 
with the offerer bundle address.
The other candidates would be trickled only if needed, i.e. if bundle is 
rejected.
Does that make sense?

Regards
Thomas
>
> Regards,
>
> Christer
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 18 Dec 2017 20:02:53 +0000

Hi,

Please see inline.

Q2_TECHNICAL:

Section 4.1.3 says:

 "Section Section 4.1.1 applies to the Answerer with the roles of Offerer and Answer being swapped."
Does this mean that the answerer shall also, for each m- section where it has yet no candidates, use "audio", port 9 and RTP/AVP, no matter what was used in the corresponding offer? If so, I believe that would require an update to RFC 3264.
Good point.
Of course not. This will be clarified when I address a similar comment by Ben on section 4.1.1.

[Christer] I have probably missed it, but what is the reason for mandating "audio" and "RTP/AVP" to begin with (I do understand the usage of port 9)? I think it should be explained in this document, as it is SDP-specific.

Q3_ EDITORIAL:

Where is there no procedures for sub-sequent offers/answers?
That will be as for regular ICE. I'll add a section that refers to draft-ice-sip-sdp to make that explicit.

[Christer] See below (Q4).

Q4_EDITORIAL:

Related to Q3:

What about other answers? For example, there could be O/A transactions BEFORE the 200 OK is sent, using UPDATEs or PRACKs?
Good point.
Even more interesting is how the  offer looks like.
However, that should be covered by the  section on subsequent offers for regular ICE, even if we are in the middle of trickling.
There is the following text in 4.2.1.2.1 of ice-sip-sdp:
"An agent MUST include candidate attributes for all local candidates it had signaled previously for that media stream."
If a trickle-ice agent wants to use offers in PRACK/UPDATE in an early dialog, it just puts all already signaled candidates in that offer.
I'll mention that in the section for subsequent offers/answer.

[Christer] Thanks.

Q5_EDITORIAL:

Second, in section 7, in the initial offer example, you don't use the "audio"/port 9/"RTP/AVP" rule from section 4.1.1. If that is due to BUNDLE, I think you need to be more explicit about it.
That rule in 4.1.1. was just a last resort, but there will be anyhow an adaptation based on a comment by Ben.
So, the SDP probably needs some  adaptations as well.
However, if you know your ports, codecs, etc. you will put that into the initial offer. There is nothing bundle-specific here.
Nevertheless, you have a point in that a host candidate could already go into this example offer.

[Christer] I think it would be good to have some explanation associated with the examples. What exactly is the example showing.

Third, in section 7, in the INFO example, I assume the second m- section shall contain a bundle-only attribute?
Thanks for the reminder. -11 was produced before the latest changes in bundle.

   Offerer BUNDLE address."
Not really sure how this fits with the example. Also, in the case of full trickle, I am not sure I understand why you only would have to include candidates in the m- section associated with the offerer BUNDLE address, if there are multiple non-bundle-only m- sections. Could you explain?
If my understanding of bundle is still correct (I haven't looked yet into the latest update), you would have to provide candidates for all non-bundle-only m-lines
as a fallback in case that bundle is rejected/not supported. These candidates were wasted, if bundle was accepted.
With trickle you can initially provide candidates just for the m-line with the offerer bundle address.
The other candidates would be trickled only if needed, i.e. if bundle is rejected.
Does that make sense?

[Christer] If you have multiple non-bundle-only m- sections, you don't know which will become the offerer bundle address before you receive the initial answer (as the answerer selects the offerer bundle address). Obviously, once the offerer bundle address has been selected, you only need to send candidates for that m- section.

Regards,

Christer

---

From: Thomas Stach <[email-masked]>
Date: Wed, 20 Dec 2017 09:52:05 +0100

Christer,

On 2017-12-18 21:02, Christer Holmberg wrote:
>     Does this mean that the answerer shall also, for each m- section
>     where it has yet no candidates, use “audio”, port 9 and RTP/AVP,
>     no matter what was used in the corresponding offer? If so, I
>     believe that would require an update to RFC 3264.
>
> Good point.
> [Christer] I have probably missed it, but what is the reason for 
> mandating “audio” and “RTP/AVP” to begin with (I do understand the 
> usage of port 9) I think it should be explained in this document, as 
> it is SDP-specific.
>
Usage of "audio" and "RTP/AVP" is just an artifact and will be corrected 
in the next revision
>     What about other answers? For example, there could be O/A
>     transactions BEFORE the 200 OK is sent, using UPDATEs or PRACKs?
>
> Good point.
> However, that should be covered by the  section on subsequent offers 
> for regular ICE, even if we are in the middle of trickling.
> "An agent MUST include candidate attributes for all local candidates 
> it had signaled previously for that media stream."
>     First, in section 7, in the initial offer example, there is
>     no a=ice-options:trickle attribute. Is there a reason for that?
>
> just an oversight
>
>     Second, in section 7, in the initial offer example, you don’t use
>     the “audio”/port 9/“RTP/AVP” rule from section 4.1.1. If that is
>     due to BUNDLE, I think you need to be more explicit about it.
>
> However, if you know your ports, codecs, etc. you will put that into 
> the initial offer. There is nothing bundle-specific here.
> [Christer] I think it would be good to have some explanation 
> associated with the examples. What exactly is the example showing.
>
All the text in section 7 (and 8) is meant to be that explanation. There 
might be some small artifacts, which I'll correct in the next revision.
  Let me know if something remains unclear once the next revision is out.

Regards
Thomas
>     Not really sure how this fits with the example. Also, in the case
>     of full trickle, I am not sure I understand why you only would
>     have to include candidates in the m- section associated with the
>     offerer BUNDLE address, if there are multiple non-bundle-only m-
>     sections. Could you explain?
>
> [Christer] If you have multiple non-bundle-only m- sections, you don’t 
> know which will become the offerer bundle address before you receive 
> the initial answer (as the answerer selects the offerer bundle 
> address). Obviously, once the offerer bundle address has been 
> selected, you only need to send candidates for that m- section.
>
> Regards,
>
> Christer
>