Transporting SIP over TCP
Hi, Googeling about this shows that FS aims to support this (in fact it supports all 3: UDP/TCP/TLS). Yet I could not find the way to configure FS in order to support that. In fact, it does not work in my current install. I have TLS configured and work, but could not make TCP works thanks in advance /tzury
It just works... to force TCP you append ;transport=tcp In reality you should be using SRV records. /b On Aug 13, 2009, at 3:40 AM, Tzury Bar Yochay wrote:
Hi,
Googeling about this shows that FS aims to support this (in fact it supports all 3: UDP/TCP/TLS). Yet I could not find the way to configure FS in order to support that. In fact, it does not work in my current install. I have TLS configured and work, but could not make TCP works
thanks in advance
/tzury
It just works... to force TCP you append ;transport=tcp Hi Brian
In fact this is exactly what I did and I could not get it work. I am using a console based application supplied by pjsip.org and when trying to register i get some error messages saying 'invalid transport "SIP/2.0/tcp"' and 'REGISTER (30669) has invalid Via' using the very same client against iptel.org seems to work.
In reality you should be using SRV records. can you please elaborate a bit more about this?
I am dumping below the cli output. thanks in advance for your time and attention tport_wakeup(0x7fd82c2afaf0): events IN tport_recv_event(0x7fd82c2afaf0) tport_recv_iovec(0x7fd82c2afaf0) msg 0x7fd82c2a1830 from (tcp/80.74.97.189:42634) has 472 bytes, veclen = 1 tport_deliver(0x7fd82c2afaf0): msg 0x7fd82c2a1830 (472 bytes) from tcp/80.74.97.189:42634/sip next=(nil) nta: received REGISTER sip:cheerfulsanity.net;transport=tcp SIP/2.0 (CSeq 30669) nta: Via check: invalid transport "SIP/2.0/tcp" from 80.74.97.189:42634 nta: REGISTER (30669) has invalid Via tport(0x7fd82c2afaf0): reset timer tport(0x7fd82c2afaf0): set timer at 1800000 ms because idle since recv tport_wakeup_pri(0x713dd0): events IN tport_recv_event(0x713dd0) tport_recv_iovec(0x713dd0) msg 0x7fd82c2a1830 from (udp/67.23.5.142:5060) has 2 bytes, veclen = 1 tport_deliver(0x713dd0): bad msg 0x7fd82c2a1830 (2 bytes) from udp/199.245.214.130:5060/sip next=(nil) tport_wakeup_pri(0x713dd0): events IN tport_recv_event(0x713dd0) tport_recv_iovec(0x713dd0) msg 0x7fd82c2a1830 from (udp/67.23.5.142:5060) has 2 bytes, veclen = 1 tport_deliver(0x713dd0): bad msg 0x7fd82c2a1830 (2 bytes) from udp/199.245.214.130:5060/sip next=(nil) tport_wakeup(0x7fd84027d7d0): events IN tport_recv_event(0x7fd84027d7d0)
I need to see the sip packet. dumped below
TCP should be uppercase I'm pretty sure. you mean the via should be Via: SIP/2.0/TCP right?
If so, then that would a bug in the client then. #wireshark dumps: 000 00 21 29 66 15 9f 00 23 ae 64 af a6 08 00 45 00 .!)f...# .d....E. 0010 02 3e 80 c2 40 00 40 06 64 e6 0a 00 00 6d 43 17 .>..@.@. d....mC. 0020 05 8e db f4 13 c4 8a 0e 91 93 f6 a7 50 06 80 18 ........ ....P... 0030 00 5c 55 42 00 00 01 01 08 0a 0e 94 11 e4 01 ba .\UB.... ........ 0040 bf 9d 52 45 47 49 53 54 45 52 20 73 69 70 3a 63 ..REGIST ER sip:c 0050 68 65 65 72 66 75 6c 73 61 6e 69 74 79 2e 6e 65 heerfuls anity.ne 0060 74 3b 74 72 61 6e 73 70 6f 72 74 3d 74 63 70 20 t;transp ort=tcp 0070 53 49 50 2f 32 2e 30 0d 0a 56 69 61 3a 20 53 49 SIP/2.0. .Via: SI 0080 50 2f 32 2e 30 2f 74 63 70 20 31 30 2e 30 2e 30 P/2.0/tc p 10.0.0 0090 2e 31 30 39 3a 35 36 33 30 38 3b 72 70 6f 72 74 .109:563 08;rport 00a0 3b 62 72 61 6e 63 68 3d 7a 39 68 47 34 62 4b 50 ;branch= z9hG4bKP 00b0 6a 69 43 34 39 35 5a 50 52 6d 32 39 39 65 4f 6e jiC495ZP Rm299eOn 00c0 6e 32 4f 4b 34 79 6a 6b 64 37 32 4c 2d 41 73 76 n2OK4yjk d72L-Asv 00d0 67 0d 0a 52 6f 75 74 65 3a 20 3c 73 69 70 3a 63 g..Route : <sip:c 00e0 68 65 65 72 66 75 6c 73 61 6e 69 74 79 2e 6e 65 heerfuls anity.ne 00f0 74 3b 74 72 61 6e 73 70 6f 72 74 3d 74 63 70 3b t;transp ort=tcp; 0100 6c 72 3e 0d 0a 4d 61 78 2d 46 6f 72 77 61 72 64 lr>..Max -Forward 0110 73 3a 20 37 30 0d 0a 46 72 6f 6d 3a 20 3c 73 69 s: 70..F rom: <si 0120 70 3a 31 30 36 30 40 63 68 65 65 72 66 75 6c 73 p:1060@c heerfuls 0130 61 6e 69 74 79 2e 6e 65 74 3e 3b 74 61 67 3d 52 anity.ne t>;tag=R 0140 45 2e 58 78 5a 6e 4b 6a 71 66 32 5a 48 2d 38 4f E.XxZnKj qf2ZH-8O 0150 58 37 30 71 70 73 78 5a 44 43 69 51 4a 37 65 0d X70qpsxZ DCiQJ7e. 0160 0a 54 6f 3a 20 3c 73 69 70 3a 31 30 36 30 40 63 .To: <si p:1060@c 0170 68 65 65 72 66 75 6c 73 61 6e 69 74 79 2e 6e 65 heerfuls anity.ne 0180 74 3e 0d 0a 43 61 6c 6c 2d 49 44 3a 20 5a 6e 61 t>..Call -ID: Zna 0190 30 61 56 68 72 2d 51 43 4a 4a 58 34 62 70 79 31 0aVhr-QC JJX4bpy1 01a0 4c 78 6b 62 4a 46 78 6a 50 4f 2d 4f 6d 0d 0a 43 LxkbJFxj PO-Om..C 01b0 53 65 71 3a 20 34 37 37 38 30 20 52 45 47 49 53 Seq: 477 80 REGIS 01c0 54 45 52 0d 0a 55 73 65 72 2d 41 67 65 6e 74 3a TER..Use r-Agent: 01d0 20 50 4a 53 55 41 20 76 31 2e 33 2d 74 72 75 6e PJSUA v 1.3-trun 01e0 6b 2f 69 36 38 36 2d 70 63 2d 6c 69 6e 75 78 2d k/i686-p c-linux- 01f0 67 6e 75 0d 0a 43 6f 6e 74 61 63 74 3a 20 3c 73 gnu..Con tact: <s 0200 69 70 3a 31 30 36 30 40 31 30 2e 30 2e 30 2e 31 ip:1060@ 10.0.0.1 0210 30 39 3a 35 30 36 30 3b 74 72 61 6e 73 70 6f 72 09:5060; transpor 0220 74 3d 54 43 50 3e 0d 0a 45 78 70 69 72 65 73 3a t=TCP>.. Expires: 0230 20 33 30 30 0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65 300..Co ntent-Le 0240 6e 67 74 68 3a 20 20 30 0d 0a 0d 0a ngth: 0 ....
On Aug 13, 2009, at 9:37 AM, Tzury Bar Yochay wrote:
I need to see the sip packet. dumped below
TCP should be uppercase I'm pretty sure. you mean the via should be Via: SIP/2.0/TCP right?
Yep
If so, then that would a bug in the client then.
Some things might accept it but sofia is usually strict about some of this stuff. /b
Hi Brian, Just for your information here is a mail I got from a colleague of mine which I consider as an experienced freeswitch integrator
"... TCP used to work, and I had about 20-30 client phones connecting with it. About 3 months ago I did an upgrade and TCP no longer worked. I was in panic mode, so I just ended up walking my clients through reconfiguring their phones to use UDP.
It is definitely a bug in Freeswitch. I can help you work up a jira bug report if you like. The bug happened somewhere between svn version 9800ish and 13223. 13223 is the version I'm running on my systems now, older, but stable for me..."
It would be just great if you can confirm the TCP functionality in the latest release of FreeSwitch /t
I'm just tryng TCP now and work (latest trunk) I done this test with eyebeam phone registeres to TCP port and call other ip phone (registered over UDB port). The audio work fine in both directions. My configuration: FS --> internet --> NAT --> Phones In the internal profile: Call-ID: OTIyNzRlNTQxNTk5NzBhYzMzYzM1YmQyNTgzNTA3MTk. User: 1004@nydomain.com Contact: "User" <sip:1004@87.12.101.59:13035;transport=TCP;rinstance=f3fd252ea20dd34a> Agent: eyeBeam release 1102u stamp 52345 Status: Registered(TCP)(unknown) EXP(2009-08-16 08:59:38) Host: mydomain.com IP: XXX:XXX.XXX.XXX Port: 13035 Auth-User: 1004 Auth-Realm: mydomain.com
Works fine here. /b On Aug 16, 2009, at 6:25 AM, Tzury Bar Yochay wrote:
Hi Brian,
Just for your information here is a mail I got from a colleague of mine which I consider as an experienced freeswitch integrator
"... TCP used to work, and I had about 20-30 client phones connecting with it. About 3 months ago I did an upgrade and TCP no longer worked. I was in panic mode, so I just ended up walking my clients through reconfiguring their phones to use UDP.
It is definitely a bug in Freeswitch. I can help you work up a jira bug report if you like. The bug happened somewhere between svn version 9800ish and 13223. 13223 is the version I'm running on my systems now, older, but stable for me..."
It would be just great if you can confirm the TCP functionality in the latest release of FreeSwitch
/t
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Brian/Bakko, Would you please tell me which softphone are you using? As you know, my own one is not working and when I tried tcp with xlite (providing transport=tls) I see in wireshark that it is still transporting it over udp(!) thanks allot in advance, Tzury On Sun, Aug 16, 2009 at 5:11 PM, Brian West <brian@freeswitch.org> wrote:
Works fine here.
/b
On Aug 16, 2009, at 6:25 AM, Tzury Bar Yochay wrote:
Hi Brian,
Just for your information here is a mail I got from a colleague of mine which I consider as an experienced freeswitch integrator
"... TCP used to work, and I had about 20-30 client phones connecting with it. About 3 months ago I did an upgrade and TCP no longer worked. I was in panic mode, so I just ended up walking my clients through reconfiguring their phones to use UDP.
It is definitely a bug in Freeswitch. I can help you work up a jira bug report if you like. The bug happened somewhere between svn version 9800ish and 13223. 13223 is the version I'm running on my systems now, older, but stable for me..."
It would be just great if you can confirm the TCP functionality in the latest release of FreeSwitch
/t
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Tzury Bar Yochay Regulus Labs ltd. http://reguluslabs.com +972 52 5133399
Tzury Bar Yochay <tzury.by@reguluslabs.com> wrote:
Brian/Bakko,
Would you please tell me which softphone are you using? As you know, my own one is not working and when I tried tcp with xlite (providing transport=tls) I see in wireshark that it is still transporting it over udp(!)
I've successfully used TLS with FreeSWITCH at both ends (yes, that's with FreeSWITCH itself as the softphone). Snom 320 phones are known to work as well if you set up SRV records for the TLS. I haven't tried other softphones because, basically, FreeSWITCH is a better phone than anything else I can find. To debug this, try wireshark or tshark to find out whether your softphone is trying to connect over the TLS port at all.
I'm not sure whether that's supposed to use TLS. I suspect not.
Jason, I think I confused you with this TLS/TCP thing. For the sake of clarification, I am talking about TCP and _not_ about TLS. That is simply transporting the signaling packets over TCP instead of UDP. No TLS should be involved at this stage. It is simply communication layer matter.
Tzury Bar Yochay <tzury.by@reguluslabs.com> wrote:
I think I confused you with this TLS/TCP thing. For the sake of clarification, I am talking about TCP and _not_ about TLS. That is simply transporting the signaling packets over TCP instead of UDP. No TLS should be involved at this stage. It is simply communication layer matter.
I can confirm that transport=tcp works fine here from one FreeSWITCH to another. (I'm doing it over IPv6, but that shouldn't make any difference).
Well if you append ;transport=tcp on the bridge lines it will use TCP . /b On Aug 17, 2009, at 9:06 AM, Tzury Bar Yochay wrote:
FreeSWITCH works very well as a client :P I am currently porting it into iPhone and Symbian, I am almost done ;-)
anyway, seriously now, can one point to a wiki page about this? How do I do that? I would need 3 server instances to place a call, right?
"Well if you append ;transport=tcp on the bridge lines it will use TCP" IMHO this statement needs some clarification based on the context of this thread. If the destination is another PBX or Freeswitch box then this is ok as FS will be initiating the TCP connection. For terminating calls to registered User Agents (UA) the decision to use TCP or UDP should be made using information collected when the UA registered. i.e if the UA registers using TCP, FS should use TCP to send and receive messages, if the UA registers with TLS, then FS should use TLS, same story for UDP. On Tue, Aug 18, 2009 at 12:10 AM, Brian West<brian@freeswitch.org> wrote:
Well if you append ;transport=tcp on the bridge lines it will use TCP .
/b
On Aug 17, 2009, at 9:06 AM, Tzury Bar Yochay wrote:
FreeSWITCH works very well as a client :P I am currently porting it into iPhone and Symbian, I am almost done ;-)
anyway, seriously now, can one point to a wiki page about this? How do I do that? I would need 3 server instances to place a call, right?
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Jim Burke Director Evolutiontel. http://www.evolutiontel.net
It already does exactly this. /b On Aug 23, 2009, at 11:49 PM, Jim Burke wrote:
For terminating calls to registered User Agents (UA) the decision to use TCP or UDP should be made using information collected when the UA registered. i.e if the UA registers using TCP, FS should use TCP to send and receive messages, if the UA registers with TLS, then FS should use TLS, same story for UDP.
I always expected it did :) My point was that you cannot put transport=TCP on a bridge statement line to an internal registered client and expect it to use a protocol that was not used at registration. Hence the clarification based on the context of the thread :) On Mon, Aug 24, 2009 at 2:53 PM, Brian West<brian@freeswitch.org> wrote:
It already does exactly this.
/b
On Aug 23, 2009, at 11:49 PM, Jim Burke wrote:
For terminating calls to registered User Agents (UA) the decision to use TCP or UDP should be made using information collected when the UA registered. i.e if the UA registers using TCP, FS should use TCP to send and receive messages, if the UA registers with TLS, then FS should use TLS, same story for UDP.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Jim Burke Director Evolutiontel. http://www.evolutiontel.net
X-Lite does support TCP, however you need to have NAPTR and SRV DNS entries. It used to support TLS, but this seems to have been removed :( sip.mydomain.net. IN NAPTR 0 0 "s" "SIPS+D2T" "" _sips._tcp.sip.mydomain.net. sip.mydomain.net. IN NAPTR 1 0 "s" "SIP+D2T" "" _sip._tcp.sip.mydomain.net. sip.mydomain.net. IN NAPTR 2 0 "s" "SIP+D2U" "" _sip._udp.sip.mydomain.net. _sip._udp.sip.mydomain.net. 43200 IN SRV 1 10 5060 sip.mydomain.net. _sip._tcp.sip.mydomain.net. 43200 IN SRV 1 10 5060 sip.mydomain.net. _sips._tcp.sip.mydomain.net. 43200 IN SRV 1 10 5061 sip.mydomain.net. On Mon, Aug 17, 2009 at 10:18 PM, bakko<asannucci@gmail.com> wrote:
Y make my tests with eyebeam.
I thing X-lite dont't support TCP transport.
BR
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Jim Burke Director Evolutiontel. http://www.evolutiontel.net
participants (5)
-
bakko
-
Brian West
-
Jason White
-
Jim Burke
-
Tzury Bar Yochay