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 >

would enable NAT traversal only at the edges when and if necessary.

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.

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 >HYPERLINK "http://lists.iptel.org/mailman/listinfo/serdev"Serdev at

>HYPERLINK