[Home]

Summary:ASTERISK-00216: [request] SIP signalling on TCP and UDP
Reporter:master (master)Labels:
Date Opened:2003-09-04 01:14:45Date Closed:2011-06-07 14:04:42
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/NewFeature
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I read through the archives but could not find much reference to * using SIP on TCP instead of UDP for signalling. Can * be configured and if so how. My service provider will only accepts SIP signalling on TCP.

Would be a good idea to include "protocol=[tcp,udp,auto]" in sip.conf.
Comments:By: John Todd (jtodd) 2003-09-04 02:46:31

My notes to this would simply be to reduce the set to "tcp,udp" and ditch the concept of automatic detection, which I think would be very difficult, especially on outbound connections.  Without some sort of timer routine on the UDP connections, an automatic detection on outbound connections won't work, plus the fact that the caller has to wait for X seconds for the UDP retransmissions timeout, which is probably unacceptable.  Simple might be better to start out with in this case.

I don't know if the TCP session that is opened is kept open for continuous commands on that particular SIP channel.  That would be complex and very difficult to know when to close, so I expect it's a new TCP session for each SIP command.  Yuck.

However, if this is _required_ by some SIP providers (and NTT is certainly not a minor SIP player, esp. in Asia) then I would suggest maybe that this is a very worthwhile feature to add to SIP overall.
By: otmar (otmar) 2003-09-04 04:56:31

One of the main points of TCP for SIP is the possibility to use TLS and thus strong authentication of SIP peers.

SER does AFAIK support TLS in the latest version,
By: John Todd (jtodd) 2003-09-05 00:40:34

More comments from the list: I suspect that inbound SIP requests should be replied to in the same format in which they were requested (UDP for UDP, TCP for TCP.)   If you really want to get fancy, see the comments below.  HOWEVER: I am a proponent of simply making outbound (new) requests with a staticly mapped protocol declaration in sip.conf, and replying to inbound requests in the format that they sent to us initially.



From: Adam Roach <adam@dynamicsoft.com>
To: "'asterisk-users@lists.digium.com'" <asterisk-users@lists.digium.com>
Subject: RE: [Asterisk-Users] SIP on TCP
Reply-To: asterisk-users@lists.digium.com
Date: Thu, 4 Sep 2003 13:28:48 -0500

John Todd [jtodd@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@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
_______________________
By: John Todd (jtodd) 2003-09-08 15:10:29

Otmar -
  Would you be interested in writing the patch suite to get TCP working with SIP on Asterisk?  I don't think we need TLS just yet; TCP would be a good start.  - JT
By: Olle Johansson (oej) 2003-09-17 14:57:08

I would suggest SIP/UDP as a default. SIP/TCP is, in my point of view, for SIPS/TLS and for very large payloads (i.e. File transfer in SIMPLE).
By: otmar (otmar) 2003-09-25 10:13:57

John,

I'm definitly interested in doing SIP/TCP, but in our setup here, we use SER as the main SIP server and Asterisk only for Voicemail and ENUM testing. Thus it's not likly that I can do that on company time, as there are a some more pressing issues demanding my time.

For my spare time, this project is too heavy. Sorry.
By: John Todd (jtodd) 2003-09-29 02:43:59

New product announced to the list, the Sipura SPA-2000  http://www.sipura.com/products/spa2000.htm  supposedly supports TLS and HTTPS/SSL encryption for SIP transport layers.
By: John Todd (jtodd) 2003-09-29 03:18:07

Closed out a slightly older request for TLS/TCP on SIP:  http://bugs.digium.com/bug_update_page.php?bug_id=0000186   since this ticket seemed to be getting some more activity.
By: John Todd (jtodd) 2004-01-31 17:51:23.000-0600

..but not enough activity.  It seems that the general consensus is that one should use a "real" SIP proxy to handle this type of RFC compliance, and that * should be a simple media gateway and application server.  That may not be everyone's opinion, but the lack of any patches or activity on TCP (or anyone willing to pay Digium to do it) certainly leads one in that direction...
By: Olle Johansson (oej) 2004-02-01 03:03:05.000-0600

John, I do not relate the TCP debate to being a SIP proxy or not. Asterisk needs to be RFC compliant and TCP and TLS support is necessary for that. TCP is also necessary to support SIP over 3G networks.

Also, Microsoft is heading the TCP/TLS way. Maybe we could find students that help us with an exam job? There's a lot of students out there looking for projects. Adding security - TLS and S/MIME - to IP-telephony seems like an interesting project.
By: cloos (cloos) 2004-02-01 13:11:21.000-0600

The only problem with getting a student to do * work as part of their studies is that -- at least in the US -- the schools often (usually?) retain copyright on anything done for credit.

The school admin would therefore need to sign Digium's disclaimer.....
By: Olle Johansson (oej) 2004-02-01 14:03:17.000-0600

Well, Cloos, there's a lot of countries outside the US... :-)
By: cloos (cloos) 2004-02-01 16:51:36.000-0600

Of course, but they are not the only schools I've seen reports of this about, just one example.

I'm sure I've seen similar issues discussed about schools in Europe a/o the UK; it is quite possibly the case anywhere employers own the rights to their employees' output (modulus contracts to the contrary).

(I'm just saying it is better to enter with one's eyes open than to be unexpectedly pissed on once thru the door. :)
By: twisted (twisted) 2004-06-16 23:10:30

So what's going on with this?  I'm going to close it if there is no real action in the next 24 hours.
By: cloos (cloos) 2004-06-17 12:49:52

|> I'm going to close it if there is no real action in the next 24 hours

As a general question, is there really any need to close feature requests?
They are not blocking anything.

Perhaps mantis needs another status for hibernating feature requests....
By: Brian West (bkw918) 2004-06-17 13:59:38

no people need to start writing it or sponsoring it... these feature requests linger around and get in the way of REAL BUGS.  Maybe someone needs to offer up a bounty on this?  They request it, we write it, they make boat loads of cash and never say one thank you...  Kinda pisses me off.  (Ya could atleast say THANKS)

bkw
By: twisted (twisted) 2004-07-08 09:14:51

closed due to lack of apparent intrest in this request.  If you would like to offer a bounty on this, please post it to the correct location in the wiki for Bounties.