На 07.07.11 02:39, Flemming Andreasen написа:
>> На 06.07.11 22:44, Flemming Andreasen написа:
>> >> I don't see a proposed latching mechanism in the document. What I saw
>> >> was a fallback mechanism in case ICE is killed by a proxy that does
>> >> latching (which is what the overwhelming majority of the SIP proxies on
>> >> the real Internet do).
>> >>
>> > Please see Section 5.7 in the loopback draft, which defines a latching
>> > mechanism as an alternative to ICE, not a fallback if ICE is
>> > blocked/doesn't work.
>>
>> I suppose I am missing something because in section 5 I read:
>>
>>     ICE/STUN/TURN provide a general solution ...
>>     ... Loopback sessions ... SHOULD use these general solutions
>>     wherever possible ... In scenarios where ICE/STUN/TURN is not
>>     available [and C1] ... the following solution MAY be adapted.
>>
>> (I am not sure why C1, requiring that the loopback source has a public
>> IP address, is necessary here but we can probably come back to this
>> later).
>>
>> So, the way I understand this is that loopback clients need to have and
>> use ICE. If ICE is not there they could try to compensate using the
>> mechanism described in 5.7.
>>
> ICE is at SHOULD strength, not MUST, and there are no fallback
> procedures defined that says to use ICE first and if it fails, then use
> latching.

Definitely not. I never meant to imply there were. It is however a
fallback in the case endpoints are prevented from even starting ICE.

>> As to the mechanism itself it basically says that mirrors shouldn't wait
>> to hear from the source and that they should start streaming as soon as
>> they are ready.
>>
> No - that is not what the draft says. The draft defines a new payload
> type called "loopbkprimer" and associated procedures for using it to
> punch holes and associated latching operation on the RTP endpoint itself
> (latching details are not spelled out in detail in the draft currently).

Indeed and this is exactly what I was referring to. The "loopbkprimer"
is the payload type that mirrors "should start streaming as soon as they
are ready" rather than "wait[ing] to hear from the source first".

>> To me this sounds quite reasonable. It's basic hole
>> punching and, as I said in my previous mail, it could also be of use in
>> other cases.
>>
>> So here's a scenario where I see this reasonable. S (source) supports
>> ICE and calls M (mirror) which also supports ICE. They are both behind
>> NATs and they are both connected to a common SIP server, say iptel.org.
>> When S's INVITE goes through the iptel.org proxy it replaces the
>> connection address in the SDP with that of its RTP proxy. This of course
>> means that even though it would see the entire candidate list M would
>> have to disable ICE.
>>
> - How does the iptel.org proxy know it needs to insert a RTP proxy ?

It either does so unconditionally or it recognizes the addresses in the
SDP as non-public so it replaces them. This how the overwhelming
majority of the Internet VoIP providers out there handle NAT traversal.

> - How would M know an RTP proxy was inserted and that M needs to disable
> ICE ?

Because the default candidate (the one inserted by the proxy) is not in
the candidate list.

> - Why does M need to disable ICE in this case rather than let it run its
> course 

Because 5245 says so (Section 5.1):

   The agent will proceed with the ICE procedures defined in this
   specification if, for each media stream in the SDP it received, the
   default destination for each component of that media stream appears
   in a candidate attribute.

   ...

   If this condition is not met, the agent MUST process the SDP based on
   normal RFC 3264 procedures


> is there an assumption that this RTP proxy will not pass ICE
> packets through and trying to do ICE will somehow incur problems ?

I suppose this would be one of the reasons yes. I didn't follow the
discussions that led to this text back in the time but I'd guess the
assumption was that if someone in the signalling path is taking control
then it would be best not to get in the way.

>> So in this case, which is not at all uncommon, the
>> technique in 5.7 would be the only way to get media flowing both ways.
>>
> ICE enables two endpoints to be behind a NAT as well. It may require
> TURN instead of an RTP proxy as is suggested in this example. The
> advantage of a TURN based solution is that it will work for other types
> of media streams than RTP.


> 
>> Also, in this case, the only one doing latching is the iptel.org service
>> (not the endpoints that do loopback) and the mechanism from 5.7 allows
>> to work around it.
>>
> That's not clear based on your description. The mechanism in section 5.7
> would require both S and M to be loopback-mirrors and send the loopback
> primer packets to the RTP proxy, which in turn needs to be a
> loopback-source for both endpoints and at this point is no longer a
> proxy (nor is the iptel.org "proxy").

I am not following. Why would both S and M need to be mirrors? S would
start streaming ... it has no reason not to. The RTP proxy in the middle
however won't be able to relay its packets until it hears from M. Until
then, it simply wouldn't know where to relay them to.

>> >> > will not
>> >> > work in every case and seems really a poor workaround for not having
>> >> > ICE.
>> >>
>> >> Sure, but if you can't use ICE because someone in the middle mangled
>> >> your SDP, then I suppose a poor workaround is better than nothing.
>> >>
>> > The proposed latching mechanism depends on SDP extensions as well, so it
>> > would seem equally vulnerable to SDP mangling by an intermediary.
>>
>> Well I guess I must be missing something because I only see regular SDP
>> in this scenario and nothing that would be vulnerable to a middle box.
>>
> If you only see regular SDP, then you are not following the mechanism
> defined in the loopback draft (loopback, mirror and source SDP
> attributes and loopbkprimer payload format).

How are these "irregular" SDP and what reason would a middle box have to
remove them?

>> >> On a side note, "the chicken and egg" problem described in the draft is
>> >> similar to what happens with unidirectional streams (e.g. where one
>> side
>> >> starts transmitting video while the other is in recvonly). The solution
>> >> proposed in this draft would also be handy in such a situation so it
>> >> would probably make sense to have it in a separate document. Of course
>> >> such a document would have to be make it clear it only exists for
>> >> backward compatibility and that it should only be used if ICE is
>> blocked.
>> >>
>> > If I read your comments right, the only issue you have with ICE is that
>> > it may be blocked whereas another solution (like latching) might not be.
>> > Is that an accurate summary ?
>>
>> My point is that everyone is using latching and latching disables ICE
>> and in such cases it would be nice for clients to have something to fall
>> back to.
>>
>> I don't see anything in this document being an actual alternative to ICE.
>>
> It defines a NAT traversal solution different from ICE, and that will
> only work under certain assumptions. The question is whether the WG
> believes we need such a mechanism in general, and if so why.

Well again, I don't see anything in this draft that would allow two
clients, both of which are behind a NAT, to talk to each other. The
relay in the middle does. In that respect I don't see how anyone can
pretend that the loopback primer is an "alternative to ICE". It is not.
 It does not provide means for clients to discover a direct path to each
other. It does not provide relaying. It only helps to resolve a
starvation in the echo use case and in a scenario where a regular
bi-directional voip call would have worked anyway because of the
latching that middle boxes are doing.

Emil

--
http://jitsi.org