Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-jsep-06.txt - PeerConnection BUNDLE policy

From: Christer Holmberg <[email-masked]>
Date: Fri, 14 Feb 2014 14:22:46 +0000

Hi,

Section 4.1.1. defines, for the PeerConnection constructor, the possibility to specify BUNDLE policy.

However, I am missing the possibility to indicate whether, within a BUNDLE group, the same port number shall be used or not. 

Section 5.2.1 does say:

	"o  The port value is set to the port of the default ICE candidate for
      	this m= section; if this m= section is not being bundled into
      	another m= section, the port value MUST be unique."

...but, it doesn't talk about the case when the port IS being bundled into another m= section. Normally, in the initial Offer, the port value will be unique also in that case, but if the PeerConnection is created due to forking, and it is known that the remote peer supports BUNDLE, then identical port values can be used already in the initial offer.

Regards,

Christer

---

From: "Liuyan (Scarlett)" <[email-masked]>
Date: Mon, 17 Feb 2014 11:30:08 +0000

Hi,

Section 5.5.2 does say:

	"o  As described in Section 4.2.2, if the SCTP association is not yet
      established, then the newly created data channels are in the
      Connecting state, else if the SCTP association is already
      established, then the newly created data channels are in the Open
      state."
  .....
  It is not clear that if the SCTP association is failed to establish, how to we deal with the newly created data channels.
  Furthermore, how long the valid duration of the connecting state of the newly created data channels are before the SCTP association has not yet established ? 

Section 5.5.3 does say:
       "5.2.3.  Closing a data channel

      When the application requests the closing of a data channel that was
      externally negotiated, the browser always performs an in-band SSN
      reset for this channel.

      It is specific to the sub-protocol whether this closing must in
      addition be signaled to the peer via a new SDP offer/answer exchange.

      The application must also close any data channel that was externally
      negotiated, for which the stream identifiers are not listed in an
      incoming SDP offer."
   ...
   When there are multiple data channels with different sub-protocol per a SCTP association, 
Maybe it needs to identify how to close a single data channel, how to close all data channels with the same sub-protocol and how to close a SCTP association.
Of course, closing a SCTP association can just set SCTP port number zero.:-)
  
Regards,
Scarlett
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Richard Ejzak <[email-masked]>
Date: Tue, 18 Feb 2014 08:11:18 -0600

Hi Scarlett,
Please note that this document has been replaced by
draft-ejzak-mmusic-data-channel-sdpneg-00 (this is noted in datatracker)
and that discussion of the topic should be directed to the mmusic list
(although there is some obvious overlap with the data channel discussion
regarding external negotiation).  I copied both groups for this email only
- please respond only to mmusic.

" It is not clear that if the SCTP association is failed to establish, how
to we deal with the newly created data channels.
  Furthermore, how long the valid duration of the connecting state of the
newly created data channels are before the SCTP association has not yet
established ?"

This issue is common to all forms of data channel negotiation and should be
addressed by the core documents rather than this one.  It appears that a
data channel can be in the connecting state indefinitely until the peer
connection is closed.

"When there are multiple data channels with different sub-protocol per a
SCTP association,
Maybe it needs to identify how to close a single data channel, how to close
all data channels with the same sub-protocol and how to close a SCTP
association.
Of course, closing a SCTP association can just set SCTP port number zero.:-)
"

The procedure describes how to close a single data channel.  We did not see
a need to have a special way to close all data channels with the same
sub-protocol since they can just be closed individually.  I don't see a
compelling use case for this, but perhaps you have one?  The document
should point out that data channels terminate with the SCTP association and
peer connection.  Sometimes we forget to state the most obvious things!

BR, Richard

On Mon, Feb 17, 2014 at 5:30 AM, Liuyan (Scarlett) <
[email-masked]> wrote:

>   It is not clear that if the SCTP association is failed to establish, how
> to we deal with the newly created data channels.
>   Furthermore, how long the valid duration of the connecting state of the
> newly created data channels are before the SCTP association has not yet
> established ?
>
> Section 5.5.3 does say:
> Maybe it needs to identify how to close a single data channel, how to
> close all data channels with the same sub-protocol and how to close a SCTP
> association.

---

From: Justin Uberti <[email-masked]>
Date: Tue, 18 Feb 2014 23:27:09 -0800

On Fri, Feb 14, 2014 at 6:22 AM, Christer Holmberg <
[email-masked]> wrote:

> However, I am missing the possibility to indicate whether, within a BUNDLE
> group, the same port number shall be used or not.
>
> Section 5.2.1 does say:
>
> ...but, it doesn't talk about the case when the port IS being bundled into
> another m= section. Normally, in the initial Offer, the port value will be
> unique also in that case, but if the PeerConnection is created due to
> forking, and it is known that the remote peer supports BUNDLE, then
> identical port values can be used already in the initial offer.
>

If a m= section is being bundled into another m= section, then the port
number must be the same, as indicated in the BUNDLE WG draft.

I did not include a policy option to force use of the same port; the
closest thing would be to use a policy of "all", which will mark all lines
except the first as bundle-only and achieve basically the same result,
although it would require a second offer to update the bundle-only ports.
If this is a problem we could consider adding another policy value.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 24 Feb 2014 17:02:44 +0000

Hi,

>> ...but, it doesn't talk about the case when the port IS being bundled into another m= section. Normally, in the initial Offer, the port value will be 
>> unique also in that case, but if the PeerConnection is created due to forking, and it is known that the remote peer supports BUNDLE, then 
> If a m= section is being bundled into another m= section, then the port number must be the same, as indicated in the BUNDLE WG draft. 

Before it is known whether the remote peer supports BUNDLE, each m= line must have a unique port number.

> I did not include a policy option to force use of the same port; the closest thing would be to use a policy of "all", which will mark all lines except the 
> first as bundle-only and achieve basically the same result, although it would require a second offer to update the bundle-only ports. If this is a 
> problem we could consider adding another policy value.

Not sure I follow. I think the usage of bundle-only is a separate issue.

The use-case I have in mind is where I want to guarantee interoperability, so I'd choose the "max-compat" policy.

However, I do need to be able to indicate whether the m= lines should have the same port number or not (again, depending on whether the remote peer has indicated support of BUNDLE or not).

Regards,

Christer