Re: [MMUSIC] Mirja Kühlewind's Discuss on draft-ietf-mmusic-sctp-sdp-23: (with DISCUSS)

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi Roman,

I think the problem is that someone who would not want to use ICE would not look at RFC6544. This means at least this part of RFC6544 is missing as general guidance in this draft:

"For media streams that are not RTP-based and do not normally use 
   RFC4571, the agent treats the media stream as a byte stream and assumes
   that it has its own framing of some sort, if needed.  It then takes
   an arbitrary number of bytes from the byte stream and places that as
   a payload in the RFC 4571 frames, including the length."

Usually duplicating text is not recommendable. However it this case it might be the easiest solution if you want to keep the document generally applicable even if you don’t use ICE. 

Also I’m not sure if the ICE part is fully specified. In your previously mail you wrote

"As far as TCP/DTLS/SCTP transport tag is concerned, please note that ICE end points are supposed to send a re-INVITE after nomination process is completed with the selected candidate address in the m= line. So, if tcp candidate is selected, re-INVITE must be sent with TCP/DTLS/SCTP transport tag in the m= line. Also, any offers/answers after the ICE nomination is complete, are supposed to send the currently selected candidate in the m= line, which will also be TCP/DTLS/SCTP in case tcp candidate is selected.“

From what I understood from ekr, you might not in any case send an re-invite; but maybe I understood this wrongly. I guess that could also be further explained in the draft.

Mirja


> Am 20.02.2017 um 10:49 schrieb Ben Campbell <[e-mail]>:
> 
>> 
>> On Feb 19, 2017, at 5:46 PM, Roman Shpount <[e-mail]> wrote:
>> 
> 
> [...]
> 
>> We are happy to add any informational content to describe the implications of running SCTP on top of TCP, but we would prefer not to redefine how ICE operates (including framing used for ICE TCP) in this draft. I think, generic ICE procedures belong in ICE related drafts.
> 
> I agree in principle; this draft is about signaling, not the media stream itself. But Mirja's comments suggest that the referenced specs may not fully describe how the stream works. Is there anything else we could reference (e.g.  RTCWEB data-channel or transports drafts) that would help clarify?  (Please feel free to argue that the referenced docs do in fact describe things sufficiently for the purposes of this draft, if you believe that to be true :-) )
> 
> 
> Thanks,
> 
> Ben.