[Asterisk-Users] SIP on TCP

[John Todd]

At 1:28 PM -0500 9/4/03, Adam Roach wrote:
>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

I should get some more sleep and remember my RFC's a bit more.  Of 
course, as you say, there is a protocol specified in the request 
which can be used to determine the correct response.  (What happens 
when the protocol in the request doesn't match the one actually used 
to deliver the request?  woo hoo!)  Could the patch simply look at 
the Via: header and grab the the last protocol?  Probably not.  Pesky 
RFC compliance...

Out of curiosity, why would you need to parse through the whole 
header to find that data?  Looks like it's right in the Via: header.

I am uncertain if the transport protocol should be able to be 
specified in the register or Dial portions of sip.conf and 
extensions.conf, respectively.  I am happier leaving that determined 
in the definition of the SIP peer, and not flexible on a per-call 
basis, just like most of the other features that are defined in 
sip.conf.  If you need per-call flexibility, use a different SIP peer 
that gets built with includes, if they are added to sip.conf (see my 
long comments from earlier today on revamping sip.conf)

JT