Subject: [rtcweb] draft-ietf-rtcweb-sdp-02 submitted

From: Suhas Nandakumar <[email-masked]>
Date: Fri, 8 Jul 2016 07:56:17 +0530

Hello All

   We have submitted the -02 version of RTCWEB SDP examples draft which
went through quite a bit of content re-shuffling and updates to match
(attempt) the latest versions of BUNDLE, JSEP and related drafts.

Many thanks to Paul for starting the review of the draft that triggered few
formatting changes, changes related to consistency of attribute values and
their ordering, to enhance the readability throughout the draft.

Please refer to the following HTML version while reviewing/reading the
draft:

https://tools.ietf.org/id/draft-ietf-rtcweb-sdp-02.html

[[ It might take a short while for the data-tracker to render the above
HTML version though ]]

Here is the high-level summary of changes
1. As far as possible, the examples reflect latest BUNDLE and JSEP
requirements.
2. SCTP examples are updated
3. Visual markers, separators are added in the SDP table
4. SSRC values, IP Address , Port numbers, CNAMEs are consistent to a great
extent now
5. Attributes ordering is consistent across all the examples now
6. RID, Simulcast examples are matched against their latest draft versions.

Please give it a read and let us know your comments/feedback.

Cheers
Suhas/Cullen

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 12 Jul 2016 09:55:29 +0200

Hi!

Some notes from my first reading of this document:

* Abstract
"This SDP examples provided in this document is still a work in
   progress, but it aims to align closest to the evolving standards
   work.
“
s/This/The/
s/closest/closely/   (maybe :-) )

* 1. Introduction
"For this purpose, SDP is used to
   construct [RFC3264 <https://tools.ietf.org/html/rfc3264>] Offers/Answers for describing (media and non-
   media) streams as appropriate for the recipients of the session
   description to participate in the session.
“
I am hesitant to separate “media and non-media” so early in this document.
If we refer to the definitions in RFC 3264 there’s only “media stream” and 4566 seems 
to include everything - not just multimedia - in “media stream”.

Do we have a reference for a non-media stream?

* Section 3
"[WebRTC <>] proposes JavaScript application to fully specify and control
   the signaling plane of a multimedia session as described in the JSEP
   specification [I-D.ietf-rtcweb-jsep <https://tools.ietf.org/html/draft-ietf-rtcweb-sdp-02#ref-I-D.ietf-rtcweb-jsep>]. “

s/application/applications/

Maybe add a third bullet describing SDP’s function to bind the SDP
to the actual media - the ice-pwd’s. There’s a transitive trust
there which we could mention in the bullets.

* Section 4
Do we have a definition of a "WebRTC session” somewhere?

"The Offer/Answer [RFC3264 <https://tools.ietf.org/html/rfc3264>] model specifies rule for the bilateral
   exchange of Session Description Protocol (SDP) messages for creation
   of multimedia streams.
“
s/rule/rules/
I would add “bidirectional” in the front of “multimedia streams”

"It defines protocol with involved
   participants exchanging desired session characteristics from each
   others perspective constructed as SDP to negotiate the session
   between them.”
This sentence is hard to parse and need a rewrite. Maybe something along

“It defines a protocol which enables participants of a desired session
to exchange session characteristics, based on a SDP constructed
from their own perspective”

I would NOT use the word negotiate here. It’s not really negotation,
it’s an offer/answer exchange… It’s really hard to describe when I’m
trying to teach people SDP, but I found that the word “negotiate” 
puts them in the wrong place. Multiple offer/answer exchanges can be
seen as a negotiation though.

"If the session is accepted the Offer/Answer model
   guarantees a common view of the multimedia session between the
   participants.”
After many years of working with SIP and SDP offer/exchanges I 
would avoid the word “guarantees” in this very sentence. ;-)

"At any time, either participant MAY generate a new SDP offer that
   updates the session in progress.”
Since this is the brief overview aimed to educate SDP offer/answer,
I would rephrase this to:
“At any time either participant MAY initiate a new offer/answer
exchange to update a session in progress by generating a new SDP offer.”

"With in the context of WebRTC, the Offer/Answer model defines the
   state-machinery for WebRTC peers to negotiate session descriptions
   between them during the initial setup stages as well as for eventual
   session updates.”
There’s the word “negotiate” again. And you don’t negotiate SDPs,
you negotiate "webrtc sessions” or “sessions”. 

5. WebRTC SDP examples
The term “non-media” is used here again.

"Supports NAT traversal using ICE mechanism”
I don’t agree that ICE is there to support NAT traversal. It’s a 
way to describe it that leads to a lot of misunderstandings. The TURN
server supports NAT traversal, ICE is a discovery protocol to find the
optimal stream path. ICE is also the way to handle dual stack networks.
Maybe rephrasing it would be a good idea to avoid
future misunderstandings:
“Supports optimal network path discovery and NAT traversal using ICE and TURN mechanisms”

Section 5.1:
s/Eventhough/Even though/
s/an WebRTC/a WebRTC/

I’ve only glanced over the actual examples, it will need much more time. Here’s
a few quick comments:

- a=inactive in 5.2.4 has a reference to RFC 3264. I think a proper reference
  would be RFC 4566 SDP
- 5.2.5: DTMF is no longer RFC 2833 - it is 4733 now.

General:
I would like to see some examples using the current IP protocol, not the legacy IPv4,
as well as dual stack examples.

- An IPv6 only web browser offering an IPv4 through a relay ice candidate
- A dual stack client
- A full IPv6 exchange - maybe switch one of the examples using IPv4 to IPv6
  just to show the syntax of address and port number

Regards,
/Olle

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 12 Jul 2016 14:10:23 +0200

> On 12 Jul 2016, at 09:55, Olle E. Johansson <[email-masked]> wrote:
> 
> 
> General:
In addition I think an offer/answer with different packetization times, like
alaw/30 ms, Opus/60 ms or something similar. Yes, I’m going down a rat hole,
but it will come up and we’d better document a proposal for how to handle this.

If one wants to be messy you can add DTMF or CNG to an offer/answer using
alaw at 8000 hz and Opus at 48000 making it necessary to have multiple DTMF
and CNG for that media stream. But that may be out of scope for this particular
document, even though it may add clarity.

/O

---

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 12 Jul 2016 18:15:06 +0530

Hello Olle

  Thanks for the review. I will go through the other comments in a while
but wanted to share one thought on the ptime feedback

JSEP-15 says

   - If this m= section is for media with configurable frame sizes, e.g.
   audio, an "a=maxptime" line, indicating the smallest of the maximum
   supported frame sizes out of all codecs included above, as specified in
   [RFC4566]
   <https://tools.ietf.org/id/draft-ietf-rtcweb-jsep-15.html#RFC4566>,
   Section 6."

The current set of examples try to follow JSEP specification to the closest
in how the SDP is constructed barring few open issues on handing certain
attributes

Please let us know your thoughts  on various ptimes across codecs is
something that should go in JSEP spec SDP rules as well ?

Thanks
Suhas

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 12 Jul 2016 15:02:02 +0200

> On 12 Jul 2016, at 14:45, Suhas Nandakumar <[email-masked]> wrote:
> 
> Hello Olle
> 
>   Thanks for the review. I will go through the other comments in a while but wanted to share one thought on the ptime feedback
> 
> JSEP-15 says
> If this m= section is for media with configurable frame sizes, e.g. audio, an "a=maxptime" line, indicating the smallest of the maximum supported frame sizes out of all codecs included above, as specified in [RFC4566] <https://tools.ietf.org/id/draft-ietf-rtcweb-jsep-15.html#RFC4566>, Section 6.”
That’s a good setting, but not the same. If you have codec Y with ptimes settable from 10 to 130 and codec Z with ptimes settable from 20 to 250,
the maxptime would be 130 if I understand you right.

What I am looking for is the weird situation where I want to offer codec Y with the default ptime of 40 and codec Z with the default ptime of 50.
This is a wormhole, since the a=ptime setting is kind of a mystery that a few brave people have been trying to solve - does it apply
to ALL codecs in a offered stream and if so - how to we handle an offer like above. Codec Y and codec Z may have incompatible
ptimes too, so one default ptime for the stream may not work at all. 
> 
> The current set of examples try to follow JSEP specification to the closest in how the SDP is constructed barring few open issues on handing certain attributes
Ok, then this issue, which is generic SDP may be out of scope for this document - but it will pop up at some unspecified time
in the future so I wanted to suggest that the time is now. 
> 
> Please let us know your thoughts  on various ptimes across codecs is something that should go in JSEP spec SDP rules as well ?
I need to look a bit more into JSEP for that. While waiting for me to do that, others may offer their opinions :-)

/O
> 
> Thanks
> Suhas
> 
> On Tue, Jul 12, 2016 at 5:40 PM, Olle E. Johansson <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On 12 Jul 2016, at 09:55, Olle E. Johansson <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> General:

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Jul 2016 12:00:32 +0000

Hi,

The examples are not aligned with all of the latest versions of associated drafts. See below.

Q1:

Assuming we want to be compliant with draft-ice-5245bis (even though both JSEP and your draft still reference RFC 5245), you should use the SDP 'ice-options: ice2’ attribute (draft-ietf-mmusic-ice-sip-sdp).

Q2:

I think the SDP ‘dtls-id’ attribute (draft-ietf-mmusic-sdp-dtls) should be added.

Q3:

According to draft-bundle, you need to include the SDP ‘rtcp-mux-only’ attribute in bundle-only m- lines.

Also in general I think it would be good to have some mux-exclusive examples, since they support of non-mux is optional (and since some vendors have indicated that they will not support non-mux long term).

Regards,

Christer

From: rtcweb <[email-masked]<mailto:[email-masked]>> on behalf of Suhas Nandakumar <[email-masked]<mailto:[email-masked]>>
Date: Friday 8 July 2016 at 05:26
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [rtcweb] draft-ietf-rtcweb-sdp-02 submitted

Hello All

   We have submitted the -02 version of RTCWEB SDP examples draft which went through quite a bit of content re-shuffling and updates to match (attempt) the latest versions of BUNDLE, JSEP and related drafts.

Many thanks to Paul for starting the review of the draft that triggered few formatting changes, changes related to consistency of attribute values and their ordering, to enhance the readability throughout the draft.

Please refer to the following HTML version while reviewing/reading the draft:

[[ It might take a short while for the data-tracker to render the above HTML version though ]]

Here is the high-level summary of changes
1. As far as possible, the examples reflect latest BUNDLE and JSEP requirements.
2. SCTP examples are updated
3. Visual markers, separators are added in the SDP table
4. SSRC values, IP Address , Port numbers, CNAMEs are consistent to a great extent now
5. Attributes ordering is consistent across all the examples now
6. RID, Simulcast examples are matched against their latest draft versions.

Cheers
Suhas/Cullen

---

From: Suhas Nandakumar <[email-masked]>
Date: Thu, 14 Jul 2016 18:33:43 +0530

Hello Christer

 Thanks for reviewing the draft. Here are few general comments on how the
SDP examples are laid out in the current version
  - It aligns closest to JSEP-14 and its dependencies
  - Wherever there is  conflicts between JSEP-14 and BUNDLE-31 , i made a
choice to stick with JSEP-14

In our presentation at IETF-96 we plan to bring up these differences as one
of the open issues

Please see inline for specific feedback items.

On Thu, Jul 14, 2016 at 5:30 PM, Christer Holmberg <
[email-masked]> wrote:

> Assuming we want to be compliant with draft-ice-5245bis (even though both
> JSEP and your draft still reference RFC 5245), you should use the SDP 'ice-options:
> ice2’ attribute (draft-ietf-mmusic-ice-sip-sdp).
>
> [suhas] - Agree .. it is one of open issues on draft alignments with JSEP

> I think the SDP ‘dtls-id’ attribute (draft-ietf-mmusic-sdp-dtls) should
[suhas] . same issues as previous one. JSEP-15 doesn't list
draft-ietf-mmusic-sdp-dtls as dependency

> Also in general I think it would be good to have some mux-exclusive
> examples, since they support of non-mux is optional (and since some vendors
> have indicated that they will not support non-mux long term).
>
>
[suhas] .. There are few offers that include rtcp-mux-only (atleast 5.3.1)
.. I agree we can add concrete examples on this. Also to note JSEP doesn't
list rtcp-mux-only in its SDP construction rules.  We hope to clarify these
open issues at the upcoming meeting.

>
> Regards,
>
> Christer
>
>
>
>
> From: rtcweb <[email-masked]> on behalf of Suhas Nandakumar <
> [email-masked]>
> To: "[email-masked]" <[email-masked]>
> Many thanks to Paul for starting the review of the draft that triggered
> few formatting changes, changes related to consistency of attribute values
> and their ordering, to enhance the readability throughout the draft.
>