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
<[email protected]> 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
[email protected]
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: +49 40 42875 - 8067
* Fax: +49 40 42875 - 8409
*************************************************/
_______________________________________________
P2PSIP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/p2psip
