Hi, I'm having problems using TLS to receive calls. I'm using a Nokia N95 to test TLS against freeswitch. I can register my client against freeswitch and make outbound calls to the test numbers (e.g. 9999). I can also make calls to other users registered over UDP. However if I try to make a call to a user registered over TLS the leg of the call to that user always goes via UDP. e.g. 1000 registered via TLS 1001 registered via TLS 1002 registered via UDP 1003 registered via UDP 1000 -> 1002 works ok 1003 -> 1002 works ok 1001 -> 1000 Doesn't work. The leg of the call between freeswitch and 1000 tries to setup via UDP 1002 -> 1000 Doesn't work. The leg of the call between freeswitch and 1000 tries to setup via UDP ===
From looking at some of the documentation it seems to me that the issue may be with the "tls-bind-params" being "transport=tls".
The phone I'm using doesn't add the "transport=tls" parameter, and only uses "sips:" to specify that the connection is via TLS. I tried setting "tls-bind-params" to a blank string but it didn't change anything. Is there any way to receive calls over TLS if you don't specify "transport=tls" in your contact string during registration? According to RFC3261 the use of the "transport=tls" parameter isn't recommended anymore and is now deprecated. -- View this message in context: http://www.nabble.com/TLS-receiving-calls-tp20771637p20771637.html Sent from the Freeswitch-users mailing list archive at Nabble.com.
Did you add <action application="export" data="sip_secure_media=true"/> into youy dialplan before bridging that call. How is your internal.conf, is TLS enabled there? Best regards Peter matrim schrieb:
Hi,
I'm having problems using TLS to receive calls.
I'm using a Nokia N95 to test TLS against freeswitch. I can register my client against freeswitch and make outbound calls to the test numbers (e.g. 9999).
I can also make calls to other users registered over UDP.
However if I try to make a call to a user registered over TLS the leg of the call to that user always goes via UDP.
e.g.
1000 registered via TLS 1001 registered via TLS 1002 registered via UDP 1003 registered via UDP
1000 -> 1002 works ok 1003 -> 1002 works ok
1001 -> 1000 Doesn't work. The leg of the call between freeswitch and 1000 tries to setup via UDP 1002 -> 1000 Doesn't work. The leg of the call between freeswitch and 1000 tries to setup via UDP
===
From looking at some of the documentation it seems to me that the issue may
be with the "tls-bind-params" being "transport=tls".
The phone I'm using doesn't add the "transport=tls" parameter, and only uses "sips:" to specify that the connection is via TLS.
I tried setting "tls-bind-params" to a blank string but it didn't change anything. Is there any way to receive calls over TLS if you don't specify "transport=tls" in your contact string during registration?
According to RFC3261 the use of the "transport=tls" parameter isn't recommended anymore and is now deprecated.
I don't have that set however I'm not trying to use SRTP yet. At the moment I'm just trying to use Secure SIP. That section of my dial plan is <condition field="${sip_has_crypto}" expression="^(AES_CM_128_HMAC_SHA1_32|AES_CM_128_HMAC_SHA1_80)$" break="never"> <action application="set" data="sip_secure_media=true"/> <!-- Offer SRTP on outbound legs if we have it on inbound. --> <!-- <action application="export" data="sip_secure_media=true"/> --> </condition> The TLS part of my internal.xml is now <!-- TLS: disabled by default, set to "true" to enable --> <param name="tls" value="true"/> <!-- additional bind parameters for TLS --> <param name="tls-bind-params" value=""/> <!-- Port to listen on for TLS requests. (5061 will be used if unspecified) --> <param name="tls-sip-port" value="$${internal_tls_port}"/> <!-- Location of the agent.pem and cafile.pem ssl certificates (needed for TLS server) --> <param name="tls-cert-dir" value="$${internal_ssl_dir}"/> <!-- TLS version ("sslv23" (default), "tlsv1"). NOTE: Phones may not work with TLSv1 --> <param name="tls-version" value="$${sip_tls_version}"/> I also tried with <!-- additional bind parameters for TLS --> <param name="tls-bind-params" value="transport=tls"/> On Mon, Dec 1, 2008 at 3:47 PM, Peter P GMX <Prometheus001@gmx.net> wrote:
Did you add <action application="export" data="sip_secure_media=true"/> into youy dialplan before bridging that call. How is your internal.conf, is TLS enabled there?
Best regards Peter
matrim schrieb:
Hi,
I'm having problems using TLS to receive calls.
I'm using a Nokia N95 to test TLS against freeswitch. I can register my client against freeswitch and make outbound calls to the test numbers (e.g. 9999).
I can also make calls to other users registered over UDP.
However if I try to make a call to a user registered over TLS the leg of the call to that user always goes via UDP.
e.g.
1000 registered via TLS 1001 registered via TLS 1002 registered via UDP 1003 registered via UDP
1000 -> 1002 works ok 1003 -> 1002 works ok
1001 -> 1000 Doesn't work. The leg of the call between freeswitch and 1000 tries to setup via UDP 1002 -> 1000 Doesn't work. The leg of the call between freeswitch and 1000 tries to setup via UDP
===
From looking at some of the documentation it seems to me that the issue may
be with the "tls-bind-params" being "transport=tls".
The phone I'm using doesn't add the "transport=tls" parameter, and only uses "sips:" to specify that the connection is via TLS.
I tried setting "tls-bind-params" to a blank string but it didn't change anything. Is there any way to receive calls over TLS if you don't specify "transport=tls" in your contact string during registration?
According to RFC3261 the use of the "transport=tls" parameter isn't recommended anymore and is now deprecated.
_______________________________________________ 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
Please tell that to everyone out there in the REAL world. It was my understanding that sips: was the one that went away in favor of transport= which is what everyone uses. /b On Dec 1, 2008, at 7:09 AM, matrim wrote:
According to RFC3261 the use of the "transport=tls" parameter isn't recommended anymore and is now deprecated.
I'm not sure about current implementations that servers are using. I'm used to using sip over UDP and TCP but this is my first time testing SIP over TLS. So I'm just going by what's in the specification and what's implemented on the devices I'm trying to test against, which are Nokia S60 devices (e.g. Nokia N95, E66). Out of interest do you have any links to anywhere this is discussed in terms of general sip implementations? On Mon, Dec 1, 2008 at 4:00 PM, Brian West <brian@freeswitch.org> wrote:
Please tell that to everyone out there in the REAL world. It was my understanding that sips: was the one that went away in favor of transport= which is what everyone uses.
/b
On Dec 1, 2008, at 7:09 AM, matrim wrote:
According to RFC3261 the use of the "transport=tls" parameter isn't recommended anymore and is now deprecated.
_______________________________________________ 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
On 12/1/08, Thomas Troy <ttroy50@gmail.com> wrote: ..snip..
Out of interest do you have any links to anywhere this is discussed in terms of general sip implementations?
Uh oh, here we go again... http://www.iana.org/assignments/sip-parameters http://tools.ietf.org/html/rfc3969 https://lists.cs.columbia.edu/pipermail/sip-implementors/2005-August/010047.... Implementation wise, most devices tend to use transport=tls: SIPFoundry - From what I've seen Snom SERs Asterisk (If you are using TLS) Cisco - I *believe* you can use either a SIPS URI or the transport=tls parameter for various SIP targets As the RFC (basically) states (RFC3261, section 12.1.x), transport=tls was deprecated in RFC 3261 because you should also be able to do TLS over SCTP (RFC3436), which makes transport=tls a bit ambiguous. sips:user@domain;transport=tcp or sips:user@domain;transport=sctp is a bit more flexible. I don't know if I've ever seen anything default to SIPS URIs. I also don't think I've ever specifically tried using them. However, my experience with TLS is admittedly somewhat limited so this shouldn't be taken as gospel. As you can see from the discussions on sip-implementors, this gets interesting when different devices are traversing a proxy using different URI schemes... However, I suspect this won't become an issue until most SIP implementations support SCTP. That should be exciting! ;) -- Kristian Kielhofner http://blog.krisk.org http://www.submityoursip.com http://www.astlinux.org http://www.star2star.com
Naturally, either way is stupid. The whole idea of putting the transport in a uri param is equally stupid to using 2 different protocol names but since SIP is the descendant of http it they decided to stick with the stupidity of http/https and have sip/sips which is almost as if it was designed to break all software trying to keep up with url syntax. If they are going to insist on using text params you'd think something like transport=foo;security=tls would be even *more* flexable in case alternate methods to encrypt crop up. This is, of course, the first step into a lengthy 12 hour discussion on how stupid SIP and url/text based protocols are. I dare someone to crank up the pcap on a box doing SIP presence for 20 phones and "read" the 1200 byte messages with all kinds of hyeroglyphic url syntax and embedded xml payloads and write up a paper on how much "sense" it makes to have it be "readable". PS supposedly sofia can support sctp, someone should try it. On Mon, Dec 1, 2008 at 9:43 PM, Kristian Kielhofner < kkielhofner@star2star.com> wrote:
On 12/1/08, Thomas Troy <ttroy50@gmail.com> wrote: ..snip..
Out of interest do you have any links to anywhere this is discussed in
terms
of general sip implementations?
Uh oh, here we go again...
http://www.iana.org/assignments/sip-parameters http://tools.ietf.org/html/rfc3969
https://lists.cs.columbia.edu/pipermail/sip-implementors/2005-August/010047....
Implementation wise, most devices tend to use transport=tls:
SIPFoundry - From what I've seen Snom SERs Asterisk (If you are using TLS) Cisco - I *believe* you can use either a SIPS URI or the transport=tls parameter for various SIP targets
As the RFC (basically) states (RFC3261, section 12.1.x), transport=tls was deprecated in RFC 3261 because you should also be able to do TLS over SCTP (RFC3436), which makes transport=tls a bit ambiguous. sips:user@domain;transport=tcp or sips:user@domain;transport=sctp is a bit more flexible.
I don't know if I've ever seen anything default to SIPS URIs. I also don't think I've ever specifically tried using them. However, my experience with TLS is admittedly somewhat limited so this shouldn't be taken as gospel. As you can see from the discussions on sip-implementors, this gets interesting when different devices are traversing a proxy using different URI schemes...
However, I suspect this won't become an issue until most SIP implementations support SCTP. That should be exciting! ;)
-- Kristian Kielhofner http://blog.krisk.org http://www.submityoursip.com http://www.astlinux.org http://www.star2star.com
_______________________________________________ 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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
On 12/2/08, Anthony Minessale <anthony.minessale@gmail.com> wrote:
Naturally, either way is stupid.
Word.
The whole idea of putting the transport in a uri param is equally stupid to using 2 different protocol names but since SIP is the descendant of http it they decided to stick with the stupidity of http/https and have sip/sips which is almost as if it was designed to break all software trying to keep up with url syntax.
Too late now.
If they are going to insist on using text params you'd think something like transport=foo;security=tls would be even *more* flexable in case alternate methods to encrypt crop up.
I can agree with you here... URI parameters in SIP have come to be the catch all for random junk that doesn't seem to fit anywhere else. Note that "random junk" includes everything from transport, to number portability, to CICs, to ISUP-OLI and on. Even in my world setting up proxies, UAs, etc to parse out the various crap people put in SIP URI params is a hassle. A big one. What a mess!!!
This is, of course, the first step into a lengthy 12 hour discussion on how stupid SIP and url/text based protocols are.
I like them but I'm weird.
I dare someone to crank up the pcap on a box doing SIP presence for 20 phones and "read" the 1200 byte messages with all kinds of hyeroglyphic url syntax and embedded xml payloads and write up a paper on how much "sense" it makes to have it be "readable".
I do it all the time. I think it's quite usable. ngrep provides a small enough binary and the ability to match on text. Certainly easier to use, especially on embedded systems without the luxury of dedicated protocol decoders. With a simple ngrep binary I can debug any text based protocol I understand. Of course, turn on TLS and see how useful *any* of these tools are... The core SIP spec and authors can't be blamed for the various junk people have been putting in SIP bodies. If what's going on in the real world is any indication, that ship sailed long ago. At this point as long as implementations can at least handle multi-part sensibly and everyone specifies the correct MIME type I don't really care. Even nastier examples abound - embedded, encapsulated ISUP! How about GTD? What about Linksys phones using SIP INFO to serve directories? Man I could go on and on... I'm not going to write a paper about it but I don't think it's that bad. Maybe I'm not just weird; maybe I'm a masochist! :)
PS
supposedly sofia can support sctp, someone should try it.
That would be cool. For anyone wanting to try, various SERs support SCTP. Cisco gateways do too. -- Kristian Kielhofner http://blog.krisk.org http://www.submityoursip.com http://www.astlinux.org http://www.star2star.com
Bring on SNAP, baby! On Tue, Dec 2, 2008 at 11:03 AM, Kristian Kielhofner < kkielhofner@star2star.com> wrote:
On 12/2/08, Anthony Minessale <anthony.minessale@gmail.com> wrote:
Naturally, either way is stupid.
Word.
The whole idea of putting the transport in a uri param is equally stupid to using 2 different protocol names but since SIP is the descendant of http it they decided to stick with the stupidity of http/https and have sip/sips which is almost as if it was designed to break all software trying to keep up with url syntax.
Too late now.
If they are going to insist on using text params you'd think something like transport=foo;security=tls would be even *more* flexable in case alternate methods to encrypt crop up.
I can agree with you here...
URI parameters in SIP have come to be the catch all for random junk that doesn't seem to fit anywhere else. Note that "random junk" includes everything from transport, to number portability, to CICs, to ISUP-OLI and on.
Even in my world setting up proxies, UAs, etc to parse out the various crap people put in SIP URI params is a hassle. A big one.
What a mess!!!
This is, of course, the first step into a lengthy 12 hour discussion on how stupid SIP and url/text based protocols are.
I like them but I'm weird.
I dare someone to crank up the pcap on a box doing SIP presence for 20 phones and "read" the 1200 byte messages with all kinds of hyeroglyphic url syntax and embedded xml payloads and write up a paper on how much "sense" it makes to have it be "readable".
I do it all the time. I think it's quite usable. ngrep provides a small enough binary and the ability to match on text. Certainly easier to use, especially on embedded systems without the luxury of dedicated protocol decoders. With a simple ngrep binary I can debug any text based protocol I understand.
Of course, turn on TLS and see how useful *any* of these tools are...
The core SIP spec and authors can't be blamed for the various junk people have been putting in SIP bodies. If what's going on in the real world is any indication, that ship sailed long ago. At this point as long as implementations can at least handle multi-part sensibly and everyone specifies the correct MIME type I don't really care.
Even nastier examples abound - embedded, encapsulated ISUP! How about GTD? What about Linksys phones using SIP INFO to serve directories? Man I could go on and on...
I'm not going to write a paper about it but I don't think it's that bad. Maybe I'm not just weird; maybe I'm a masochist! :)
PS
supposedly sofia can support sctp, someone should try it.
That would be cool. For anyone wanting to try, various SERs support SCTP. Cisco gateways do too.
-- Kristian Kielhofner http://blog.krisk.org http://www.submityoursip.com http://www.astlinux.org http://www.star2star.com
_______________________________________________ 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
We'll schedule a round table with the topic SIP OMFG STFU At the next ClueCon aug 4th-6th 2009 to stir things up a bit =D On Tue, Dec 2, 2008 at 1:03 PM, Kristian Kielhofner < kkielhofner@star2star.com> wrote:
On 12/2/08, Anthony Minessale <anthony.minessale@gmail.com> wrote:
Naturally, either way is stupid.
Word.
The whole idea of putting the transport in a uri param is equally stupid to using 2 different protocol names but since SIP is the descendant of http it they decided to stick with the stupidity of http/https and have sip/sips which is almost as if it was designed to break all software trying to keep up with url syntax.
Too late now.
If they are going to insist on using text params you'd think something like transport=foo;security=tls would be even *more* flexable in case alternate methods to encrypt crop up.
I can agree with you here...
URI parameters in SIP have come to be the catch all for random junk that doesn't seem to fit anywhere else. Note that "random junk" includes everything from transport, to number portability, to CICs, to ISUP-OLI and on.
Even in my world setting up proxies, UAs, etc to parse out the various crap people put in SIP URI params is a hassle. A big one.
What a mess!!!
This is, of course, the first step into a lengthy 12 hour discussion on how stupid SIP and url/text based protocols are.
I like them but I'm weird.
I dare someone to crank up the pcap on a box doing SIP presence for 20 phones and "read" the 1200 byte messages with all kinds of hyeroglyphic url syntax and embedded xml payloads and write up a paper on how much "sense" it makes to have it be "readable".
I do it all the time. I think it's quite usable. ngrep provides a small enough binary and the ability to match on text. Certainly easier to use, especially on embedded systems without the luxury of dedicated protocol decoders. With a simple ngrep binary I can debug any text based protocol I understand.
Of course, turn on TLS and see how useful *any* of these tools are...
The core SIP spec and authors can't be blamed for the various junk people have been putting in SIP bodies. If what's going on in the real world is any indication, that ship sailed long ago. At this point as long as implementations can at least handle multi-part sensibly and everyone specifies the correct MIME type I don't really care.
Even nastier examples abound - embedded, encapsulated ISUP! How about GTD? What about Linksys phones using SIP INFO to serve directories? Man I could go on and on...
I'm not going to write a paper about it but I don't think it's that bad. Maybe I'm not just weird; maybe I'm a masochist! :)
PS
supposedly sofia can support sctp, someone should try it.
That would be cool. For anyone wanting to try, various SERs support SCTP. Cisco gateways do too.
-- Kristian Kielhofner http://blog.krisk.org http://www.submityoursip.com http://www.astlinux.org http://www.star2star.com
_______________________________________________ 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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
On 12/2/08, Anthony Minessale <anthony.minessale@gmail.com> wrote:
We'll schedule a round table with the topic
SIP OMFG STFU
At the next ClueCon aug 4th-6th 2009 to stir things up a bit =D
Heh. I've been trying to make it back these last couple of years. I just might make it in '09! -- Kristian Kielhofner http://blog.krisk.org http://www.submityoursip.com http://www.astlinux.org http://www.star2star.com
participants (7)
-
Anthony Minessale
-
Brian West
-
Kristian Kielhofner
-
matrim
-
Michael Collins
-
Peter P GMX
-
Thomas Troy