Accepting an "optional" SRTP offer (crypto in RTP/AVP) and establishing SRTP
We are working with an endpoint that offers optional SRTP in the non-RFC-compliant way of an a=crypto attribute within RTP/AVP. I have told FreeSWITCH to allow this with rtp_allow_crypto_in_avp=true at the right place in the dialplan. Immediately after that in the dialplan I have to reject SRTP by using rtp_secure_media=forbidden, otherwise the call setup still fails. By setting the value to forbidden, the call does proceed unencrypted. We want FreeSWITCH to proceed with media encryption. Setting rtp_secure_media to any other value results in FreeSWITCH rejecting the offer like this: v=0 o=FreeSWITCH 1538660754 1538660755 IN IP4 192.168.100.104 s=FreeSWITCH c=IN IP4 192.168.100.104 t=0 0 m=audio 0 RTP/AVP 19 m=video 0 RTP/AVP 19 Is there anything else I can do to force SRTP in the answer? “The information transmitted is intended only for the person or entity to which it is addressed and may contain proprietary, business-confidential and/or privileged material. If you are not the intended recipient of this message you are hereby notified that any use, review, retransmission, dissemination, distribution, reproduction or any action taken in reliance upon this message is prohibited. If you received this in error, please contact the sender and delete the material from any computer.”
Can anyone offer insight into this matter? Endpoint offers RTP/AVP with crypto. We want Freeswitch to respond to the RTP/AVP and agree to the crypto and do SRTP.
On Oct 5, 2018, at 10:27 AM, William Simon <wsimon@stratusvideo.com> wrote:
We are working with an endpoint that offers optional SRTP in the non-RFC-compliant way of an a=crypto attribute within RTP/AVP.
I have told FreeSWITCH to allow this with rtp_allow_crypto_in_avp=true at the right place in the dialplan.
Immediately after that in the dialplan I have to reject SRTP by using rtp_secure_media=forbidden, otherwise the call setup still fails. By setting the value to forbidden, the call does proceed unencrypted.
We want FreeSWITCH to proceed with media encryption. Setting rtp_secure_media to any other value results in FreeSWITCH rejecting the offer like this:
v=0 o=FreeSWITCH 1538660754 1538660755 IN IP4 192.168.100.104 s=FreeSWITCH c=IN IP4 192.168.100.104 t=0 0 m=audio 0 RTP/AVP 19 m=video 0 RTP/AVP 19
Is there anything else I can do to force SRTP in the answer?
“The information transmitted is intended only for the person or entity to which it is addressed and may contain proprietary, business-confidential and/or privileged material. If you are not the intended recipient of this message you are hereby notified that any use, review, retransmission, dissemination, distribution, reproduction or any action taken in reliance upon this message is prohibited. If you received this in error, please contact the sender and delete the material from any computer.”
Take a close look to default.xml of vanilla dialplan. There are some examples of SDP parsing here, you can use them in condition to detect your special case. To enforce SRTP you just need to set rtp_secure_media. Don't forget to reread documentation on the last one: https://freeswitch.org/confluence/display/FREESWITCH/rtp_secure_media Alex On Thu, Oct 11, 2018 at 12:54 AM William Simon <wsimon@stratusvideo.com> wrote:
Can anyone offer insight into this matter?
Endpoint offers RTP/AVP with crypto. We want Freeswitch to respond to the RTP/AVP and agree to the crypto and do SRTP.
On Oct 5, 2018, at 10:27 AM, William Simon <wsimon@stratusvideo.com> wrote:
We are working with an endpoint that offers optional SRTP in the non-RFC-compliant way of an a=crypto attribute within RTP/AVP.
I have told FreeSWITCH to allow this with rtp_allow_crypto_in_avp=true at the right place in the dialplan.
Immediately after that in the dialplan I have to reject SRTP by using rtp_secure_media=forbidden, otherwise the call setup still fails. By setting the value to forbidden, the call does proceed unencrypted.
We want FreeSWITCH to proceed with media encryption. Setting rtp_secure_media to any other value results in FreeSWITCH rejecting the offer like this:
v=0 o=FreeSWITCH 1538660754 1538660755 IN IP4 192.168.100.104 s=FreeSWITCH c=IN IP4 192.168.100.104 t=0 0 m=audio 0 RTP/AVP 19 m=video 0 RTP/AVP 19
Is there anything else I can do to force SRTP in the answer?
“The information transmitted is intended only for the person or entity to which it is addressed and may contain proprietary, business-confidential and/or privileged material. If you are not the intended recipient of this message you are hereby notified that any use, review, retransmission, dissemination, distribution, reproduction or any action taken in reliance upon this message is prohibited. If you received this in error, please contact the sender and delete the material from any computer.” _________________________________________________________________________ Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://cluecon.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 https://freeswitch.com
-- Alex Sibyakin | Support Engineer FreeSWITCH Solutions | 17345 Civic Drive #2531 Brookfield, WI 53045 <https://maps.google.com/?q=17345+Civic+Drive+%232531+Brookfield,+WI+53045&entry=gmail&source=g> Email: alex@freeswitch.com Website: https://www.FreeSWITCH.com <https://www.freeswitch.com/> Need commercial support? Contact sales@freeswitch.com for details.
Unfortunately, that doesn't work. It gives the result I described: refusal of all media with m=audio 0 and m=video 0. On Oct 10, 2018, at 9:56 PM, Alexey Sibyakin <alex@freeswitch.com<mailto:alex@freeswitch.com>> wrote: Take a close look to default.xml of vanilla dialplan. There are some examples of SDP parsing here, you can use them in condition to detect your special case. To enforce SRTP you just need to set rtp_secure_media. Don't forget to reread documentation on the last one: https://freeswitch.org/confluence/display/FREESWITCH/rtp_secure_media Alex On Thu, Oct 11, 2018 at 12:54 AM William Simon <wsimon@stratusvideo.com<mailto:wsimon@stratusvideo.com>> wrote: Can anyone offer insight into this matter? Endpoint offers RTP/AVP with crypto. We want Freeswitch to respond to the RTP/AVP and agree to the crypto and do SRTP.
On Oct 5, 2018, at 10:27 AM, William Simon <wsimon@stratusvideo.com<mailto:wsimon@stratusvideo.com>> wrote:
We are working with an endpoint that offers optional SRTP in the non-RFC-compliant way of an a=crypto attribute within RTP/AVP.
I have told FreeSWITCH to allow this with rtp_allow_crypto_in_avp=true at the right place in the dialplan.
Immediately after that in the dialplan I have to reject SRTP by using rtp_secure_media=forbidden, otherwise the call setup still fails. By setting the value to forbidden, the call does proceed unencrypted.
We want FreeSWITCH to proceed with media encryption. Setting rtp_secure_media to any other value results in FreeSWITCH rejecting the offer like this:
v=0 o=FreeSWITCH 1538660754 1538660755 IN IP4 192.168.100.104 s=FreeSWITCH c=IN IP4 192.168.100.104 t=0 0 m=audio 0 RTP/AVP 19 m=video 0 RTP/AVP 19
Is there anything else I can do to force SRTP in the answer?
“The information transmitted is intended only for the person or entity to which it is addressed and may contain proprietary, business-confidential and/or privileged material. If you are not the intended recipient of this message you are hereby notified that any use, review, retransmission, dissemination, distribution, reproduction or any action taken in reliance upon this message is prohibited. If you received this in error, please contact the sender and delete the material from any computer.” _________________________________________________________________________ Professional FreeSWITCH Services sales@freeswitch.com<mailto:sales@freeswitch.com> https://freeswitch.com<https://freeswitch.com/> Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://cluecon.com<https://cluecon.com/> FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org<mailto:FreeSWITCH-users@lists.freeswitch.org> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users https://freeswitch.com<https://freeswitch.com/> -- Alex Sibyakin | Support Engineer FreeSWITCH Solutions | 17345 Civic Drive #2531 Brookfield, WI 53045<https://maps.google.com/?q=17345+Civic+Drive+%232531+Brookfield,+WI+53045&entry=gmail&source=g> Email: alex@freeswitch.com<mailto:alex@freeswitch.com> Website: https://www.FreeSWITCH.com<https://www.freeswitch.com/> Need commercial support? Contact sales@freeswitch.com<mailto:sales@freeswitch.com> for details. _________________________________________________________________________ Professional FreeSWITCH Services sales@freeswitch.com<mailto:sales@freeswitch.com> https://freeswitch.com Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://cluecon.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 https://freeswitch.com “The information transmitted is intended only for the person or entity to which it is addressed and may contain proprietary, business-confidential and/or privileged material. If you are not the intended recipient of this message you are hereby notified that any use, review, retransmission, dissemination, distribution, reproduction or any action taken in reliance upon this message is prohibited. If you received this in error, please contact the sender and delete the material from any computer.”
Are you trying this on 1.8.2 version?
On Oct 5, 2018, at 10:27 AM, William Simon <wsimon@stratusvideo.com> wrote:
We are working with an endpoint that offers optional SRTP in the non-RFC-compliant way of an a=crypto attribute within RTP/AVP.
I have told FreeSWITCH to allow this with rtp_allow_crypto_in_avp=true at the right place in the dialplan.
Immediately after that in the dialplan I have to reject SRTP by using rtp_secure_media=forbidden, otherwise the call setup still fails. By setting the value to forbidden, the call does proceed unencrypted.
We want FreeSWITCH to proceed with media encryption. Setting rtp_secure_media to any other value results in FreeSWITCH rejecting the offer like this:
v=0 o=FreeSWITCH 1538660754 1538660755 IN IP4 192.168.100.104 s=FreeSWITCH c=IN IP4 192.168.100.104 t=0 0 m=audio 0 RTP/AVP 19 m=video 0 RTP/AVP 19
Is there anything else I can do to force SRTP in the answer?
We are on 1.6.20.
On Oct 12, 2018, at 6:00 PM, Michael Jerris <mike@jerris.com> wrote:
Are you trying this on 1.8.2 version?
On Oct 5, 2018, at 10:27 AM, William Simon <wsimon@stratusvideo.com> wrote:
We are working with an endpoint that offers optional SRTP in the non-RFC-compliant way of an a=crypto attribute within RTP/AVP.
I have told FreeSWITCH to allow this with rtp_allow_crypto_in_avp=true at the right place in the dialplan.
Immediately after that in the dialplan I have to reject SRTP by using rtp_secure_media=forbidden, otherwise the call setup still fails. By setting the value to forbidden, the call does proceed unencrypted.
We want FreeSWITCH to proceed with media encryption. Setting rtp_secure_media to any other value results in FreeSWITCH rejecting the offer like this:
v=0 o=FreeSWITCH 1538660754 1538660755 IN IP4 192.168.100.104 s=FreeSWITCH c=IN IP4 192.168.100.104 t=0 0 m=audio 0 RTP/AVP 19 m=video 0 RTP/AVP 19
Is there anything else I can do to force SRTP in the answer?
_________________________________________________________________________ Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://cluecon.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 https://freeswitch.com
“The information transmitted is intended only for the person or entity to which it is addressed and may contain proprietary, business-confidential and/or privileged material. If you are not the intended recipient of this message you are hereby notified that any use, review, retransmission, dissemination, distribution, reproduction or any action taken in reliance upon this message is prohibited. If you received this in error, please contact the sender and delete the material from any computer.”
Michael, are you aware of a bug that would cause this behavior in 1.6.20? Just trying to narrow down whether we are up against a bug or a configuration error on our part.
On Oct 12, 2018, at 6:00 PM, Michael Jerris <mike@jerris.com> wrote:
Are you trying this on 1.8.2 version?
On Oct 5, 2018, at 10:27 AM, William Simon <wsimon@stratusvideo.com> wrote:
We are working with an endpoint that offers optional SRTP in the non-RFC-compliant way of an a=crypto attribute within RTP/AVP.
I have told FreeSWITCH to allow this with rtp_allow_crypto_in_avp=true at the right place in the dialplan.
Immediately after that in the dialplan I have to reject SRTP by using rtp_secure_media=forbidden, otherwise the call setup still fails. By setting the value to forbidden, the call does proceed unencrypted.
We want FreeSWITCH to proceed with media encryption. Setting rtp_secure_media to any other value results in FreeSWITCH rejecting the offer like this:
v=0 o=FreeSWITCH 1538660754 1538660755 IN IP4 192.168.100.104 s=FreeSWITCH c=IN IP4 192.168.100.104 t=0 0 m=audio 0 RTP/AVP 19 m=video 0 RTP/AVP 19
Is there anything else I can do to force SRTP in the answer?
_________________________________________________________________________ Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://cluecon.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 https://freeswitch.com
“The information transmitted is intended only for the person or entity to which it is addressed and may contain proprietary, business-confidential and/or privileged material. If you are not the intended recipient of this message you are hereby notified that any use, review, retransmission, dissemination, distribution, reproduction or any action taken in reliance upon this message is prohibited. If you received this in error, please contact the sender and delete the material from any computer.”
1.6.20 is unsupported now that 1.8 is out On Tue, Oct 16, 2018 at 1:55 PM William Simon <wsimon@stratusvideo.com> wrote:
Michael, are you aware of a bug that would cause this behavior in 1.6.20? Just trying to narrow down whether we are up against a bug or a configuration error on our part.
On Oct 12, 2018, at 6:00 PM, Michael Jerris <mike@jerris.com> wrote:
Are you trying this on 1.8.2 version?
On Oct 5, 2018, at 10:27 AM, William Simon <wsimon@stratusvideo.com> wrote:
We are working with an endpoint that offers optional SRTP in the non-RFC-compliant way of an a=crypto attribute within RTP/AVP.
I have told FreeSWITCH to allow this with rtp_allow_crypto_in_avp=true at the right place in the dialplan.
Immediately after that in the dialplan I have to reject SRTP by using rtp_secure_media=forbidden, otherwise the call setup still fails. By setting the value to forbidden, the call does proceed unencrypted.
We want FreeSWITCH to proceed with media encryption. Setting rtp_secure_media to any other value results in FreeSWITCH rejecting the offer like this:
v=0 o=FreeSWITCH 1538660754 1538660755 IN IP4 192.168.100.104 s=FreeSWITCH c=IN IP4 192.168.100.104 t=0 0 m=audio 0 RTP/AVP 19 m=video 0 RTP/AVP 19
Is there anything else I can do to force SRTP in the answer?
_________________________________________________________________________ Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://cluecon.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 https://freeswitch.com
“The information transmitted is intended only for the person or entity to which it is addressed and may contain proprietary, business-confidential and/or privileged material. If you are not the intended recipient of this message you are hereby notified that any use, review, retransmission, dissemination, distribution, reproduction or any action taken in reliance upon this message is prohibited. If you received this in error, please contact the sender and delete the material from any computer.” _________________________________________________________________________ Professional FreeSWITCH Services sales@freeswitch.com https://freeswitch.com
Official FreeSWITCH Sites https://freeswitch.com/oss https://freeswitch.org/confluence https://cluecon.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 https://freeswitch.com
-- Brian West | Co-founder and Developer Need Commercial support? email sales@freeswitch.com FreeSWITCH Solutions | 17345 Civic Drive #2531 Brookfield, WI 53045 <https://maps.google.com/?q=17345+Civic+Drive+%232531+Brookfield,+WI+53045&entry=gmail&source=g> Email: brian@freeswitch.com Mobile: 918-424-9378 Website: https://www.FreeSWITCH.com <https://www.freeswitch.com/> [image: https://www.facebook.com/signalwireinc?src=email] <https://www.facebook.com/freeswitch> [image: https://twitter.com/freeswitch] <https://twitter.com/freeswitch>
participants (4)
-
Alexey Sibyakin
-
Brian West
-
Michael Jerris
-
William Simon