On 04-12 15:12, Adrian Georgescu wrote:
> I think there should be no "sigle" outbound proxy out there, if it is
> it becomes just another single point of failure. The ideal solution
> would provide a shared user-location database between multiple servers > which would all act as outbound-proxy for each call they serve and
> would enable NAT traversal only at the edges when and if necessary.

  I think this is exactly what Path is about, you can have different
  outbound proxy for each registered contact.

> A first step in this direction would be to store more information in
> the location table like the address of the server that handled the
> registration and both NAT ed and not NAT-ed contacts.

  You mean the destination IP of the REGISTER request so that some other
  server elected when the original server fails can select which IP to use
  to get the INVITE through the NAT, right ? That's on my todo list
  (with quite high priority).

  The other part -- NATed and non-NATed contact -- is already
  implemented. If you call fix_nated_register then the original Contact
  value would be preserved and the source IP and port of the request
  would be stored in the received column of location table (or can be
  appended to the message as ;received parameter of the Contact if the
  registrar is not co-located with the NAT-enabled proxy).

  The lookup function would put the original Contact into the
  Request-URI but the request would be forwarded to the IP and port in
  received parameter. For the scenario with decoupled outbound proxies
  and registrar (and also if Path is used) we would need to communicate
  the IP and port of the NAT to the outbound proxy instead -- Route
  header field could be used for this, for example.

    Jan.
 
> Based on this
> information depending on the call flow the SIP farm members should
> route the call to the member that serves the NAT-ed client and should
> expire only locations served locally.
>
> I am somewhere between Jan and Klaus opinions working on a similar
> concept, it will be nice to see some implementations available to
> compare them.
>
> Adrian
>
> On Dec 4, 2004, at 2:58 PM, Jan Janak wrote:
>
> >On 04-12 13:24, Klaus Darilion wrote:
> >>
> >>
> >>Jan Janak wrote:
> >>>I like 1) more than 2). Support for Path header field could be also
> >>>useful for other stuff then NAT traversal. We will definitely accept
> >>>that into the main tree if you implement it.
> >>
> >>Uuh, you're right - someone has to implement it! :-)
> >
> >  Yeah :-).
> >
> >>> And we could do something like:
> >>> if (save("location")) {
> >>> save_path();
> >>> copy_path_to_reply();
> >>> sl_send_reply("200", "OK");
> >>> };
> >>>
> >>> That would allow us to keep this logic separated from registrar.
> >>>- The path vector should be probably stored separately -- outside the
> >>>  location table and outside usrloc. In the script we could do
> >>>  something like:
> >>>
> >>>  lookup("location");
> >>>  lookup_path("path_table");
> >>>
> >>>  Function lookup_path would lookup the path vector and add it to the
> >>>  message as the pre-loaded route set.
> >>
> >>This would ensure to do not influence the registrar und location
> >>module,
> >>but I think implementation would be much more easier if we include it
> >>into the registrar module and enable it with a configuration parameter
> >>(usepath=0/1). Also from the database schema it makes sense to include
> >>it into the location table. There is a 1:1 relation between the path
> >>and
> >>the location (and the path value may be NULL).
> >
> >  I proposed separate table because, in my opinion, it is easier to
> >  implement. Moreover, if you keep it separately -- independent of
> >  usrloc, you can retrieve the path vector even if you do not use user
> >  location to get the next hop URI (PSTN gateways, static
> >configuration,
> >  path vector configured by users, and so on).
> >
> >>>- One problem here might be the limitation of SER to execute the
> >>>routing
> >>> logic only for one branch only. That means it would not be possible
> >>>to
> >>> lookup different path vector for different contacts. I think that
> >>>this
> >>> problem can be ignored at the beginning, SER would be simply limited
> >>> to using one path vector per AOR.
> >>
> >>That's a problem. In case for 3GPP this might be negligible (there is
> >>always only 1 handset registered). But for typical VoIP this won't
> >>work.
> >>E.g. I have to phones registered: one at home, one at work, and both
> >>are
> >>behind NAT and use an outbound proxy.
> >>
> >>This limitation can be bypassed by using solution 2 - as the "route"
> >>will be hidden in the contact uri. Furthermore, solution 2 would not
> >>requrie changes to the main proxy and therefore testing and rollout
> >>would be much easier.
> >>
> >>I also think solution 2 would be easier to implement, but still
> >>solution
> >>1 would be a more generic solution.
> >
> >  Yes, that's true. I think, however, that 1) is the right approach.
> >
> >    Jan.
> >
> >_______________________________________________
> >Serdev mailing list
> >Serdev at iptel.org
> >http://mail.iptel.org/mailman/listinfo/serdev