[Serusers] Theory behind a media proxy and NATed UA

[Nils Ohlmeier]

Felipe,

after the UA, which send the INVITE, received the 200 OK for the INIVTE it has 
to start sending RTP.

  Nils

On Tuesday 04 October 2005 16:50, Felipe Louback wrote:
> My Nated UA does work fine. I use X-lite. Now I am trying to
> understand why it works. It has everything not to work.... I mean,
> after the Nated client send an INVITE, the proxy replaces the unvalid
> IP of the SDP field and puts its valid IP, so it can be in the middle
> of the conversation. But through what I studied in SIP, after a client
> send an INVITE, it expects audio to get audio(that is why it sends the
> port and ip in the SDP body). Since it is expecting to get audio, how
> does the media proxy talks to it, since there isn't any port opened in
> the NAT device?
>
> The problem with NAT is that the called part cannot open an audio
> channel with the Nated callee because in the SDP body, there is an
> invalid IP. In theory, it seems that a media proxy has the same
> problem the called has to open an audio channel..... I just couldn't
> figure out this...
>
> Thanks,
>
> Felipe
>
> On 10/4/05, Greger V. Teigre <greger at teigre.com> wrote:
> > Mediaproxy cannot force the nated ua to send rtp (unless it supports
> > active media, which most don't, AFAIK).
> > Some UAs (ex. Grandstream old firmware) has an issue where it takes a
> > couple of seconds before you get sound.  However, not getting anything
> > means that the UA does not have anything to send and that silence
> > suppression is probably turned on. If you speak using the nated UA, does
> > it start sending rtp?
> > g-)
> >
> > ----- Original Message -----
> > From: "Felipe Louback" <louback at gmail.com>
> > To: "Greger V. Teigre" <greger at teigre.com>
> > Cc: <serusers at lists.iptel.org>
> > Sent: Tuesday, October 04, 2005 04:17 PM
> > Subject: Re: [Serusers] Theory behind a media proxy and NATed UA
> >
> > > Andy told that after the first UDP packet is received on the
> > > mediaproxy socket it knows
> > > where to send the packets to. That is the problem.... after the
> > > invite, the NAT-ed UA will wait for traffic, and not send traffic.
> > > Greger, I read Section 3.5 of the document you said, but they dont
> > > explain my doubt. There you can find how the register process is done
> > > and how the NAT problem can be solved. In the document it is said the
> > > proxy put his address in the SDP payload, but how does the media proxy
> > > force the NATed UA to send a UDP packet? By default, the UA is waiting
> > > for audio after it sends an INVITE....
> > >
> > > Felipe
> > >
> > > On 10/4/05, Greger V. Teigre <greger at teigre.com> wrote:
> > >> Section 3.5 of the ONsip.org Getting Started document provides an
> > >> intro from
> > >> a SIP/SER point of view.  Tell me if you miss something :-)
> > >> g-)
> > >>
> > >> ----- Original Message -----
> > >> From: "Felipe Louback" <louback at gmail.com>
> > >> To: <serusers at lists.iptel.org>
> > >> Sent: Monday, October 03, 2005 07:27 PM
> > >> Subject: [Serusers] Theory behind a media proxy and NATed UA
> > >>
> > >> > The problem with NAT is because the IP address of the SDP body is a
> > >> > non routeable IP. So how does a media proxy works?
> > >> >
> > >> > I read that a media proxy put his address at the sdp body and both
> > >> > UA talks with the media proxy instead of each other. At the time a
> > >> > NAT user sends an INVITE, there is no corresponding port on the NAT.
> > >> > So How does a media proxy contact the NATed UA?
> > >> > Isn't this the same problem the called part will have to contact the
> > >> > NATed party?
> > >> >
> > >> > I read a couple of papers about it, but in all of them it is said
> > >> > that both ends talk to the media proxy and that is all. No
> > >> > explanation about how things work. I know it works because I am
> > >> > using mediaproxy.
> > >> >
> > >> > If anyone could point me how this works or where I can find a
> > >> > document explaining....
> > >> >
> > >> > Thanks,
> > >> >
> > >> > Felipe
> > >> >
> > >> > --
> > >> > Master Student - Electrical Engineering Department
> > >> > Computer Engineering and Telecommunications Research Group
> > >> > Universidade Federal de Minas Gerais - Brazil
> > >> >
> > >> > "For God so loved the world that he gave his one and only Son, that
> > >> > whoever believes in him shall not perish but have eternal life."
> > >> > John 3:16
> > >> >
> > >> > _______________________________________________
> > >> > Serusers mailing list
> > >> > serusers at lists.iptel.org
> > >> > http://lists.iptel.org/mailman/listinfo/serusers
> > >
> > > --
> > > Master Student - Electrical Engineering Department
> > > Computer Engineering and Telecommunications Research Group
> > > Universidade Federal de Minas Gerais - Brazil
> > >
> > > "For God so loved the world that he gave his one and only Son, that
> > > whoever believes in him shall not perish but have eternal life."
> > > John 3:16
>
> --
> Master Student - Electrical Engineering Department
> Computer Engineering and Telecommunications Research Group
> Universidade Federal de Minas Gerais - Brazil
>
> "For God so loved the world that he gave his one and only Son, that
> whoever believes in him shall not perish but have eternal life."
> John 3:16
>
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers