<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
On 07/08/2011 07:45 PM, José Pablo Méndez Soto wrote:
<blockquote
cite="mid:CANUEeQ1P7tXLQSHAVKM5sgh78X1it+1BQWCCbVhtSXNDcB0+FQ@mail.gmail.com"
type="cite">Thanks a lot Bogdan.<br>
<br>
I follow the use of rPort all the way explained here. What I don't
understand, is, if the received and rport parameters are filled in
by the UAS that gets the request, how is that useful to the UAC
that originated it when the reply is routed back to it? What
situations may happen so that the UAC needs this info?<br>
</blockquote>
The proxy adding the rport + received is doing that for itself - it
is populating that info in request (when received) so that the proxy
will know at reply time where to send it back.<br>
<br>
Regards,<br>
Bogdan<br>
<br>
<blockquote
cite="mid:CANUEeQ1P7tXLQSHAVKM5sgh78X1it+1BQWCCbVhtSXNDcB0+FQ@mail.gmail.com"
type="cite">
<br>
NAT of course, but what would cause the SIP UAC not to process the
reply packet correctly? Is it the info contained at layer 5? or
the socket disruption at layer 3?<br>
<br clear="all">
<b style="color: rgb(153, 153, 153);"><span style="color:
rgb(153, 153, 153);"><font size="2"><font size="2"><span
style="font-family: verdana,sans-serif;"><span
style="font-family: trebuchet ms,sans-serif;"><span
style="font-family: verdana,sans-serif;">José Pablo
Méndez</span></span></span></font><br>
</font></span></b><b style="color: rgb(153, 153, 153);"><span
style="color: rgb(153, 153, 153);"></span></b><b style="color:
rgb(153, 153, 153);"><span style="color: rgb(153, 153, 153);"></span></b><b
style="color: rgb(153, 153, 153);"><span style="color: rgb(153,
153, 153);"></span></b><b style="color: rgb(153, 153, 153);"><span
style="color: rgb(153, 153, 153);"></span></b><br>
<br>
<br>
<div class="gmail_quote">2011/7/8 Bogdan-Andrei Iancu <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:bogdan@opensips.org">bogdan@opensips.org</a>></span><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
Hi José,<br>
<br>
'rport' VIA param is to be used in NAT situations. As the VIA
hdr is used for routing back the replies, if the caller is
behind nat (and its VIA with a private IP), the routing back
of the reply to it will not be possible.<br>
<br>
The way rport works it is very simple - this param (together
with "received") are added to the top most VIA hdr if this VIA
indicates a different IP:port than the src ip:port on net
level. The received and rport are added to contain the layer 3
IP and port (which can be used later for routing back the
reply).<br>
<br>
Regards,<br>
Bogdan
<div>
<div class="h5"><br>
<br>
On 07/06/2011 01:55 AM, José Pablo Méndez Soto wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
Hello,<br>
<br>
Can anybody explain how the rPort works in conjunction
with STUN?<br>
<br>
I have gone through the RFCs but can't make sense out of
a packet capture I have over here. If possible, I would
like someone to explain how the layer 3 and 5 IP
addresses will flow and be re-writed when SIP works
behind a NAT (Just one side behind NAT and the other
publicly available lets say).<br>
<br>
Thanks in advance,<br>
</blockquote>
<br>
</div>
</div>
<font color="#888888">
-- <br>
Bogdan-Andrei Iancu<br>
OpenSIPS eBootcamp - 2nd of May 2011<br>
OpenSIPS solutions and "know-how"<br>
<br>
</font></blockquote>
</div>
<br>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
Bogdan-Andrei Iancu
OpenSIPS eBootcamp - 2nd of May 2011
OpenSIPS solutions and "know-how"</pre>
</body>
</html>