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

From: jdrosen at cisco.com (Jonathan Rosenberg)
Date: Mon, 13 Mar 2006 14:52:02 -0500

inline.

David Barrett wrote:

>>-----Original Message-----
>>From: Eunsoo Shim [mailto:eunsoo at research.panasonic.com]
>>Subject: Re: [p2p-sip] Problem statement for P2P SIP NAT traversal
>>
>>In principle, working out requirements and looking for a solution
>>without presupposing a solution are all fair. Nevertheless, I think we
>>should pay attention to existing solutions first.
> 
> 
> Certainly.  But there are many "existing solutions".  Even if we stick
> within the bounds of IETF there are at least two serious contenders: ICE and
> Teredo (RFC 4380). 

Teredo can be used with ICE, of course. Its even called out in the draft 
as such. It only helps with connecting to other v6 endpoints. YMMV on 
how important that is.

> And if we look further afield I know of at least two
> others (and I'm sure there are more).  But unless we make a serious effort
> to evaluate ICE alternatives, we're not making a serious effort to evaluate
> ICE alternatives.  So the question is:
> 
> "Are we going to make a serious effort to evaluate alternatives to ICE?"
> 
> If the answer is no, then let's state as much.  It certainly simplifies our
> work.  This seems to be Jonathan's suggestion, and it's an entirely
> reasonable approach (though not the one I recommend).

You are right, that is my suggestion.

> 
> But if the answer is yes, then let's do it.  Let's state what the criteria
> for selection are, and take the best option.  If ICE comes out on top,
> wonderful, we can defend our choice as not only convenient but optimal.  And
> if we can do better than ICE, wonderful, who wouldn't want this?

If there is something better than ICE, what makes that specific to p2p?

> 
> I'd just like to know if we're even considering anything other than ICE, and
> what the grounds for consideration are.  It was my impression that a
> discussion on this topic on this list had already occurred (late Jan) and
> this plan (defining the NAT-traversal requirements before choosing a
> solution) was the result [1]. 
> 
> ----------------------------------------------------------------------------
> [1] https://lists.cs.columbia.edu/pipermail/p2p-sip/2006-January/000366.html
> 
> Specifically, the working group will:
> 
> ...
> 
> 5. Select firewall/NAT traversal technique(s) for P2P SIP and integrate
>     them into the P2P SIP architecture or framework.  If necessary,
>     define requirements for enhancements of existing techniques to be
>     acted on by other working groups.
> 
> ----------------------------------------------------------------------------
> 
> My contribution to these requirements (if we choose to have them) would be:
> 
> - Establishes direct connections with >90% effectiveness in today's internet
> 	. eg, include symmetric<->symmetric piercing

I'll agree with that.

> - Evaluates all routes in parallel and select the fastest
> 	. vs sequential evaluation

You can't have your cake and eat it too. ICE originally worked this way 
and it was found to be hugely problematic from a congestion and nat 
overload perspective. That is why it was changed later on.

So, I strongly disagree with this requirement.

I also dont see what it has to do with p2p. Nothing about this 
requirement is unique to p2p sip.

> - Discovers the minimum keepalive frequency to maintain UDP NAT mappings
> 	. vs deferring to the application layer

Ideally I'd agree with you; but this is profoundly hard to do without 
more directly controlled nats.

I also don't see what this has to do with p2p.

> - Integrates with core SIP syntax (INVITE, REGISTER, etc)
> 	. vs a standalone protocol with unique grammar

That seems like a solution proposal and not a requirement. It also has 
nothing to do with p2p.

I find it odd that your suggested requirements miss what I think is the 
only new requirement here - that the solution not require a centralized 
server in order to operate. THAT is actually a reasonable and new 
requirement introduced by p2p.

> 
> I'm not totally sure how ICE and Teredo stack up against this,

Of course you are. Please don't dance around the point. You know very 
well from your other comments how ICE does and doesn't address these 
points. To date, your proposals on investigating SIP p2p nat traversal 
seem to be a thinly veiled attempt to design and/or select alternate nat 
traversal techniques because of some grudge against what has been 
specified already.

As I have suggested before, if you have beefs with the design of ICE, 
take them to mmusic and lets discuss there as part of ICE discussions. 
If you have an alternative proposal, I look forward to the draft. But, 
it is a travesty to the community to use p2p sip as an excuse to 
redesign parts of SIP with new requirements that have nothing to do with 
p2p.

-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: slavitch at gmail.com (Michael Slavitch)
Date: Mon, 13 Mar 2006 15:54:11 -0500

> redesign parts of SIP with new requirements that have nothing to do with 
The result of the process will be a set of requirements to solve the 
use-case needs of P2PSIP.

If it can be */demonstrated /*that ICE can meet these requirements ICE 
will be fine. If not a set of requirements will be sent to MMUSIC.
If MMUSIC cannot act on these requirements or if ICE cannot be seen as 
effectively meeting those requirements something else must be 
considered.  It is the onus of ICE to meet these requirements, not the 
other way around.

I say requirement #1 is:  P2PSIP NAT traversal must be in broad 
interoperable use.
Teredo may be such a beast.  I am not so sure about ICE.

It is the requirements that win, not a draft implementation.  ICE is 
still an Internet-Draft.  It is not yet RFC standard in wide adoption.

It is true that P2PSIP should borrow on existing standards for SIP.  SIP 
has been around for a decade.
ICE is still in draft form, version seven and counting.

When ICE is RFC level and in wide interoperable use the same will be 
said for it. 

Until then it is a draft, and drafts can still be fed requirements or 
suggestions, or rejected outright. 

How many iterations of ICE have we seen. How many YEARS has it taken? 
And it is still in draft form. 
I would respect "use ICE" if the ICE RFC was settled five years ago.  It 
was not.  ICE is still an open question.

Meanwhile,  Skype works right now and is gobbling up share.  If ICE was 
a simple RFC three years ago this would not be the case.

See you in Dallas

Regards

Michael

---

From: dbarrett at quinthar.com (David Barrett)
Date: Mon, 13 Mar 2006 12:59:01 -0800

> From: Jonathan Rosenberg [mailto:jdrosen at cisco.com]

Cool!  I didn't realize ICE supported this yet.

> overload perspective. That is why it was changed later on.

Extra cool!  Again, my understanding of ICE was out of date.

> more directly controlled nats.

Well, I disagree here.  Just use a parallel "throwaway" connection whose
only purpose is to discover NAT refresh times.  I use this in iGlance and it
works great.  With it I've discovered that NAT refresh times are horribly
erratic, and not at all constant (I've experienced NATs that start at 1s and
grow up to 512s over time).  I believe this is a sufficiently advanced
problem that it should be handled by the NAT solution itself, rather than
left up to the application developer.

> I also don't see what this has to do with p2p.

If P2P is defined purely as DHT, then I'd agree.  But it's my understanding
our mandate takes a broader view, including the integration of NAT
penetration best practices.

> That seems like a solution proposal and not a requirement. It also has

Well, yes, I'd suggest we not abstract NAT from SIP, just like I'd prefer we
not abstract DHT from SIP (another topic of ongoing debate).  I don't
dispute we *can* (ICE being a great example of the result when you do), but
I personally think SIP can and should be extended to accomplish both.  

As such, I'm offering this as a requirement.  I don't claim that it *is* a
requirement (because the list doesn't yet exist, and certainly hasn't been
formalized), but I'm happy to argue for its inclusion.

> requirement introduced by p2p.

Again, I accept as reasonable the view that the *only* topic open for debate
is how to decentralize the SIP proxy.  Personally, I take a broader view
(and one that I believe is consistent with our mandate).

> redesign parts of SIP with new requirements that have nothing to do with

Well, given that I was wrong on at least two points about ICE, I can say
with certainty that I didn't know how they'd stack up.  ICE has undergone
(and, I think, is undergoing) rapid change, and it's hard to keep up.

As for my ulterior motive, I think it's not so thinly veiled: I believe
there are superior options to ICE and I'd like us to investigate them.
You're correct, this has been my explicit goal from the start.  So far as I
can tell, it's within our mandate to consider alternatives to ICE, and I'm
just trying to push along that path.

That's a fair suggestion that I take my concerns to the ICE group, but given
that I fundamentally disagree that ICE is needed at all (my point is that
SIP should handle it implicitly), this seems like a futile gesture.

And I appreciate your request for a drafted alternative.  If the P2P-SIP
group lists the criteria for acceptance and commits to a fair evaluation
based on those criteria, that's just what I (and I'm sure others) will do.
 
Finally, let's keep this focused on the merits and combinations of ICE, SIP,
P2P, DHTs, etc.  This isn't about me.

Anyway, ultimately the P2P-SIP group will recommend best practices and
standards for deploying SIP in internet-wide, (mostly?) serverless
scenarios.  One component of this is NAT penetration.  One proposal is to
just say "we recommend ICE" and be done with it.  My proposal is to define
what criteria we'll use to evaluate NAT penetration proposals, and then
judge the options accordingly.

Which proposal do you (ie, everyone else) prefer?

-david

---

From: jdrosen at cisco.com (Jonathan Rosenberg)
Date: Mon, 13 Mar 2006 16:18:27 -0500

Michael Slavitch wrote:

>> redesign parts of SIP with new requirements that have nothing to do 
>> with p2p.
>>
>> -Jonathan R.
>>   
> 

I'm afraid I have to disagree with that.

It is not the job of p2p sip to redefine the requirements for all of the 
SIP extensions that our out there, so that you can choose to retain or 
discard various ones as you see fit. If this were the case, "p2p sip" is 
a poor name for this group. It sounds like some folks are looking for 
'p2p voip', and you'd like to define a protocol that is not 
interoperable with sip to do that. Well, that is one possible charter, 
but not the one I'd hope for.

> Teredo may be such a beast.  I am not so sure about ICE.

Well, we can debate all of that. ICE is actually in use quite a bit in 
various softphones and voip deployments in service providers today. 
Teredo is for v6, as you know. As I said, a v6 only solution for nat 
traversal is .... interesting. YMMV as to whether that meets the needs 
of the community.

In any case, all of this is really just sounding like the 'we hate 
certain sip extensions and plan on doing our own' WG. Now, I can point 
to other SIP documents in various stages of deployment. So, I guess, by 
your metric, p2p sip shall be able to discard anything it likes that has 
not reached some magic deployment threshold? Absurd.

> still an Internet-Draft.  It is not yet RFC standard in wide adoption.

Its not an RFC, no. WIDE usage? Depends on your definition. Implemented? 
Absolutely. Deployed? Yes.

I'll note I found this criteria (technique must be in widespread 
deployment) laughable. p2p SIP itself is not even yet a working group. 
We've got threads going on debating fundamental issues like, should the 
DHT be done within SIP or through a layer separate? And can it be 
secured? p2p SIP is itself only just getting started. And you are going 
to throw away a fundamental piece of SIP architecture because its not 
done yet? Now that is ironic.

> suggestions, or rejected outright.

Sure it can be changed or improved; we've been doing that for a while. 
This is a hard problem as you know, with many constraints from different 
communities.

But rejected outright? Well, its a WG document, it has broad support 
from the WG as such. There are no plans for its rejection that I know of.

> And it is still in draft form. I would respect "use ICE" if the ICE RFC 
> was settled five years ago.  It was not.  ICE is still an open question.
> 

Ah. So, by your metric (wide deployment), our only possible solution for 
p2p SIP, nat traversal and all, would be Skype?

-Jonathan R.

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Mon, 13 Mar 2006 16:42:08 -0500

> traversal is .... interesting. YMMV as to whether that meets the needs

I know, we use an implementation of ICE in our softphones.  It works if you
have a systems
engineer handy.

However our softphones don't work with Vendor B softphones or service
provider C.
Vendor D doesn't know we exist, and Vendor E claims that they support ICE
but lie, and
there is no way to debunk that without extensive testing, which doesn't
scale.   Provider
F won't bother until his vendor supplies ICE and his vendor is waiting for
an RFC but\
pushing proprietary phones.

Without an RFC, an interoperability test,  and comparison code it's not an
open standard,
it's a recommendation.

If you want a bunch of interoperable silos, ICE is great.  Maintains the
CPE/Carrier silos fine.
That's great if there was no alternative, but there is. Skype just works.
My mother uses it.
Her ancient relatives in Ukraine use it.   No systems engineers at all.
Their IT departments
consist of twelve years olds, no NOC involved, and the equipment needed is
available at
the nearby shop.   Click, call, done.

I agree with you, there are implementations of NAT traversal that read on
ICE.  Your point?
When I can get a state diagram that can be fed to coders and to testers
without handholding
it's a protocol. Until then it's a recommendation.

> not reached some magic deployment threshold? Absurd.

I don't hate ICE.  I want ICE to work interoperably, simply and
effectively.  I want vovida code.
If that is true then there is no problem.   If a spec goes  to 100 vendors
and the result is 100
implementations that interoperate ICE is great.  I've wanted ICE for a long
time.
I'm still waiting.  Meanwhile ICE exists, no waiting.

> This is a hard problem as you know, with many constraints from different

Skype did it several years ago. It's done.  It borrowed from file sharing.
Done.

> from the WG as such. There are no plans for its rejection that I know of.

It's not rejection by the IETF that matters.  It's rejection by the market
at large.

  |  Ah. So, by your metric (wide deployment), our only possible solution
for

> p2p SIP, nat traversal and all, would be Skype?

Not just that.   Of course not.  But it works and has done so for  a while.
No systems engineering, no TURN setup, no STUN setup.  It just works.

The #1 requirement of P2PSIP: It just works.  No excuses.

If ICE "just works"  we're in total agreement and we have no issue.  Let's
find out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060313/16c18d14/attachment.html

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Mon, 13 Mar 2006 16:44:24 -0500

One sentance above should state:

"Meanwhile ICE exists, no waiting."

Should be:

"Meanwhile Skype exists, no waiting."

That is all,

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

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Mon, 13 Mar 2006 16:53:32 -0500

Jonathan Rosenberg wrote:

>discard various ones as you see fit. 
>
I agree with Jonathan. Reviewing the requirements of various SIP 
extensions MUST be performed in WGs like SIP, SIPPING, SIMPLE and so on 
according to each WG's charter.

>If this were the case, "p2p sip" is 
To repeat myself, I strongly believe that interoperability with the 
client server SIP is important for P2P SIP.
We are not trying to reinvent SIP. We should not.
As far as I remember, the separation of SIP and the overlay layer was 
supported widely in the P2P SIP ad-hoc meeting in Vancouver.
One of the main advantages of the separation was "no change in SIP 
almost or at all".

>p2p SIP, nat traversal and all, would be Skype?

Thanks.

Eunsoo

---

From: jdrosen at cisco.com (Jonathan Rosenberg)
Date: Mon, 13 Mar 2006 16:58:09 -0500

Interop is easy when the protocol and all implementations come from a 
single company, as they do with Skype.

Interop is harder when you want to introduce standards so that multiple 
vendors and multiple providers can interoperate. Thats what IETF does. 
Thats why we are here. Its a difficult process that takes longer, 
because it requires multiple participants with differing interests and 
perspectives, and broader requirements covering more diverse needs.

If you want p2p-sip to 'just work', I suggest that time is better spent 
figuring out how to eliminate the need to configure the servers that ICE 
depends on - turn and stun servers - and figure out how to dynamically 
find ones amongst peers in the mesh. When you do that, ICE will just 
work and do so in a p2p environment. I think that is a better service to 
the community than rants about how ICE is taking so long along with bold 
claims about how you can do something better, faster, and with better 
interoperability results.

-Jonathan R.

Michael Slavitch wrote:

> On 3/13/06, *Jonathan Rosenberg* <jdrosen at cisco.com 
> <mailto:jdrosen at cisco.com>> wrote:
> 
> 
> 
> I know, we use an implementation of ICE in our softphones.  It works if 
> you have a systems
> engineer handy.
> 
> Vendor D doesn't know we exist, and Vendor E claims that they support 
> ICE but lie, and
> F won't bother until his vendor supplies ICE and his vendor is waiting 
> for an RFC but\
> Without an RFC, an interoperability test,  and comparison code it's not 
> an open standard,
> it's a recommendation.
> 
> That's great if there was no alternative, but there is. Skype just 
> works.  My mother uses it. 
> consist of twelve years olds, no NOC involved, and the equipment needed 
> is available at
> I agree with you, there are implementations of NAT traversal that read 
> on ICE.  Your point?
> If that is true then there is no problem.   If a spec goes  to 100 
> vendors and the result is 100
> implementations that interoperate ICE is great.  I've wanted ICE for a 
> long time.
> Skype did it several years ago. It's done.  It borrowed from file 
> sharing. Done.
> 
> It's not rejection by the IETF that matters.  It's rejection by the 
> market at large. 
> 
>   |  Ah. So, by your metric (wide deployment), our only possible 
> solution for
> 
> If ICE "just works"  we're in total agreement and we have no issue.  
> Let's find out. 
> 
> 
>

---

From: salman at cs.columbia.edu (Salman Abdul Baset)
Date: Mon, 13 Mar 2006 17:05:09 -0500 (EST)

Skype works because they are not constrained by any interop issues. And
there is possibly no magic which can make a protocol interoperable.
Developers are dictated by deadlines and they make mistakes. I am sure the
Skype developers must have made mistakes. Their protocol suit has been
regularly updated to correct those mistakes (check for stack version
number in skype system call dumps)

Also, the core protocol developer community is very small in Skype as
compared to SIP/STUN/ICE which certainly has hundreds and possibly a few
thousand developers worldwide. They all have different needs and
requirements vs possibly a few requirements for Skype.

While a good majority of the academic world is busy in churning papers after
papers about making an algorithm 'purely' distributed, Skype combines the
benefits of distributed and central paradigms in a very decent way.

An interesting question for me is: how many internet-drafts/RFCs does a
developer needs to read to implement a Skype like network? From some of
the posts on this list, it appears that people want to have one document
to read and to be able to implement a Skype like system. After reading
a RFC/draft, they find it difficult to decide what to implement and what to
leave.

Regards,
Salman

---

From: ag at ag-projects.com (Adrian Georgescu)
Date: Mon, 13 Mar 2006 14:06:15 -0800

Jonathan is absolutely right, P2P SIP should only concentrate on how  
to allocate and find resources. The way the signaling and nat  
traversal work have already been sorted out, this to-be WG should  
just find a way to put the pieces together to achieve scalability.

Adrian

On Mar 13, 2006, at 1:58 PM, Jonathan Rosenberg wrote:

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

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Mon, 13 Mar 2006 17:09:25 -0500

'To repeat myself, I strongly believe that interoperability with the client
server SIP is important for P2P SIP.
We are not trying to reinvent SIP. We should not. As far as I remember, the
separation of SIP and the overlay layer was
supported widely in the P2P SIP ad-hoc meeting in Vancouver. One of the main
advantages of the separation was "no change in SIP
almost or at all".'

I fully agree with this.   The separation of SIP and the overlay is what
makes SIP reuse possible.   The biggest change I foresee in this
model involves the overloading of names used to identify nodes, agents and
addresses.   In other words,  "words" and "names".

SIP syntax could allow:  DNS name, IPV4, IPV6,  or "P2PNAME".  There are
lots of people working on smart ways to do 'P2PNAME'.

In our experience if SIP/RTP/SDP allow p2pnames to overload addresses in
descriptions  of entities (much like DNS, but possibly not DNS, perhaps
something else)  then those protocols can continue merrily along.  No more
changes to SIP or SDP needed.  Minor changes that don't break
interoperability.

Given the nature of these protocols this many not require any changes to the
existing state machines.
It only adds one additional descriptor to the valid set of possible
descriptors.

Changes involving syntax are not major, and they are backward compatible.
Changes involving state behavior are major and break things.

In code-speak it becomes a recompile with another accepted data-type, and
some testing, using existing test suites.

It becomes easy.

If  the SIP agenst on top of the overlay uses ICE, great.

If ICE meets the requirements for the underlying overlay, better.

Let's find out.

Regards

Michael

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

---

From: sathya at research.panasonic.com (Sathya Narayanan)
Date: Mon, 13 Mar 2006 17:09:27 -0500

David -

> <snip>
I don't understand how you came to the conclusion that "it's within our
mandate to consider alternatives to ICE". The relevant sentence in the
charter reads,
"

Select firewall/NAT traversal technique(s) for P2P SIP and integrate
   them into the P2P SIP architecture or framework.  If necessary,
   define requirements for enhancements of existing techniques to be
   acted on by other working groups.

"

Please note "If necessary" - the necessity MUST be demonstrated before
suggesting new requirements and it MUST be acted on by other
(appropriate) working groups.
We had a debate on this earlier and agreed to the sentence as it is
written now.

thanks,
Sathya

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Mon, 13 Mar 2006 17:15:34 -0500

I think any open standard protocol has an issue of interoperability 
because there will be various implementations.
A simple mistake of a developer is enough to cause a problem in 
interoperability.
The interoperability issue cannot be cited as a weakness in comparison 
with Skype's software since it is an implementation by just one company.
Whatever we design in P2P SIP WG will have the same interoperability issue.
Thanks.

Eunsoo

Michael Slavitch wrote:

> I know, we use an implementation of ICE in our softphones.  It works 
> if you have a systems
> engineer handy.
>
> there is no way to debunk that without extensive testing, which 
> doesn't scale.   Provider
> Without an RFC, an interoperability test,  and comparison code it's 
> not an open standard,
> it's a recommendation.
>
> If you want a bunch of interoperable silos, ICE is great.  Maintains 
> the CPE/Carrier silos fine.
> Her ancient relatives in Ukraine use it.   No systems engineers at 
> all. Their IT departments
> consist of twelve years olds, no NOC involved, and the equipment 
> needed is available at
> When I can get a state diagram that can be fed to coders and to 
> testers without handholding
>------------------------------------------------------------------------
>

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Mon, 13 Mar 2006 17:30:55 -0500

"The interoperability issue cannot be cited as a weakness in comparison"

Interoperability becomes a non-issue if there is a reference design to draw
from,
as well as an interoperability test plan, and a clear design.

If a spec is too complex to be implemented in software the problem may not
be the software.

"with Skype's software since it is an implementation by just one company.
Whatever we design in P2P SIP WG will have the same interoperability issue."

Which is why demonstratable code always wins.  I agree with you.

Skype's software is software.   Code always wins.

It's always easier to build a spec from code than code from a spec.

An internet-draft  should have code alongside to test the design.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060313/a6e5b9e2/attachment.html

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Mon, 13 Mar 2006 16:33:11 -0600

> We had a debate on this earlier and agreed to the sentence as it is

I'm thinking I agree with Sathya here. IETF-wise, we may have a  
difficult time chartering work that overlaps with MMUSIC's work.

--
Dean

---

From: jdrosen at cisco.com (Jonathan Rosenberg)
Date: Mon, 13 Mar 2006 17:41:33 -0500

So, we clearly still have some disconnects on the interpretation of the 
charter text here, since my read was the same as Sathya's. Let me suggest:

5. The group shall determine how to apply the existing SIP NAT traversal 
techniques (ICE/STUN/TURN for media and SIP-outbound for signaling) in a 
p2p environment. It is anticipated that this work will primarily involve 
discovery of STUN and TURN server resources in the p2p mesh. The 
resulting mechanism must be interoperable with non-p2p clients. If the 
group discovers that the existing techniques do not work, it shall 
develop requirements into the relevant working groups (MMUSIC, BEHAVE, 
SIP as needed) for changes needed to make them work.

-Jonathan R.

---

From: huang-ming.pan at comcast.net (Peter Pan)
Date: Mon, 13 Mar 2006 14:57:56 -0800

I forgot to ask another few stupid questions:

Q3: By "interop" does it mean "p2ply" or bridged?

Q4: Is it possible to "mesh" peers in a Chord overlay interop with peers in
a Kademlia?

Thanks.

Peter

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Mon, 13 Mar 2006 18:27:24 -0500

Michael Slavitch wrote:

> Interoperability becomes a non-issue if there is a reference design to 
> draw from,
> If a spec is too complex to be implemented in software the problem may 
> not be the software.
>
> Whatever we design in P2P SIP WG will have the same interoperability 
> issue. "
>
I appreciate your statement about the importance of running code.
"Rough consensus and running code" has been one of the most important 
operation principles of IETF in my understanding.
We will hear the speech about it by David Clark during the IETF social 
event in Dallas.
Actually I feel more urgency for running code of P2P SIP than as a 
matter of principle.
It is great that this group has many folks who are eager to implement 
the (future) P2P SIP spec and see running code.
I am one of them.
I hope we have active discussions about implementation while we work out 
all the details of the spec in parallel.
Thanks.

Eunsoo

---

From: dbarrett at quinthar.com (David Barrett)
Date: Mon, 13 Mar 2006 16:31:25 -0800

> SIP as needed) for changes needed to make them work.

Excellent clarification.  If that's what the group wants, then I agree with
this wording.

However, the first line of the original wording was "Select firewall/NAT
traversal technique(s) for P2P SIP" -- I presumed the word 'select' implied
there would be a selection of some kind from multiple options, with ICE
being one of them.  If this isn't the case, and if ICE is the forgone
conclusion, then let's use Jonathan's text above.

But NAT penetration is a "make or break" feature on which we shouldn't
compromise.  Assigning a "no-bid contract" to ICE without investigating the
alternatives seems extremely convenient, but hardly ideal.

If ICE is so clearly the right choice, what's the harm in proving it by
pitting against a field of challengers?

-david

---

From: fluffy at cisco.com (Cullen Jennings)
Date: Mon, 13 Mar 2006 21:52:20 -0800

On 3/13/06 2:33 PM, "Dean Willis" <dean.willis at softarmor.com> wrote:

> IETF-wise, we may have a

It's very good bet that you will have difficulties chartering works that
overlaps with any existing WG.

---

From: bryan at ethernot.org (David A. Bryan)
Date: Tue, 14 Mar 2006 09:58:28 -0500

I'll chime in late here...on planes all day yesterday.

I think there are several motivations for reusing existing stuff
unless we really, really believe it won't work. That was certainly how
I intended the wording to read when I first started hacking up an
attempt at the charter:

1) Interoperability. If regular SIP endpoints use method x to do
function y, we should try as hard as possible to do that. If not, we
have just created another island like Skype. Maybe it is an open
island, but if it can't talk to regular SIP devices properly or only
in very limited cases, it is still an island.

2) Time to finish. The more of the (extensive) work that has been done
on SIP extensions we can reuse, the more quickly we can develop a
version of SIP with distributed resource location, and perhaps later
other distributed aspects (voice mail or what have you). If we
redesign something for the sake of redesigning it, we delay that.

Now of course the above statements don't mean every SIP extension
designed with client-server in mind will prove to be perfect in a p2p
environment, but I really think the burden of proof should be on does
it not work. Otherwise, we are, as some people pointed out, looking at
a different communications system, not really SIP. I don't think it
is, but if that is what folks really want, our straw man charter
really needs a whole lot of rewording ;)

Just my 2 cents.

David Bryan

---

From: aki.niemi at nokia.com (Aki Niemi)
Date: Tue, 14 Mar 2006 17:30:02 +0200

ext Jonathan Rosenberg wrote:
> find ones amongst peers in the mesh. 

Exactly.

However, last time I looked, this was buried in the charter text as
something to work on "later". I think it should be first priority. In
fact, I'd hazard a guess that running media relays (and not the SIP
rendezvous) is the highest costing resource that most desperately needs
to be distributed in this system.

Cheers,
Aki

---

From: Markus.Isomaki at nokia.com ([email-masked])
Date: Wed, 15 Mar 2006 03:05:42 +0200

Hi,

I agree. IETF prefers narrow and focused charters, which is good
engineering, but often it means that some important components of the
overall solution fall through the cracks, and the real interoperable
deployments get delayed for a number of years. In this case I believe
that for P2P-SIP to be usable in practice, also the discovery and
allocation of STUN and TURN servers must belong to the default package.

ICE framework itself is very P2P oriented, so I think it should be
usable as such.

Markus

>From: p2p-sip-bounces at cs.columbia.edu 
>[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of ext Aki Niemi
>Sent: 14 March, 2006 17:30
>To: ext Jonathan Rosenberg
>Cc: P2P-SIP
>> If you want p2p-sip to 'just work', I suggest that time is better 
>> spent figuring out how to eliminate the need to configure 
>the servers 
>> that ICE depends on - turn and stun servers - and figure out how to 
>> dynamically find ones amongst peers in the mesh.
>
>Exactly.
>
>However, last time I looked, this was buried in the charter 
>text as something to work on "later". I think it should be 
>first priority. In fact, I'd hazard a guess that running media 
>relays (and not the SIP
>rendezvous) is the highest costing resource that most 
>desperately needs to be distributed in this system.
>
>Cheers,
>Aki