[sr-dev] why new tcp connection?

Juha Heinanen jh at tutpro.com
Sun Nov 8 01:14:33 CET 2009


Iñaki Baz Castillo writes:

 > Ok, but for non natted TCP dialogs the usage of "alias" (supported by
 > SR) is a working (and really standarized) solution.

if i understood correctly there just a couple of drafts (no rfc) about
alias, and i don't see a point in having two mechanism for the same
thing: one for non-nated requests and another for nated and if ua is
using tcp or udp.

anyway, what i though is this:

- when request comes in, script always calls alias_contact() on it.
  alias_contact() checks if request has contact header and if not, does
  nothing.  if request has contact header, alias_contact() adds
  ;alias=ip:port param to contact uri containing received ip:port if
  contact ip:port does not match received ip:port.  otherwise it does
  nothing. 

- before any in-dialog request is t_relayed, script calls handle_alias()
  function that checks if r-uri has ;alias param and if so, removes it
  and sets $du.

this is very simple for the script writer.  the only thing that remains
to do in the script is to check if incoming invite request comes from
behind nat and if so, arm mediaproxy/rtpproxy.  of course, if you like,
you don't have to call alias_contact() on requests that use tcp and
don't come from behind nat, but call force_tcp_alias() instead.

any more comments before i start writing those two functions?

-- juha



More information about the sr-dev mailing list