Subject: [p2p-sip] Problem statement for P2P SIP NAT traversal

From: quittek at netlab.nec.de (Juergen Quittek)
Date: Thu, 02 Mar 2006 10:59:47 +0100

Dear all,

We tried to analyze the NAT and firewall problem in order to identify
issues that would need consideration when standardizing P2P SIP.

Basically we identified four issues, three for SIP signaling and one for
middlebox detection.  Please find them at

<http://www.ietf.org/internet-drafts/draft-quittek-p2p-sip-middlebox-00.txt>

Here is the abstract:

   Middleboxes, particularly firewalls and network address translators,
   are essential components of today's Internet infrastructure.  They
   are designed to support client-server applications well, but very
   often they are obstacles for peer-to-peer communication.  This memo
   discusses middlebox traversal issues of SIP-based peer-to-peer
   communication.  Required communication steps are analyzed concerning
   their potential constraints caused by middleboxes.  The requirements
   derived from this analysis are compared with the capabilities of
   currently available middlebox traversal methods and SIP signaling
   standards.  The comparison identifies open issues that need to be
   considered when designing standards for a SIP-based peer-to-peer
   communication infrastructure.

The memo contains the essential facts, but we think it needs a more
detailed elaboration in the next version.

Thanks,

    Juergen
-- 
Juergen Quittek        quittek at netlab.nec.de       Tel: +49 6221 90511-15
NEC Europe Ltd.,       Network Laboratories        Fax: +49 6221 90511-55
Kurfuersten-Anlage 36, 69115 Heidelberg, Germany   http://www.netlab.nec.de

---

From: jdrosen at cisco.com (Jonathan Rosenberg)
Date: Thu, 02 Mar 2006 10:14:41 -0500

So, I read this with much interest.

I disagree with many of the assumptions and the analysis performed by 
this document. First and foremost, I think it is a dire, dire, dire 
mistake should any kind of nat traversal solution be proposed for p2p 
sip which is not directly interoperable with the "regular SIP" nat 
traversal strategies. This draft seems to hint that something totally 
new is needed, though I wasnt sure.

Secondly, the draft says its an analysis of existing nat traversal 
techniques for sip. However, it omits the main SIP nat traversal 
techinque in its entirety - ICE and sip-outbound. I dont know how an 
analysis of the applicability of existing nat traversal techniques can 
be considered complete when it has missed the main standards in this area.

Indeed, ICE is basically p2p NAT traversal, and so I believe ice fits 
into a p2p framework extremely well. The only trick you'll need to 
figure out is discovering turn and stun servers, since those presumably 
will be functions provided by other peers in the network (ICE allows for 
any means of discovery of relay services and also allows usage of 
non-turn ones too). If p2p sip endpoints do not use ICE for nat 
traversal, then we will not have interopreability for nat traversal 
between regular sip and p2p-sip, and that is not acceptable IMHO.

The draft presumes that any nat traversal solution requires a step where 
the presence of nat is detected, and typed (section 2.1.2). I strongly 
disagree with this. The ice solution does not attempt to discover or 
otherwise characterize nats at all. Indeed, one of our main experiences 
with rfc3489 was that the whole notion of nat discovery and type 
computation was flawed. That is why this functionality was removed from 
rfc3489bis almost two years ago.

Section 4.2.1 asserts that middlebox detection is needed for non-UDP 
flows. I half agree with this. I agree that we need to make tcp work, 
and support configurations where there is no intermediary, even if its 
another user in the p2p network. The draft asserts that there are no 
solutions for that, but its just not true. ICE-tcp 
(draft-ietf-mmusic-ice-tcp) will allow for creation of direct tcp 
connections through nat as long as the nats allow it; if they don't 
it'll end up falling back on a connection through a relay. Note that 
this relay can be dicsovered by any means, and thus can be another user 
on the p2p network.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen at cisco.com                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: karstbj at yahoo.com (Karst Bjorgson)
Date: Fri, 3 Mar 2006 23:30:42 -0800 (PST)

> be considered complete when it has missed the main

The draft also fails to mention IPv6. I believe this
is a bit short-sighted. Microsoft is making a big push
for IPv6 in Windows Vista. Vista will include an
implementation of Teredo (RFC 4380), which provides
some pretty interesting NAT traversal facilities.

-- Karst

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: dbarrett at quinthar.com (David Barrett)
Date: Sat, 4 Mar 2006 00:12:44 -0800

Hi Karst, 

Do you know if there is any intent for Teredo to support symmetric NATs?
I'd suggest this be a base requirement for P2P-SIP.

-david

> -----Original Message-----
> From: p2p-sip-bounces at cs.columbia.edu [mailto:p2p-sip-
> bounces at cs.columbia.edu] On Behalf Of Karst Bjorgson
> Sent: Friday, March 03, 2006 11:31 PM
> To: Jonathan Rosenberg; Juergen Quittek
> Cc: P2P-SIP
> Subject: Re: [p2p-sip] Problem statement for P2P SIP NAT traversal
> 
> 
> 
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip

---

From: jdrosen at cisco.com (Jonathan Rosenberg)
Date: Sat, 04 Mar 2006 10:20:56 -0500

Its important to note that teredo fits fine into the ice framework. For 
a v4 host it allows it to get a v6 address that can be offered as a 
candidate.

-Jonathan R.

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Sat, 04 Mar 2006 10:30:19 -0500

I also think that support for symmetric NATs is a must.
The requirements draft can be revised to state this explicitly.
Thanks.

Eunsoo

---

From: edpimentl at gmail.com (Edpimentl)
Date: Sat, 04 Mar 2006 10:40:02 -0500

Good comments, I like to point you to the Open-Source Miredo project
which is a Teredo Server
http://www.simphalempin.com/dev/miredo/
http://freshmeat.net/projects/miredo/?branch_id=51002&release_id=211721

We are planning to incorporate Miredo - Teredo Server with OpenSER.

Best.
E Pimentel
http://googaya.com

-- 

ENUM:   878107472467468
Mail:   edpimentl[at]gmail[dot]com
Web:    http://agileco.net
WebLog: http://googaya.com
IM:     [AOL | Jabber | Yahoo | MSN ] edpimentl
Voip:   [SKype | AgileSIP | GoogleTalk | FWD(14272) ] edpimentl

---

From: karstbj at yahoo.com (Karst Bjorgson)
Date: Sun, 5 Mar 2006 22:36:51 -0800 (PST)

> >I'd suggest this be a base requirement for P2P-SIP.

I am pretty sure that a Teredo implementation could be
tuned to work through a lot of symmetric NAT, or at
least in the symmetric to non-symmetric cases. But, as
Jonathan said, IPv6 should be supported as an option.
The combination of IPv4 and IPv6 will work more often
than IPv4 alone.

-- Karst

---

From: fred at perspectiveip.ca (Frederick Lefebvre)
Date: Mon, 6 Mar 2006 19:33:53 -0500

What about mandating the use IPv6 and leave the NAT traversal issue to
the IPv6 transition mechanism used?  Wouldn't it make the
implementation of p2p-sip easier if the protocol did not have to work
around NATs?
Of course, feel free to wonder if this is a realistic proposal or not.
 But with the upcoming Windows Vista, all of a sudden a fairly large
percentage of users will have V6 connectivity and it might not sound
so crazy anymore.

-- Fred

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Mon, 6 Mar 2006 19:52:59 -0500

Are you serious? How many ISP's offer IPV6?  How many organizations outside
academe and a few large enterprises?
Do you realize how many people in the real world still use Windows 2000 and
Windows 98, including some very large organizations?
Given past history Vista will  run on the majority of Windows desktop
systems starting around  2010-2011, and that is optimistic.

In the meantime, Skype works now.

If P2PSIP is limited to IPV6 we might as well call it a day right now and
start licensing runtime modules from Skype.

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

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Mon, 06 Mar 2006 21:33:22 -0500

I strongly believe support for IPv4 is a must.
Thanks.

Eunsoo

Michael Slavitch wrote:

> Are you serious? How many ISP's offer IPV6?  How many organizations
> outside academe and a few large enterprises?
> Do you realize how many people in the real world still use Windows
> 2000 and Windows 98, including some very large organizations?
> If P2PSIP is limited to IPV6 we might as well call it a day right now
> and start licensing runtime modules from Skype.
>
>
> On 3/6/06, * Frederick Lefebvre* <fred at perspectiveip.ca
> <mailto:fred at perspectiveip.ca>> wrote:
>
>     On 3/6/06, Karst Bjorgson <karstbj at yahoo.com
>     <mailto:karstbj at yahoo.com>> wrote:
>     > p2p-sip at cs.columbia.edu <mailto:p2p-sip at cs.columbia.edu>
>     <https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip>
>     >
>
>     p2p-sip at cs.columbia.edu <mailto:p2p-sip at cs.columbia.edu>
>------------------------------------------------------------------------
>

---

From: henry at pulver.com (Henry Sinnreich)
Date: Mon, 6 Mar 2006 21:04:55 -0600

>> Are you serious? How many ISP's offer IPV6?

I agree with Michael. Groupthink and wishful thinking can be serious
impediments for P2P SIP. Skype was original.

 Thanks, Henry

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Eunsoo Shim
Sent: Monday, March 06, 2006 8:33 PM
To: Michael Slavitch
Cc: P2P-SIP
Subject: Re: [p2p-sip] Problem statement for P2P SIP NAT traversal

Eunsoo

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Tue, 7 Mar 2006 11:42:14 -0600

On Mar 6, 2006, at 6:52 PM, Michael Slavitch wrote:

> Given past history Vista will  run on the majority of Windows  
> desktop systems starting around  2010-2011, and that is optimistic.
>
> If P2PSIP is limited to IPV6 we might as well call it a day right  
> now and start licensing runtime modules from Skype.
>
>
> On 3/6/06, Frederick Lefebvre <fred at perspectiveip.ca> wrote: What  
> about mandating the use IPv6 and leave the NAT traversal issue to

I believe the suggestion was that we not develop a P2P-SIP specific  
mechanism for NAT traversal on IPV6 networks, but leave that to the  
IPV6 transition mechanism.

This is far different from suggesting that we not support IPV4.

--
Dean

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Tue, 7 Mar 2006 12:49:46 -0500

"What about mandating the use (of) IPv6" and "Wouldn't it make the
implementation of p2p-sip easier if the protocol did not have to work around
NATs?"  sound very clear to me.

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

---

From: csp at csperkins.org (Colin Perkins)
Date: Tue, 7 Mar 2006 20:00:42 +0000

> This is far different from suggesting that we not support IPV4.

Indeed -- there are interesting approaches that build a peer-to-peer  
IP overlay network, perhaps IPv6-based, as the NAT traversal  
mechanism, and then run normal applications on that overlay network.

Colin

---

From: stiemerling at netlab.nec.de (Martin Stiemerling)
Date: Wed, 8 Mar 2006 11:46:46 +0100

Hi Jonathan, all,

> new is needed, though I wasnt sure.

Nope, the draft is NOT suggesting to use something totally new. Indeed
it tries to identify the possible ways to go in p2p sip. And definitely,
all techniques of NAT traversal mentioned in the document should
work just fine with the "regular SIP". There is no intention to open
the box for yet another NAT traversal technique.

> be considered complete when it has missed the main standards in  

Granted. We have missed ICE, even though it is well-known. This is not
because of ignorance but due to a very fast approaching -00 deadline.
As said above, the document's intention is not to open the box for a
new protocols, but to explorer the existing NAT traversal space.

> any means of discovery of relay services and also allows usage of

I share this view.

> rfc3489bis almost two years ago.

Sure, it is quite difficult to characterize NATs in general, but  
nodes should
be free to run their NAT classification procedure. Where  
classification does
not refer to "this is kind of NAT type X" but more "does it work what  
I want
to achieve".

> (draft-ietf-mmusic-ice-tcp) will allow for creation of direct tcp

Same here as with the ICE above.

Thanks,

   Martin

---

From: stiemerling at netlab.nec.de (Martin Stiemerling)
Date: Wed, 8 Mar 2006 11:51:33 +0100

> The draft also fails to mention IPv6. I believe this

Well, is there a NAT for IPv6? Or do you refer to NAT
traversal of IPv6 itself?

If it is NAT traversal of IPv6 itself, your SIP application would
probably not see much of it. In this case the operating system
would get you an IPv6 address, which is basically located at
the Teredo server.

   Martin

---

From: quittek at netlab.nec.de (Juergen Quittek)
Date: Wed, 08 Mar 2006 12:27:25 +0100

Jonathan and Martin,

> the box for yet another NAT traversal technique.

The point of confusion might be that the draft tries to decompose functions
that are nicely integrated into existing NAT traversal techniques.
These functions are listed separately, but there is not intention
to propose that the selected NAT traversal methods for P2P SIP should
be individual solutions for each function. The drafts says (probably
not strong enough) that this is not required (and probably not
recommendable).

> new protocols, but to explorer the existing NAT traversal space.

Yes, the lack of ICE coverage is really a flaw.  But it should be no
problem to fix it for the next version.  Also, I do not see a big impact
on the identified issues that we should take care of when developing
P2P SIP.

> not refer to "this is kind of NAT type X" but more "does it work what

Yes, the draft should state this more clearly.
Since we do not have a common NAT taxonomy, it would be very difficult
to clearly identify a NAT type.  But it will be comparably easy to identify
which kind of communication is possible and how it can be achieved.

>> (draft-ietf-mmusic-ice-tcp) will allow for creation of direct tcp

Please note that draft-ietf-mmusic-ice-tcp-00 has the same publication
date as the P2P SIP NAT traversal draft. So, it is no wonder that ICE TCP
is not yet included.

The draft does not state or assert that there is no solution for TCP
NAT traversal.  But it states that there are no known tools for
performing middlebox detection for protocols other than UDP. And
after reading draft-ietf-mmusic-ice-tcp-00 I still think this is correct.

Thanks,

    Juergen

---

From: quittek at netlab.nec.de (Juergen Quittek)
Date: Wed, 08 Mar 2006 12:32:59 +0100

Karst,

The draft does not make any specific assumption about IPv4 or IPv6.
Particularly, it does not make the (potentially wrong) assumption
that if the entire Internet had moved to IPv6, there would be no
NATs anymore.

Thanks,

    Juergen

---

From: quittek at netlab.nec.de (Juergen Quittek)
Date: Wed, 08 Mar 2006 12:34:42 +0100

> This is far different from suggesting that we not support IPV4.

Whatever we develop, it should fully cover both, IPv4 and IPv6.

Thanks,

    Juergen

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Wed, 8 Mar 2006 09:27:08 -0500

A participating P2P node MUST NOT neet to support IPV6. IPV6 may exist in
the mesh, but it must not be the defining characteristics of the mesh
itself, otherwise we are limiting ourselves once again to orthodoxy.  There
are several well-known techniques already discussed in this list that makes
the underlying addressing protocols abstract entitites.  They work both in
theory and in practise, are well-founded, and should be considered. They are
not open research topics, they are new elaborations of well-understood
techniques.  The only matter left is determining if the underlying
abstraction identifiers are robust enough and can map into SIP without any
changes or harm.

P2P overlays can traverse any protocol that has the following
characteristics:

1. A known consistant datalink layer.
2. A known consistant socket mechanism.
3. An addressing scheme that can be overloaded by some well-published or
well-known identifier.

That's it.

There are mathematical proofs for this.  This is not guesswork.

The protocol underneath need not be IPV6. It can be IPV4, IPX,  or even
DECNET.  With a little work and crossed fingers you could support X.25 and
HDLC.

I have personal experience in this matter as a I developed similar overlay
systems for peer to peer communications nearly a decade ago, systems that
completely abstracted the underlying addressing schemes with unique
identifiers in order to transparently traverse not only NATs but protocol
gateways and without changes to the network layer or existing protocol
addressing schemes.  It not only worked for IPV4 and IPV6 but worked for
IPX, DECnet,  and other proprietary protocols, and required minor changes
only to top-line application and database schemas, not the underlying
systems themselves.
In that industry the procurement cycles take upwards of a decade and the
equipment is used for a very long time in very distant places, so upgrades
are not possible.  If an obscure programmer could do this a decade ago there
is no excuse for the IETF to say it is not possible nor a good idea now.

Michael

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

---

From: henry at pulver.com (Henry Sinnreich)
Date: Wed, 8 Mar 2006 08:55:00 -0600

Michael,

I wish you could submit an I-D to the hopefully soon to be formed P2P SIP WG
discussing these issues.

Henry

  _____  

From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of Michael Slavitch
Sent: Wednesday, March 08, 2006 8:27 AM
To: Juergen Quittek; P2P-SIP
Subject: Re: [p2p-sip] Problem statement for P2P SIP NAT traversal

That's it.   

Michael

On 3/8/06, Juergen Quittek < <mailto:quittek at netlab.nec.de>
quittek at netlab.nec.de> wrote:

Thanks,

    Juergen

-- 
Michael Slavitch
Ottawa, Ontario Canada 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060308/7625522d/attachment.html

---

From: gregd at research.panasonic.com (Greg Daley)
Date: Wed, 08 Mar 2006 10:04:04 -0500

Hi Juergen.

Juergen Quittek wrote:
[cut]
> after reading draft-ietf-mmusic-ice-tcp-00 I still think this is correct.

This is the WG document.  There were prior individual submissions
which could be referred to.

Let's be very careful not to re-invent things in our rush to
define requirements for P2P-SIP.

I know this is not the intention, but if we fail to regard the
body of work available, we will make too much work for ourselves.

Greg

---

From: quittek at netlab.nec.de (Juergen Quittek)
Date: Wed, 08 Mar 2006 16:15:10 +0100

Hi Michael,

--On 3/8/06 9:27 AM -0500 Michael Slavitch wrote:

> A participating P2P node MUST NOT neet to support IPV6. IPV6 may

Probably I should have phrased more carefully.  My apologies not
not being clear enough.

I just wanted to state that whatever we develop, it should be
possible to implement it for an IPv4 environment as well as for
an IPv6 environment (probably in different ways).  This does not
imply that every implementation must fully support both (which
would not make too much sense).

Still, we can think about whether or not, an IPv6 client needs
to be become aware that its public IP address is an IPv4 address
(or vice versa). The current SIP/SDP specification would require
this.

> exist in the mesh, but it must not be the defining characteristics
> of the mesh itself, otherwise we are limiting ourselves once again
> to orthodoxy.  There are several well-known
> techniques already discussed in this list that makes the underlying
> addressing protocols abstract entitites.  They work both in theory

This is a nice way of dealing with the IPv4/IPv6 problem that
certainly should be considered as design choice for our P2P SIP
solution.

> and in practise, are well-founded, and should be considered. They
> are not open research topics, they are new
> elaborations of well-understood techniques.  The only matter left
> is determining if the underlying abstraction identifiers are robust
> enough and can map into SIP without any changes or harm.
>
> P2P overlays can traverse any protocol that has the following characteristics:
>
> 3. An addressing scheme that can be overloaded by some well-published
> or well-known identifier.
>
> That's it.

Right ... except for setting it up. when you bootstrap the overlay
or connect a new node, you might have to care about the ugly NATted
world underneath.

> The protocol underneath need not be IPV6. It can be IPV4, IPX,  or
> even DECNET.  With a little work and crossed fingers you could
> support X.25 and HDLC.
>
> I have personal experience in this matter as a I developed similar
> overlay systems for peer to peer communications nearly a decade ago,
> systems that completely abstracted the underlying addressing schemes
> with unique identifiers in order to
> transparently traverse not only NATs but protocol gateways and without
> changes to the network layer or existing protocol addressing schemes.
> It not only worked for IPV4 and IPV6 but worked for IPX, DECnet,  and
> other proprietary protocols, and
> required minor changes only to top-line application and database
> schemas, not the underlying systems themselves.
> In that industry the procurement cycles take upwards of a decade and
> the equipment is used for a very long time in very distant places, so
> upgrades are not possible.  If an obscure programmer could do this a
> decade ago there is no excuse for the IETF
> to say it is not possible nor a good idea now.

Did anyone say so?

> Michael

I do not feel to be in any disagreement with you.
Please consider that we are in an early phase right now
and many design decisions have not been made yet.

If you refer to the draft on problem statements for NAT traversal:
It is not intended to limit the solution space for P2P SIP in any way.
I just lists potential issues with SIP and middlebox detection when
designing the P2P SIP solution.  We will make sure that we state this
very clearly in the next version.

Thanks,

    Juergen

> On 3/8/06, Juergen Quittek < quittek at netlab.nec.de> wrote:
>
>

---

From: quittek at netlab.nec.de (Juergen Quittek)
Date: Wed, 08 Mar 2006 16:40:48 +0100

Greg,

> which could be referred to.

Yes, there was Jonathan's draft out since October.
Also we are missing the entire ICE story.
Still, in the draft we talked about 'existing tools'.
I hope that ICE TCP will soon be something I can use as tool.

> define requirements for P2P-SIP.

That's the point of misunderstanding.  We tried in the draft
not to limit the solution space in any way. Intentionally, we
avoided talking about 'requirements'. We just listed 'issues
to be considered' developing P2P SIP.
I'm sorry for communicating this badly in the draft.

> body of work available, we will make too much work for ourselves.

Completely agreed.  The draft charter intentionally says "Select
firewall/NAT traversal technique(s)" and not "Develop ...".

Thanks,

    Juergen

---

From: lowekamp at cs.wm.edu (Bruce Lowekamp)
Date: Wed, 8 Mar 2006 11:01:02 -0500

> which kind of communication is possible and how it can be achieved.

I've found draft-ietf-behave-nat-udp-04 to be very useful in terms of
describing the behavior of NATs.  As others have pointed out,
ultimately the only test is whether the NAT does what you need it to 
(and I have a couple on my desk that characterize the right way but
fail applications in bizarre ways), but this draft (which has been
submitted for publication) is useful for the common terminology it
provides.

Ultimately, I too hope that whatever P2P SIP protocol we come up with
will simply say "use ICE" (or something similar), and we can all go
out and have a beer when it comes time to discuss NATs.  Sadly, I
suspect getting to that point will take a lot of work on requirements.

Bruce

---

From: dbarrett at quinthar.com (David Barrett)
Date: Sun, 12 Mar 2006 20:24:51 -0800

> From: Juergen Quittek
> Sent: Wednesday, March 08, 2006 3:27 AM
> To: Martin Stiemerling; Jonathan Rosenberg
> Cc: P2P-SIP

My impression was that we would define what we need from NAT traversal, and
then evaluate all the options (ICE included).  Furthermore, once our
requirements are specified, I thought we were going to remain option to new
NAT traversal options, and not presuppose ICE as the final choice (otherwise
we should just pick it now).

For example, would we be open to the following chain of events?

1) We publish what P2P-SIP requires in the way of NAT traversal
2) Somebody invents a protocol that meets these requirements
3) We adopt this new protocol, despite it not being ICE

If we're not, then let's just say "P2P-SIP will use ICE" and be done with
it.  Granted, I believe that'd be a mistake, but I respect that reasonable
minds can disagree on this point.

-david

---

From: dbarrett at quinthar.com (David Barrett)
Date: Sun, 12 Mar 2006 20:26:07 -0800

-david