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

Hi Kevin,

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

Regards,

Christer

From: Kevin Dempsey [mailto:kevindempsey70@gmail.com]
Sent: 30. syyskuuta 2013 11:51
To: Christer Holmberg
Cc: Justin Uberti; Cullen Jennings (fluffy); rtcweb@ietf.org
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 <christer.holmberg@ericsson.com<mailto: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<mailto:rtcweb@ietf.org>
https://www.ietf.org/mailman/listinfo/rtcweb