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

From: royrr at us.saic.com (Roy, Radhika R.)
Date: Mon, 23 Jan 2006 16:35:12 -0500

Michael:

I agree with you because this is one of the magic that p2p-SIP is bringing
on the table adding tremendous values. In fact, SIP implementations are
faltering because of FW/NAT crossing problems.

If the power of p2p-SIP is so great that it can solve the most complex
problems of VoIP communications like FW/NAT crossing, why should we object
to it instead of welcoming?

Best regards,

Radhika

  _____  

From: Michael Slavitch [mailto:slavitch at gmail.com] 
Sent: Monday, January 23, 2006 4:21 PM
To: Pyda Srisuresh
Cc: Roy, Radhika R.; David Barrett; P2P-SIP
Subject: Re: [p2p-sip] Draft charter for possible P2PSIP WG

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

On 23/01/06, Pyda Srisuresh <srisuresh at yahoo.com
<mailto:srisuresh at yahoo.com> > wrote:

I understand. It is a reasonable approach.

cheers,
suresh

--- "Roy, Radhika R." <royrr at us.saic.com <mailto:royrr at us.saic.com> > 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
>
> -----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
<mailto:p2p-sip-bounces at cs.columbia.edu> 
> <mailto: <mailto:p2p-sip-bounces at cs.columbia.edu>
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> 
> <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
>
>

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

-- 
Michael Slavitch
Ottawa, Ontario Canada 

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

---

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

On Jan 23, 2006, at 3:35 PM, Roy, Radhika R. wrote:

> Michael:
>
>
>
> I agree with you because this is one of the magic that p2p-SIP is  
> bringing on the table adding tremendous values. In fact, SIP  
> implementations are faltering because of FW/NAT crossing problems.
>
>
>
> If the power of p2p-SIP is so great that it can solve the most  
> complex problems of VoIP communications like FW/NAT crossing, why  
> should we object to it instead of welcoming?
>
>

Radhika,

Peer to peer techniques have no "magic" way of making NATs an easy-to- 
solve problem.  NATs are ugly, complex, nasty, and highly  
differentiated beasties, and there are myriad techniques for getting  
across different sorts of NATs.

P2P-SIP is about enabling P2P-SIP nodes to find and communicate with  
other P2P-SIP nodes. We know that some of these nodes will be behind  
NATs. We know that if ALL nodes are behind unique NATs (including the  
"rendezvous function or server"), then there is no known solution to  
be had using P2P techniques.

That said, we need to be able to answer a couple of questions in  
order to get things talking. We hope that P2P techniques will give us  
a better way to answer these questions than client-server techniques  
didm but they're pretty much the same question.

These include:

1) Where shall I send an offer in order to reach my correspondent,  
and how can the response to that offer reach me?

2) How can I inform my potential correspondents as to where they  
should send offers if they want to reach me?

3) If I or my correspondent is behind a particularly nasty relay  
element (firewall, NAT, etc.), what intermediate shall I use to  
attempt to reach (or be made reachable to) my correspondent, and how  
shall I communicate with that correspondent? Are there intermediate  
nodes that I can solicit for assistance with this task?

Notice that all of these questions fall roughly into the category of  
"resource discovery".

--
Dean