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 <
christer.holmberg@ericsson.com> wrote:

>  Hi,
>
>
>
>>     >>>>> 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.
>
> 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
>> >>>>>
>> >>>>> 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.
>
> Excellent.
>
> Regards,
>
> Christer
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>