Re: [P2PSIP] Proposal for progress on protocols

["Wei Gengyu" <[e-mail]>]

Hi, 

SIP has been widely used between SIP client and proxy or servers, 
and it is easy to get some testbed results.  

And we have to see the fact that there are many mobile terminals installed with SIP UA.
When considering the mobile terminal as a client of P2PSIP overlay, 
the SIP protocol is cheap and suitable. 

While in "Concepts and Terminology for Peer to Peer SIP draft-willis-p2psip-concepts-04"
or "Concepts and Terminology for Peer to Peer SIP" (draft-ietf-p2psip-concepts-00),
"An overlay may or may not also include one or more nodes called
   P2PSIP Clients.  The role of a client in the P2PSIP model is still
   under discussion, with a number of suggestions for roles being put
   forth, and some arguing that clients are not needed at all.  However,
   if they exist, then people agree that they will also be able to store
   and retrieve information from the overlay.  Section 5.5 discusses the
   possible roles of a client in more detail."

In section 5.5:
"In one alternative, a client interacts with the P2PSIP overlay
   through an associated peer (or perhaps several such peers) using the
   Client Protocol.  The client does not run the distributed database
   algorithm, does not store resource records, and is not involved in
   routing messages to other peers or clients.  Though interactions with
   its associated peer, a client can insert, modify, examine, and remove
   resource records.  A client can also send SIP messages to its
   associated peer for routing through the overlay.  In this
   alternative, a client is a node that wants to take advantage of the
   overlay, but is unable or unwilling to contribute resources back to
   the overlay.

   One way to realize this alternative is for a peer to behave as
   [RFC3261] proxy/registrar.  Clients then use standard SIP mechanisms
   to add, update, and remove registrations and to send SIP messages to
   peers and other clients.  If this is done, there is no need for a
   separate Client Protocol and no need for P2PSIP to define a distinct
   "P2PSIP Client" concept."

   And there are also second and third alternatives. 

My opinion is that adopting SIP between the client and the associated proxy Peer
will be simplify the facilities to support mobile clients in the reference model.

Best regards,

Gengyu 

----- Original Message ----- 
From: "Zheng Hewen" <[e-mail]>
To: "'Wei Gengyu'" <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, November 12, 2007 6:52 PM
Subject: RE: [P2PSIP] Proposal for progress on protocols


> 
> Hi,
> 
>    In my understanding according to P2PSIP Reference model defined in "Concepts and Terminology for Peer to Peer SIP"
> (draft-ietf-p2psip-concepts-00), SIP is not eligible to act as a communication protocol between a peer and its associated
> clients.
>    Further, in detail, considering those reasons as below, SIP is not eligible to be chosen as the signal underlying
> protocol of P2PSIP client protocol:
>   (1). SIP does not exist between a client and its associated peer at some scenarios.
>   According to P2PSIP Overlay Reference Model depicted in Figure 1 in "Concepts and Terminology for Peer to Peer SIP"
> (draft-ietf-p2psip-concepts-00), P2PSIP client protocol runs between a peer without any SIP entity and a client with a SIP
> entity, the peer does not recognize SIP protocol, SIP is not eligible to act as the signal underlying protocol of P2PSIP
> client protocol.
> 
>   (2). SIP is not a general Remote Procedure Call (RPC).
>   A P2PSIP client protocol on top of SIP acts as a remote procedure call (RPC) mechanism.  The SIP guidelines document
> [RFC4485] prohibits the use of SIP as a RPC mechanism.
> 
>   (3). SIP is not a general purpose transfer protocol.
>   One of P2PSIP client protocol main tasks is to transfer resource object and its content, those contents is irrelevant to
> SIP.  SIP's operation and the SIP guideline document [RFC4485] prohibit sending large amounts of data unrelated to SIP's
> operation.
> 
>   (4). SIP is not a lookup protocol.
>   SIP is not a lookup protocol; it relies on DNS to locate an appropriate SIP server.  Insert and lookup functionality is
> essential for any P2PSIP client protocol.  Using SIP as a peer-to-peer protocol requires integrating lookup functionality
> into SIP which goes against its design philosophy.
> 
> Best regards,
> Hewen
> 
> -----Original Message-----
> From: Wei Gengyu [mailto:[e-mail]]
> Sent: 2007?11?12? 17:28
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [P2PSIP] Proposal for progress on protocols
> 
> Hi, all
> 
> I have a question.
> 
> A peer in a P2PSIP overlay can be the proxy of a mobile client.
> Could SIP(rfc3261) be used between the client and the proxy Peer instead of defining a new protocol?
> 
> Best regards,
> 
> Gengyu
> 
> ----- Original Message -----
> From: <[e-mail]>
> To: <[e-mail]>; <[e-mail]>
> Sent: Thursday, November 08, 2007 5:28 PM
> Subject: RE: [P2PSIP] Proposal for progress on protocols
> 
> 
> Hi all,
> 
> I agree with Henning's proposal. There is another issue: support for
> clients.
> 
> I can to volunteer for "mobility" or "support for clients".
> 
> Marcin
> 
>>-----Original Message-----
>>From: ext Emil Ivov [mailto:[e-mail]]
>>Sent: 07 November, 2007 18:53
>>To: P2PSIP Mailing List
>>Subject: Re: [P2PSIP] Proposal for progress on protocols
>>
>>Henning, all,
>>
>>I think this is definitely the way to go and both Enrico and I
>>(as authors of one of the proposals) would be happy to
>>contribute on any of the points in your list. We also thought
>>that there are two other issues that would probably require
>>some consideration:
>>
>>- DHT upgrades - as far as I can see, it is currently most
>>covered by ASP, but the general opinion in Chicago seemed to
>>be that this is indeed an important issue that would have to
>>be addressed by the peer protocol.
>>
>>- Mobility - taking mobility into account would probably
>>influence some of the design choices (underlying protocol,
>>session flexibility, etc..) so it might be worth to try and
>>see to what extent would the existing proposals fit mobile nodes.
>>
>>One last thing. We should probably try and start having some
>>of these discussions before the meeting or, even better, to
>>find some way to foster offline work on each topic, since they
>>are likely to require more than the time we'll have there. I
>>guess that Philip's presentation in Chicago was made with the
>>same intentions, but it was pretty clear that the time we had
>>was insufficient for any meaningful discussions.
>>
>>Cheers
>>Emil
>>
>>Henning Schulzrinne wrote:
>>> I'd like to propose a mechanism to make progress on converging on a
>>> protocol. My high-level impression is that most of the
>>proposals, with
>>> the exception of the HIP-based ones, are philosophically not
>>that far
>>> removed, and the differences are more at the mechanical
>>level. One way
>>> to make progress would be to identify some of the major pieces, and
>>> then, in Vancouver, systematically go through them. An initial list,
>>> definitely incomplete, includes
>>>
>>> - packet format
>>> - NAT traversal for p2p messages (not media or SIP signaling)
>>> - channel security for p2p messages
>>> - recursion vs. iterative
>>> - hash algorithm negotiation and usage
>>>
>>> One possibility is to identify a volunteer for each area, so
>>that the
>>> task is more manageable. If there are major philosophical
>>differences,
>>> we should probably discuss those first, however.
>>>
>>> Henning
>>>
>>> _______________________________________________
>>> P2PSIP mailing list
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/p2psip
>>>
>>
>>_______________________________________________
>>P2PSIP mailing list
>>[e-mail]
>>https://www1.ietf.org/mailman/listinfo/p2psip
>>
> 
> _______________________________________________
> P2PSIP mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/p2psip
> 
> 
> 
>

_______________________________________________
P2PSIP mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/p2psip