Asterisk 1.6.2.20 : Listening port for TCP

Hello

I run AsteriskNOW 1.7

I use it both in UDP and also TCP protocol for iPhone compatibility (Acrobits SipPhone).

I have been trying to force Asterisk 1.6.2.20 to listen to another UDP-TCP port than 5060. I want it to listen to UDP-TCP/10060 only.

But whatever I do, Asterisk stubbornly listens to TCP/5060 although it is correctly listening to UDP/10060.

Can someone help me forcing it to listen to the TCP port that I want ?

This is the content of sip_general_additional.conf :

[code]faxdetect=yes
vmexten=*97
context=from-sip-external
callerid=Unknown
notifyringing=yes
notifyhold=yes
tos_sip=cs3
tos_audio=ef
tos_video=af41
alwaysauthreject=yes
useragent=FPBX-2.9.0(1.6.2.20)
disallow=all
allow=alaw
allow=ulaw
allow=g729
allow=gsm
allow=g723
tcpenable=yes
tcpbindport=10060
tcpbindaddr=0.0.0.0
language=af
callevents=no
bindport=10060
bindaddr=0.0.0.0
jbenable=no
defaultexpiry=1800
maxexpiry=3600
minexpiry=60
g726nonstandard=no
allowguest=no
srvlookup=no
registerattempts=0
registertimeout=20
rtpkeepalive=0
t38pt_udptl=no
videosupport=no
maxcallbitrate=384
canreinvite=no
rtptimeout=30
rtpholdtimeout=300
checkmwi=10
notifyhold=yes
notifyringing=yes
nat=yes

[/code]

Why do you need to use TCP? It’s support is not a core requirement of SIP and so few people use that it is not that surprising that it lacks features.

My guess is that you will need to modify the source code. If you don’t want to use multiple port numbers, that should not require any detailed understanding.

[quote=“david55”]Why do you need to use TCP? It’s support is not a core requirement of SIP and so few people use that it is not that surprising that it lacks features.

My guess is that you will need to modify the source code. If you don’t want to use multiple port numbers, that should not require any detailed understanding.[/quote]

The TCP protocol is required when you want to get all the features of a SIP phone like Acrobits on iPhone. The most important feature being incoming calls in background. The limitations of IOS4 require that TCP protocol be used for incoming calls notification.

In order to keep the connection on and fully responsive, the TCP protocol is indeed needed.

It works perfectly, the only problem being that I want to use anther port than TCP/5060 for avoiding hacking.

[quote=“david55”]

My guess is that you will need to modify the source code. If you don’t want to use multiple port numbers, that should not require any detailed understanding.[/quote]

Then why is there a provision for Asterisk instructions like hereunder, that seem ineffective ? :

tcpenable=yes tcpbindport=10060 tcpbindaddr=0.0.0.0

There are no such provisions in either the chan_sip.c or sip.conf.sample for 1.6.2.20.

For 1.8.7.0 the port is specified as part of the bind address and bindport is deprecated or removed.

You have got your sample configuration from an unreliable third party.

[quote=“david55”]There are no such provisions in either the chan_sip.c or sip.conf.sample for 1.6.2.20.

For 1.8.7.0 the port is specified as part of the bind address and bindport is deprecated or removed.

You have got your sample configuration from an unreliable third party.[/quote]

Thanks, so it means that, beside recompiling a version of Asterisk 1.6, there is no way I can force it to listen to a specific port for the TCP protocol, and thus only TCP/5060 is possible.

That is weird, considering that UDP can be changed.

Well, I solved the problem and the solution is quite simple :

tcpbindaddr=0.0.0.0:26060

For UDP, there are two instructions : bindaddr and bindport.

Not so for TCP !

What seems to have happened is that UDP supports both ways of specifying the port and TCP, as a new feature, only the new way. Looking at the CHANGES file, the ability to add the port number onto the bind address was added on the transition between 1.4 and 1.6. SIP over TCP was added on the same transition (although it is marked as experimental only in 1.6.1.0).

The documentation for 1.8 drops the option to specify the UDP port separately; I haven’t checked if this has been removed from the code.