Subject: [p2p-sip] Requirements Explosion

From: royrr at us.saic.com (Roy, Radhika R.)
Date: Wed, 11 Jan 2006 08:16:46 -0500

Kundan:
 
If I understand correctly, you are suggesting that we should start to
develop a generic p2p-(problem-specific) protocol and then
use/apply/implement this using SIP protocol standards. Is this correct
interpretation?
 
I thought that we would examine the present SIP protocol standards and will
find which parts of the SIP standards are NOT in consistent with the p2p
public Internet. 
 
To me, to make SIP a pure p2p protocol in different aspects like
registration, location, removing the needs of middle network functional
entities like proxies, transparent crossing of FWs/NATs by SIP signaling
messages and audio/video payload, etc., we will develop p2p-SIP protocol. To
develop the p2p-SIP protocol, we may have to take couple of steps as
follows:
 
1. Base p2p-SIP protocol (no FW/NAT crossing, no location services, etc.,
but may allow to use SIP without the need intermediate entities like
proxies)
2. Extend the base p2p-SIP protocol to solve the complex problems like
FW/NAT crossing, location services, etc.
3. Extend the same for multipoint multimedia conferencing
4. Others
 
Would you please help us to clarify the above?
 
Best regards,
Radhika

  _____  

From: p2p-sip-bounces at cs.columbia.edu on behalf of Kasthuri Ram V.
Sent: Wed 1/11/2006 4:04 AM
To: Kundan Singh
Cc: p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] Requirements Explosion

Hi Kundan, 

On Wed, 2006-01-11 at 01:53 -0500, Kundan Singh wrote: 
> So in conclusion, I think we should start with defining the generic 
> location-service and P2P-service protocol, and then specific data format 
> for SIP-location-service, and implement it for basic audio-only no-NAT 
> SIP user agent and basic SIP proxy and registrar using some existing 
> DHT/P2P algorithm. 
> Comments? 

Well summarized!! This is where we should begin and carry it forward. 

Cheers, 
Ram 
-- 

> 
> Regards, 
> 
> Kundan 
> _______________________________________________ 
> p2p-sip mailing list 
> p2p-sip at cs.columbia.edu 
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
<https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip>  

**************** CAUTION - Disclaimer ***************** 
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely
for the use of the addressee(s). If you are not the intended recipient,
please notify the sender by e-mail and delete the original message. Further,
you are not to copy, disclose, or distribute this e-mail or its contents to
any other person and any such actions are unlawful. This e-mail may contain
viruses. Infosys has taken every reasonable precaution to minimize this
risk, but is not liable for any damage you may sustain as a result of any
virus in this e-mail. You should carry out your own virus checks before
opening the e-mail or attachment. Infosys reserves the right to monitor and
review the content of all messages sent to or from this e-mail address.
Messages sent to or from this e-mail address may be stored on the Infosys
e-mail system.

***INFOSYS******** End of Disclaimer ********INFOSYS*** 
_______________________________________________ 
p2p-sip mailing list 
p2p-sip at cs.columbia.edu 
https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
<https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip>

---

From: kns10 at cs.columbia.edu (Kundan Singh)
Date: Wed, 11 Jan 2006 12:40:02 -0500

> use/apply/implement this using SIP protocol standards. Is this correct

Yes. The intended application has two parts: P2P network (chord, pastry 
etc) and application (SIP video call, presence, etc). I said that we 
should first define the interface between the two, and then add the two 
parts (which can be done independently). The interface can be defined in 
two steps: (1) a generic API/protocol for accessing the services of or 
providing services to any P2P network. (2) application specific profiles 
such as for SIP location service, presence services, etc.

> messages and audio/video payload, etc., we will develop p2p-SIP protocol. To

True. These can form the application specific profiles. I think, these 
are important but independent problems and an application can implement 
some or all of these. For example, in the P2P-SIP-Nat-Audio profile we 
can list the following requirements, and require that an application 
meets all these to be called a P2P-SIP-Nat-Audio phone:
1. Transport: TLS. URI: sips. (or pick SMIME; but pick one as mandatory)
2. All sent messages are in canonical form of SIP message/headers.
3. Connection reuse (for reverse direction messages).
4. Do P2P lookup and updates as per SIP-LS profile (above). RFC3263 not 
required. But some way to bootstrap should be defined.
5. Support INVITE/ACK/CANCEL/BYE/OPTIONS. (REGISTER not needed).
6. Must support ICE, SRTP, etc., for media. (or should it be RTP over 
TCP/TLS?)
7. RFC3261: interpret all SHOULD as MUST, SHOULD NOT as MUST NOT.
8. SDP in INVITE and 200 OK a MUST. re-INVITE must be supported.
9. Each node also a TURN/STUN server.
10.Dynamic ports instead of listening on 5060 always.
11. Must support REFER.
12. Must support G.711, GSM, iLBC, and Speex (both 8 and 16kHz).
13. Must support at least one audio session per call.
14. No need to emulate PSTN or interoperate (for basic phone). So no 
DTMF, ENUM, tel, etc.
... <should we try to complete the list as much as possible? what do
      people think should be in a basic P2P-SIP audio/video/IM client>
n. Gracefully handle any incoming SIP messages in a SIP compliant way 
(e.g., may reject as '400 Not in canonical form' if the parser is not 
capable of handling non canonical SIP messages.)

Similarly there can be P2P-SIP-Multimedia-IM, P2P-SIP-Proxy, 
P2P-SIP-presence requirements. But these requirements are just specific 
application profiles. We can define the minimum requirements for an 
application profile for interoperability, ease of development and 'just 
works' user experience. As and when new applications get developed, new 
application profiles can be added for compliance with P2P-SIP.

So I think the steps could be: (1) define the P2P location (get/put) and 
service (join/lookup) protocol, (2) define the application specific 
protocol for SIP lookup and presence, initially, (3) define the minimum 
set of requirements for a P2P-SIP-Nat-Audio-Video-IM application and 
P2P-SIP-Proxy application using this P2P location and service protocols, 
(4) implement such a phone and proxy using some existing SIP and DHT 
implementations.

Regards,
Kundan

---

From: bryan at ethernot.org (David A. Bryan)
Date: Wed, 11 Jan 2006 13:39:59 -0500

I think a lot of the architecture proposed by Kundan makes good sense,
and is inline with the direction people seemed interested in taking
things at the meeting in Vancouver. There seemed to be strong
agreement  to separate the SIP call completion from the P2P lookup
service. (although I think the protocol for transport of the lookup
was still up in the air, with some advocating something looking like
SIP (or even using SIP), and others advocating something like XML or
SOAP or the like, but the two being separated no matter which decision
was made)

As far as the specific requirements, I'm not sure specifying such a
broad range of codecs is really needed -- SDP negotiation can be used
just as in conventional SIP, and people may want to use others, not
support one or more of the mentioned ones, etc. That said, agreeing on
at least one seems essential for interoperability. Tough decision.

I also think that one of the advantages in a SIP based P2P
communications system, rather than a non-SIP one, is the ability to
connect to existing devices and gateways, so I think things like PSTN
interoperability are critical -- more critical in my mind than things
like REFER and the features that enables, actually, although obviously
both are important. That probably means at least the capacity for
register too...not sure how else can provide outside connectivity to
existing systems for PSTN connectivity.

I think each node being a STUN/TURN server, connection reuse, ICE,
etc. is definitely critical. We must assume nodes will be behind NATs
as a matter of course.

Thoughts?

David Bryan

---

From: ssal at intracom.gr (Sotiris Salloum)
Date: Wed, 11 Jan 2006 21:39:36 +0100

Dear all, 

>From my point of view p2p-sip could provide standardization in a field where
no standardization exist for the moment (but instead proprietary solutions)

Based on the increasing (day by day) bandwidth availability, an increasing
field of application's will appear to take into advantage all the
interconnected computing power (either for VoIp, VoD, research, location
etc). This will require a common protocol to work as a basis like TCP/UDP
did for the past. 

Based on the above assumptions I wanted to share with you my proposal that
maybe this work could be better to have another acronym? (pip) in order to
avoid confusion with VoIP and Skype and to show it's full potentials and
dynamics?

Regards
Sotiris

Sotiris Salloum MSc. PhD Candidate
INTRACOM SA - Content Distribution Networks
Athens Greece 
19002 Peania Attica

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Kundan Singh
Sent: Wednesday, January 11, 2006 6:40 PM
To: p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] Requirements Explosion

Regards,
Kundan

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Wed, 11 Jan 2006 16:07:37 -0500

It sounds that you are proposing we focus on (a) generic P2P protocol(s).
I understand your point but it is one of the things some of us, 
including myself, have been carefully excluding.
One reason I have is that I think that P2P technologies are diverse and 
different P2P technologies serve different applications better than others.
It seems it will become a very difficult task to find and standardize, 
within a WG, a small set of P2P technologies suiting all kinds of 
applications.
So I think we should have and maintain a clear focus on the target P2P 
application, which is P2P real-time communications (Internet telephony, 
Presence, IM) in this P2P SIP community.

Thanks.

Eunsoo

Sotiris Salloum wrote:

>>I thought that we would examine the present SIP protocol standards and
>>    
>>
>will
>  
>
>>messages and audio/video payload, etc., we will develop p2p-SIP protocol.
>>    
>>
>To
>