[p2p-sip] New internet draft available

[enrico.marocco at telecomitalia.it (Enrico Marocco)]

Seaward Hu wrote:
>       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 *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.

>       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? *

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

>       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.*

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.

>       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?

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.

> 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?*

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