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

[Justin Uberti <[e-mail]>]

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

>
> Good points - proposed resolutions inline …
>
> On Sep 19, 2013, at 3:08 AM, Christer Holmberg <
> [e-mail]> 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.
>
> 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.


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

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

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?

> >
> >
> > 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?
>
> 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 :)
>

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.

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

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

exactly. This will be spelled out in setRemote processing.

>
> >
> >
> > Q_6:      BUNDLE
> >
> > We’ll probably also need some text about BUNDLE.
> >
>
> 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.

>
> >
> > Regards,
> >
> > Christer
> >
> > _______________________________________________
> > rtcweb mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rtcweb
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>