[Home]

Summary:ASTERISK-12417: [patch] multiple 'transport' on peer doesn't work, tcp port still open
Reporter:pj (pj)Labels:
Date Opened:2008-07-20 15:28:23Date Closed:2009-03-24 06:55:46
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 20080731__issue13117_multiple_transports.diff
( 1) cli.txt
( 2) sip_show_settings.diff
( 3) sipdebug.txt
Description:When I specify eg. 'transport=udp,tcp,tls' in peer configuration, in effect is only first transport type.
Currently, I can't specify multiple transport for peers.
Separate to more rows, doesn't solve this, ie:
transport=udp
transport=tcp
transport=tls
still only first is used.

Second issue is, that even if 'sip show settings' displays tcp port disabled (default), asterisk still have tcp/5060 open.

****** ADDITIONAL INFORMATION ******

Global Settings:
----------------
 UDP SIP Port:           5060
 UDP Bindaddress:        0.0.0.0
 TCP SIP Port:           Disabled
 TLS SIP Port:           5061
 TLS Bindaddress:        0.0.0.0


tcp        0      0 0.0.0.0:5060                0.0.0.0:*                   LISTEN
tcp        0      0 0.0.0.0:5061                0.0.0.0:*                   LISTEN
udp        0      0 0.0.0.0:5060                0.0.0.0:*
Comments:By: Brett Bryant (bbryant) 2008-07-20 18:28:16

pj, right now the first option is the only one used for outgoing calls. The other transports specified are just accepted for incoming calls to that peer.
By: pj (pj) 2008-07-21 01:37:19

Bret, thank you for answer, but I still think it not working as expected:
when I specify multiple transport (eg. udp,tls) I can register via all methods, but peer is immediatelly qualified as 'unreachable', when other than first transport type is actually used. Seems, that qualify still uses first transport and not what peer is actually using (see debug). So, currently I can't let my users to chose arbitrary transport, before this was added, it works this way.
Also 'sip show peer xxx' still displays only first transport.

And what about second issue? 'sip show settings' shows, that tcp is disabled, but in reality asterisk still listen on tcp/5060 port.


ipbx*CLI> sip show tcp
Host                           Port Transport   Type
193.85.164.154                 10317  TLS       Server



[Jul 21 08:39:09] Reliably Transmitting (NAT) to 193.85.164.154:10317:
OPTIONS sip:324@193.85.164.154:10317;transport=TLS;rinstance=c8365134974a3bde SIP/2.0
Via: SIP/2.0/UDP 193.179.38.20:5060;branch=z9hG4bK3c9b2c81;rport
Max-Forwards: 70
From: "asterisk" <sip:asterisk@193.179.38.20>;tag=as3feb5f46
To: <sip:324@193.85.164.154:10317;transport=TLS;rinstance=c8365134974a3bde>
Contact: <sip:asterisk@193.179.38.20>
Call-ID: 4787d8e6545f28746396778624923ecc@193.179.38.20
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX SVN-trunk-r132312
Date: Mon, 21 Jul 2008 06:39:09 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Content-Length: 0

By: Digium Subversion (svnbot) 2008-07-21 12:34:44

Repository: asterisk
Revision: 132468

U   trunk/channels/chan_sip.c

------------------------------------------------------------------------
r132468 | bbryant | 2008-07-21 12:34:40 -0500 (Mon, 21 Jul 2008) | 5 lines

Fix bug where ast_parse_arg would inadvertantly enable sip tcp when parsing a tcpbindaddr if it was disabled.

(closes issue ASTERISK-12417)
Reported by: pj

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=132468
By: Brett Bryant (bbryant) 2008-07-21 12:38:18

pj, I'll look into the probably with qualifying later today.
By: Brett Bryant (bbryant) 2008-07-21 15:03:51

pj, please try the patch i've just implemented. It should fix the behavior you were referrring to with transports.
By: pj (pj) 2008-07-21 15:25:57

svn trunk with this patch fails to compile...

  [CC] chan_sip.c -> chan_sip.o
chan_sip.c: In function ‘register_verify’:
chan_sip.c:10857: error: ‘sip_peer’ undeclared (first use in this function)
chan_sip.c:10857: error: (Each undeclared identifier is reported only once
chan_sip.c:10857: error: for each function it appears in.)
chan_sip.c:10858: error: expected ‘;’ before ‘if’
make[1]: *** [chan_sip.o] Error 1
make[1]: Leaving directory `/root/src/asterisk-r132505/channels'
By: Brett Bryant (bbryant) 2008-07-21 15:58:49

pj, sorry about that, I did some things out of order when making the patch.
By: pj (pj) 2008-07-22 15:03:34

now it compile and working fine, except in case, when I have sip presence in softphone turned on to monitor some extensions state. In that case, I'm not able even to make calls when using tls transport. When have presence on and with udp transport, I can make outgoing calls from softphone, but peer seems to be unregistered, so unreachable for accept calls :(
sip debug attached
By: pj (pj) 2008-07-22 15:53:26

also notice, that asterisk still listening on tcp/5060, even if 'sip show settings' shows  
TCP SIP Port:           Disabled

Asterisk SVN-trunk-r132470M
By: Brett Bryant (bbryant) 2008-07-23 02:40:40

pj, i've uploaded a seperate patch that fixes a bug in "sip show settings" that shows TCP as disabled when it wasn't. I'll combine the two and take a look at your sip debug tomorrow.
By: pj (pj) 2008-07-23 04:20:43

Bret, tcp still not working as written in sip.conf.sample, tcp/5060 should be disabled by default.
I haven't 'tcpenable' in my sip.conf, but asterisk still listening tcp/5060 and after your patch 'sip show settings' also shows:
 TCP SIP Port:           5060
 TCP Bindaddress:        0.0.0.0

from sip.conf.sample
tcpenable=no                    ; Enable server for incoming TCP connections (default is no)
;tlsenable=no                   ; Enable server for incoming TLS (secure) connections (default is no)
By: Brett Bryant (bbryant) 2008-07-23 10:47:44

pj, have you upgraded trunk to a revision > 132468? Here's the configuration I'm testing with on the latest trunk including the sip_show_settings patch:

[general]
context=default
allowoverlap=no
bindaddr=0.0.0.0
tcpenable=no
tcpbindaddr=0.0.0.0
tlsenable=yes
tlsbindaddr=0.0.0.0
tlscertfile=/etc/asterisk/asterisk.pem
tlsdontverifyserver=yes
srvlookup=yes


By: pj (pj) 2008-07-23 12:46:43

I'm using trunk r132823 with sip_show_settings.diff
seems, that problem is, when 'tcpenable=no' doesn't exist in sip.conf, asterisk then still listening on tcp/5060, but it should be disabled by default, as is writen in sip.conf.sample.
When I put 'tcpenable=no' into sip.conf, asterisk correctly disables tcp/5060
By: Brett Bryant (bbryant) 2008-07-23 15:32:55

pj, this issue has been fixed in trunk.
By: pj (pj) 2008-07-24 16:00:05

SVN-trunk-r133448
I can confirm, that asterisk now correctly disable tcp/5060 by default and also it correctly displays in 'sip show settings'

Still persist problems
- with client is qualified as 'unreachable', when have multiple transport defined in sip.conf
- not possible to call when using tls transport in combination with client subscribed to sip presence.

some asterisk lock, that happened during my tests...

=== Thread ID: -1215251568 (do_monitor           started at [19552] chan_sip.c restart_monitor())
=== ---> Lock #0 (chan_sip.c): MUTEX 19522 do_monitor &monlock 0xb79f1280 (1)
       asterisk(ast_bt_get_addresses+0x19) [0x80f2973]
       /usr/lib/asterisk/modules/chan_sip.so [0xb797b1d7]
       /usr/lib/asterisk/modules/chan_sip.so [0xb79cb6fc]
       asterisk [0x81670b2]
       /lib/i686/libpthread.so.0 [0xb7c77315]
       /lib/i686/libc.so.6(clone+0x5e) [0xb7d65dde]
By: Brett Bryant (bbryant) 2008-07-28 16:01:08

pj, please try the newest patch to see if it fixes your issue.
By: pj (pj) 2008-07-28 17:07:13

SVN-trunk-r134125M + 20080728__issue13117_multiple_transports.diff
- qualify unreachable issue seems to be gone
- sip/udp with presence seems to be OK
- sip/tls without presence OK
- sip/tls with presence still has some issue (can call asterisk localy, eg. echo test, but can't call other sip device through asterisk, it fails, phone more times unregisters/registers, sip presence stops working completely (all phone status is displayed as unknown) or softphone that tried to call is 'in use' until softphone restart), console log attached below...
also some weird debug messages, like this, starts appearing in asterisk log

[Jul 29 00:10:34] DEBUG[23434] chan_sip.c: peer '322' has contacted us over UDP even though we prefer UDP.
[Jul 29 00:10:41] DEBUG[23434] chan_sip.c: peer 'bill-gw' has contacted us over UDP even though we prefer UDP.


[Jul 29 00:07:39]     -- Called bill-gw/0222583463
[Jul 29 00:07:39]   == Extension Changed 324[linestates] new state InUse for Notify User 324
[Jul 29 00:07:41]     -- SIP/bill-gw-085481e8 is making progress passing it to SIP/324-0853af80
[Jul 29 00:07:46]     -- Registered SIP '324' at 193.85.164.154 port 11247 expires 400
[Jul 29 00:07:46] WARNING[23559]: chan_sip.c:10870 register_verify: peer '324' HAS STOPPED USING TLS in favor of 'TLS' (but this was allowed in sip.conf)!
[Jul 29 00:07:46]   == Extension Changed 324[linestates] new state Idle for Notify User 324 (queued)
[Jul 29 00:07:46]     -- Unregistered SIP '324'
[Jul 29 00:07:46] WARNING[23559]: chan_sip.c:10870 register_verify: peer '324' HAS STOPPED USING TLS in favor of 'TLS' (but this was allowed in sip.conf)!
[Jul 29 00:07:47]     -- Registered SIP '324' at 193.85.164.154 port 11247 expires 400
[Jul 29 00:07:47]        > Saved useragent "eyeBeam release 1100z stamp 47739" for peer 324
[Jul 29 00:07:47] WARNING[23559]: chan_sip.c:10870 register_verify: peer '324' HAS STOPPED USING TLS in favor of 'TLS' (but this was allowed in sip.conf)!
[Jul 29 00:07:47] NOTICE[23559]: chan_sip.c:15716 handle_response_peerpoke: Peer '324' is now Reachable. (260ms / 4000ms)
[Jul 29 00:07:47]   == Spawn extension (zamestnanci, 222583463, 4) exited non-zero on 'SIP/324-0853af80'
[Jul 29 00:07:47]     -- Executing [h@zamestnanci:1] GotoIf("SIP/324-0853af80", "1?2:3") in new stack
[Jul 29 00:07:47]     -- Goto (zamestnanci,h,2)
[Jul 29 00:07:47]     -- Executing [h@zamestnanci:2] NoOp("SIP/324-0853af80", "call_stats ") in new stack
[Jul 29 00:07:47]     -- Executing [h@zamestnanci:3] NoOp("SIP/324-0853af80", "Finish if-zamestnanci-38") in new stack
[Jul 29 00:07:47]     -- Executing [h@zamestnanci:4] Hangup("SIP/324-0853af80", "") in new stack
[Jul 29 00:07:47]   == Spawn extension (zamestnanci, h, 4) exited non-zero on 'SIP/324-0853af80'
[Jul 29 00:07:48]     -- Registered SIP '324' at 193.85.164.154 port 11248 expires 400
[Jul 29 00:07:48] WARNING[23560]: chan_sip.c:10870 register_verify: peer '324' HAS STOPPED USING TLS in favor of 'TLS' (but this was allowed in sip.conf)!
[Jul 29 00:07:48]     -- Unregistered SIP '324'
[Jul 29 00:07:48] WARNING[23560]: chan_sip.c:10870 register_verify: peer '324' HAS STOPPED USING TLS in favor of 'TLS' (but this was allowed in sip.conf)!
[Jul 29 00:07:48]     -- Registered SIP '324' at 193.85.164.154 port 11248 expires 400
[Jul 29 00:07:48]        > Saved useragent "eyeBeam release 1100z stamp 47739" for peer 324
[Jul 29 00:07:48] WARNING[23560]: chan_sip.c:10870 register_verify: peer '324' HAS STOPPED USING TLS in favor of 'TLS' (but this was allowed in sip.conf)!
[Jul 29 00:07:49] NOTICE[23560]: chan_sip.c:15716 handle_response_peerpoke: Peer '324' is now Reachable. (225ms / 4000ms)
[Jul 29 00:07:49]   == Extension Changed 324[linestates] new state Idle for Notify User 324
By: pj (pj) 2008-07-28 17:15:49

also notice, that many RTP ports remain open, even if 'core show channels' and 'sip show channels' are empty
'core show locks' empty
By: Brett Bryant (bbryant) 2008-08-01 13:17:10

I've uploaded a patch that fixes the wierd log messages, but I haven't been able to look at the sip tls prescence and unfortunately because my summer internship is over for now I won't be the one looking at this bug in the future.

The prescence issue with tls might causes rtp ports to remain open might be related to ASTERISK-11599 . You might want to try the patch there to see if the rtp ports are closed.
By: pj (pj) 2008-08-02 04:20:13

I'm afraid, that 'transport' doesn't work as expected...
I have only one transport permited (transport=udp) in sip.conf peer definition, but I'm still able to successfully register and even make calls using tls. Only some warnings are printed on cli, during peer registration, but after some attempts, peer is registered. Same behaviour, when I have in asterisk transport=tls only, peer can be successfully registered via UDP.
cli.txt attached.
By: Leif Madsen (lmadsen) 2008-11-20 09:17:41.000-0600

Ping(status)?

I'm dropping this down to Confirmed status as it appears there is an issue here, but the attached patch(es) to resolve the issue seem to have no effect.
By: pj (pj) 2009-03-24 02:59:43

because long time of no activity here, I think we can close this bugreport (some issues reported here, like "sip tcp port still listening" was resolved)
I created new bugreport ASTERISK-1456727 related to crashes and multiple transport use, so solving "multiple transport" issue can continue here. thanks
By: Leif Madsen (lmadsen) 2009-03-24 06:55:45

Closed at the request of the reporter. Continuation at issue ASTERISK-13806.