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

[Justin Uberti <[e-mail]>]

On Fri, Sep 27, 2013 at 12:15 PM, 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.
>
> I assume you mean the session version, because that is what is currently
> zero.
>

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.
>
> And, if we agree to change it, clearly document and justify it.
>

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

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

>
>
>
> >> 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"
>
> Assuming you by identical mean port zero, we'll still have to agree on
> that. But, that discussion belongs to MMUSIC.
>
>
>
>
>
>
>
> >>> 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.
>
>
>
> I want to have text covering both the 1st (unique address) and 2nd (shared
> address) Offer.
>
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.

>
>
> Regards,
>
>
>
> Christer
>
>
>
>