[Home]

Summary:ASTERISK-18837: empty Sender-Adress if use TCP-Protocoll for SIP-Messages
Reporter:Andreas Topp (a.topp@computersmore.de)Labels:
Date Opened:2011-11-08 05:45:13.000-0600Date Closed:2011-12-06 13:47:16.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/TCP-TLS
Versions:1.8.8.0 Frequency of
Occurrence
Constant
Related
Issues:
Environment:CentOSAttachments:( 0) Atrerisk188-TCPnok-UDPok.pcap
Description:The SIP-Packages does not contain the  
Sender-IP-Adress in the Via-Header if you use TCP as SIP-protocol. This does  
not occur if i use UDP.

Best Regards and thank you very much for this awesome software!
Andreas Topp
Comments:By: Walter Doekes (wdoekes) 2011-11-09 13:38:17.002-0600

Are you talking about the received= parameter (response), or the sent_by part of the Via header (request)?

Could you provide a SIP trace to point out the problem exactly.

By: Andreas Topp (a.topp@computersmore.de) 2011-11-11 05:22:05.286-0600

i attached a trace for you! Hope this can help!

By: Walter Doekes (wdoekes) 2011-11-11 07:37:37.212-0600

Confirmed indeed.
{noformat}
[test2]
type=peer
host=127.0.0.1
port=1234
qualify=yes
transport=tcp
{noformat}

Yields:
{noformat}
$ nc -l 1234
OPTIONS sip:127.0.0.1 SIP/2.0
Via: SIP/2.0/TCP (null);branch=z9hG4bK7d3028cd
Max-Forwards: 70
From: "asterisk" <sip:asterisk@(null):0>;tag=as6faeed9f
To: <sip:127.0.0.1>
Contact: <sip:asterisk@(null);transport=TCP>
Call-ID: 6065a10026ab71b83b19fd687711c159@(null)
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX SVN-branch-1.8-r343936M
Date: Fri, 11 Nov 2011 13:35:16 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0
{noformat}



By: Walter Doekes (wdoekes) 2011-11-12 02:04:34.548-0600

Ok. It seems it's caused by tcpenable=no (the default). I'm pretty sure that we should disallow transport=tcp when tcpenable=no. I don't think you should expect working TCP signaling with only outbound TCP. And, I think the RFC is pretty explicit that you should always have TCP listening on the same port as UDP.

My assessment is that this is:
(a) A configuration error: you should enable tcpenable=yes.
(b) A bug in parsing the configuration: tcp should be disallowed from peers if tcpenable=no (a warning is probably nice to have)

By: Walter Doekes (wdoekes) 2011-11-13 07:39:43.201-0600

I added a patch on the review board ( https://reviewboard.asterisk.org/r/1585 ) that should warn you when you have tcpenable=no and try to use tcp transport.

By: Andreas Topp (a.topp@computersmore.de) 2011-11-14 04:53:26.883-0600

thank you very much for this improvement!

By: Matt Jordan (mjordan) 2011-11-15 09:19:50.820-0600

Walter: since you have a patch on reviewboard, I'm going to go ahead and assign this issue to you.