Re: [P2PSIP] draft-knauf-p2psip-disco-00

[Alexander Knauf <[e-mail]>]

Dear Peter,

thanks for your detailed comments! Please see comments inline.


On 16.Sep 2010 18:54, Peter Musgrave wrote:

> Here are my comments on -00. Looking forward to -01
>
>
> 2.
> Add a definitions for
> Owner Peer ?
> Peer Co-ordinates?
>    
We will include the following definition:
Owner Peer: A RELOAD peer that stores the DisCo-Registration. It commonly will
not participate the distributed conference.

Do you suggest to rename the term "Coordinate Value" to "Peer
Coordinates"?

> 3.1 Where does the URL that E uses resolve to? A? B? O?
>    
Actually, if no ordinary SIP registration has been performed for
the Conf-ID, E can only participate via 3rd Party invitation. A focus
then sets its IP address into the Contact header.

> 3.5 Call Delegation
> Could 302 be used instead? (REFER does have the advantage that it can
> be used later on to load balance, i.e. not just on incoming calls)
>    
The focus, which re-invites the transferred participant, sends
an INVITE that includes the conference URI in the From/Contact header.
This decouples the INVITE from dedicated peers and allows for a
'virtual' conference focus entity. The routing decision is based on the
additional Record-Route header, which carries the URI of the re-inviting focus.

>
> In 4.2 a node SHOULD be aware of it's relative position but in 4.1 it
> MUST select the focus peer whose co-ordinate value best matches. Is
> this inconsistent?
>    
Thanks, MUST be corrected to SHOULD.

> 4.2
> Is the N-dimensional cartesian co-ordinate defined anywhere? Is this
> presuming e.g. Chord. The statement is made that a concrete set of
> topology algorithms is out of scope - hence I would have thought the
> topology designator (i.e. cartesian co-ordinates) is also
> out-of-scope. Some topologies may elect to use a different
> representation.
>    
Yes, the n-dimensional coordinate vector does not cover all topology
algorithms. It is described for one class of approaches. We will clarify
this in -01.

> 4.4
> Co-ordinate in contact field:
> - will all peers know the co-ordinate scheme being used?
>    
Yes.

> 4.5
> DisCo peers can not be behind a NAT…
> I understand why this is a challenge but p2psip has NAT traversal and
> I see a very common application of DisCo to aggregate conference
> traffic within an enterprise to reduce the amount of media going
> outside. I think this would be of huge benefit to Disco.
>    
Yes. We will consider this deployment scenario in -01.

> 5.1
> Is the use of the term 'media types' indicating audio/video or the
> CODECs which are in use?
>    
This goes in accordance to the event package for conference state
RFC4575. The<type>  element carries the indication for audio/video/etc
and a<label>  element references to media codecs.

> 5.2 When a potential peer becomes active - how does it exchange media
> with the other active focus?
>    
A potential focus peer has at least one established media stream to
its own active focus. It can start a new negotiation process with its
own focus. The latter than has to recursively re-negotiate the new media
with all other endpoints. Thus every member of the conference is enabled
to obtain the new media.

> Figure 7: Is there any merit in sending the REFER to the Joining Peer
> instead of the PotentialFocus? In general dialog-creating REFERs are
> less common and some nodes make a policy choice not to respond to
> them. Does e.g. the ICE exchange get simpler if the new INVITE comes
> from the Joining Peer?
>    
We think that it is more common to send a REFER to (new) focus peer
instead of sending it to the joining party. Between potential and
active focus there already exists a relation, may because they already
have a SIP dialog or because they are members of the same conference.

The ICE negotiation get simpler if focus peers are not placed behind
NATs. However, considering your deployment case where foci may be also
behind NATs, it doesn't matter who sends the new INVITE.

Thanks again&  best regards,

Alex

>
> Nits:
> 1.
> s/complies the/complies with the/
>
> 3.3
> "A conference member proposes as a focus"  ->
> "A conference member proposes itself as a focus"
>
> 4.1 (last para)
> s/inadequate/inappropriate/  ?
>
> 4.3 point 2
> s/another a DisCo/another DisCo/
>
> 4.3 point 3
> s/is like to register/is similar to registering/
>
> 4.3
> s/MAY registers/MAY register/
>
> 5.1
> s/differnt/different/
> s/participating the conference/participating in the conference/
>
> Regards,
>
> Peter Musgrave
>
>
>
> On Thu, Sep 16, 2010 at 9:56 AM, Gabriel Hege
> <[e-mail]>  wrote:
>    
>> Hi Peter,
>>
>> thank you very much for your comments.
>>
>> The first version of the draft is really just about distributing the control
>> of the conference, but the idea is that the focus peers also do media
>> distribution. Whether this involves mixing and reencoding or just relaying
>> is dependent on the implementation and the media types involved.
>>
>> We are currently working on a major update to the draft, which will talk
>> more about media distribution.
>>
>> best regards,
>>   gabriel
>>
>> Am 15.09.2010 12:30, schrieb Peter Musgrave:
>>      
>>> Hi,
>>>
>>> I am reading this more carefully now (and will post some detailed
>>> questions and comments in a few days).
>>>
>>> One high-level question. Is DisCO *just* about distributing the
>>> control of the conference? It talks about distributed focus peers but
>>> does not indicate whether these are doing a distributed audio mix (and
>>> it does not indicate how such peers would exchange audio data). e.g.
>>> the description in 5.2 does not discuss how a new focus peer exchanges
>>> media with existing focii...
>>>
>>> Thanks,
>>>
>>> Peter Musgrave
>>> _______________________________________________
>>> P2PSIP mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/p2psip
>>>        
>>      


-- 
/*************************************************
* Alexander Knauf B.Sc.
* AG INET
* Dept. Informatik
* HAW Hamburg
* Berliner Tor 7
* D-20099 Hamburg, Germany
* Room: 580
* Net: http://inet.cpt.haw-hamburg.de/members/knauf
* Phone: [phone] - 8067
* Fax: [phone] - 8409
*************************************************/