Hi 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 accept SIP signalling on TCP. Thanks Master -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20030903/24443554/attachment.htm
Well that can be done but you'd have to change some UDP socket functions to TCP socket functions in channels/chan_sip.c regards Martin On Thu, 4 Sep 2003, Master Abi wrote:> Hi > > 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 accept SIP signalling on TCP. > > Thanks > > Master > >
>Hi > >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 accept SIP >signalling on TCP. > >Thanks > >MasterOut of curiosity, what SIP provider is that? I've never seen any SIP providers that even support SIP over TCP, much less mandate it. If that is required, maybe a "protocol=[tcp,udp,auto]" feature is a good idea in sip.conf. JT
On Wednesday 03 September 2003 09:32 am, Master Abi wrote:> Hi > > 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 accept SIP signalling on TCP. > > Thanks > > MasterThis suggestion is not exactly elegant, yet it may be of help: "The UDP over TCP tunnel is a simple UDP-over-TCP application written in Java, and is designed so that people behind a firewall can connect through a TCP connection to play Quake and other UDP-based games." It is available at: http://freshmeat.net/projects/udptunnel/?topic_id=907%2C150%2C151 -- Thanks, Timothy Soos XQL, LLC
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
John Todd [mailto:jtodd@loligo.com] writes:> 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 was talking about message framing. I'll rephrase in the form of a FAQ. Q: How do you know where the SDP (or any other body) ends? A: You have to find and parse the Content-Length header field, find the end of the headers, and count bytes. /a