Subject: [p2p-sip] Requirements Explosion

From: royrr at us.saic.com (Roy, Radhika R.)
Date: Tue, 10 Jan 2006 22:27:02 -0500

H, Eunsoo:

Right.

What we need to do is to develop a basic core spec that will define the base
p2p-SIP protocol (just recall what SIP has been before 3261) that will make
SIP as p2p protocol augmenting its utility as well as it will be compliant
of SIP. 

Once we start the base work, we will then look into this what we are
missing. I am sure people are here to provide comments and will judge its
value what we mean by p2p-SIP protocol (by the way, it may be a baby step).

On the other hand, if we look into the big picture of the entire SIP works
in the IETF, what are those? Are these not some basic extensions of SIP RFC
3261? Are there any fundamental changes in the direction of SIP protocol? I
do not think so. 

There are some important problems remain to be solved in the FW/NAT areas.
However, it is NOT SIP problems. It is the problem of the IP
network/transport layer for the entire Internet that is NOT allowing to SIP
signaling and its payload to cross the "traditional" FWs/NATs for a session
that last for hours. 

In addition, multipoint conferencing problems using multiple media are yet
to be solved satisfactorily even for the centralized case.

We expect, p2p-SIP will also be able to solve FWs/NATs crossing and
multipoint conferencing to the best satisfaction of SIP eventually.

So, we have a long way to go to solve all those problems from pure p2p point
of view as we see the limitations of SIP are becoming apparent in the
context of the p2p public Internet.

Best regards,

Radhika

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

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

---

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

> signaling and its payload to cross the "traditional" FWs/NATs for a session

Well, saying "it's not SIP's problem" is small comfort if it renders SIP 
unusable (or prohibitively difficult) in the real world.  If the goal of 
the P2P-SIP group is to improve interoperability between P2P 
implementations of SIP, and if the #1 P2P complexity is NAT/FW 
traversal, then it sure would be nice if the P2P-SIP group did something 
about it.

A unified INVITE/ACK grammar that automatically pierced NATs would 
simplify the overall architecture tremendously and make SIP a more 
practical solution for real-world use on the real-world internet.

-david

---

From: vkg at lucent.com (Vijay K. Gurbani)
Date: Wed, 11 Jan 2006 07:41:39 -0600

> signaling and its payload to cross the "traditional" FWs/NATs for a session

Nonetheless, SIP is increasingly being viewed as a tool in the
arsenal for UDP and TCP connectivity.  See [1], which argues
that SIP should take a broader architectural role in P2P network
layer connectivity.

[1] Saikat Guha, Yutaka Takeda, and Paul Francis, "NUTSS: A SIP-
based Approach to UDP and TCP Network Connectivity," Proceedings
of the ACM SIGCOMM 2004 Workshop on Future directions in network
architecture, Aug-Sept. 2004, pp. 43-48.

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Lucent Technologies/Bell Laboratories, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 10301 bytes
Desc: S/MIME Cryptographic Signature
Url : https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060111/f1940755/smime-0001.bin

---

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

David Barrett wrote:

> Well, saying "it's not SIP's problem" is small comfort if it renders 
> SIP unusable (or prohibitively difficult) in the real world.  If the 
> goal of the P2P-SIP group is to improve interoperability between P2P 
> traversal, then it sure would be nice if the P2P-SIP group did 
> something about it.
>
I guess lots of peers will be located behind NAT/FW. Thus I think also 
that P2P SIP community (or the future P2P SIP WG) would need to look 
into NAT/FW traversal issues with collaboration with other WGs such as 
BEHAVE and MMUSIC.

Thanks.

Eunsoo