[Asterisk-Users] SIP on TCP

[Adam Roach]

John Todd [jtodd at loligo.com] writes:

>    I don't know how to automatically determine TCP or UDP for 
> outbound connections without blocking or putting in some really
> nasty UDP failure detection modes.  Maybe this would best be
> configured to start with just "protocol=[tcp,udp]" as the only
> options, but I leave that to the patch writers, as they know far
> better than me how to make that work.

For SIP in general, you look at the "transport" parameter on
the request URI. If it isn't present, you use UDP; otherwise,
you use the transport indicated.

To do this properly in Asterisk, I would suggest using the same
basic mechanism. In other words, to route a call over UDP, you
would use:

  exten => _1NXXNXXXXXX,1,Dial(SIP/${EXTEN}@${GATEWAY})

Or something like this (syntax needs tweaking):

  exten => _1NXXNXXXXXX,1,Dial(SIP/${EXTEN}@${GATEWAY};transport=udp)

On the other hand, to route a call over TCP, you would use:

  exten => _1NXXNXXXXXX,1,Dial(SIP/${EXTEN}@${GATEWAY};transport=tcp)

You would want to have the ability to do similar things for
sip.conf. For example, you would want the following to be
valid:

  register => user at example.com;transport=udp/1000

Now, I know that ";" is how you start a comment in the Asterisk
configuration files, so you'll need to replace it with something
else. Comma and | would cause confusion with parameters passed
in to Dial()... perhaps "!" or "#"?

Finally, you would also want to add a transport parameter
to the user sections in sip.conf, like:

  [2000]
  type=friend
  host=dynamic
  context=international
  dtmfmode=rfc2833
  secret=123456
  transport=tcp

Unfortunately, I don't have the time to write this patch myself
at the moment. I'll note that it's a somewhat nontrivial task,
as you have to parse the headers as they arrive to find the
"Content-Length:" or "l:" header field, find the CR/LF/CR/LF sequence
that marks the end of the header, and then count bytes to the end
of the message. You can get this right for about 90% of the cases
with a quick hack, but getting it right per RFC 3261 is a royal
pain.

Then there's the whole issue of response routing using the
protocol indicated in the topmost "Via:" header field, and the
issue of routing subsequent requests in the same dialog using the
"Contact:" header field...

/a