Subject: [p2p-sip] Requirements Explosion (was: EvaluatingSIPimplementations)

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Tue, 10 Jan 2006 16:13:40 -0500

I appreciate the spirit of 'facing challenges' and also understand the 
importance of  defining what means 'SIP compliant'.
Certainly it will become an issue for P2P SIP.
Eventually we may have to define 'P2P SIP compliance' that is based on 
'SIP compliance'.

However, please let me suggest we take a caution with respect to the issue.
I doubt that we need to scan all the documents relevant to SIP and P2P 
for specifying P2P SIP at the current stage. Maybe we have to do so in 
the far future.
As a number of people said before, we may as well focus on 'basic' 
features of SIP in designing P2P SIP in the beginning. I still hope we 
can focus on basic problems before attacking more complex problems and 
all the features of SIP (that are growing continuously).

Furthermore, if we take a certain approach in designing P2P SIP (like 
the one presented as 'DHT-based approach'), we can have a decent 
modularity in P2P SIP that means the P2P aspects (building and maintain 
an overlay network and performing resource search and placement) are 
separated from SIP call control features quite decently. In that case, 
we will have to worry less about all the details of SIP features than 
otherwise. This architecture design is still an open issue and I'd like 
to have it not forgotten.

Thanks.

Eunsoo

Roy, Radhika R. wrote:

> Hi, Folks:
>
> I would say that it is not an elephant in the room. In fact, if you 
> include all SIP RFCs, it only exemplifies some additional aspects of 
> SIP RFC 3261. To summarize those in relation to p2p-SIP works, there 
> is not much in addition to the base RFC 3261.
>
> While we go on working on p2p-SIP, it will not only use all RFCs of 
> SIP, we will also scan all of the information of p2p works that are 
> being progressing independent of SIP in addition to DNS, IPv6, 
> routing, AAA/DIAMETER, Security, Mobile IP4/IPv6, mobile 
> routers/networks (NEMO), MANET, and others.
>
> What we will do eventually is to scan all the relevant points of those 
> on-going works for p2p-SIP without blindly reading all of the pages of 
> all documents. Well there may be some lapses as we mover forward as it 
> happens for all cases, we do need to face the challenge. Otherwise, 
> our works will be obsolete and will not meet the needs with the test 
> of time.
>
> Who will do these challenging works? The answer is: It is all of us 
> together.
>
> Best regards,
>
> Radhika
>
> -----Original Message-----
> From: p2p-sip-bounces at cs.columbia.edu 
> [mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David Barrett
> Sent: Tuesday, January 10, 2006 2:51 PM
> To: henry at pulver.com
> Cc: 'Nils Ohlmeier'; 'Alan Johnston'; 'Robert Sparks'; 
> p2p-sip at cs.columbia.edu; Kai.Vehmanen at nokia.com
> Subject: Re: [p2p-sip] Requirements Explosion (was: Evaluating 
> SIPimplementations)
>
> Henry Sinnreich wrote:
>
>> Benny Prijono wrote:
>
>>
>
>>>Your list with 50+ RFCs looks absolutely horrifying!
>
>>
>
>> Unfortunately I have to agree with you, but how can we dismiss all 
> this work
>
>> performed in the IETF? What would we say to the authors?
>
> Is it just me or is this the elephant in the room that nobody discusses?
>
> For example, SIP alone is documented in over *30 different RFCs*
>
> according to Henry's list, and that's just *one* protocol.  To do
>
> anything meaningful you also need SDP, STUN, TURN, ICE, RTP, RTCP, etc,
>
> etc.  Every one of these requires its own parsers, and its own state
>
> machines.  Given this, just building a reasonably compliant "Hello
>
> world!" VoIP app is an incredible undertaking.
>
> Furthermore, while a totally vanilla VoIP app can be simplified with
>
> off-the-shelf libraries, bending the RFCs in ways the authors didn't
>
> intend (such as P2P-SIP) is a Herculean effort because it's not just one
>
> library that needs tweaking, but many -- each with its own maintainer,
>
> own build process, own CVS repository, update cycle, bug database, etc.
>
>
> What I think would help SIP adoption more than anything is a "SIP 2.0"
>
> that is a distillation of everything learned up to date, re-unified into
>
> a single document with a single grammar, parser, and update cycle.
>
> Personally, I would pull together the essential elements of the various
>
> text protocols (SIP, SDP, STUN, TURN, ICE, and some DHT-maintenance
>
> commands), but leave RTP and the binary protocols separate.  With this
>
> tighter, smaller standard, true interoperability within this minimal
>
> subset might have a greater chance of succeeding.
>
> Until then, given that *nobody* understand the big picture entirely, and
>
> even *fewer* have the resources to build it, everyone will just do the
>
> best they can and we'll end up basically where we are -- with a wide
>
> collection of "SIP compliant" devices and services that, despite the
>
> best intentions of the designers, are mostly incompatible, or that only
>
> achieve compatibility through extreme testing and custom tweaking.
>
> Am I a lone pessimist in this view, or would you agree?
>
> -david
>
>------------------------------------------------------------------------
>
>_______________________________________________
>p2p-sip mailing list
>p2p-sip at cs.columbia.edu
>https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>  
>

---

From: dbarrett at quinthar.com (David Barrett)
Date: Tue, 10 Jan 2006 14:06:44 -0800

> for specifying P2P SIP at the current stage. Maybe we have to do so in 

I agree this is what needs to be done to stay relevant in the real 
world.  But it's a tacit acknowledgment that SIP is too difficult to 
even attempt "correctly".  This seems a red flag if even an IETF working 
group -- with no deadlines or market pressures -- is unwilling to tackle 
SIP as a whole.  It feels like we're adding another level to a house of 
cards.

When I was doing iGlance (www.iglance.com) I started with the attitude 
"Yes!  Let's do this thing 100% SIP compliant."  But my productivity 
dropped to basically zero once I took up the reigns.  Thus my attitude 
went to, "Ok, let's strive for 100% compliance later, but let's get the 
basics up first."  And then "Ok, even the basics are too complicated to 
worry about now, so let's stay compliant with the state machines and 
worry about the syntax later."  And then "Boy, these state machines are 
restrictive, let's just stay SIP influenced for now, so maybe someday we 
can come back and do it 'right'."

Henning sold me on SIP in person, and I still believe it's an awesome, 
well-designed, rich and robust architecture.  But it's grown out of 
control to the point it is brittle and cumbersome -- the antithesis of 
what it was intended to be.

I believe were we to circle the wagons a bit wider and be more 
deliberate with compliance (and non-compliance), we'd move faster and 
produce a more usable result.

But so long as we attempt to comply with everything ever written on SIP 
(and its pantheon of supporting protocols), we'll never agree on 
anything, we'll never be able to verify success, and the final result 
will be so cumbersome (by definition, more cumbersome that what is 
already in place), that it won't matter.

So again I'd propose the P2P-SIP group focus less on seamless 
integration with the chaotic SIP universe as a whole, and more on 
creating an ordered, simple subset of the universe that is easy to 
understand, covers all the bases that real applications deal with in the 
real world, and "just works" with minimum dependency on external documents.

-david

---

From: henry at pulver.com (Henry Sinnreich)
Date: Tue, 10 Jan 2006 16:27:54 -0600

>real world, and "just works" with minimum dependency on external documents.

This is an excellent goal. The work will probably have to be a volunteer
effort, since it would be difficult to make this a charter objective for a
(hopefully) IETF WG. Such a document could be submitted eventually to the
P2P SIP WG only after it will be formed.

Any volunteers for a minimum and doable list of requirements for the P2P SIP
peer node? 

Thanks, Henry

-----Original Message-----
From: David Barrett [mailto:dbarrett at quinthar.com] 
Sent: Tuesday, January 10, 2006 4:07 PM
To: Eunsoo Shim
Cc: Roy, Radhika R.; henry at pulver.com; Nils Ohlmeier; Robert Sparks; Alan
Johnston; Kai.Vehmanen at nokia.com; p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] Requirements Explosion (was:
EvaluatingSIPimplementations)

-david

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Tue, 10 Jan 2006 17:42:11 -0500

David Barrett wrote:

>> I doubt that we need to scan all the documents relevant to SIP and 
>> P2P for specifying P2P SIP at the current stage. Maybe we have to do 
>> so in the far future.
>
>
> even attempt "correctly".  

I respect your experiences with SIP and your thoughts after that and I 
am not a person to argue about them. Even if I can, I would not like to 
do it.
Just let me supplement my statements with respect to your comment above.
I did not mean that SIP was too difficult to even attempt correctly. The 
background of my statement in my previous message was that I did not 
think P2P SIP would require lots of changes in many aspects of SIP. I 
think (actually believe) we can design P2P SIP in such a way that the 
P2P aspects are fairly independent of SIP call control procedures, 
probably independent of most of the RFCs relevant to SIP.

> This seems a red flag if even an IETF working group -- with no 
> deadlines or market pressures -- is unwilling to tackle SIP as a whole.

Again, I do not think I raised such a flag. Obviously I am not 
representing an IETF working group, either. I expressed just an opinion 
shared with a number of people that P2P SIP could be designed with 
little or minimum change in SIP.

> It feels like we're adding another level to a house of cards.
>
> went to, "Ok, let's strive for 100% compliance later, but let's get 
> the basics up first."  And then "Ok, even the basics are too 
> complicated to worry about now, so let's stay compliant with the state 
> machines and worry about the syntax later."  And then "Boy, these 
> state machines are restrictive, let's just stay SIP influenced for 
> now, so maybe someday we can come back and do it 'right'."
>
> But so long as we attempt to comply with everything ever written on 
> SIP (and its pantheon of supporting protocols), we'll never agree on 
> understand, covers all the bases that real applications deal with in 
> the real world, and "just works" with minimum dependency on external 
> documents.
>
> -david

Regards,

Eunsoo

---

From: kns10 at cs.columbia.edu (Kundan Singh)
Date: Wed, 11 Jan 2006 01:53:57 -0500

>>real world, and "just works" with minimum dependency on external documents.

I think this is a very hard problem because of the interpretation of 
"real" by different people at different times. For each X in 
conferencing, voicemail, NAT traversal, ..., Is X part of a real app? 
Such questions can be either yes or no depending on what you want to 
build. For example, I don't need NAT travesal for my Intranet phone, and 
I don't need Voicemail for my SIP-IM client. So essentially this becomes 
a product or application requirement but not a protocol requirement.

I this we should first focus on the protocol requirement, and then build 
the application satisfying the base protocol requirement. And later, 
incrementally add new application requirements in the software.

Regarding the number of RFCs/drafts in SIP, I think it signifies a good 
sign that SIP can be extended for various new requirements without 
affecting the base SIP protocol. Thus a "real" application can choose 
which RFCs/drafts (application requirements) to implement and still be 
interoperable with other application that implement the same drafts/RFCs 
(requirements). For example, in Henning's class, students built basic 
SIP-based video phones with limited features that just works as part of 
their class assignments. So SIP is not that hard, as it sounded in the 
earlier postings.

As for P2P-SIP, I think it should just depend on the base protocol RFC 
3261. Unless we want to create specific profiles such as 
P2P-SIP-NAT-Conf, P2P-RTP/SDP-SIP, or P2P-SIP-Presence-IM.

If we agree on the 'external DHT/P2P' architecture, P2P-SIP can further 
reduce to just P2P-Location-Service without depending on SIP at all. So 
in that case all the RFCs/drafts become external to the protocol, and we 
need only one 'Location-Service' protocol.
So in my opinion, to get started we should pick an existing location 
service protocol (using get/put APIs) and create opensource software 
that glues some existing SIP and DHT implementations using this location 
service protocol.

Even if we don't agree on 'external DHT/P2P' architecture, a 
standardized location-service API helps to interoperate various SIP 
implementations with various P2P networks, even if the P2P network 
maintenance is done by, say, SIP.

Regarding th location-service API/protocol: starting point could be the 
get/put/remove APIs with some identity assertion and verifications. 
(e.g., see the OpenDHT paper - http://www.opendht.org).

Soon we realize that we need another set of protocol/APIs for 
join/leave/lookup for adding new services. For example, if a Turn server 
wants to get discovered or a SIP presence server wants to get discovered 
on P2P. So the service can join on P2P network indicating it's service 
profile (based on one or more RFC/draft) and identity (or domain that 
the service is serving). Others can lookup the service on P2P using some 
criteria (such as service profile, proximity, etc). This is similar to 
DNS SRV/NAPTR on P2P.

So the protocol can evolve in two dimensions: location-service 
(get/put/remove) and P2P-service (join/leave/lookup). Our implementation 
may initially implement either or both for a basic SIP phone, and later 
add various application requirements (e.g., presence, NAT traversal, etc).

A generic location-service protocol can be specified using existing RFC 
formats such as Sun RPC, XML-RPC or SOAP -- this is the on-the-wire 
protocol. A particular location-service is specific for the type of 
lookup you want to do and defines the 'data-format'. So a 
SIP-location-service will implement something like get(user at domain), 
put(user at domain,contacts), etc. So SIP-LS will define a specific 'data 
format' for parameters to get/put. Similarly, a Presence-LS will define 
how presence data gets stored (e.g., just put the PUBLISH message body 
with a given key, thus reusing the existing work done in SIPPING/SIP).

A generic P2P-service protocol should be specified using some common 
on-the-wire protocol so that it can work with various P2P networks. A 
specific P2P-service is implemented using some underlying P2P network, 
say Chord, Kademlia, or Pastry. The API can be something like:
join(service-name, serving-identifier, server-addresses); & leave(...).
server-addresses := lookup(service-name, serving-identifier, criteria);
(server-addresses,identifier) := lookup(service-name, criteria);
where criteria could be something like fastest, closest, etc.

The location-service and P2P-service can be layered on top of each other 
but that is an implementation choice. For example, all P2P-SIP proxies 
can provie get/put/remove as well as join and lookup among each other 
using service-name = "SIP-LS" and serving-identifier="example.net" if 
serving users at example.net. Similarly, all P2P-SIP clients can just join 
using service-name = "SIP-LS" and serving-identifier="user at example.net". 
A SIP client that as external DHT interface, can just call 
get/put/remove to any existing provider DHT node. and so on.

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?

Regards,

Kundan

---

From: enrico.marocco at TILAB.COM (Enrico Marocco)
Date: Wed, 11 Jan 2006 09:36:24 +0100

> Any volunteers for a minimum and doable list of requirements for the P2P SIP

I'm not quite sure I understand which kind of requirements we are
talking about; can you better explain the relation between such list and
the Salman's one (draft-baset-sipping-p2preq-00)?

Enrico

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to 
MailAdmin at tilab.com. Thank you
====================================================================

---

From: ag at ag-projects.com (Adrian Georgescu)
Date: Wed, 11 Jan 2006 09:55:16 +0100

Hi Kundan,

It is a brilliant description of indeed achievable goals.

Regards,
Adrian

---

From: Kasthuriram_V at infosys.com (Kasthuri Ram V.)
Date: Wed, 11 Jan 2006 14:34:23 +0530

Hi Kundan,

> SIP user agent and basic SIP proxy and registrar using some existing 

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

Cheers,
Ram
--

> Kundan

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

---

From: dbarrett at quinthar.com (David Barrett)
Date: Wed, 11 Jan 2006 01:38:21 -0800

Hi Kundan!  Glad to see you're still active with P2P/SIP.

> SIP user agent and basic SIP proxy and registrar using some existing 

I think this is a great proposal, though quite different than mine. 
What I like about your proposal is that it has a clear and limited goal; 
it doesn't try to satisfy everybody.

Unfortunately, it doesn't satisfy me.  (Which is fine; my proposal would 
certainly leave others dissatisfied, too.)

What it sounds like we both agree upon is the need to trim back the 
requirements to a smaller, clearer set:  You're emphasizing serverless 
operation, while I'm focused on NAT/firewall traversal.

Both are "P2P" and within the scope of the use cases outlined last 
month.  And both are areas that can see great improvement.

It's really a matter of whether to focus on adding more features to the 
SIP universe (serverless operation), or refactoring what's already in 
place (NAT/firewall traversal).

Personally, I think SIP has come so far it's in desperate need for a 
breather, and we have a great opportunity to "retreat and regroup" such 
that future efforts (such as serverless operation) are less painful. 
But I understand that's just one view.

-david

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Wed, 11 Jan 2006 10:09:28 -0500

>SIP user agent and basic SIP proxy and registrar using some existing 
I like this proposal a lot like many other people.
Regards,

Eunsoo

---

From: henry at pulver.com (Henry Sinnreich)
Date: Wed, 11 Jan 2006 11:11:36 -0600

> for basic audio-only no-NAT 
>SIP user agent

I hope we include presence and IM right from the start and see no difference
if video will be there as well.

Thanks, Henry 

-----Original Message-----
From: Eunsoo Shim [mailto:eunsoo at research.panasonic.com] 
Sent: Wednesday, January 11, 2006 9:09 AM
To: Kundan Singh
Cc: p2p-sip at cs.columbia.edu
Subject: Re: [p2p-sip] Requirements Explosion

Eunsoo