RE: Issue 155: Implicit gatherer/listener

Forwarding....

-----Original Message-----
From: Jiannan Zheng 
Sent: Tuesday, October 14, 2014 9:45 AM
To: Peter Thatcher
Cc: Bernard Aboba
Subject: RE: Issue 154: RTCP Port Control


we have the same goal that we don't want to churn the spec too much at this stage. 

two topics, let's go over them one by one, 

first, let's agree there is a disagreement. The move of gather() to listener (together with the constructor/start change in the ice trasnport) has an unexpected behavior change impacting the demux scenario. 
It is an unfortunate bug we identified late. Somehow I cannot even find the issue ID for it... I would suggest we reopen that issue and see if we can address that specific issue without impacting other part of the protocol. 
My take is to keep the move as is but introduce an optional parameter in the IceGatherer constructor for the association, it should have the mimimum impact for everybody; or we take a more formal path to move the createassociated* function. 

second, about other solutions
My team is implementing the ORTC engine for IE/Skype and we have a real blocker with our known scenarios. 
Introducing UDP transport doesn't solve the diffserv port range issue for ICE.   
Demoting to UDP is something we will propose after this initial phase of ORTC. In a system which could fork SIP/SDP to PSTN GW and other clients, we will need such capability. However it seems a very long route and partial solution for today's problem. 

For your GW question, no, Microsoft doesn't build any PSTN GWs. This whole demux (and SDES) issue is about inter-op with older clients/GWs. We took the headache of introducing demux in ORTC but threw in a blocker in the last minute to make the value less.

thanks, 

-Jiannan 



________________________________________
From: Peter Thatcher <pthatcher@google.com>
Sent: Tuesday, October 14, 2014 8:33 AM
To: Jiannan Zheng
Cc: Bernard Aboba
Subject: Re: Issue 154: RTCP Port Control

Let me see if I understand this correctly:  You have customers who want to use the ORTC API to do interop with endpoints that don't speak ICE and don't speak DTLS and has certain constraints on what the port ranges should be.  Is that correct?

Are these ORTC clients web clients or native clients?  If they are native clients, then you can just add whatever you want to the API you are giving your customers.  Going slightly outside the bounds (such as adding a parameter for "this is RTCP") of the standard is less of an issue with a native library.  If they are web clients, then in what kind of time frame do they need a solution to this?  Because it's going to be a while before any browser has an implementation of ORTC, as far as I know.

But given your description of the problem to be solved, I think a different approach would make more sense.  In our original designs of ORTC, we anticipated having more objects available for native applications, such as SdesTransport (instead of DtlsTransport) and UdpTransport (instead of IceTransport), etc.  If you're speaking so something that's non-ICE and non-DTLS and needs tight control of ports, I think an SdesTransport (or no crypto?) on top of a UdpTransport would (with tight port controls) would make more sense than trying to use the IceTransport and DtlsTransport objects to speak to something that doesn't do ICE and DTLS.

On last question:  Do you plan on updating your PSTN gateway to speak ICE and DTLS?  If so, can't you just updated it to also do RTCP-mux?
It's so simple to add, and would simplify so many things.






On Mon, Oct 13, 2014 at 11:14 PM, Jiannan Zheng <jzheng@exchange.microsoft.com> wrote:
> Hi, Peter,
>
> emm... it looks like my mail is not forwarded by the mail list... anyway let's communicate in a little bit offline fashion so that we don't make a scene.
>
> The discussion keeps on shifting from the initial topic, the onlocalcandidate move to ice lisenter was for something totally not related to rtcp demux. This side-effect behavior change is not expected and we want to look for a way to keep the gatherer move but leave the rest of the protocol behavior stable. This change created major complexity in my implementation to inter-op with my existing customers and it is a blocker on my side.
>
> I want to understand the complexity delta on your side. If moving the createassociated* is too much and I am open to other less heavy proposals. What I need is a hint at the 2nd gatherer creation about the association, even an optional parameter of the first gatherer in the constructor can do the work, other implementations can choose to ignore the parameter.
>
> Regarding the diffserv with port range, indeed we have such deployment and ORTC cannot handle it as of now. Doing a +1 internally is a practical hack to reduce the risk of doing things very wrong, like leaving RTCP in diffserv-ed range while RTP not. We may need a proposal to set browser level policies like the preferred port range for audio/video etc.
>
> thanks,
>
> -Jiannan
>
>
>
>
>
>
> ________________________________________
> From: Peter Thatcher <pthatcher@google.com>
> Sent: Monday, October 13, 2014 9:50 PM
> To: Jiannan Zheng
> Cc: Bernard Aboba; public-ortc@w3.org
> Subject: Re: Issue 154: RTCP Port Control
>
> Sorry, I don't mean to be so difficult about this, but I think the API 
> has already added so much complexity for the case where the remote end 
> point doesn't do RTCP mux, and I really don't want to see more added 
> if we don't really need it.
>
> On Mon, Oct 13, 2014 at 8:13 PM, Jiannan Zheng 
> <jzheng@exchange.microsoft.com> wrote:
>> Hi,
>>
>> First let's acknowledge there was a behavior change impacting RTP/RTCP de-mux scenario, in theory such change should get some agreement.
>>
>> RTP/RTCP in nature should be associated, otherwise the whole RTP RTT calculation will be all wrong. We either solve it by mux-ing them, or in legacy system, hinting it, like +1.
>
> The behavior change is that the browser doesn't know whether it's RTCP 
> or not while it's gathering.  It only knows once it goes beyond 
> gathering.  But I don't think the browser needs to know during the 
> gathering phase.
>
>> Another example would be you are on a port range based diffserv network configuration, having totally unrelated local port allocation could end up with RTP/RTCP falling into different diffserv port range.
>
> In a scenario like that, wouldn't we need a more advanced way to tell 
> the browser what kinds of ports to use anyway?  The RTP/RTCP 
> distinction wouldn't be enough.  Even using RTP_PORT+1 could fall on a 
> port range boundary.
>
>>
>> UDP demotion is the same/similar case of +1, it is about existing PSTN GWs don't support ICE/DTLS. We cannot build a SIP gateway without more extensions and special handling of RTP/RTCP de-mux in ORTC. This is beyond the worry of today's infant ORTC, but we'd better not close the whole door.
>
> I think any endpoint that doesn't speak ICE and DTLS is out scope for ORTC 1.1.
>
> If some future version of ORTC wants to try and speak non-ICE and 
> non-DTLS to legacy clients with interesting port requirements, then 
> I'm guessing we'd end up with a quite a different API (perhaps a 
> RawUdpTransport instead of IceTransport and DtlsTransport), and we can 
> think about what that would be like at that point in time.  For now, I 
> think it's out of scope.
>
>
>
>
>
>>
>> Thanks,
>>
>> -Jiannan
>>
>> -----Original Message-----
>> From: Peter Thatcher [mailto:pthatcher@google.com]
>> Sent: Monday, October 13, 2014 6:21 PM
>> To: Jiannan Zheng
>> Cc: Bernard Aboba; public-ortc@w3.org
>> Subject: Re: Issue 154: RTCP Port Control
>>
>> I think the big question you bring up in your email is:  does the IceGatherer (aka IceListener) need to know if the candidates it is gathering are for RTP or RTCP?  I think in general, the answer is "no", the IceGatherer doesn't care.
>>
>> However, you point out two use cases that could perhaps be solved with IceGatherer knowing.  Once is "+1 port for RTCP" and the other is "UDP demotion".  I don't see the "+1 port" use case as very compelling since I don't think there are any PSTN gateways (or any legacy clients, for that matter) that speak both ICE and DTLS but require this RTCP port behavior.  Do you know of any?
>>
>> The second use case you mention is "udp demotion".  I'm not familiar with that one.  Can you explain what a JS app would need to do be able do, or expect the browser to do, that it can't right now?
>>
>>
>>
>>
>> On Sat, Oct 11, 2014 at 9:44 AM, Jiannan Zheng <jzheng@exchange.microsoft.com> wrote:
>>> With the move of candidate gathering callback to the ICE gatherer class, we accidentally introduced a behavior change in the RTP/RTCP demux.
>>>
>>> 6/15 spec says:
>>> "createAssociatedTransport
>>> Create an associated RTCIceTransport for RTCP, and implicitly create a newly associated RTCIceListener object as well for RTCP, or reusing an existing RTCP RTCIceListener if one is already associated with the existing RTP RTCIceListener. If called more than once for the same component, throw an InvalidStateError exception. If called when component is "RTCP", throw a SyntaxError exception.
>>> "
>>> We do not do the "implicitly create a newly associated RTCIceListener object as well for RTCP, or reusing an existing RTCP RTCIceListener if one is already associated with the existing RTP RTCIceListener" any more with the move.
>>>
>>> Assuming we still do offer/answer, with the callback in ice transport and createassociatedtrasnport() call, browsers knows the RTP/RTCP association before generating the initial offer. After the move, because ice transport start needs the remote ice parameters, browser can only know this RTP/RTCP association after the answer.  We pretty much mandate the RTP/RTCP local candidate gathering should not be associated. It closes the door to support extensions like UDP demotion,which is needed to call many existing PSTN gateways and some of them needs this +1 behavior.  This is not a minor behavior change and we may need more discussions if we indeed want to take this 6/15 "associated listener" behavior out.
>>>
>>> The suggestion to move createassociated* together with the onlocalcandidate callback can keep the association behavior the same and satisfy the onlocalcandidate move request. It sounds to me a better solution.
>>>
>>> thanks,
>>>
>>> -Jiannan
>>>
>>> ________________________________________
>>> From: Bernard Aboba <Bernard.Aboba@microsoft.com>
>>> Sent: Wednesday, October 08, 2014 6:10 PM
>>> To: Peter Thatcher
>>> Cc: public-ortc@w3.org
>>> Subject: Re: Issue 154: RTCP Port Control
>>>
>>> I think the question is more about where createAssociated belongs. When local candidate gathering was moved from the ICE Transport to the ICE gatherer, should createAssociated have moved with it? That would leave RTCIceTransport.component undetermined until .start is called (at which time it would be inherited from the gatherer). But this seems like it wouldn't be a big problem.
>>>
>>>
>>>
>>>> On Oct 8, 2014, at 1:17 PM, Peter Thatcher <pthatcher@google.com> wrote:
>>>>
>>>> The application can keep around state about which candidates go 
>>>> with RTP and which go with RTCP.  It's not that hard for a handler 
>>>> to have access to that state (it can even just be a closure, I 
>>>> think).  I don't think the platform needs to do anything special to help it.
>>>>
>>>> On Wed, Oct 8, 2014 at 12:59 PM, Bernard Aboba 
>>>> <Bernard.Aboba@microsoft.com> wrote:
>>>>> A related issue is that currently the RTCIceGatherer does not have a "component" property as the RTCIceTransport does.  One awkward implication of this is that the onlocalcandidate Event handler cannot determine the component of the ICE candidate based on properties of the RTCIceGatherer object because there is no RTCIceGatherer.component attribute.
>>>>>
>>>>> To get around this, the sample code creates RTCIceTransport objects with names corresponding to the names of the RTCIceGatherer objects.  However, prior to calling RTCIceTransport.start (which may only occur quite a bit after creation of the RTCIceTransport and RTCIceGatherer objects) there is no association between an RTCIceTransport and RTCIceGatherer.
>>>>>
>>>>> A somewhat more straightforward way to handle this would be to have an RTCIceGatherer.createAssociatedGatherer method, as well as an RTCIceGatherer.component attribute.
>>>>> If we did this, I don't think we would need an RTCIceTransport.createAssociatedTransport() method.  Instead, the RTCIceTransport component could be determined from RTCIceTransport.gatherer.component.
>>>>> ________________________________________
>>>>> From: Bernard Aboba
>>>>> Sent: Wednesday, October 08, 2014 12:02 PM
>>>>> To: public-ortc@w3.org
>>>>> Subject: Issue 154: RTCP Port Control
>>>>>
>>>>> While RFC 3605 defines the "a=rtcp:" SDP attribute which allows for control of the RTCP port, there are legacy RTP implementations that assume that RTCP uses a port of RTP + 1.
>>>>>
>>>>> Currently there is no way to indicate a relationship between RTP and RTCP RTCIceGatherer objects, or to request that an RTCIceGatherer object created for TCP use the port + 1 of the object created for RTP.
>>>>>
>>>

Received on Tuesday, 14 October 2014 16:54:55 UTC