TCP SIP Asterisk 1.4
Hello,
Does anyone know of a TCP SIP patch for Asterisk 1.4?
There is an official patch for Asterisk 1.2
http://blog.brickaloch.com/index.php/2007/10/19/sip-tcp-support-i...
But what about the Asterisk 1.4 branch?
Cheers
Asterisk 1.4.8 Patch;
http://bugs.digium.com/view.php?id=10354
Asterisk 1.2 work;
http://bugs.digium.com/view.php?id=4903
Could these or better TCP SIP patches be added to Trixbox?
If anyone knows of any better patches, please let me know.
I plan on testing them and reporting my findings.
Thanks,
I think the plan is to integrate the SIP/TCP patch in the upcoming Trixbox 2.6.
At least I hope so, because this a must-have feature that is long overdue...
Kerry, what do you think?
And please, anyone, if you know of any patches please post here. I have looked quite hard for them but haven't come up with much.
http://bugs.digium.com/file_download.php?file_id=15111&type=bug
Please include this Asterisk 1.4.9 chan_sip.c patch.
Going to apply it this weekend to 1.4.17 and see how i get on :o)
It's only officially supported in 1.6 - the 1.6 beta has it.
Hey, yea i noticed it is not officially in 1.6 when i was reading the release notes for it.
However it is not going to be until this time next year before we see trixbox with Asterisk 1.6 ready rolled!
I just really want to get Exchange UM 2007 working directly without using a UDP to TCP conversion, and the main issue for me is i need TCP SIP to fix some bugs with counterpaths Bria client which we use.
Sorry that was meant to read "yea i noticed it is officially in 1.6"
Got TCP over SIP working in Asterisk 1.4.17 :o)
cd /usr/src
wget http://downloads.digium.com/pub/asterisk/releases/asterisk-1.4.17...
tar xvf asterisk-1.4.17.tar.gz
cd asterisk-1.4.17/channels
download the 1.4.8 patch from
http://bugs.digium.com/file_download.php?file_id=15111&type=bug&d...
and place in /usr/src/asterisk-1.4.
apply the patch;
patch < sip-20070808-1.4.9.tcp
I had one error; 'Hunk #24 FAILED at 17069.'
I fixed it by opening chan_sip.c.rej and chan_sip.c (which has all the other patches applied at this point), i then manuially implemented the changes and copied chan_sip.c back in place.
Change (Around lines 17258);
if ((sipsock > -1) && (memcmp(&old_bindaddr, &bindaddr, sizeof(struct sockaddr_in)))) {
close(sipsock);
sipsock = -1;
}
To;
if (memcmp(&old_bindaddr, &bindaddr, sizeof(struct sockaddr_in))) {
if (sipsock > -1) {
close(sipsock);
sipsock = -1;
}
if (siptcpsock > -1) {
close(siptcpsock);
siptcpsock = -1;
}
}
And delete the line "return -1;" under the section following the above code. (See chan_sip.c.rej)
Setup build environment on centos (Your trixbox install);
yum install gcc gcc-cpp gcc-c++
cd /usr/src/asterisk
./configure
make
amportal stop
make install
amportal start
Check that asterisk is listening on a tcp port :o)
netstat -l -p | grep asterisk
You should see;
[trixbox1.localdomain channels]# netstat -l -p | grep asterisk
tcp 0 0 *:sip *:* LISTEN 26503/asterisk
Next add the following two lines to sip.conf (or sip_custom.conf if you’re using freepbx);
tcpenable=yes
transport=tcp
sip reload
I tested using counterpath's Bria client wich allows you to explicitly choose to use TCP.
I believe unless you have the ability to force the client to use TCP, it will always default to UDP.
Could this please, please be added to trixbox 2.6?????????
Please dev guys?
This patch is the offical Asterisk patch (it can be seen on http://bugs.digium.com/view.php?id=4903 that this patch has gone into CVS, but will not be part of the asterisk HEAD for Asterisk 1.4).
Well, it is clear that we can't possibly wait for the Asterisk 1.6 final release, so whether by default or not, we should try to come up with a solution to enable this in the upcoming Trixbox.
I'm curious. Why do so many want SIP over TCP? TCP carries a significant overhead for retransmission that is not helpful in realtime voice channels. Are you hoping for interoperability with some other piece of software?
They want to integrate with Microsoft Unified Communications/Exchange 2007 which only operates over SIP/TCP.
That makes sense to integrate with the MS product. And it makes sense that MS chose poorly with their implementation. TCP is for retransmitting packets to guarantee delivery. While extremely useful for file transfers, it is counterproductive in the realm of realtime communications.
As an aside, Preston, I noticed we both registered on the site on the same day.
There are lots of us lurking who want TCP ONLY for Exchange 2007/UCS!!!!
So what's better? An experimental RPM build of 1.4 with the tcp patch knowing that this code will never be in asterisk or an RPM of 1.6? They both seem like they will be full of bugs but I think 1.6 is better because this will be a release at some point.
Comments?
In an ideal world, 1.6 would be better. However it would be significantly more buggy overall in all areas. Whereas with an optional patch chan_sip.so the bugs would be restricted to a limited area as oppose to the whole system being an unknown!
I looked at that sip_tcp patch and it makes major changes to sip.c. This is the core of Asterisk and could be responsible for all kinds of bugs. Also if this code worked well I think Digium would have committed it not rewritten it.
I hope to see trix 2.4 become truely "stable" (feels like it has "ghosts" still), then maybe put some thought and testing into this. If we dont find any bugs in this patch, maybe it can be a part of trixbox. But the fact that Digium didnt commit the patch is a bit troublesome as the fact that SIP/TCP in Exchange 2007 was known long before Asterisk 1.2 even- I would hate to waste time debugging something that they arent even comfortable with.
Looking forward to this possible Exchange integration, but looking more forward to a stable platform right now.
Are there a lot of really showstopping bugs in Asterisk 1.6?
If not, let's go that route.
After taking playing with this patch on a test system and after taking everyones thoughts and comments on board, i think i would prefer to have a stable system over anything else.
Then maybe once Asterisk 1.6 is out, it could be added to the beta or development repository.
That way the community could upgrade as desired and play with it, speeding the testing.
Asterisk 1.4.17 is fully stable yet? They just broke call parking for example. Asterisk 1.6 is probably 18-24 months away from being production quality. The SIP TCP Patch for Asterisk 1.4 is a total can of worms and unless it is comitted by Digium, we risk having massive problems across the board. If you want it now, compile Asterisk from source. We have enough issues getting current code to work right and putting in any code that is just a hack and isn't even considered to be beta code is totally irresponsible on our part.
Kerry - how do you really feel?
Here's a more constructive suggestion for those of us who want TCP support. The beta of 1.6 is out and has it. Those of you who want this functionality should start running/testing 1.6 and reporting anything you find. That way 1.6 stabilizes faster than 1.4 and we all reap the benefits.
Cheers!
Instead of staring at the worms, get rid of them.
Especially people like the Trixbox devs who know the ins and outs of Asterisk very well should help to get 1.6 stable ASAP.
It's not only about SIP/TCP, there are several features in Asterisk 1.6 that are badly needed for professional use and larger scale deployments.
We did a compile of Asterisk 1.6 to put into the beta repo but it seg faults as soon as it runs. As soon as we get it working it will be available but it is a LONG way away from being usable in production. Please read their blogs, this will be a long list of incremental beta releases, seeing Beta 2 does NOT mean it is close to a release candidate, each beta releases some incremental feature for testing but the entire feature suite is some time in the future. I can't imagine anyone running 1.6 for a business deployment for at least a year to 18 months when the majority of the requested features are actually in and working.
Even when I set transport=tcp on an outgoing trunk, the SIP Via Header always has Transport:UDP.
...
...
I just spent a couple of hours playing with the source. Apparently, you can't set transport in the Peer section of a trunk. I added code for it, and __sip_xmit would fail as follows:
DEBUG[19821] chan_sip.c: send_request, xmit[Feb 21 04:22:36] ERROR[19821] chan_sip.c: Connect Failed Sock: -1 192.168.2.4:5060 Bad file descriptor
Is there a way to configure an outbound trunk to use the TCP transport?
Lets not forget, Sip is the control protocol not a real time streaming transport. That happens to be RTP and I don't recall RTP being made TCP. Having a control protocol that is session based is not such a bad thing. Especially when working with presence at a myriad of different levels.
Actually, the Microsoft Speech Server uses TCP for SIP control messages.
I'm not a cpp programmer by trade; it's been years since I wrote in c.
Editing chan_sip.c
I've (lazily) added the following line around 16750 so trunks can be configured to use tcp transport.
} else if (!strcasecmp(v->name, "transport")) {
ast_log(LOG_DEBUG, "Setting transport=tcp for peer.\n");
ast_set_flag(&peer->flags[1], SIP_PAGE2_TCP);
I've worked up to the following code around line 1777, but the errno is returning 9 (looking for the setting in def in a socket.h file?). I'm guessing that calling connect and moving on is not acceptable, and we need to wait for the asynch result. I grabbed this code from the web. I just need this for a POC for the moment.
res = connect(p->sockfd, (const struct sockaddr *)dst, sizeof(struct sockaddr_in));
if (res < 0) {
if (errno == EINPROGRESS) { // fails, 9 is actually returned.
tv.tv_sec = 15;
tv.tv_usec = 0;
FD_ZERO(&myset);
FD_SET(p->sockfd, &myset);
if (select(p->sockfd, NULL, &myset, NULL, &tv) > 0) {
lon = sizeof(int);
getsockopt(p->sockfd, SOL_SOCKET, SO_ERROR, (void*)(&valopt), &lon);
if (valopt) {
ast_log(LOG_ERROR, "Connect Failed Sock: (valopt) %i %s:%d %s\n",p->sockfd,ast_inet_ntoa(dst->sin_addr), ntohs(dst->sin_port), strerror(errno));
}
}
else {
ast_log(LOG_ERROR, "Connect Failed Sock: (select<0) %i %s:%d %s\n",p->sockfd,ast_inet_ntoa(dst->sin_addr), ntohs(dst->sin_port), strerror(errno));
}
}
else {
ast_log(LOG_ERROR, "Connect Failed Sock: (%i not EINPROGRESS) %i %s:%d %s\n",errno, p->sockfd,ast_inet_ntoa(dst->sin_addr), ntohs(dst->sin_port), strerror(errno));
}
ast_set_flag(&p->flags[1], SIP_PAGE2_TCP_CONNECTED);
}
Any comment is appreciated.
I think I'll take the advice of the earlier comments to wait for newest version of Asterisk.
Even if I did get the "connect" working, I'd probably be chasing bugs elsewhere.
If you really need SIP-TCP right now, an alternative might be to use openser as a proxy, translating TCP to UDP
We use sipX as a proxy to translate between TCP and UDP, and it seems to work fine.

Member Since:
2007-01-21