Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg: external rejection of channel

[Paul Kyzivat <[e-mail]>]

I would like some clarity about how this interacts with DCEP.

IMO these are not mutually exclusive. But they must be used with care.

So, when a channel that was in the SDP previously then disappears from 
the SDP it is necessary to close the corresponding channel. But channels 
that were opened via DCEP should not be closed.

That also means that one should never mention a DCEP channel in SDP.

	Thanks,
	Paul

On 2/26/14 3:12 PM, Makaraju, Maridi Raju (Raju) wrote:
> Please find my comments inline.
>
> But, there is no text on rejecting a data channel in the SDP answer.
>
> The answer can of course reject the whole m- line, using port zero in
> the Answer m- line. But, how does the answerer reject an individual
> sub-protocol data channel?
>
> Only attributes for "accepted data channels" are included in the SDP
> answer, which indicates back to the offerer which ones are rejected
> (they just aren't there).  This should be made clearer in the text.
>
>     Section 5.1.1 says, regarding the SDP dcmap attribute, for accepted
>     data channels:
>
>     “This line MUST be replicated without changes in the SDP answer, if
>
>                      the answerer accepts the offered data channel.”
>
>     I guess one way to reject would be to simply not include the dcmap
>     attribute in the Answer, and the Offerer then needs to figure out
>     what was rejected based on the stream values not present in the Answer.
>
> Yes.  That is what was intended.
>
> /[Raju] In addition to the above mentiooed cases, if we all agree we
> need to add the following cases in the next draft:/
>
> */1./*SDP offer has no a=dcmap. This has two use cases:
>
> a.Initial SDP offer: no data channel streams (DCS) are open yet.
>
> b.Subsequent SDP offer: Remove all previously opened data channels/streams.
>
> In either case, the SCTP association is kept open (and ICE procedures
> are performed) even when no data channels are in use.
>
> */2./*Creation of new DCS(s) using SDP offer (initial or subsequent)
>
> a.Offerer has to create the data channels locally first by doing
> createDataChannel or equivalent API into data channel stack before
> sending offer.
>
> */3./*SDP offer was rejected
>
> a.DCSs are kept per previous SDP offer/answer. This means DCSs that are
> to be deleted has to be deleted (i.e. calling createDataChannel or
> equivalent API) only after successful SDP answer.
>
> b.If any new DCSs are attempted to be created per new SDP offer, these
> have to be closed now.
>
> */4./*Per
> http://dev.w3.org/2011/webrtc/editor/webrtc.html#dom-peerconnection-createdatachannel
> createDataChannel() API the ‘external’ negotiation field is per data
> channel.  But this draft only allows external negotiation to be used for
> all or no streams; it can’t be selective. This restriction is also
> needed so that the SDP offer/answer odd/even stream id allocation won’t
> conflict DCP’s TLS role based odd/even mechanism.
>
> Best Regards!
>
> Raju
>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>