<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1250">
<META content="MSHTML 6.00.2900.2627" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial size=2><SPAN
class=921464523-18052005>Hello,</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=921464523-18052005></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=921464523-18052005>I was very
interested in the outbound proxy functionality discussed last december on the
serdev list:</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN class=921464523-18052005>has anyone seen any
implementations come out ?</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=921464523-18052005></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN class=921464523-18052005>Thanks in
advance,</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=921464523-18052005></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN
class=921464523-18052005>Giuseppe</SPAN></FONT></DIV>
<DIV><FONT face=Arial size=2><SPAN
class=921464523-18052005></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2><SPAN
class=921464523-18052005></SPAN></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV>On 04-12 15:12, Adrian Georgescu wrote:<BR>><I> I think there should be
no "sigle" outbound proxy out there, if it is <BR></I>><I> it becomes just
another single point of failure. The ideal solution <BR></I>><I> would
provide a shared user-location database between multiple servers </I>><I>
which would all act as outbound-proxy for each call they serve and
<BR></I>><I> would enable NAT traversal only at the edges when and if
necessary.<BR></I><BR> I think this is exactly what Path is about, you can
have different<BR> outbound proxy for each registered
contact.<BR><BR>><I> A first step in this direction would be to store more
information in <BR></I>><I> the location table like the address of the server
that handled the <BR></I>><I> registration and both NAT ed and not NAT-ed
contacts. <BR></I><BR> You mean the destination IP of the REGISTER request
so that some other<BR> server elected when the original server fails can
select which IP to use<BR> to get the INVITE through the NAT, right ?
That's on my todo list<BR> (with quite high priority).<BR><BR> The
other part -- NATed and non-NATed contact -- is already<BR> implemented.
If you call fix_nated_register then the original Contact<BR> value would
be preserved and the source IP and port of the request<BR> would be stored
in the received column of location table (or can be<BR> appended to the
message as ;received parameter of the Contact if the<BR> registrar is not
co-located with the NAT-enabled proxy).<BR><BR> The lookup function would
put the original Contact into the<BR> Request-URI but the request would be
forwarded to the IP and port in<BR> received parameter. For the scenario
with decoupled outbound proxies<BR> and registrar (and also if Path is
used) we would need to communicate<BR> the IP and port of the NAT to the
outbound proxy instead -- Route<BR> header field could be used for this,
for example.<BR><BR> Jan.<BR> <BR>><I> Based on this
<BR></I>><I> information depending on the call flow the SIP farm members
should <BR></I>><I> route the call to the member that serves the NAT-ed
client and should <BR></I>><I> expire only locations served
locally.<BR></I>><I> <BR></I>><I> I am somewhere between Jan and Klaus
opinions working on a similar <BR></I>><I> concept, it will be nice to see
some implementations available to <BR></I>><I> compare them.<BR></I>><I>
<BR></I>><I> Adrian<BR></I>><I> <BR></I>><I> On Dec 4, 2004, at 2:58
PM, Jan Janak wrote:<BR></I>><I> <BR></I>><I> >On 04-12 13:24, Klaus
Darilion wrote:<BR></I>><I> >><BR></I>><I> >><BR></I>><I>
>>Jan Janak wrote:<BR></I>><I> >>>I like 1) more than 2).
Support for Path header field could be also<BR></I>><I> >>>useful
for other stuff then NAT traversal. We will definitely accept<BR></I>><I>
>>>that into the main tree if you implement it.<BR></I>><I>
>><BR></I>><I> >>Uuh, you're right - someone has to implement it!
:-)<BR></I>><I> ><BR></I>><I> > Yeah :-).<BR></I>><I>
><BR></I>><I> >>> And we could do something like:<BR></I>><I>
>>> if (save("location")) {<BR></I>><I> >>>
save_path();<BR></I>><I> >>> copy_path_to_reply();<BR></I>><I>
>>> sl_send_reply("200", "OK");<BR></I>><I> >>>
};<BR></I>><I> >>><BR></I>><I> >>> That would allow us
to keep this logic separated from registrar.<BR></I>><I> >>>- The
path vector should be probably stored separately -- outside the<BR></I>><I>
>>> location table and outside usrloc. In the script we could
do<BR></I>><I> >>> something like:<BR></I>><I>
>>><BR></I>><I> >>>
lookup("location");<BR></I>><I> >>>
lookup_path("path_table");<BR></I>><I> >>><BR></I>><I>
>>> Function lookup_path would lookup the path vector and add it
to the<BR></I>><I> >>> message as the pre-loaded route
set.<BR></I>><I> >><BR></I>><I> >>This would ensure to do not
influence the registrar und location <BR></I>><I>
>>module,<BR></I>><I> >>but I think implementation would be much
more easier if we include it<BR></I>><I> >>into the registrar module
and enable it with a configuration parameter<BR></I>><I>
>>(usepath=0/1). Also from the database schema it makes sense to
include<BR></I>><I> >>it into the location table. There is a 1:1
relation between the path <BR></I>><I> >>and<BR></I>><I> >>the
location (and the path value may be NULL).<BR></I>><I> ><BR></I>><I>
> I proposed separate table because, in my opinion, it is easier
to<BR></I>><I> > implement. Moreover, if you keep it separately --
independent of<BR></I>><I> > usrloc, you can retrieve the path
vector even if you do not use user<BR></I>><I> > location to get the
next hop URI (PSTN gateways, static <BR></I>><I>
>configuration,<BR></I>><I> > path vector configured by users,
and so on).<BR></I>><I> ><BR></I>><I> >>>- One problem here
might be the limitation of SER to execute the <BR></I>><I>
>>>routing<BR></I>><I> >>> logic only for one branch only.
That means it would not be possible <BR></I>><I>
>>>to<BR></I>><I> >>> lookup different path vector for
different contacts. I think that <BR></I>><I> >>>this<BR></I>><I>
>>> problem can be ignored at the beginning, SER would be simply
limited<BR></I>><I> >>> to using one path vector per
AOR.<BR></I>><I> >><BR></I>><I> >>That's a problem. In case
for 3GPP this might be negligible (there is<BR></I>><I> >>always only 1
handset registered). But for typical VoIP this won't <BR></I>><I>
>>work.<BR></I>><I> >>E.g. I have to phones registered: one at
home, one at work, and both <BR></I>><I> >>are<BR></I>><I>
>>behind NAT and use an outbound proxy.<BR></I>><I>
>><BR></I>><I> >>This limitation can be bypassed by using
solution 2 - as the "route"<BR></I>><I> >>will be hidden in the contact
uri. Furthermore, solution 2 would not<BR></I>><I> >>requrie changes to
the main proxy and therefore testing and rollout<BR></I>><I> >>would be
much easier.<BR></I>><I> >><BR></I>><I> >>I also think
solution 2 would be easier to implement, but still <BR></I>><I>
>>solution<BR></I>><I> >>1 would be a more generic
solution.<BR></I>><I> ><BR></I>><I> > Yes, that's true. I
think, however, that 1) is the right approach.<BR></I>><I>
><BR></I>><I> > Jan.<BR></I>><I>
><BR></I>><I>
>_______________________________________________<BR></I>><I> >Serdev
mailing list<BR></I>><I> ><A
href="http://lists.iptel.org/mailman/listinfo/serdev">Serdev at
iptel.org</A><BR></I>><I> ><A
href="http://lists.iptel.org/mailman/listinfo/serdev">http://mail.iptel.org/mailman/listinfo/serdev</A><BR></I></DIV></BODY></HTML>
<BR>
<P><FONT SIZE=2>--<BR>
No virus found in this outgoing message.<BR>
Checked by AVG Anti-Virus.<BR>
Version: 7.0.308 / Virus Database: 266.11.10 - Release Date: 13/05/2005<BR>
</FONT> </P>