Subject: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)

From: Christer Holmberg <[email-masked]>
Date: Thu, 19 Sep 2013 10:08:16 +0000

Hi,

Section 5.2.1:
-----------------

Q_1:      o- line <sess-version> initial value - deviation

What is the reason for recommending a <sess-version> zero value in the initial Offer, when the RFC says SHOULD use an NTP format timestamp?

I don't have any strong feelings, but in general: whenever we deviate from the "base" SDP procedures I think we should justify why.

Q_2:      o- line <sess-version> initial value - forking

When a new PeerConnection is created due to forking, the <sess-version> value must be based (incremented) on the value associated with the "mother" PeerConnection, for which the initial Offer of the whole communication session was created.

Q_3:      RTP

The text says:

"The <proto> field MUST be set to "RTP/SAVPF". "

But, that of course only applies to RTP based streams (not the data channel). Also, in general, it needs to be clear what information needs to be in every m- line, and what information is protocol specific. I would suggest to have a "General" sub-section, a "RTP" sub-section, etc.

Q_4:      BUNDLE

The text says:

"If a m= section is not being bundled into another m= section, it MUST
                generate a unique set of ICE credentials and gather its own set of
                candidates.  Otherwise, it MUST use the same ICE credentials and
                candidates that were used in the m= section that it is being bundled
                into."

As, when BUNDLE is used, the initial Offer will contain identical ICE candidates, does that mean that we will also include identical address information in the initial Offer?

I don't object to that - I just want to clarify, as it has impacts on the text in the BUNDLE spec :)

Section 5.2.2:
-----------------

Q_5:      Offer when in "local-offer"

The text says:

"If the initial offer was applied using setLocalDescription, but an
                answer from the remote side has not yet been applied, meaning the
                PeerConnection is still in the "local-offer" state, the steps for
                generating an initial offer should be followed,"

I don't understand this. Why would you create a new Offer while you are waiting for an Answer to the previously sent Offer?

Also, when setRemote() is called, to which Offer does it apply?

Q_6:      BUNDLE

We'll probably also need some text about BUNDLE.

Regards,

Christer

---

From: Kevin Dempsey <[email-masked]>
Date: Fri, 20 Sep 2013 09:27:28 +0100

For Q.3, doesn't RFC 5764 say the proto field for DTLS-SRTP should be "
UDP/TLS/RTP/SAVPF"

On 19 September 2013 11:08, Christer Holmberg <
[email-masked]> wrote:

>  Hi,****
>
> ** **
>
> Section 5.2.1:****
>
> -----------------****
>
> ** **
>
> *Q_1:      o- line <sess-version> initial value - deviation*
>
> ** **
>
> What is the reason for recommending a <sess-version> zero value in the
> initial Offer, when the RFC says SHOULD use an NTP format timestamp? ****
>
> ** **
>
> I don’t have any strong feelings, but in general: whenever we deviate from
> the “base” SDP procedures I think we should justify why.****
>
> ** **
>
> ** **
>
> *Q_2:      o- line <sess-version> initial value - forking*
>
> ** **
>
> When a new PeerConnection is created due to forking, the <sess-version>
> value must be based (incremented) on the value associated with the “mother”
> PeerConnection, for which the initial Offer of the whole communication
> session was created.****
>
> ** **
>
> ** **
>
> *Q_3:      RTP*
>
> ** **
>
> The text says:****
>
> ** **
>
> “The <proto> field MUST be set to "RTP/SAVPF". “****
>
> ** **
>
> But, that of course only applies to RTP based streams (not the data
> channel). Also, in general, it needs to be clear what information needs to
> be in every m- line, and what information is protocol specific. I would
> suggest to have a “General” sub-section, a “RTP” sub-section, etc.****
>
> ** **
>
> ** **
>
> *Q_4:      BUNDLE*
>
> ** **
>
> The text says:****
>
> ** **
>
> “If a m= section is not being bundled into another m= section, it MUST****
>
>                 generate a unique set of ICE credentials and gather its
> own set of****
>
>                 candidates.  Otherwise, it MUST use the same ICE
> credentials and****
>
>                 candidates that were used in the m= section that it is
> being bundled****
>
>                 into.”****
>
> ** **
>
> As, when BUNDLE is used, the initial Offer will contain identical ICE
> candidates, does that mean that we will also include identical address
> information in the initial Offer?****
>
> ** **
>
> I don’t object to that – I just want to clarify, as it has impacts on the
> text in the BUNDLE spec :)****
>
> ** **
>
> ** **
>
> Section 5.2.2:****
>
> -----------------****
>
> ** **
>
> ** **
>
> *Q_5:      Offer when in “local-offer”*
>
> ** **
>
> The text says:****
>
> ** **
>
> “If the initial offer was applied using setLocalDescription, but an****
>
>                 answer from the remote side has not yet been applied,
> meaning the****
>
>                 PeerConnection is still in the "local-offer" state, the
> steps for****
>
>                 generating an initial offer should be followed,”****
>
> ** **
>
> I don’t understand this. Why would you create a new Offer while you are
> waiting for an Answer to the previously sent Offer? ****
>
> ** **
>
> Also, when setRemote() is called, to which Offer does it apply?****
>
> ** **
>
> * *
>
> *Q_6:      BUNDLE*
>
> ** **
>
> We’ll probably also need some text about BUNDLE.****
>
> ** **
>
> ** **
>
> Regards,****
>
> ** **
>
> Christer****
>
> ** **
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 20 Sep 2013 12:12:22 +0200

On 09/20/2013 10:27 AM, Kevin Dempsey wrote:
>     credentials and
>     As, when BUNDLE is used, the initial Offer will contain identical
>     ICE candidates, does that mean that we will also include identical
>     address information in the initial Offer?
>
>     I don't object to that -- I just want to clarify, as it has
>     impacts on the text in the BUNDLE spec :)
>
>

I think we should be careful here to specify that BUNDLE is used 
according to the BUNDLE spec, and that any description given here is 
non-normative.

Over to MMUSIC....

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 20 Sep 2013 10:20:51 +0000

I really hope BUNDLE will be used as described in BUNDLE. At least that should be our starting point. If we want to change something, it shall be justified and discussed, before put into a document.

In addition, in the example flow in JSEP, BUNDLE IS used with different addresses, so an alignment will be needed in any case.

Regards,

Christer

From: [email-masked] [mailto:[email-masked]] On Behalf Of Harald Alvestrand
Sent: 20. syyskuuta 2013 13:12
To: [email-masked]
Subject: Re: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)

Q_4:      BUNDLE

The text says:

I think we should be careful here to specify that BUNDLE is used according to the BUNDLE spec, and that any description given here is non-normative.

Over to MMUSIC....

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 20 Sep 2013 12:38:19 +0200

On 09/20/2013 12:20 PM, Christer Holmberg wrote:
>
> I really hope BUNDLE will be used as described in BUNDLE. At least 
> that should be our starting point. If we want to change something, it 
> shall be justified and discussed, before put into a document.
>
> In addition, in the example flow in JSEP, BUNDLE IS used with 
> different addresses, so an alignment will be needed in any case.
>
>

Since we're all tracking moving objects, I think we have to write text 
as best we can, and just point out which parts are normative and which 
parts are not.

In this particular case, using MUST language for whether or not ICE 
credentials are the same or different is inappropriate for this spec; 
instead it should say something like "The BUNDLE spec says that it MUST 
generate".

Then we just make sure it gets right before BUNDLE is published.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 20 Sep 2013 10:47:21 +0000

Hi,

The reason I asked is because one of the open issues in BUNDLE is whether identical ICE credentials (and identical address properties) are allowed in the initial Offer, and one of the JSEP authors has been against that :)

But, in general I do agree with you. Whenever we reference procedures defined elsewhere, we shall reference those.

And, in this case, BUNDLE has a section on ICE, so we should reference those. And, if we have any issues with the BUNDLE ICE procedures, we should bring it to MMUSIC, before making deviations "on the fly"...

Regards,

Christer

From: Harald Alvestrand [mailto:[email-masked]]
Sent: 20. syyskuuta 2013 13:38
To: Christer Holmberg
Cc: [email-masked]
Subject: Re: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)

Since we're all tracking moving objects, I think we have to write text as best we can, and just point out which parts are normative and which parts are not.

In this particular case, using MUST language for whether or not ICE credentials are the same or different is inappropriate for this spec; instead it should say something like "The BUNDLE spec says that it MUST generate".

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 20 Sep 2013 18:22:36 +0000

Good points - proposed resolutions inline …

On Sep 19, 2013, at 3:08 AM, Christer Holmberg <[email-masked]> wrote:

> I don’t have any strong feelings, but in general: whenever we deviate from the “base” SDP procedures I think we should justify why.

Lets use NTP 

> When a new PeerConnection is created due to forking, the <sess-version> value must be based (incremented) on the value associated with the “mother” PeerConnection, for which the initial Offer of the whole communication session was created.

uh, that is old text sorry. I'm proposing the principal that any time the SDP changes (including new candidate lines) the version gets larger. 

> 
> 
> Q_3:      RTP
> 
> The text says:
> 
> “The <proto> field MUST be set to "RTP/SAVPF". “
> 
> But, that of course only applies to RTP based streams (not the data channel). Also, in general, it needs to be clear what information needs to be in every m- line, and what information is protocol specific. I would suggest to have a “General” sub-section, a “RTP” sub-section, etc.

Yep - I think this should be offers are created with RTP/SAVPF for audio and video and system can reeve offers with SAVPF or SAVP
> 
> 
> Q_4:      BUNDLE
> 
> The text says:
> 
> “If a m= section is not being bundled into another m= section, it MUST
>                into.”

no the initial offer will not have identical stuff other than on lines that "bundle-only" and we still need to add more text on this but idea is to make just like what is in united-plan

> 
> I don’t object to that – I just want to clarify, as it has impacts on the text in the BUNDLE spec :)
> 
> 
> Section 5.2.2:
> -----------------
> 
> 
> Q_5:      Offer when in “local-offer”
> 
> The text says:
> 
> “If the initial offer was applied using setLocalDescription, but an
>                generating an initial offer should be followed,”
> 
> I don’t understand this. Why would you create a new Offer while you are waiting for an Answer to the previously sent Offer?

Justin has asked for this in the case when the offer has not been sent to anyone else. This is not going to be useful for typical systems trying to have SIP or Jingle compatible flow but who knows …

> Also, when setRemote() is called, to which Offer does it apply?

The most recent one. And the JS app would have to make sure it passed the write one or you run high odds of getting completely broken behavior. 

> 
> 
> Q_6:      BUNDLE
> 
> We’ll probably also need some text about BUNDLE.
> 

yep - but plan is to match up with unified plan

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 20 Sep 2013 22:17:26 +0000

Hi Cullen,

> uh, that is old text sorry. I'm proposing the principal that any time the SDP changes (including new candidate lines) the version gets larger. 

Yes. But keep in mind that this is an Offer created for a new PeerConnection. 

----------------

> no the initial offer will not have identical stuff other than on lines that "bundle-only" and we still need to add more text on this but idea is to make just like what is in united-plan

Regarding the details (usage of port zero etc) of "bundle-only", that is still something we have to agree upon. But, that discussion belongs to MMUSIC (and, I believe there is a thread about that already :)

But again, in the case of forking, when a new PeerConnection is created, I think we should allow identical stuff in the initial Offer of that PeerConnection. Because, the remote party has already indicated support of BUNDLE, in the Answer that was sent for the "mother" PeerConnection, so the initial Offer for the new PeerConnection will be the second Offer for the remote party.

At some point, we are going to have to add much more details about forking, in the case multiple PeerConnections are used. It is not enough to only say "create a new PeerConnection" :)

----------------

> Justin has asked for this in the case when the offer has not been sent to anyone else. This is not going to be useful for typical systems trying to have SIP or Jingle compatible flow but who knows ...

Again, we have consensus to base JSEP on 3264. And, if we are going to deviate from 3264, I'd like to have some discussion and justification for that. 

I'd also have a section somewhere which summarizes *all* 3264 deviations that JSEP makes.

Regards,

Christer

---

From: Justin Uberti <[email-masked]>
Date: Fri, 27 Sep 2013 11:01:48 -0700

On Fri, Sep 20, 2013 at 11:22 AM, Cullen Jennings (fluffy) <[email-masked]
> wrote:

> initial Offer, when the RFC says SHOULD use an NTP format timestamp?
> >
> > I don’t have any strong feelings, but in general: whenever we deviate
> from the “base” SDP procedures I think we should justify why.
>
> Lets use NTP
>

It's not necessary to use NTP, since the session-id is already random.
Starting the session id at zero makes it easier for developers see the
changes to the session id. I can spell this out in the next version of the
document.

> session was created.
> uh, that is old text sorry. I'm proposing the principal that any time the
> SDP changes (including new candidate lines) the version gets larger.
>

agree

> suggest to have a “General” sub-section, a “RTP” sub-section, etc.
>
> Yep - I think this should be offers are created with RTP/SAVPF for audio
> and video and system can reeve offers with SAVPF or SAVP
>

Currently the document specifies what to do with media lines, with later
discussion of handling the SCTP line. Do you think the current information
is not sufficiently descriptive?

> own set of
> being bundled
> information in the initial Offer?
>
> no the initial offer will not have identical stuff other than on lines
> that "bundle-only" and we still need to add more text on this but idea is
> to make just like what is in united-plan

> the text in the BUNDLE spec :)

I'm not sure what the exact concern is here - I just put this here to be
clear about the exact processing needed, since the BUNDLE draft is also a
moving target.

> meaning the
> steps for
> waiting for an Answer to the previously sent Offer?
>
> Justin has asked for this in the case when the offer has not been sent to
> anyone else. This is not going to be useful for typical systems trying to
> have SIP or Jingle compatible flow but who knows …
>

It's possible that the initial offer is never sent, because you just want
to set it to warm up the stack. So you can update the offer without any
consequences.

> The most recent one. And the JS app would have to make sure it passed the
> write one or you run high odds of getting completely broken behavior.
>

exactly. This will be spelled out in setRemote processing.

> yep - but plan is to match up with unified plan

Can you be specific about what more you think needs to be said? The
createAnswer treatment of BUNDLE is one clear thing that is currently
missing.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 27 Sep 2013 11:03:04 -0700

On Fri, Sep 20, 2013 at 3:17 PM, Christer Holmberg <
[email-masked]> wrote:

> value must be based (incremented) on the value associated with the "mother"
> > uh, that is old text sorry. I'm proposing the principal that any time
> the SDP changes (including new candidate lines) the version gets larger.
>
> Regarding the details (usage of port zero etc) of "bundle-only", that is
> still something we have to agree upon. But, that discussion belongs to
> MMUSIC (and, I believe there is a thread about that already :)
>
> But again, in the case of forking, when a new PeerConnection is created, I
> think we should allow identical stuff in the initial Offer of that
> PeerConnection. Because, the remote party has already indicated support of
> BUNDLE, in the Answer that was sent for the "mother" PeerConnection, so the
> initial Offer for the new PeerConnection will be the second Offer for the
> remote party.
>
> At some point, we are going to have to add much more details about
> forking, in the case multiple PeerConnections are used. It is not enough to
> only say "create a new PeerConnection" :)
>
>
> ----------------
>
>
> >> Section 5.2.2:
> >> -----------------
> >>
> >>
> >> I don't understand this. Why would you create a new Offer while you are
> > Justin has asked for this in the case when the offer has not been sent
> to anyone else. This is not going to be useful for typical systems trying
> to have SIP or Jingle compatible flow but who knows ...
>
> Again, we have consensus to base JSEP on 3264. And, if we are going to
> deviate from 3264, I'd like to have some discussion and justification for
> that.
>

We have been through this many times before. The state machine that has
been in the JSEP document for a while clearly shows that
local-offer->local-offer state transitions are permitted.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 27 Sep 2013 18:52:54 +0000

Hi,

> We have been through this many times before.
>
> The state machine that has been in the JSEP document for a while clearly shows that local-offer->local-offer state transitions are permitted.

If we've been through this many times, I must have missed, or forgotten, each time :) Well, that can happen, so feel free to send me a link to a discussion/decission on this.

But, still, whatever deviations we agree to make to 3264, I would like to have it clearly documented - with justification.

In this case, I would also want to have it documented that the previous Offer is "cancelled", and that any associated pranswer/answer etc only applies to the latest offer.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 27 Sep 2013 19:15:16 +0000

Hi,

> It's not necessary to use NTP, since the session-id is already random. Starting the session id at zero makes it easier for developers see the changes to the session id. I can spell this out in the next version of the document.

I assume you mean the session version, because that is what is currently zero.

But, I am sure there is a reason why SDP recommends NTP. So, again, if we want to change that, we shall discuss it in MMUSIC.

And, if we agree to change it, clearly document and justify it.

> Currently the document specifies what to do with media lines, with later discussion of handling the SCTP line. Do you think the current information is not sufficiently descriptive?

My point was that we need to be more clear on what is generic, what is RTP, and what is SCTP. But, as you say SCTP text is still to be added, that clarification can be done when the SCTP text is added.

> no the initial offer will not have identical stuff other than on lines that "bundle-only"

Assuming you by identical mean port zero, we'll still have to agree on that. But, that discussion belongs to MMUSIC.

>Can you be specific about what more you think needs to be said? The createAnswer treatment of BUNDLE is one clear thing that is currently missing.

I want to have text covering both the 1st (unique address) and 2nd (shared address) Offer.

And, when a PeerConnection is created due to forking (ie you use a separate PeerConnection for each forked leg of a session), I assume already the 1st Offer for that PeerConnection can have a shared address (as the remote entity has indicated support for BUNDLE). That also needs to be covered.

Regards,

Christer

---

From: Justin Uberti <[email-masked]>
Date: Fri, 27 Sep 2013 14:48:10 -0700

On Fri, Sep 27, 2013 at 12:15 PM, Christer Holmberg <
[email-masked]> wrote:

>   > It's not necessary to use NTP, since the session-id is already
> random. Starting the session id at zero makes it easier for developers see
> the changes to the session id. I can spell this out in the next version of
> the document.
>

whoops :)

>
> But, I am sure there is a reason why SDP recommends NTP. So, again, if we
> want to change that, we shall discuss it in MMUSIC.
>

As long as what we are proposing is consistent with 3261 (the suggestion of
NTP is only SHOULD strength), and we explain why it should be done this way
in the rtcweb document (which the document already does, to some degree), I
don't think we need to argue about it in mmusic.

There are bigger fish to fry...

> >> Yep - I think this should be offers are created with RTP/SAVPF for
> audio and video and system can reeve offers with SAVPF or SAVP
> >
> My point was that we need to be more clear on what is generic, what is
> RTP, and what is SCTP. But, as you say SCTP text is still to be added, that
> clarification can be done when the SCTP text is added.
>

Sorry I was unclear - there is SCTP-specific text in the current document.

> that "bundle-only"
> Assuming you by identical mean port zero, we'll still have to agree on
> that. But, that discussion belongs to MMUSIC.
>
>
>
>
>
>
>
> >>> Q_6:      BUNDLE
> >>>
Acknowledged.

>
>
> And, when a PeerConnection is created due to forking (ie you use a
> separate PeerConnection for each forked leg of a session), I assume already
> the 1st Offer for that PeerConnection can have a shared address (as the
> remote entity has indicated support for BUNDLE). That also needs to be
> covered.
>
>
>
Yes. Which may indicate the need for a setting on a PeerConnection to use a
shared address on the initial offer, since it might have come from such a
fork.

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 28 Sep 2013 06:52:30 +0000

Hi,

>>>>> But, that of course only applies to RTP based streams (not the data channel). Also, in general, it needs to be clear what information
>>>>> needs to be in every m- line, and what information is protocol specific. I would suggest to have a “General” sub-section, a “RTP” sub-section, etc.
>>>>>
>>>>>

>Sorry I was unclear - there is SCTP-specific text in the current document.

Ok, so while the content itself might be ok, at some point I'd like to have separate sub-sections for the generic stuff, the RTP specicif stuff, and the SCTP specific stuff.

>> And, when a PeerConnection is created due to forking (ie you use a separate PeerConnection for each forked leg of a session), I assume

>> already the 1st Offer for that PeerConnection can have a shared address (as the remote entity has indicated support for BUNDLE). That also needs to be covered.

> Yes. Which may indicate the need for a setting on a PeerConnection to use a shared address on the initial offer, since it might have come from such a fork.

Excellent.

Regards,

Christer

---

From: Kevin Dempsey <[email-masked]>
Date: Mon, 30 Sep 2013 09:50:58 +0100

Can someone explain why the proto field is 'RTP/SAVPF' rather than
'UDP/TLS/RTP/SAVPF'?
We are using DTLS-SRTP after all.

On 28 September 2013 07:52, Christer Holmberg <
[email-masked]> wrote:

>> channel). Also, in general, it needs to be clear what information
>> >>>>> needs to be in every m- line, and what information is protocol
>> specific. I would suggest to have a “General” sub-section, a “RTP”
>> sub-section, etc.
>> >>>>>
>> >>>>>
>> >>> Currently the document specifies what to do with media lines, with
>> later discussion of handling the SCTP line. Do you think the current
>> information is not sufficiently descriptive?
>> >>
>>  >> My point was that we need to be more clear on what is generic, what
>> is RTP, and what is SCTP. But, as you say SCTP text is still to be added,
>> that clarification can be done when the SCTP text is added.
>>
>
> Ok, so while the content itself might be ok, at some point I'd like to
> have separate sub-sections for the generic stuff, the RTP specicif stuff,
> and the SCTP specific stuff.
>
>
>
>>     >>>>> Q_6:      BUNDLE
>> >>>>>
>> separate PeerConnection for each forked leg of a session), I assume
>>
>> >> already the 1st Offer for that PeerConnection can have a shared
>> address (as the remote entity has indicated support for BUNDLE). That also
>> needs to be covered.
>>
>> >>
>>
> > Yes. Which may indicate the need for a setting on a PeerConnection to
> use a shared address on the initial offer, since it might have come from
> such a fork.
>
> Excellent.
>
> Regards,
>
> Christer
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 30 Sep 2013 09:49:38 +0000

Hi Kevin,

I agree. According to RFC 5763 the correct value is UDP/TLS/RTP/SAVP.

Regards,

Christer

From: Kevin Dempsey [mailto:[email-masked]]
Sent: 30. syyskuuta 2013 11:51
To: Christer Holmberg
Cc: Justin Uberti; Cullen Jennings (fluffy); [email-masked]
Subject: Re: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)

Can someone explain why the proto field is 'RTP/SAVPF' rather than 'UDP/TLS/RTP/SAVPF'? We are using DTLS-SRTP after all.

On 28 September 2013 07:52, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

>>>>> needs to be in every m- line, and what information is protocol specific. I would suggest to have a "General" sub-section, a "RTP" sub-section, etc.
>>>>>
>>>>>

Excellent.

Regards,

Christer

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb