Subject: [p2p-sip] Draft charter for possible P2PSIP WG

From: royrr at us.saic.com (Roy, Radhika R.)
Date: Mon, 23 Jan 2006 13:41:26 -0500

David and Suresh:

I agree with David that our focus should be p2p-SIP and hence we will work
first how SIP can traverse FWs/NATs to provide VoIP services because p2p-SIP
is also not a general purpose protocol.

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 David Barrett
Sent: Monday, January 23, 2006 12:17 PM
To: Pyda Srisuresh; Philip Matthews; Dean Willis
Cc: P2P-SIP
Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG

> -----Original Message-----

> From: Pyda Srisuresh [mailto:srisuresh at yahoo.com
<mailto:srisuresh at yahoo.com> ]

> [suresh] OK. However, several P2P applications that do not use SIP will

> also

> need NAT-penetration service.

No doubt.  But I'm afraid attempting to satisfy everyone by abstracting out

a new, general purpose NAT-traversal algorithm might end up satisfying

nobody.

(ie, if everyone has either size 4 or size 8 feet, size 6 shoes don't help.)

Our primary audience is the SIP community, so we MUST satisfy them.  We CAN

satisfy others, but needn't.  As such, I recommend we make SIP "just work"

across NATs, and then encourage anyone who wants NAT traversal to use SIP

(even if not a VoIP application).

-david

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060123/5ef74849/attachment.html

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Mon, 23 Jan 2006 14:22:06 -0600

If I may:

1) Getting SIP to work across NAT boundaries is not our problem here.  
It's a real problem, but one for another working group.

2) If we're not actually talking about the scope of the dra t  
charter, let;'s change the thread title, as this title is misleading.

--
Dean

On Jan 23, 2006, at 12:41 PM, Roy, Radhika R. wrote:

> David and Suresh:
>
> I agree with David that our focus should be p2p-SIP and hence we  
> will work first how SIP can traverse FWs/NATs to provide VoIP  
> services because p2p-SIP is also not a general purpose protocol.
>
> Best regards,
>
> Radhika
>
> From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip- 
> bounces at cs.columbia.edu] On Behalf Of David Barrett
> > From: Pyda Srisuresh [mailto:srisuresh at yahoo.com]
>
> >
>
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip

---

From: srisuresh at yahoo.com (Pyda Srisuresh)
Date: Mon, 23 Jan 2006 12:51:56 -0800 (PST)

I understand. It is a reasonable approach.

cheers,
suresh

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Mon, 23 Jan 2006 16:20:33 -0500

If P2P SIP doesn't include methods for dealing with NAT traversal then P2P
SIP is a pointless effort and best left to proprietary techniques led by
commercial vendors, vendors that are actually interested in deploying real
solutions in the real world.

Whether it's native to the protocol or begged, borrowed or stolen from
somewhere or something else doesn't matter, it just needs to be done and
accounted for and a mandatory part of P2PSIP support.  It has to just work
for all implementations.  It cannot be abstracted away.

The SIP standardization community ignored NAT traversal partially due to a
lingering ethic in the IETF that idealizes a so-called "end-to-end" world,
and partially because "it wasn't in our mandate". We are still struggling
with that that error, despite attempts to correct it with ICE, which in any
event are still in development, not common deployment as a part of the
protocol. After all these years the solution isn't firmly in place.

It is finally part of the SIP mandate more  as a patch and repair effort
than an originating design. And that effort seems reluctant at best and not
a top priority at all.

If an effective solution is part of the P2P SIP mandate from day one the P2P
SIP implementations will offer a distinct advantage over their classic SIP
cousins, which will have to deal with a history of mistakes and balkanized
implementations.

Learn from the mistakes of the past. Passing the buck has had real negative
impact, and P2P SIP cannot fall in that same trap.

Regards
Michael

--
Michael Slavitch
Ottawa, Ontario Canada
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060123/601cc465/attachment.html

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Mon, 23 Jan 2006 23:06:11 -0600

On Jan 23, 2006, at 3:20 PM, Michael Slavitch wrote:

> If P2P SIP doesn't include methods for dealing with NAT traversal  
> then P2P SIP is a pointless effort and best left to proprietary  
> techniques led by commercial vendors, vendors that are actually  
> interested in deploying real solutions in the real world.
>

If you're interested in defining solutions that can't be deployed in  
the real world, then you need to do that work in something besides an  
IETF  working group. The IETF is NOT a research organization.

> Whether it's native to the protocol or begged, borrowed or stolen  
> from somewhere or something else doesn't matter, it just needs to  
> be done and accounted for and a mandatory part of P2PSIP support.   
> It has to just work for all implementations.  It cannot be  
> abstracted away.

I expect P2P-SIP to work when some or all of its nodes are behind  
NATs. This is NOT the same thing as inventing a new way to get SIP  
across NATS. We already AHVE ways to get SIP across NATs, and those  
are defined in other working groups.

> The SIP standardization community ignored NAT traversal partially  
> due to a lingering ethic in the IETF that idealizes a so-called  
> "end-to-end" world,  and partially because "it wasn't in our  
> mandate". We are still struggling  with that that error, despite  
> attempts to correct it with ICE, which in any event are still in  
> development, not common deployment as a part of the protocol. After  
> all these years the solution isn't firmly in place.
>

I don't disagree.

> It is finally part of the SIP mandate more  as a patch and repair  
> effort than an originating design. And that effort seems reluctant  
> at best and not a top priority at all.
>

Arguable.

>
> If an effective solution is part of the P2P SIP mandate from day  
> one the P2P SIP implementations will offer a distinct advantage  
> over their classic SIP cousins, which will have to deal with a  
> history of mistakes and balkanized implementations.
>
> Learn from the mistakes of the past. Passing the buck has had real  
> negative impact, and P2P SIP cannot fall in that same trap.

So make it work using the mechanisms available. If we really CAN'T  
make it work using those mechanisms, then we need to push new  
requirements into the other working groups that are or will be  
chartered to do that work. We need to stop trying to boil the entire  
ocean of everything that might possibly be done in a new and exciting  
way using P2P techniques and concentrate on a tightly-scoped set of  
deliverables if we want to have an IETF working group.

--
Dean