[Freeswitch-dev] mod_dingaling does not set crypto
Hello, Using mod_dingaling I am unable to get it to append the crypto details to the session-accept Jingle stanza. The message is sent as: <iq xmlns="jabber:client" from="freeswitch@macbooks-macbook.local/talk" to="fff@macbooks-macbook.local/talk" type="set" id="300"> <jin:jingle xmlns:jin="urn:xmpp:jingle:1" action="session-accept" sid="233007325" initiator="fff@macbooks-macbook.local"> <jin:content name="audio" creator="initiator"> <rtp:description xmlns:rtp="urn:xmpp:jingle:apps:rtp:1" media="audio" ssrc="1351525407"> <rtp:payload-type id="0" name="PCMU" clockrate="8000" ptime="8000" maxptime="8000"> <rtp:parameter name="bitrate" value="64000"></rtp:parameter> </rtp:payload-type> </rtp:description> <p:transport xmlns:p="http://www.google.com/transport/p2p"></p:transport> </jin:content> </jin:jingle> <ses:session xmlns:ses="http://www.google.com/session" type="accept" id="233007325" initiator="fff@macbooks-macbook.local"> <pho:description xmlns:pho="http://www.google.com/session/phone"> <pho:payload-type id="0" name="PCMU" clockrate="8000" bitrate="64000" xmlns:pho="http://www.google.com/session/phone"></pho:payload-type> </pho:description> </ses:session> </iq> The full Wireshark trace can be found at http://filebin.ca/8JFB0hyFdHf On investigation it would seem that the TFLAG_SECURE flag is not being set. If I hack out the test on this flag in mdl_build_crypto() then the crypto is included in the message generated by Freeswitch: <iq xmlns="jabber:client" from="freeswitch@macbooks-macbook.local/talk" to="fff@macbooks-macbook.local/talk" type="set" id="301"> <jin:jingle xmlns:jin="urn:xmpp:jingle:1" action="session-accept" sid="7FnyqtQPPMNPn5h7nnJuRiv3GWg/bRAs" initiator="audio"> <jin:content name="audio" creator="initiator"> <rtp:description xmlns:rtp="urn:xmpp:jingle:apps:rtp:1" media="audio" ssrc="1351524387"> <rtp:payload-type id="0" name="PCMU" clockrate="8000" ptime="8000" maxptime="8000"> <rtp:parameter name="bitrate" value="64000"></rtp:parameter> </rtp:payload-type> <rtp:encryption> <rtp:crypto crypto-suite="AES_CM_128_HMAC_SHA1_80" key-params="inline:J8/3QjLtugHFof08KBIevXxUOBo3x8PdphPMx7J4" tag="1"></rtp:crypto> </rtp:encryption> </rtp:description> <p:transport xmlns:p="http://www.google.com/transport/p2p"></p:transport> </jin:content> </jin:jingle> <ses:session xmlns:ses="http://www.google.com/session" type="accept" id="7FnyqtQPPMNPn5h7nnJuRiv3GWg/bRAs" initiator="audio"> <pho:description xmlns:pho="http://www.google.com/session/phone"> <pho:payload-type id="0" name="PCMU" clockrate="8000" bitrate="64000" xmlns:pho="http://www.google.com/session/phone"></pho:payload-type> </pho:description> </ses:session> </iq> But, I can't see how this flag is ever set. Is this a bug or am I missing something very simple?? This is using Freeswitch commit fa1276d9492fd39ea733f7af301faed3556c9544 (dated 8th July 2012) The jingle profile is here http://filebin.ca/8JGG8ZhEUSh. Regards, Richard
does it work then? I had it disabled on purpose cos I have not confirmed it works yet. On Wed, Jul 11, 2012 at 4:47 AM, Richard Screene <richard.screene@netdev.co.uk> wrote:
Hello,
Using mod_dingaling I am unable to get it to append the crypto details to the session-accept Jingle stanza. The message is sent as:
<iq xmlns="jabber:client" from="freeswitch@macbooks-macbook.local/talk" to="fff@macbooks-macbook.local/talk" type="set" id="300"> <jin:jingle xmlns:jin="urn:xmpp:jingle:1" action="session-accept" sid="233007325" initiator="fff@macbooks-macbook.local"> <jin:content name="audio" creator="initiator"> <rtp:description xmlns:rtp="urn:xmpp:jingle:apps:rtp:1" media="audio" ssrc="1351525407"> <rtp:payload-type id="0" name="PCMU" clockrate="8000" ptime="8000" maxptime="8000"> <rtp:parameter name="bitrate" value="64000"></rtp:parameter> </rtp:payload-type> </rtp:description> <p:transport xmlns:p="http://www.google.com/transport/p2p"></p:transport> </jin:content> </jin:jingle> <ses:session xmlns:ses="http://www.google.com/session" type="accept" id="233007325" initiator="fff@macbooks-macbook.local"> <pho:description xmlns:pho="http://www.google.com/session/phone"> <pho:payload-type id="0" name="PCMU" clockrate="8000" bitrate="64000" xmlns:pho="http://www.google.com/session/phone"></pho:payload-type> </pho:description> </ses:session> </iq>
The full Wireshark trace can be found at http://filebin.ca/8JFB0hyFdHf
On investigation it would seem that the TFLAG_SECURE flag is not being set. If I hack out the test on this flag in mdl_build_crypto() then the crypto is included in the message generated by Freeswitch:
<iq xmlns="jabber:client" from="freeswitch@macbooks-macbook.local/talk" to="fff@macbooks-macbook.local/talk" type="set" id="301"> <jin:jingle xmlns:jin="urn:xmpp:jingle:1" action="session-accept" sid="7FnyqtQPPMNPn5h7nnJuRiv3GWg/bRAs" initiator="audio"> <jin:content name="audio" creator="initiator"> <rtp:description xmlns:rtp="urn:xmpp:jingle:apps:rtp:1" media="audio" ssrc="1351524387"> <rtp:payload-type id="0" name="PCMU" clockrate="8000" ptime="8000" maxptime="8000"> <rtp:parameter name="bitrate" value="64000"></rtp:parameter> </rtp:payload-type> <rtp:encryption> <rtp:crypto crypto-suite="AES_CM_128_HMAC_SHA1_80" key-params="inline:J8/3QjLtugHFof08KBIevXxUOBo3x8PdphPMx7J4" tag="1"></rtp:crypto> </rtp:encryption> </rtp:description> <p:transport xmlns:p="http://www.google.com/transport/p2p"></p:transport> </jin:content> </jin:jingle> <ses:session xmlns:ses="http://www.google.com/session" type="accept" id="7FnyqtQPPMNPn5h7nnJuRiv3GWg/bRAs" initiator="audio"> <pho:description xmlns:pho="http://www.google.com/session/phone"> <pho:payload-type id="0" name="PCMU" clockrate="8000" bitrate="64000" xmlns:pho="http://www.google.com/session/phone"></pho:payload-type> </pho:description> </ses:session> </iq>
But, I can't see how this flag is ever set. Is this a bug or am I missing something very simple??
This is using Freeswitch commit fa1276d9492fd39ea733f7af301faed3556c9544 (dated 8th July 2012)
The jingle profile is here http://filebin.ca/8JGG8ZhEUSh.
Regards, Richard
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
Hello Anthony, Thanks for your quick response!
does it work then? I had it disabled on purpose cos I have not confirmed it works yet.
That would explain it then :-) I have managed to get SRTP working for the outbound voice path, but it required a couple of hacks: 1) It was attempting to decrypt the STUN/ICE Bind Requests and failing. I've bodged it for now by passing the SFF_PLC flag to switch_rtp.c:read_rtp_packet() but I suspect this will stop inbound voice paths from working! 2) In mod_dingaling.c:try_secure() the incorrect crypto_type is passed to switch_rtp_add_crypto_key(). I suspect there is some confusion between the crypto_type and crypto_send_type/crypto_recv_type members of tech_pvt->transports. I've hacked it for now as shown below. I hope this is useful to you. I'm going to try with the outbound voice path tomorrow. Regards, Richard For reference here are the diffs: diff --git a/src/mod/endpoints/mod_dingaling/mod_dingaling.c b/src/mod/endpoints/mod_dingaling/ index c47f589..1dda789 100644 --- a/src/mod/endpoints/mod_dingaling/mod_dingaling.c +++ b/src/mod/endpoints/mod_dingaling/mod_dingaling.c @@ -956,9 +956,11 @@ switch_status_t mdl_build_crypto(struct private_object *tech_pvt, ldl_tran char *p; +/* if (!switch_test_flag(tech_pvt, TFLAG_SECURE)) { return SWITCH_STATUS_SUCCESS; } +*/ if (type == AES_CM_128_HMAC_SHA1_80) { @@ -1056,10 +1058,13 @@ static switch_status_t mdl_add_crypto(struct private_object *tech_pvt, static void try_secure(struct private_object *tech_pvt, ldl_transport_type_t ttype) { +/* if (!switch_test_flag(tech_pvt, TFLAG_SECURE)) { return; } +*/ + tech_pvt->transports[ttype].crypto_type = tech_pvt->transports[ttype].crypto_recv_type; //if (tech_pvt->transports[ttype].crypto_type) { switch_rtp_add_crypto_key(tech_pvt->transports[ttype].rtp_session, diff --git a/src/switch_rtp.c b/src/switch_rtp.c index 7d6ad29..99b4f83 100644 --- a/src/switch_rtp.c +++ b/src/switch_rtp.c @@ -3234,6 +3234,7 @@ static int rtp_common_read(switch_rtp_t *rtp_session, switch_payload_t *p if (read_pretriggered) { read_pretriggered = 0; } else { + *flags |= SFF_PLC; status = read_rtp_packet(rtp_session, &bytes, flags, SWITCH_TRU //switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH } On 12 Jul 2012, at 00:13, Anthony Minessale wrote:
does it work then? I had it disabled on purpose cos I have not confirmed it works yet.
On Wed, Jul 11, 2012 at 4:47 AM, Richard Screene <richard.screene@netdev.co.uk> wrote:
Hello,
Using mod_dingaling I am unable to get it to append the crypto details to the session-accept Jingle stanza. The message is sent as: <snip>
try patch in latest head minus your plc hack. I have not made any changes to mod_dingaling yet but the core should not try to decode stun now. On Thu, Jul 12, 2012 at 11:58 AM, Richard Screene <richard.screene@netdev.co.uk> wrote:
Hello Anthony,
Thanks for your quick response!
does it work then? I had it disabled on purpose cos I have not confirmed it works yet.
That would explain it then :-)
I have managed to get SRTP working for the outbound voice path, but it required a couple of hacks: 1) It was attempting to decrypt the STUN/ICE Bind Requests and failing. I've bodged it for now by passing the SFF_PLC flag to switch_rtp.c:read_rtp_packet() but I suspect this will stop inbound voice paths from working! 2) In mod_dingaling.c:try_secure() the incorrect crypto_type is passed to switch_rtp_add_crypto_key(). I suspect there is some confusion between the crypto_type and crypto_send_type/crypto_recv_type members of tech_pvt->transports. I've hacked it for now as shown below.
I hope this is useful to you. I'm going to try with the outbound voice path tomorrow.
Regards, Richard
For reference here are the diffs:
diff --git a/src/mod/endpoints/mod_dingaling/mod_dingaling.c b/src/mod/endpoints/mod_dingaling/ index c47f589..1dda789 100644 --- a/src/mod/endpoints/mod_dingaling/mod_dingaling.c +++ b/src/mod/endpoints/mod_dingaling/mod_dingaling.c @@ -956,9 +956,11 @@ switch_status_t mdl_build_crypto(struct private_object *tech_pvt, ldl_tran char *p;
+/* if (!switch_test_flag(tech_pvt, TFLAG_SECURE)) { return SWITCH_STATUS_SUCCESS; } +*/
if (type == AES_CM_128_HMAC_SHA1_80) { @@ -1056,10 +1058,13 @@ static switch_status_t mdl_add_crypto(struct private_object *tech_pvt, static void try_secure(struct private_object *tech_pvt, ldl_transport_type_t ttype) {
+/* if (!switch_test_flag(tech_pvt, TFLAG_SECURE)) { return; }
+*/ + tech_pvt->transports[ttype].crypto_type = tech_pvt->transports[ttype].crypto_recv_type;
//if (tech_pvt->transports[ttype].crypto_type) {
switch_rtp_add_crypto_key(tech_pvt->transports[ttype].rtp_session,
diff --git a/src/switch_rtp.c b/src/switch_rtp.c index 7d6ad29..99b4f83 100644 --- a/src/switch_rtp.c +++ b/src/switch_rtp.c @@ -3234,6 +3234,7 @@ static int rtp_common_read(switch_rtp_t *rtp_session, switch_payload_t *p if (read_pretriggered) { read_pretriggered = 0; } else { + *flags |= SFF_PLC; status = read_rtp_packet(rtp_session, &bytes, flags, SWITCH_TRU
//switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH }
On 12 Jul 2012, at 00:13, Anthony Minessale wrote:
does it work then? I had it disabled on purpose cos I have not confirmed it works yet.
On Wed, Jul 11, 2012 at 4:47 AM, Richard Screene <richard.screene@netdev.co.uk> wrote:
Hello,
Using mod_dingaling I am unable to get it to append the crypto details to
the session-accept Jingle stanza. The message is sent as:
<snip>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
Hello Anthony, That seems to work better than my attempt! Thanks for your help! Richard On 13 Jul 2012, at 23:19, Anthony Minessale wrote:
try patch in latest head minus your plc hack. I have not made any changes to mod_dingaling yet but the core should not try to decode stun now.
On Thu, Jul 12, 2012 at 11:58 AM, Richard Screene <richard.screene@netdev.co.uk> wrote:
Hello Anthony,
Thanks for your quick response!
does it work then? I had it disabled on purpose cos I have not confirmed it works yet.
That would explain it then :-)
I have managed to get SRTP working for the outbound voice path, but it required a couple of hacks: 1) It was attempting to decrypt the STUN/ICE Bind Requests and failing. I've bodged it for now by passing the SFF_PLC flag to switch_rtp.c:read_rtp_packet() but I suspect this will stop inbound voice paths from working! 2) In mod_dingaling.c:try_secure() the incorrect crypto_type is passed to switch_rtp_add_crypto_key(). I suspect there is some confusion between the crypto_type and crypto_send_type/crypto_recv_type members of tech_pvt->transports. I've hacked it for now as shown below.
I hope this is useful to you. I'm going to try with the outbound voice path tomorrow.
Regards, Richard
For reference here are the diffs:
diff --git a/src/mod/endpoints/mod_dingaling/mod_dingaling.c b/src/mod/endpoints/mod_dingaling/ index c47f589..1dda789 100644 --- a/src/mod/endpoints/mod_dingaling/mod_dingaling.c +++ b/src/mod/endpoints/mod_dingaling/mod_dingaling.c @@ -956,9 +956,11 @@ switch_status_t mdl_build_crypto(struct private_object *tech_pvt, ldl_tran char *p;
+/* if (!switch_test_flag(tech_pvt, TFLAG_SECURE)) { return SWITCH_STATUS_SUCCESS; } +*/
if (type == AES_CM_128_HMAC_SHA1_80) { @@ -1056,10 +1058,13 @@ static switch_status_t mdl_add_crypto(struct private_object *tech_pvt, static void try_secure(struct private_object *tech_pvt, ldl_transport_type_t ttype) {
+/* if (!switch_test_flag(tech_pvt, TFLAG_SECURE)) { return; }
+*/ + tech_pvt->transports[ttype].crypto_type = tech_pvt->transports[ttype].crypto_recv_type;
//if (tech_pvt->transports[ttype].crypto_type) {
switch_rtp_add_crypto_key(tech_pvt->transports[ttype].rtp_session,
diff --git a/src/switch_rtp.c b/src/switch_rtp.c index 7d6ad29..99b4f83 100644 --- a/src/switch_rtp.c +++ b/src/switch_rtp.c @@ -3234,6 +3234,7 @@ static int rtp_common_read(switch_rtp_t *rtp_session, switch_payload_t *p if (read_pretriggered) { read_pretriggered = 0; } else { + *flags |= SFF_PLC; status = read_rtp_packet(rtp_session, &bytes, flags, SWITCH_TRU
//switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH }
On 12 Jul 2012, at 00:13, Anthony Minessale wrote:
does it work then? I had it disabled on purpose cos I have not confirmed it works yet.
On Wed, Jul 11, 2012 at 4:47 AM, Richard Screene <richard.screene@netdev.co.uk> wrote:
Hello,
Using mod_dingaling I am unable to get it to append the crypto details to
the session-accept Jingle stanza. The message is sent as:
<snip>
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
Richard Screene Senior Developer NetDev Ltd & Drum Collaboration +44 1273 936125 www.netdev.co.uk www.thisisdrum.com Registered in England and Wales Company Number 04741258
ok so I pushed the flag to be set so now it should work out of the box, thanks for testing. On Mon, Jul 16, 2012 at 8:05 AM, Richard Screene <richard.screene@netdev.co.uk> wrote:
Hello Anthony,
That seems to work better than my attempt!
Thanks for your help! Richard
On 13 Jul 2012, at 23:19, Anthony Minessale wrote:
try patch in latest head minus your plc hack. I have not made any changes to mod_dingaling yet but the core should not try to decode stun now.
On Thu, Jul 12, 2012 at 11:58 AM, Richard Screene <richard.screene@netdev.co.uk> wrote:
Hello Anthony,
Thanks for your quick response!
does it work then? I had it disabled on purpose cos I have not
confirmed it works yet.
That would explain it then :-)
I have managed to get SRTP working for the outbound voice path, but it
required a couple of hacks:
1) It was attempting to decrypt the STUN/ICE Bind Requests and failing.
I've bodged it for now by passing the SFF_PLC flag to
switch_rtp.c:read_rtp_packet() but I suspect this will stop inbound voice
paths from working!
2) In mod_dingaling.c:try_secure() the incorrect crypto_type is passed to
switch_rtp_add_crypto_key(). I suspect there is some confusion between the
crypto_type and crypto_send_type/crypto_recv_type members of
tech_pvt->transports. I've hacked it for now as shown below.
I hope this is useful to you. I'm going to try with the outbound voice path
tomorrow.
Regards,
Richard
For reference here are the diffs:
diff --git a/src/mod/endpoints/mod_dingaling/mod_dingaling.c
b/src/mod/endpoints/mod_dingaling/
index c47f589..1dda789 100644
--- a/src/mod/endpoints/mod_dingaling/mod_dingaling.c
+++ b/src/mod/endpoints/mod_dingaling/mod_dingaling.c
@@ -956,9 +956,11 @@ switch_status_t mdl_build_crypto(struct private_object
*tech_pvt, ldl_tran
char *p;
+/*
if (!switch_test_flag(tech_pvt, TFLAG_SECURE)) {
return SWITCH_STATUS_SUCCESS;
}
+*/
if (type == AES_CM_128_HMAC_SHA1_80) {
@@ -1056,10 +1058,13 @@ static switch_status_t mdl_add_crypto(struct
private_object *tech_pvt,
static void try_secure(struct private_object *tech_pvt,
ldl_transport_type_t ttype)
{
+/*
if (!switch_test_flag(tech_pvt, TFLAG_SECURE)) {
return;
}
+*/
+ tech_pvt->transports[ttype].crypto_type =
tech_pvt->transports[ttype].crypto_recv_type;
//if (tech_pvt->transports[ttype].crypto_type) {
switch_rtp_add_crypto_key(tech_pvt->transports[ttype].rtp_session,
diff --git a/src/switch_rtp.c b/src/switch_rtp.c
index 7d6ad29..99b4f83 100644
--- a/src/switch_rtp.c
+++ b/src/switch_rtp.c
@@ -3234,6 +3234,7 @@ static int rtp_common_read(switch_rtp_t *rtp_session,
switch_payload_t *p
if (read_pretriggered) {
read_pretriggered = 0;
} else {
+ *flags |= SFF_PLC;
status = read_rtp_packet(rtp_session,
&bytes, flags, SWITCH_TRU
//switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH
}
On 12 Jul 2012, at 00:13, Anthony Minessale wrote:
does it work then? I had it disabled on purpose cos I have not
confirmed it works yet.
On Wed, Jul 11, 2012 at 4:47 AM, Richard Screene
<richard.screene@netdev.co.uk> wrote:
Hello,
Using mod_dingaling I am unable to get it to append the crypto details to
the session-accept Jingle stanza. The message is sent as:
<snip>
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
Official FreeSWITCH Sites
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-dev mailing list
FreeSWITCH-dev@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
Richard Screene Senior Developer NetDev Ltd & Drum Collaboration +44 1273 936125 www.netdev.co.uk www.thisisdrum.com Registered in England and Wales Company Number 04741258
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
Hello Anthony, We're not quite there yet! It would appear that TFLAG_SECURE is not set for the outbound call. I've had to comment out the check in mdl_build_crypto(). Would we expect the the flag to be set for both legs of the call? Also, I'm getting *a lot* of the following errors: 2012-07-17 11:05:36.128059 [ERR] switch_rtp.c:4296 Error: SRTP protection failed with code 13 I did see this once yesterday (with the previous version) but it went away so I assumed it was something I was doing. Now, I'm getting it all the time. If you'd like me to investigate further please let me know. Thanks for your continuing help, Richard On 16 Jul 2012, at 18:44, Anthony Minessale wrote:
ok so I pushed the flag to be set so now it should work out of the box, thanks for testing.
On Mon, Jul 16, 2012 at 8:05 AM, Richard Screene <richard.screene@netdev.co.uk> wrote:
Hello Anthony,
That seems to work better than my attempt!
Thanks for your help! Richard
On 13 Jul 2012, at 23:19, Anthony Minessale wrote:
try patch in latest head minus your plc hack. I have not made any changes to mod_dingaling yet but the core should not try to decode stun now.
On Thu, Jul 12, 2012 at 11:58 AM, Richard Screene <richard.screene@netdev.co.uk> wrote:
Hello Anthony,
Thanks for your quick response!
does it work then? I had it disabled on purpose cos I have not
confirmed it works yet.
That would explain it then :-)
I have managed to get SRTP working for the outbound voice path, but it
required a couple of hacks:
1) It was attempting to decrypt the STUN/ICE Bind Requests and failing.
I've bodged it for now by passing the SFF_PLC flag to
switch_rtp.c:read_rtp_packet() but I suspect this will stop inbound voice
paths from working!
2) In mod_dingaling.c:try_secure() the incorrect crypto_type is passed to
switch_rtp_add_crypto_key(). I suspect there is some confusion between the
crypto_type and crypto_send_type/crypto_recv_type members of
tech_pvt->transports. I've hacked it for now as shown below.
I hope this is useful to you. I'm going to try with the outbound voice path
tomorrow.
Regards,
Richard
For reference here are the diffs:
diff --git a/src/mod/endpoints/mod_dingaling/mod_dingaling.c
b/src/mod/endpoints/mod_dingaling/
index c47f589..1dda789 100644
--- a/src/mod/endpoints/mod_dingaling/mod_dingaling.c
+++ b/src/mod/endpoints/mod_dingaling/mod_dingaling.c
@@ -956,9 +956,11 @@ switch_status_t mdl_build_crypto(struct private_object
*tech_pvt, ldl_tran
char *p;
+/*
if (!switch_test_flag(tech_pvt, TFLAG_SECURE)) {
return SWITCH_STATUS_SUCCESS;
}
+*/
if (type == AES_CM_128_HMAC_SHA1_80) {
@@ -1056,10 +1058,13 @@ static switch_status_t mdl_add_crypto(struct
private_object *tech_pvt,
static void try_secure(struct private_object *tech_pvt,
ldl_transport_type_t ttype)
{
+/*
if (!switch_test_flag(tech_pvt, TFLAG_SECURE)) {
return;
}
+*/
+ tech_pvt->transports[ttype].crypto_type =
tech_pvt->transports[ttype].crypto_recv_type;
//if (tech_pvt->transports[ttype].crypto_type) {
switch_rtp_add_crypto_key(tech_pvt->transports[ttype].rtp_session,
diff --git a/src/switch_rtp.c b/src/switch_rtp.c
index 7d6ad29..99b4f83 100644
--- a/src/switch_rtp.c
+++ b/src/switch_rtp.c
@@ -3234,6 +3234,7 @@ static int rtp_common_read(switch_rtp_t *rtp_session,
switch_payload_t *p
if (read_pretriggered) {
read_pretriggered = 0;
} else {
+ *flags |= SFF_PLC;
status = read_rtp_packet(rtp_session,
&bytes, flags, SWITCH_TRU
//switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH
}
On 12 Jul 2012, at 00:13, Anthony Minessale wrote:
does it work then? I had it disabled on purpose cos I have not
confirmed it works yet.
On Wed, Jul 11, 2012 at 4:47 AM, Richard Screene
<richard.screene@netdev.co.uk> wrote:
Hello,
Using mod_dingaling I am unable to get it to append the crypto details to
the session-accept Jingle stanza. The message is sent as:
<snip>
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
Official FreeSWITCH Sites
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-dev mailing list
FreeSWITCH-dev@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
Richard Screene Senior Developer NetDev Ltd & Drum Collaboration +44 1273 936125 www.netdev.co.uk www.thisisdrum.com Registered in England and Wales Company Number 04741258
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
Richard Screene Senior Developer NetDev Ltd & Drum Collaboration +44 1273 936125 www.netdev.co.uk www.thisisdrum.com Registered in England and Wales Company Number 04741258
Just to give you all the information: A few days ago I hacked the RTP so that the RTP bug NEVER_CHANGE_SSRC_ON_MARKER was enabled. I removed it and it seemed to work yesterday. But, would this have anything to do with the "SRTP protection failed" error I was seeing today? Thanks, Richard On 16 Jul 2012, at 18:44, Anthony Minessale wrote:
ok so I pushed the flag to be set so now it should work out of the box, thanks for testing.
On Mon, Jul 16, 2012 at 8:05 AM, Richard Screene <richard.screene@netdev.co.uk> wrote:
Hello Anthony,
That seems to work better than my attempt!
Thanks for your help! Richard
On 13 Jul 2012, at 23:19, Anthony Minessale wrote:
try patch in latest head minus your plc hack. I have not made any changes to mod_dingaling yet but the core should not try to decode stun now.
On Thu, Jul 12, 2012 at 11:58 AM, Richard Screene <richard.screene@netdev.co.uk> wrote:
Hello Anthony,
Thanks for your quick response!
does it work then? I had it disabled on purpose cos I have not
confirmed it works yet.
That would explain it then :-)
I have managed to get SRTP working for the outbound voice path, but it
required a couple of hacks:
1) It was attempting to decrypt the STUN/ICE Bind Requests and failing.
I've bodged it for now by passing the SFF_PLC flag to
switch_rtp.c:read_rtp_packet() but I suspect this will stop inbound voice
paths from working!
2) In mod_dingaling.c:try_secure() the incorrect crypto_type is passed to
switch_rtp_add_crypto_key(). I suspect there is some confusion between the
crypto_type and crypto_send_type/crypto_recv_type members of
tech_pvt->transports. I've hacked it for now as shown below.
I hope this is useful to you. I'm going to try with the outbound voice path
tomorrow.
Regards,
Richard
For reference here are the diffs:
diff --git a/src/mod/endpoints/mod_dingaling/mod_dingaling.c
b/src/mod/endpoints/mod_dingaling/
index c47f589..1dda789 100644
--- a/src/mod/endpoints/mod_dingaling/mod_dingaling.c
+++ b/src/mod/endpoints/mod_dingaling/mod_dingaling.c
@@ -956,9 +956,11 @@ switch_status_t mdl_build_crypto(struct private_object
*tech_pvt, ldl_tran
char *p;
+/*
if (!switch_test_flag(tech_pvt, TFLAG_SECURE)) {
return SWITCH_STATUS_SUCCESS;
}
+*/
if (type == AES_CM_128_HMAC_SHA1_80) {
@@ -1056,10 +1058,13 @@ static switch_status_t mdl_add_crypto(struct
private_object *tech_pvt,
static void try_secure(struct private_object *tech_pvt,
ldl_transport_type_t ttype)
{
+/*
if (!switch_test_flag(tech_pvt, TFLAG_SECURE)) {
return;
}
+*/
+ tech_pvt->transports[ttype].crypto_type =
tech_pvt->transports[ttype].crypto_recv_type;
//if (tech_pvt->transports[ttype].crypto_type) {
switch_rtp_add_crypto_key(tech_pvt->transports[ttype].rtp_session,
diff --git a/src/switch_rtp.c b/src/switch_rtp.c
index 7d6ad29..99b4f83 100644
--- a/src/switch_rtp.c
+++ b/src/switch_rtp.c
@@ -3234,6 +3234,7 @@ static int rtp_common_read(switch_rtp_t *rtp_session,
switch_payload_t *p
if (read_pretriggered) {
read_pretriggered = 0;
} else {
+ *flags |= SFF_PLC;
status = read_rtp_packet(rtp_session,
&bytes, flags, SWITCH_TRU
//switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH
}
On 12 Jul 2012, at 00:13, Anthony Minessale wrote:
does it work then? I had it disabled on purpose cos I have not
confirmed it works yet.
On Wed, Jul 11, 2012 at 4:47 AM, Richard Screene
<richard.screene@netdev.co.uk> wrote:
Hello,
Using mod_dingaling I am unable to get it to append the crypto details to
the session-accept Jingle stanza. The message is sent as:
<snip>
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
Official FreeSWITCH Sites
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-dev mailing list
FreeSWITCH-dev@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
Richard Screene Senior Developer NetDev Ltd & Drum Collaboration +44 1273 936125 www.netdev.co.uk www.thisisdrum.com Registered in England and Wales Company Number 04741258
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
Richard Screene Senior Developer NetDev Ltd & Drum Collaboration +44 1273 936125 www.netdev.co.uk www.thisisdrum.com Registered in England and Wales Company Number 04741258
Give latest git head unchanged a shot again of you have a chance. That Darcy issue was fixed IIRC. Also I DoD a few rounds of changes. Btw next time use Jira Jira.freeswitch.org its easier to track stuff. I almost lost this thread 3 pages deep on my email. On Jul 17, 2012 7:03 AM, "Richard Screene" <richard.screene@netdev.co.uk> wrote:
Just to give you all the information: A few days ago I hacked the RTP so that the RTP bug NEVER_CHANGE_SSRC_ON_MARKER was enabled. I removed it and it seemed to work yesterday. But, would this have anything to do with the "SRTP protection failed" error I was seeing today?
Thanks, Richard
On 16 Jul 2012, at 18:44, Anthony Minessale wrote:
ok so I pushed the flag to be set so now it should work out of the box, thanks for testing.
On Mon, Jul 16, 2012 at 8:05 AM, Richard Screene <richard.screene@netdev.co.uk> wrote:
Hello Anthony,
That seems to work better than my attempt!
Thanks for your help!
Richard
On 13 Jul 2012, at 23:19, Anthony Minessale wrote:
try patch in latest head minus your plc hack.
I have not made any changes to mod_dingaling yet but the core should
not try to decode stun now.
On Thu, Jul 12, 2012 at 11:58 AM, Richard Screene
<richard.screene@netdev.co.uk> wrote:
Hello Anthony,
Thanks for your quick response!
does it work then? I had it disabled on purpose cos I have not
confirmed it works yet.
That would explain it then :-)
I have managed to get SRTP working for the outbound voice path, but it
required a couple of hacks:
1) It was attempting to decrypt the STUN/ICE Bind Requests and failing.
I've bodged it for now by passing the SFF_PLC flag to
switch_rtp.c:read_rtp_packet() but I suspect this will stop inbound voice
paths from working!
2) In mod_dingaling.c:try_secure() the incorrect crypto_type is passed to
switch_rtp_add_crypto_key(). I suspect there is some confusion between the
crypto_type and crypto_send_type/crypto_recv_type members of
tech_pvt->transports. I've hacked it for now as shown below.
I hope this is useful to you. I'm going to try with the outbound voice path
tomorrow.
Regards,
Richard
For reference here are the diffs:
diff --git a/src/mod/endpoints/mod_dingaling/mod_dingaling.c
b/src/mod/endpoints/mod_dingaling/
index c47f589..1dda789 100644
--- a/src/mod/endpoints/mod_dingaling/mod_dingaling.c
+++ b/src/mod/endpoints/mod_dingaling/mod_dingaling.c
@@ -956,9 +956,11 @@ switch_status_t mdl_build_crypto(struct private_object
*tech_pvt, ldl_tran
char *p;
+/*
if (!switch_test_flag(tech_pvt, TFLAG_SECURE)) {
return SWITCH_STATUS_SUCCESS;
}
+*/
if (type == AES_CM_128_HMAC_SHA1_80) {
@@ -1056,10 +1058,13 @@ static switch_status_t mdl_add_crypto(struct
private_object *tech_pvt,
static void try_secure(struct private_object *tech_pvt,
ldl_transport_type_t ttype)
{
+/*
if (!switch_test_flag(tech_pvt, TFLAG_SECURE)) {
return;
}
+*/
+ tech_pvt->transports[ttype].crypto_type =
tech_pvt->transports[ttype].crypto_recv_type;
//if (tech_pvt->transports[ttype].crypto_type) {
switch_rtp_add_crypto_key(tech_pvt->transports[ttype].rtp_session,
diff --git a/src/switch_rtp.c b/src/switch_rtp.c
index 7d6ad29..99b4f83 100644
--- a/src/switch_rtp.c
+++ b/src/switch_rtp.c
@@ -3234,6 +3234,7 @@ static int rtp_common_read(switch_rtp_t *rtp_session,
switch_payload_t *p
if (read_pretriggered) {
read_pretriggered = 0;
} else {
+ *flags |= SFF_PLC;
status = read_rtp_packet(rtp_session,
&bytes, flags, SWITCH_TRU
//switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH
}
On 12 Jul 2012, at 00:13, Anthony Minessale wrote:
does it work then? I had it disabled on purpose cos I have not
confirmed it works yet.
On Wed, Jul 11, 2012 at 4:47 AM, Richard Screene
<richard.screene@netdev.co.uk> wrote:
Hello,
Using mod_dingaling I am unable to get it to append the crypto details to
the session-accept Jingle stanza. The message is sent as:
<snip>
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
Official FreeSWITCH Sites
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-dev mailing list
FreeSWITCH-dev@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
--
Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm
MSN:anthony_minessale@hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com
IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org
googletalk:conf+888@conference.freeswitch.org
pstn:+19193869900
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
Official FreeSWITCH Sites
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-dev mailing list
FreeSWITCH-dev@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
Richard Screene
Senior Developer
NetDev Ltd & Drum Collaboration
+44 1273 936125
www.netdev.co.uk
www.thisisdrum.com
Registered in England and Wales
Company Number 04741258
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
Official FreeSWITCH Sites
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-dev mailing list
FreeSWITCH-dev@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
*Richard Screene **Senior Developer **NetDev Ltd & Drum Collaboration **+44 1273 936125 www.netdev.co.uk* *www.thisisdrum.com* <http://www.thisisdrum.com/>** *Registered in England and Wales *Company Number 04741258
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
Autocomplete FTL. SSRC not Darcy. Did not DoD On Jul 21, 2012 11:23 AM, "Anthony Minessale" <anthony.minessale@gmail.com> wrote:
Give latest git head unchanged a shot again of you have a chance. That Darcy issue was fixed IIRC. Also I DoD a few rounds of changes. Btw next time use Jira Jira.freeswitch.org its easier to track stuff. I almost lost this thread 3 pages deep on my email. On Jul 17, 2012 7:03 AM, "Richard Screene" <richard.screene@netdev.co.uk> wrote:
Just to give you all the information: A few days ago I hacked the RTP so that the RTP bug NEVER_CHANGE_SSRC_ON_MARKER was enabled. I removed it and it seemed to work yesterday. But, would this have anything to do with the "SRTP protection failed" error I was seeing today?
Thanks, Richard
On 16 Jul 2012, at 18:44, Anthony Minessale wrote:
ok so I pushed the flag to be set so now it should work out of the box, thanks for testing.
On Mon, Jul 16, 2012 at 8:05 AM, Richard Screene <richard.screene@netdev.co.uk> wrote:
Hello Anthony,
That seems to work better than my attempt!
Thanks for your help!
Richard
On 13 Jul 2012, at 23:19, Anthony Minessale wrote:
try patch in latest head minus your plc hack.
I have not made any changes to mod_dingaling yet but the core should
not try to decode stun now.
On Thu, Jul 12, 2012 at 11:58 AM, Richard Screene
<richard.screene@netdev.co.uk> wrote:
Hello Anthony,
Thanks for your quick response!
does it work then? I had it disabled on purpose cos I have not
confirmed it works yet.
That would explain it then :-)
I have managed to get SRTP working for the outbound voice path, but it
required a couple of hacks:
1) It was attempting to decrypt the STUN/ICE Bind Requests and failing.
I've bodged it for now by passing the SFF_PLC flag to
switch_rtp.c:read_rtp_packet() but I suspect this will stop inbound voice
paths from working!
2) In mod_dingaling.c:try_secure() the incorrect crypto_type is passed to
switch_rtp_add_crypto_key(). I suspect there is some confusion between the
crypto_type and crypto_send_type/crypto_recv_type members of
tech_pvt->transports. I've hacked it for now as shown below.
I hope this is useful to you. I'm going to try with the outbound voice path
tomorrow.
Regards,
Richard
For reference here are the diffs:
diff --git a/src/mod/endpoints/mod_dingaling/mod_dingaling.c
b/src/mod/endpoints/mod_dingaling/
index c47f589..1dda789 100644
--- a/src/mod/endpoints/mod_dingaling/mod_dingaling.c
+++ b/src/mod/endpoints/mod_dingaling/mod_dingaling.c
@@ -956,9 +956,11 @@ switch_status_t mdl_build_crypto(struct private_object
*tech_pvt, ldl_tran
char *p;
+/*
if (!switch_test_flag(tech_pvt, TFLAG_SECURE)) {
return SWITCH_STATUS_SUCCESS;
}
+*/
if (type == AES_CM_128_HMAC_SHA1_80) {
@@ -1056,10 +1058,13 @@ static switch_status_t mdl_add_crypto(struct
private_object *tech_pvt,
static void try_secure(struct private_object *tech_pvt,
ldl_transport_type_t ttype)
{
+/*
if (!switch_test_flag(tech_pvt, TFLAG_SECURE)) {
return;
}
+*/
+ tech_pvt->transports[ttype].crypto_type =
tech_pvt->transports[ttype].crypto_recv_type;
//if (tech_pvt->transports[ttype].crypto_type) {
switch_rtp_add_crypto_key(tech_pvt->transports[ttype].rtp_session,
diff --git a/src/switch_rtp.c b/src/switch_rtp.c
index 7d6ad29..99b4f83 100644
--- a/src/switch_rtp.c
+++ b/src/switch_rtp.c
@@ -3234,6 +3234,7 @@ static int rtp_common_read(switch_rtp_t *rtp_session,
switch_payload_t *p
if (read_pretriggered) {
read_pretriggered = 0;
} else {
+ *flags |= SFF_PLC;
status = read_rtp_packet(rtp_session,
&bytes, flags, SWITCH_TRU
//switch_log_printf(SWITCH_CHANNEL_SESSION_LOG(session), SWITCH
}
On 12 Jul 2012, at 00:13, Anthony Minessale wrote:
does it work then? I had it disabled on purpose cos I have not
confirmed it works yet.
On Wed, Jul 11, 2012 at 4:47 AM, Richard Screene
<richard.screene@netdev.co.uk> wrote:
Hello,
Using mod_dingaling I am unable to get it to append the crypto details to
the session-accept Jingle stanza. The message is sent as:
<snip>
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
Official FreeSWITCH Sites
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-dev mailing list
FreeSWITCH-dev@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
--
Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/
ClueCon http://www.cluecon.com/
Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm
MSN:anthony_minessale@hotmail.com
GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com
IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org
googletalk:conf+888@conference.freeswitch.org
pstn:+19193869900
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
Official FreeSWITCH Sites
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-dev mailing list
FreeSWITCH-dev@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
Richard Screene
Senior Developer
NetDev Ltd & Drum Collaboration
+44 1273 936125
www.netdev.co.uk
www.thisisdrum.com
Registered in England and Wales
Company Number 04741258
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting@freeswitch.org
http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server
Official FreeSWITCH Sites
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-dev mailing list
FreeSWITCH-dev@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire
AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
*Richard Screene **Senior Developer **NetDev Ltd & Drum Collaboration **+44 1273 936125 www.netdev.co.uk* *www.thisisdrum.com* <http://www.thisisdrum.com/>** *Registered in England and Wales *Company Number 04741258
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
Join Us At ClueCon - Aug 7-9, 2012
FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
participants (2)
-
Anthony Minessale
-
Richard Screene