[Serusers] Re: [Serdev] Splitting NAT traversal from proxy functionality

[Jan Janak]

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.

Some implementation hints:

- Function similar to record_route would be needed that would add Path
  header field

- Registrar would need all Path header fields into the 200 OK. I have
  been thinking about decoupling REGISTER processing and reply
  generation so that it would be possible to execute some routing logic
  between these two steps. So there would be something like:
  if (save("location")) {
	sl_send_reply("200", "OK");
  };

  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.

- 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.

- lookup_path would need to calculate the next hop according the the
  rules for record routing from RFC3261 -- that is already implemented
  in rr so we do not need to reinvent the wheel here.

- I would suggest to store all that in a separate module -- that (and
  the extension to registrar I have mentioned) would allow us to keep
  this extension cleanly separated.

  What do you think ?

    Jan.

On 02-12 11:16, Klaus Darilion wrote:
> Hi all!
> 
> This is a "request for comments" and I would be happy If you give me 
> your opinions. And maybe we could see some of the results in ser. :-)
> 
> When configuring ser (editing the ser.cfg), IMO a big problem is the 
> mixture of routing logic and NAT traversal. Every time I think about 
> routing policies (inbound, outbound, in-dialog, out-dialog ...) I always 
> have to take care about the NAT traversal. ser.cfg would be much easier 
> to handle if we do not have to take care about NAT traversal. Therefore, 
>  already several companies use dedicated NAT traversal devices which 
> will be configured as outbound proxy in the user agents (eg. Jasomi Peer 
> Point).
> 
> I want to use another ser instance as dedicated outbound proxy - that is 
> NAT traversal and nothing more (maybe some kind of protection using the 
> permissions and pike modules). AFAIK this is not possible with current 
> ser out-of-the-box. If this is wrong, please correct me and ignore the 
> rest of this email.
> 
> I came up with 2 solutions for this problem:
> 1. Using the "Path:" header as described in RFC3327
> 2. Enhance ser to rewrite the Contact: in the outbound proxy, store the 
> real contact, and forward to the main proxy.
> 
> Now, a bit more detailed for the follwing setup:
> UA1 -- OBProxy -- mainProxy -- ..... UA2
> 
> 
> 1.
> During registration, the OBP adds an "Path:" header with its SIP URI to 
> the REGISTER message. The mainProxy does not only save the AOR and the 
> Contact: URI, but also the Path: headers. If the main proxy "lookup()" 
> the contact of UA1, it also retrieves the stored Path and creates the 
> Route: headers. Therefore, the OBP stays always in the signaling path 
> for out-dialog transactions. To stay also in the signaling path for 
> in-dialog transaction, RecordRoute will be used (as usual).
> 
> Advantages: The OBProxy does not have to save()/lookup(), therefore no 
> kind of storage is required. Will be needed for 3GPP.
> 
> Disadv: The UA has to send keep-alive messages (CRLF) to keep the NAT 
> binding alive.
> 
> Todo: save() must also save the "Path", lookup() must retrieve the 
> "Path" and add it to the "Route". Adding the Path header can be done by 
> a new function or using "subst/append_hf".
> 
> 2.
> The outbound proxy receives a REGISTER with e.g.
> Contact: <sip:klaus at 10.0.0.4:5060>.
> First it uses fix_nated_contact: =>
> Contact: <sip:klaus at 1.2.3.4:4321>.
> Then it creates a new contact URI which uses the fixed contact as 
> username and the IP Address of the OBP as domain part, e.g:
> Contact: <sip:klaus%401.2.3.4%3A4321 at 5.6.7.8>
> Then, the outbound proxy saves in the location table the fixed contact 
> and the modified contact (instead of the AOR) and then it forwards the 
> modified REGISTER to the mainProxy.
> Now, the main proxy will store <sip:klaus%401.2.3.4%3A4321 at 5.6.7.8> as 
> contact for the AOR of UA1. Thus, if the main proxy makes a "lookup()", 
> it will forward the requests to the OBP. Then the OBP also makes a 
> lookup and retreives the fixed contact address.
> 
> Todo: create a new "save_obp" function which rewrites the contact and 
> stores the fixed and new contact (instead of fixed contact and AOR).
> 
> 
> What do you think about this? (I prefer Version 1)
> I think this will be a good enhancement to ser and should not be that 
> hard to implement.
> 
> regards,
> Klaus
> 
> _______________________________________________
> Serdev mailing list
> serdev at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serdev