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

From: RADHIKA.R.ROY at saic.com (Roy, Radhika R.)
Date: Mon, 13 Mar 2006 20:45:45 -0500

Inline [RRR]

  _____  

From: p2p-sip-bounces at cs.columbia.edu on behalf of Eunsoo Shim
Sent: Mon 3/13/2006 6:10 PM
To: David Barrett
Cc: P2P-SIP
Subject: Re: [p2p-sip] Problem statement for P2P SIP NAT traversal

If we see major problems with things under the charters of other WGs and 
we need fix for the problems even though the problems are not specific 
to P2P (SIP), then we should join the appropriate WGs and work out 
solutions there. I would be happy to join such efforts. 

[RRR] A universal solution for FW/NAT traversal did NOT work in the past
(e.g., couple of WGs were formed with this expectation). Is not possible to
understand what p2p-SIP wants for FW/NAT traversal first? I guess that this
has been main focus for this discussion initially.

[RRR] Later on, I believe, ICE and others on-going works of FW/NAT traversal
by MMUSIC and other WGs were broght into discussions as a part of the
pointers for solutions even for p2p-SIP.

[RRR] If FW/NAT traversal becomes make or break for p2p-SIP, I guess, we
need to investigate further to have final decision as others (e.g., David)
also pointed out: ICE/STUN and alternatives to ICE/STUN .

Thanks. 

Eunsoo

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Mon, 13 Mar 2006 21:39:15 -0500

P2PSIP may be the wrong name for the WG.  I don't have a better one but it's
more P2P than it is pure SIP.

In fact what I keep on hearing is that changing SIP is verboten. So, let's
not do that any more than we have to.  If the complaint is "don't mess with
SIP", then "don't mess with SIP".   Message heard.  Live within what can be
construed as legitimate constraints.

Let me come up with yet another new buzzword/acronym. If you're not fond of
it I don't mind.

Peer To Peer Overlay With Address Overloading:  P2POAO

Advantages:

1.   Overlay is abstracted from application and protocol. SIP et al  sit on
top of OAO.
2.   Changes to SIP/SDP/RTP involve only AO  (recognizing overlay
addresses), which is
      nomenclature. One example of an overlay address could be a CERT-like
numeric string.
      In fact it is probably the best overlay address. Globally unique
identifiers with real
      certified identity.
3.   These changes do not alter state nor existing functionality of existing
standards.
4.   They are additions to, not changes to, existing protocols. Old still
works with new.
5.   Overlay NAT traversal is still needed, but need not be offer/answer.
6.   If offer/answer is needed ICE would be the IETF preference..
7.   If ICE can't support the overlay,  then request changes to ICE.
8.   If ICE can't or won't be changed to support the overlay, don't use
offer/answer.
9.   Offer/answer is not really needed if bootstrap can be seeded out of
band.
10. Once bootstrap is taken care of there is a wealth of choices.

For offer answer the answer that is insisted upon looks to be ICE.
But if it isn't offer-answer there are a wealth of things to draw upon,

The advantage is that there are a whole number of overlay schemes that would
work well in such an OAO environment. I do not know which one is best for
P2PSIP, but I have my personal preferences that I can argue later.  But that
preference is not religious, it just has to work. First we have to decide if
the overlay and SIP should be separate entities.

Given "don't change SIP"  there is no other way to go forward. There is no
other choice, so the choice is easy.

Now:

STUN-like things may still be needed, as a protocol that assists discovery.

TURN-like things (might as well be TURN-derived) could supply super node
services.
(In fact, they could be only self-organizing self-advertising
overlay-addressed versions of STUN and TURN)

ICE would still be used by SIP over P2POAO  if the overlay translates the
addresses transparently. This may well be the only requirement change for
ICE:

1.  to recognize overlay addressing as legitimate.
2.  to accept substitutions from the overlay, make it the canonical source
of real addresses.
3.  to move from 'overlay' addressing to 'real' and vice-versa using the
overlay as a reference.

That's about it.  Everything else in ICE would remain the same.  We may be
able to live with that.

Nothing apart from some basic housekeeping would change for MMUSIC, SIP,
SIPING amongst others. (an investigation would be needed to make sure this
is true).

The rest  of the work would belong in P2PSIP (or P2POAO or whatever it
really is).
Perhaps it's the "SIP" part of the name that causes kerfuffles, so if so,
name it something else.  Perhaps.

So, if the insistence is "don't change SIP"  and "for offer/answer NAT
traversal use ICE" the answer well may be:

1. Don't change SIP (apart from name support).
2. If ICE doesn't work for P2PSIP overlay offer/answer don't use
offer/answer in the overlay.
3. Given that offer/answer would bot be used by the overlay look for
alternatives and their traversal methods that are hence wise appropriate.
4. Allow non-ICE SIP UA systems to use the overlay as a tunnel in the place
of ICE.

I am not sure how this could step on toes. If ICE is an algorithm for
offer/answer protocols then not using ICE for protocols that are not based
on offer-answer should not be a problem.

If it still is, we're talking religion, not technology, and that means there
is no desire for a solution to the problem.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060313/af7881d2/attachment.html

---

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

One of the items that was brought at some of the previous ad-hoc meetings
was that general overlay network problem seemed to be a very wide scope. In
fact it felt more like a research problem to many people than an engineering
problem. Overlay networks for file sharing clearly have very different
requirements than the overlay networks that have been discussed here. Doing
a general overlay network that worked for many application sounds hard. I'm
not sure if you were suggesting a wider scope or not but probably anything
we can do to keep the scope small is a good way to start.

Cullen

On 3/13/06 6:39 PM, "Michael Slavitch" <slavitch at gmail.com> wrote:

> In fact what I keep on hearing is that changing SIP is verboten. So, let's not
> do that any more than we have to.  If the complaint is "don't mess with SIP",
> then "don't mess with SIP".   Message heard.  Live within what can be
> Let me come up with yet another new buzzword/acronym. If you're not fond of it
> I don't mind.
> 
> 2.   Changes to SIP/SDP/RTP involve only AO  (recognizing overlay addresses),
> which is 
> 9.   Offer/answer is not really needed if bootstrap can be seeded out of band.
> addresses transparently. This may well be the only requirement change for ICE:
> 
> 2.  to accept substitutions from the overlay, make it the canonical source of
> real addresses.
> SIPING amongst others. (an investigation would be needed to make sure this is
> true). 
> 
> The rest  of the work would belong in P2PSIP (or P2POAO or whatever it really
> is).
> Perhaps it's the "SIP" part of the name that causes kerfuffles, so if so, name
> it something else.  Perhaps.
> 
> 2. If ICE doesn't work for P2PSIP overlay offer/answer don't use offer/answer
> in the overlay.
> 4. Allow non-ICE SIP UA systems to use the overlay as a tunnel in the place of
> ICE.
> 
> offer/answer protocols then not using ICE for protocols that are not based on
> offer-answer should not be a problem.
> 
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060314/4bee848b/attachment.html