Subject: [p2p-sip] New internet draft available

From: hu.xinyu at huawei.com (Seaward Hu)
Date: Mon, 07 Aug 2006 16:29:32 +0800

Hi David, I have read your draft and I think it's a good base to define the
overlay client protocol and peer protocol, below is my comments in bold
font:

3.2.1. Relay Agent Peer Selection

It is extremely difficult to determine apriori which type of relay agent
peer fits best for a media session with a particular UA. To avoid this
choice, UAs SHOULD find as many relay agent peers as possible and MUST
establish media sessions using the
<http://www.p2psip.org/drafts/draft-marocco-p2psip-interwork-00.html#I-D.iet
f-mmusic-ice> ICE (Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Methodology for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols," June 2006.) [I-D.ietf-mmusic-ice] mechanism so that
the most appropriate relay can be chosen at run time. 

[Seaward]Q1: If the UA has a public IP address, why not initial the directly
connection test by itself at first? In the section 5-examples, the first 2
steps always are the getting relay and response.

3.3.1. P2PSIP Proxy Peer URI

P2PSIP proxy peers act as SIP servers and are identified by SIP URLs. Such
URLs MUST have only the host field set, and its value MUST match the overlay
identifier. 

For example, the URL which identifies P2PSIP proxy peers registered within
the overlay "p2psip.org" could be "sip:p2psip.org". 

[Seaward] Q2: In normal case, there will be more than 1 peer in overlay can
take the proxy task, do you mean those proxy peers have the same name:
P2PSIP.org? 

3.3.2. Relay Agent Peers URIs

Since relay agent peers can implement different protocols, there will be
different URI schemas for identifying each kind. As a general rule, URLs
identifying relay agent peers which implement a given protocol, will be
formed according to the specific scheme and will have the host field (or the
equivalent field) matching the overlay identifier. 

While such URI schema do not currently exist, one could use something like
"turn:p2psip.org" and "teredo:p2psip.org" identify relay agent peers
registered in the overlay "p2psip.org" and implementing TURN and TEREDO
protocols respectively. 

[Seaward] Q3: The same as Q2.

4.1. Registering with the Overlay

UAs perform registration in the overlay through the P2PSIP client protocol.
Such registration consists of an insertion of a P2PSIP overlay user routing
record bound to the user identifier. 

To support interworking with canonical SIP, the user identifier MUST be a
well formed SIP URL, with the host field matching the overlay identifier.
The user field MUST be set, and its value will usually be the P2PSIP overlay
user identifier. 

According to local policies, the user MAY need to enroll and obtain
appropriate credentials for their URL before being able to register records
for it. 

[Seaward] Q4: What kind of URL is the well formed SIP URL?  If the user
field value being unique in overlay and the host field matching the overlay
identifier are enough?
 
Figure 5
[Seaward] Q5: Can you describe the step 11 in more details? I can't
understand the use of overlay in this step.

And in step 12, do you mean the media will be relayed twice by two relay
agents?

Figure 6

When Carol receives the INVITE, the session establishment completes carrying
ICE offers and answers (if supported) (11). MAY (11) means (10)

Media is relayed across Alice's relay agent peer (11). 

[Seaward] Q6: In step 7, if the request are relayed by relay agent before
arrived at proxy peer? If not, why proxy peer carry the ICE offer in step
10?

Figure 7

[Seaward] Q7: Same question as Q6, who carry the ICE offer?

Thanks.

Seaward 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060807/9b0860b9/attachment.html

---

From: enrico.marocco at telecomitalia.it (Enrico Marocco)
Date: Mon, 07 Aug 2006 14:36:14 +0200

Seaward Hu wrote:
> establish media sessions using the *ICE (Rosenberg, J., ?Interactive
> Connectivity Establishment (ICE): A Methodology for Network Address
> Translator (NAT) Traversal for Offer/Answer Protocols,? June 2006.)*
> <http://www.p2psip.org/drafts/draft-marocco-p2psip-interwork-00.html#I-D.ietf-mmusic-ice>
> [I-D.ietf-mmusic-ice] mechanism so that the most appropriate relay can
> be chosen at run time.
> 
> *[Seaward]Q1: If the UA has a public IP address, why not initial the
> directly connection test by itself at first?

When working, local candidates would be selected using ICE.

>                                              In the section 5-examples,
> the first 2 steps always are the getting relay and response.*

That's the common behaviour.  User agents' UI could let users disable
derived candidates gathering (and thus relay agent peer lookup), but
this should be done very carefully.  However, they MUST continue using
ICE because they cannot know if peers they are going to establish
sessions with have public addresses too.

> P2PSIP proxy peers act as SIP servers and are identified by SIP URLs.
> Such URLs MUST have only the host field set, and its value MUST match
> the overlay identifier.
> 
> For example, the URL which identifies P2PSIP proxy peers registered
> within the overlay "p2psip.org" could be "sip:p2psip.org".
> 
> *[Seaward] Q2: In normal case, there will be more than 1 peer in overlay
> can take the proxy task, do you mean those proxy peers have the same
> name: P2PSIP.org? *

Yes.  That's the identifier UAs use for finding them.

> formed according to the specific scheme and will have the host field (or
> the equivalent field) matching the overlay identifier.
> 
> While such URI schema do not currently exist, one could use something
> like "turn:p2psip.org" and "teredo:p2psip.org" identify relay agent
> peers registered in the overlay "p2psip.org" and implementing TURN and
> TEREDO protocols respectively.
> 
> *[Seaward] Q3: The same as Q2.*

The same as previous.  In fact UAs are not interested in finding a
specific instance of relay agent peer or proxy peer: they just need to
have some.

> UAs perform registration in the overlay through the P2PSIP client
> protocol. Such registration consists of an insertion of a P2PSIP overlay
> user routing record bound to the user identifier.
> 
> To support interworking with canonical SIP, the user identifier MUST be
> a well formed SIP URL, with the host field matching the overlay
> identifier. The user field MUST be set, and its value will usually be
> the P2PSIP overlay user identifier.
> 
> appropriate credentials for their URL before being able to register
> records for it.
> 
> *[Seaward] Q4: What kind of URL is the well formed SIP URL?

Any URL compliant with the SIP scheme.

>                                                              If the user
> field value being unique in overlay and the host field matching the
> overlay identifier are enough?*

Aren't they?

> *Figure 5*
> *[Seaward] Q5: Can you describe the step 11 in more details? I can?t
> understand the use of overlay in this step.*

Step 11 represents the session establishment; it is drawn as a fat line
because it consists of many SIP and STUN message exchanges.  For some
exaustive examples, see draft-ietf-mmusic-ice-09, Section 11.  Here the
overlay is involved as the router for SIP messages (183s, PRACKs,
UPDATEs...) carrying ICE offers and answers.

> *And in step 12, do you mean the media will be relayed twice by two
> relay agents?*

Yes, in that example both UAs need to use media relays.

> *Figure 6*
> 
> When Carol receives the INVITE, the session establishment completes
> carrying ICE offers and answers (if supported) (11). *MAY (11) means (10)*

Right, "11" should be "10" here.  Thanks.

> *[Seaward] Q6: In step 7, if the request are relayed by relay agent
> before arrived at proxy peer? If not, why proxy peer carry the ICE offer
> in step 10?*

Relay agent peers are not meant to relay SIP messages.

> **Figure 7**
> 
> *[Seaward] Q7: Same question as Q6, who carry the ICE offer?*

The INVITE request (1) or the first reliable response in (8); it doesn't
really matter.

--
Enrico