Re: Symmetrical streams

On 07/01/11 05:12, jywang wrote:
> Hi stefan,
>
> I think a PeerConnection object maybe is good to group streams which should be
> transmited in the same 5-tuple, and another object can be created if need.
>
> In this way, the developer can do their selection, and the service provider also
> understand how to decide. However, we have to constrain the PeerConnection's
> concept for this purpose.
I don't think the PeerConnection today is a good description of mapping 
to RTP sessions.

The currently accepted wisdom in IETF is that between two peers, there 
should be one RTP session containing all the video media, and one RTP 
session containing all the audio data. Whether the two RTP sessions are 
distinguished by 5-tuple or by some other means, and if there really 
needs to be two, is still a debate.

It's logical for these RTP sessions to be bidirectional.
> -Wang Jinyi
> -CNIC CAS
> ----- Original Message -----
> From: "Stefan Håkansson LK"<stefan.lk.hakansson@ericsson.com>
> To: "jywang"<jywang@cnic.cn>
> Cc: "Cullen Jennings"<fluffy@cisco.com>;<public-webrtc@w3.org>
> Sent: Thursday, June 30, 2011 9:55 PM
> Subject: Re: Symmetrical streams
>
>
>> On 2011-06-30 05:03, jywang wrote:
>>> -Wang Jinyi
>>> -CNIC CAS
>>> ----- Original Message -----
>>> From: "Stefan Håkansson LK"<stefan.lk.hakansson@ericsson.com>
>>> To: "Cullen Jennings"<fluffy@cisco.com>
>>> Cc:<public-webrtc@w3.org>
>>> Sent: Thursday, June 30, 2011 2:08 AM
>>> Subject: RE: Symmetrical streams
>>>
>>>
>>>
>>> ________________________________________
>>> From: Cullen Jennings [fluffy@cisco.com]
>>> Sent: Wednesday, June 29, 2011 7:50 PM
>>> To: Stefan Håkansson LK
>>> Cc: public-webrtc@w3.org
>>> Subject: Re: Symmetrical streams
>>>
>>> On Jun 29, 2011, at 2:32 AM, Stefan Håkansson LK wrote:
>>>
>>>>> (The discussion below involves PeerConnection. As we all know this is only one of the API proposals, and no decision has been
>>>>> taken on what starting point(s) the WG should use. But I thought it would be nice to discuss API functionality for a change!
>>>>> And
>>>>> the discussion may be relevant for the other API as well.)
>>>>>
>>>>> It is likely that many uses of APIs for real-time communication will be for symmetrical services - symmetrical in the sense
>>>>> that
>>>>> the Streams flowing from A to B will have counterparts flowing from B to A.
>>>>>
>>>>> Video conferencing is a typical example, there will likely be one Stream containing one audio and one video component from A to
>>>>> B
>>>>> and a corresponding Stream from B to A.
>>>>>
>>>>> For cases when all streams are not multiplexed over the same 5-tuple it would be beneficial if the IP-addresses and ports found
>>>>> to work for the A to B streams are re-used for B to A streams for several reasons:
>>>>> -reduce NAT traversal problems
>>>>> -simplify QoS handling
>>>>> -simplify interop with legacy systems
>>>>>
>>>>> However, in the current PeerConnection API there is no way ask for pairing symmetrical Streams in this way. There are several
>>>>> ways this could be added, one way could be to add a second Stream as a second (optional) argument to addStream. When this
>>>>> argument is used the PeerConnection pairs the transport of the added Stream with the incoming Stream (identified by the label).
>>>>>
>>>>> The use would be (refer to http://www.whatwg.org/specs/web-apps/current-work/webrtc.html#peer-to-peer-connections):
>>>>> 1. A side does addStream with a locally generated Stream as argument
>>>>> 2. B side gets an onaddstream event
>>>>> 3. B side does addStream with a locally generated Stream _and_ the received Stream as arguments
>>>>> 4. Under the hood the PeerConnections makes the Streams use the same 5-tuples for transport
>>>>>
>>>>> (Other options include:
>>>>> * adding an optional argument to addStream that the A side uses to indicate that a return stream is expected; the application
>>>>> on
>>>>> the B side is notfied about this and is expected to provide a Stream
>>>>> * having the PeerConnections automatically re-use open channels; if there is an RTP audio stream flowing from A to B, and B
>>>>> adds
>>>>> a Stream that contains an audio component, that audio would flow on the same channel)
>>>>>
>>>>> Comments?
>>>> Hi Stefan,
>>>> I agree we need want to have this symmetry property when possible. When I read the whatwg proposal I just>assumed that it
>>>> actually
>>>> worked in the  way you mention on your last option ( the PeerConnections automatically>re-use open channels ). Upon closer
>>>> reading, it does not seem to say that all. I'll have to think more about this but>having the underly thing setting up the
>>>> streams
>>>> just take care of this seem like a nice property.
>>>> I guess the question comes down to step 3 of your proposal - do we need to pass the received Stream or not?>Either way sees like
>>>> the underlying function could figure it out.
>>>> Thoughts?
>>> Hi Cullen,
>>>
>>> yes I agree to that what it basically comes down to is: should this be visible from the API (either when A side adds a Stream, or
>>> when B side does as a response to the A side's new stream) or not.
>>>
>>> Stefan
>>>
>>> Hi All,
>>>
>>> Is there any valuable use case which show that an application or a user need to know this, or they want to configure streams
>>> separately?
>> What I can think of is a situation where there is more than one symmetrical Stream pair; if one of these are to be torn down and
>> they haven't been properly paired at set up you would leave more connections open than required.
>>
>> I can't say how common or relevant this would be though.
>>> Making this property is visible or not is not a difficult thing, isn't it?
>>> Therefore, if we need the visibility for some cases, we should open this feature to user; otherwise, leave this issue to the
>>> underly
>>> thing.
>>> Moreover, the property can be added in the future.
>>>
>>> Wang Jinyi
>>>
>>>
>>>
>
>
>
>
>

Received on Monday, 11 July 2011 08:12:53 UTC