Subject: RE: [midcom] pre-midcom work item

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 1 Oct 2001 17:39:39 -0400

Folks,

I've just submitted an I-D to the archives, co-authored with Christian
Huitema and Rohan Mahy, on what this protocol might look like. Until it
appears in the archives, you can pick it up from:

http://www.jdrosen.net/papers/draft-rosenberg-midcom-stun-00.txt

Its just a step above "echo", but it can determine the presence of nats,
diagnose the type, and help determine binding lifetimes. This protocol will
suffice to help a SIP enabled voip phone get through a fairly large fraction
of nats (full cone and restricted cone, which is about 80-90% of nats
depending on who you ask) while still maintaining direct, end-to-end voice
transport. The protocol is totally independent of sip; a separate draft (in
sipping) is pending on how to use the stun protocol in a sip client. 

Comments/questions/flames welcome as always. Hopefully this will help
clarify the kind of things the new charter item is aiming at.

Thanks,
Jonathan R.

> -----Original Message-----
> From: Abdallah Rayhan [mailto:[email-masked]]
> Sent: Monday, September 24, 2001 2:21 PM
> To: Jonathan Rosenberg; Melinda Shore; [email-masked]
> Subject: RE: [midcom] pre-midcom work item
> 
> 
> --- Jonathan Rosenberg <[email-masked]> wrote:
> 
> > > Secondly, this introduces
> > > new architectural constraints that is going to screw
> > > the consensus achieved so far on the architecture draft.
> > 
> > How is that?
> 
> Before amending the charter we at least need to know
> what and how this would work. Instead we got a charter
> change dictated on us before learning how this 
> SIP-happy-NAT is going to influence the current architecture,
> or being discussed and scrutinized by the WG.
> 
> <snip>
> > > 
> > > The deployment argument of IKE/IPSec, IP6, MPLS didnt stop 
> > > the WGs from developing those standards. Why should we be
> > > the exception?
> > 
> > No one is saying that it should not be deployed. Full steam 
> ahead. We
> > need
> > midcom, and that hasn't changed. The fact is that midcom can't fully
> > solve
> > our problems.
> > 
> > Its also worth noting that there are already solutions 
> being deployed
> > today
> > that play the role of the proposed addition. Those are all
> > proprietary and
> > not interoperable. Let us not let that continue.
> 
> What will happen is another beast will be added to the gang.
> 
> _______________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.ca address at http://mail.yahoo.ca
> 

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
midcom mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/midcom

---

From: "Mark Pietras" <[email-masked]>
Date: Thu, 4 Oct 2001 10:20:19 -0500

Jonathan,

More of a question about the _solution_ than the particulars of STUN:

Have you found a solution to the problem of "misguided" media?  That is,
when two clients are behind the same NAT and there's no call-control/routing
element with them in that same "realm?!", both will be forced to assume that
the other is on the "outside" the NAT.  Both the signaling and the media
will be sent "outside" just to be routed right back.  Signaling might not be
a big deal, but media might be (from a latency or more interestingly a
NAT-loading perspective).

Mark P.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Jonathan Rosenberg
Sent: Monday, October 01, 2001 4:40 PM
To: 'Abdallah Rayhan'; Jonathan Rosenberg; Melinda Shore;
[email-masked]
Subject: RE: [midcom] pre-midcom work item

Folks,

Thanks,
Jonathan R.

---