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

From: "Sanjoy Sen" <[email-masked]>
Date: Mon, 8 Oct 2001 09:47:41 -0500

Mark, Sorry for jumping in late! But a solution for this is described in our
recently submitted draft at
http://www.ietf.org/internet-drafts/draft-sen-midcom-fw-nat-00.txt.
Basically, if you use an RTP proxy like device under the control of a SIP
Proxy, then the SIP Proxy can decide whether or not to force the media to go
to the RTP Proxy (i.e., in case of 2 UA's behind the same NAT, the SDP is
not changed by the SIP Proxy & the media can bypass the RTP Proxy). Please
let me know your comments/feedback.

Thanks,
Sanjoy

> -----Original Message-----
> From: Mark Pietras [mailto:[email-masked]]
> Sent: Thursday, October 04, 2001 10:20 AM
> To: Jonathan Rosenberg; midcom
> Subject: RE: [midcom] pre-midcom work item
> 
> 
> 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,
> 
> 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
> 
> 
> _______________________________________________
> midcom mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/midcom
>

---

From: "Mark Pietras" <[email-masked]>
Date: Mon, 8 Oct 2001 11:57:40 -0500

RE: [midcom] pre-midcom work itemSanjoy, jump in any time.

My question was specifically about an environment (like an enterprise) with
_no_ call control element (e.g. SIP Proxy) in the same realm.  This is the
PSTN equivalent of a Centrex environment.  If there _is_ a call control
element in the same realm, this more closely mimics a PBX environment.

Your proposal clearly has additional call control, as well as media control
in the solution, so it's really a different environment and a different
question.

As a side note, the media routing problem I pointed out in the IP-packet
world is the same as what you find in the PSTN world today.  That is, in a
Centrex configuration, TDM traffic goes to the first TDM switch in the
service provider network before getting routed back.  Of course, there's no
where near the latency (and other QoS issues) involved so it's not a big
issue...  To keep TDM traffic on site, one would put a PBX (a local TDM
switch) on prem... equivalent to putting a call control element (SIP Proxy)
on prem.  Ideally, we (us packet voice folks) could solve this media routing
problem rather than mimicking some of the same problems.  More intelligence
in call control and client, like Jonathan suggests, is an option...

Mark.
  -----Original Message-----
  From: Sanjoy Sen [mailto:[email-masked]]
  Sent: Monday, October 08, 2001 9:48 AM
  To: 'Mark Pietras'; Jonathan Rosenberg; midcom
  Subject: RE: [midcom] pre-midcom work item

  Mark, Sorry for jumping in late! But a solution for this is described in
our recently submitted draft at
http://www.ietf.org/internet-drafts/draft-sen-midcom-fw-nat-00.txt.
Basically, if you use an RTP proxy like device under the control of a SIP
Proxy, then the SIP Proxy can decide whether or not to force the media to go
to the RTP Proxy (i.e., in case of 2 UA's behind the same NAT, the SDP is
not changed by the SIP Proxy & the media can bypass the RTP Proxy). Please
let me know your comments/feedback.

  Thanks,
  Sanjoy