SIP over TCP + convert to UDP to talk to SIP Phone

1
votes

I have linphone installed on my Ubuntu 12.04 box. A coworker would like to test out a Windows SIP phone that uses, he says, SIP over TCP rather than UDP.

IT occurs to me that I could create a 20 cent C++ program that has two threads, one for the UDP side, one for the TCP side, which simply receives one protocol and sends it to the other. Since the UDP portion would be only on the linux box, I doubt there be any issues with datagrams vs. streams, and SIP is not particularly 'streamy" anyway.

Would this work or is there some underlying protocol nastiness that I am unaware of. Is the SIP used over TCP the same SIP that normally travels by UDP? Is there a well known C++ solution for this?

I've looked around for possible solutions and socat is a possibility but it is GPL and this is intended for an embedded OCO project.

Any additional advice or suggestions would be quite welcome.

2
c++tcpudpsip
Can't socat do that for you? – Kerrek SB
You need to parse SIP. If a SIP message comes in on TCP, you need to know how long that message is. Which you can only learn by parsing SIP and considering the Content-Length header, at least for messages that have a body. For messages without a body, you can likely get away by looking for a pair of \r\n – nos
Yes, socat can do it GPL. My boss hates GPL. – Wes Miller

2 Answers

2
votes

Looks like linphone supports SIP over TCP (which is mandated by RFC 3261).

http://www.linphone.org/eng/features/

And yes, it's the same SIP messages over the wire.

2
votes

The answer to your original question is that no you wouldn't be able to just "pipe" the TCP SIP packets to your UDP socket. SIP does include the type of transport in a Via header which is used to determine the network path to transmit responses on. In addition to that for in-dialogue transmissions your SIP server would need to generate new SIP requests destined for the TCP client and it would need some setting or mechanism to get it to send those requests to your "pipe" which would then need to parse the SIP request to work out where the packet needs to be sent.

All in all it would be at best a very fragile solution and at worst a pretty broken one. It'd be much quicker and easier to find a SIP server/client that supports TCP as most of them do these days and in fact appears to be what you've gone ahead and done.