Hello!
I have been experimenting with drop-in replacement of old "rtpproxy-ng" module with new "rtpengine". Wondering what is wrong in my configuration: there are no security attributes in rtpengine answer on RTP/SAVPF offer. Neither "fingerprint" (DTLS) nor "crypto" (SDES).
I used Firefox 29 during this test.
1. Here's original offer :
INVITE sip:user5@..... SIP/2.0
Via: SIP/2.0/WS 9mk86fpn2d35.invalid;branch=z9hG4bK1997444 Max-Forwards: 69 To: sip:user5@...... From: "user4" sip:user4@......;tag=dvf1co8urv Call-ID: phmq9o62cv21timhfnpf CSeq: 4233 INVITE Proxy-Authorization: Digest algorithm=MD5, username="user4", realm="......", nonce="U1o8H1NaOvP3wxegsYCKOJX7S7DV/r1N", uri="sip:user5@......", response="44e7b16c55d3237f63e04b3c0b194f45" Contact: sip:user4@ ......;gr=urn:uuid:c193bcd4-aa2e-47ef-a106-22e60f5fde9e;ob Allow: ACK,CANCEL,BYE,OPTIONS,INVITE,MESSAGE Content-Type: application/sdp Supported: path, outbound, gruu User-Agent: JsSIP 0.3.7 Content-Length: 607
v=0 o=Mozilla-SIPUA-29.0 15825 0 IN IP4 0.0.0.0 s=SIP Call t=0 0 a=ice-ufrag:2102f082 a=ice-pwd:8733e5248a7fb087b40ea45b3ca6f634 *a=fingerprint:sha-256 32:AA:85:DB:D8:3C:E6:C3:46:07:11:9E:9F:54:B9:42:7F:5C:37:5F:9D:D1:AD:19:22:A3:AC:9C:6C:A5:A6:CD* m=audio 62290 *RTP/SAVPF* 109 0 8 101 c=IN IP4 ..... a=rtpmap:109 opus/48000/2 a=ptime:20 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv .....
Here's the snippet for translation SRTP-RTP:
rtpengine_offer("force trust-address symmetric replace-origin replace-session-connection ICE=force_relay *RTP/AVP*");
2. Here's final answer (from rtpengine):
SIP/2.0 200 OK
Via: SIP/2.0/WS 9mk86fpn2d35.invalid;branch=z9hG4bK1997444 Record-Route: sip:......;lr;nat=yes Record-Route: sip:.....:15060;transport=udp;lr;ovid=3207d8cd Record-Route: sip:95f6551e81@.......:10080;transport=ws;lr;ovid=3207d8cd Contact: sip:user5@......1:49362 To: sip:user5@.....;tag=4d436110 From: "user4"sip:user4@....;tag=dvf1co8urv Call-ID: phmq9o62cv21timhfnpf CSeq: 4233 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp Supported: replaces, eventlist
User-Agent: X-Lite release 4.5.4 stamp 70864 Content-Length: 432
v=0 o=- 1398422264455879 3 IN IP4 ..... s=X-Lite 4 release 4.5.4 stamp 70864 c=IN IP4 ...... t=0 0 m=audio 30002 *RTP/SAVPF* 109 0 8 101 a=rtpmap:109 opus/48000/2 a=fmtp:109 useinbandfec=1 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=rtcp:30003 ....
Error from JsSIP:
{name: "INTERNAL_ERROR", message: "Could not negotiate answer SDP; cause =
*NO_DTLS_FINGERPRINT*", __exposedProps__: Object}
Here's the snippet for translation RTP-SRTP:
rtpengine_answer("force trust-address symmetric replace-origin replace-session-connection rtcp-mux-demux ICE=force *RTP/SAVPF* ");
There was another test with Chrome 34 with the same result.
Offer:
INVITE sip:user5@.... SIP/2.0 Via: SIP/2.0/WS ja9i6d3am6k8.invalid;branch=z9hG4bK6193236 Max-Forwards: 69 To: sip:user5@.... From: "user4" sip:user4@....;tag=jupqetdp1v Call-ID: 7jbhpjb4r4qt8m4s2pdb CSeq: 957 INVITE Proxy-Authorization: Digest algorithm=MD5, username="user4", realm=".....", nonce="U1pKZ1NaSTtLo2vjK9TGyBu6Axb+EtyN", uri="sip:user5@...", response="98f6275d3636664b611ff1411af982af" Contact: sip:user4@....;gr=urn:uuid:8cd4e797-7314-485f-b191-4a15a6581c42;ob Allow: ACK,CANCEL,BYE,OPTIONS,INVITE,MESSAGE Content-Type: application/sdp Supported: path, outbound, gruu User-Agent: JsSIP 0.3.7 Content-Length: 1586 v=0 o=- 7510391807340598328 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE audio a=msid-semantic: WMS ErnvtgCDe9aR6LWxNRgT83r0mxtyAV87LUxT m=audio 51672 *RTP/SAVPF *111 103 104 0 8 106 105 13 126 c=IN IP4 10.61.2.151 a=rtcp:51672 IN IP4 .... ...... a=ice-ufrag:EMn7uHfSS7ulRGU2 a=ice-pwd:FskTdhj7qT6ELP7uTIb+gquQ a=ice-options:google-ice *a=fingerprint:sha-256 46:6E:E0:18:4A:C5:06:A8:26:85:ED:FE:16:C1:86:5E:8D:BC:4D:D9:F2:1A:75:81:A1:A7:CE:5A:79:4D:B7:22*a=setup:actpass a=mid:audio a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=sendrecv a=rtcp-mux *a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:R6qaiU7Cm471zNF6f3Q87TyXbHjEt/VhLgUgY2ZZ a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:lch+mfN/hi9QmseWu+ss1M2vA8mwRh8GQYChaJvc* a=rtpmap:111 opus/48000/2 .... Answer:
SIP/2.0 200 OK Via: SIP/2.0/WS ja9i6d3am6k8.invalid;branch=z9hG4bK6193236
Record-Route: sip:...;lr;nat=yes Record-Route: sip:....:15060;transport=udp;lr;ovid=3207d8cd Record-Route: sip:712a450958@...:10080;transport=ws;lr;ovid=3207d8cd Contact: < sip:user5@10.61.2.151:49362> To: sip:user5@....;tag=b8c8ee57 From: "user4"sip:user4@...;tag=jupqetdp1v Call-ID: 7jbhpjb4r4qt8m4s2pdb CSeq: 957 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp Supported: replaces, eventlist User-Agent: X-Lite release 4.5.4 stamp 70864 Content-Length: 432 v=0 o=- 1398425917116411 3 IN IP4 ... s=X-Lite 4 release 4.5.4 stamp 70864 c=IN IP4 .... t=0 0 m=audio 30006 *RTP/SAVPF* 111 0 8 126 a=rtpmap:111 opus/48000/2 a=fmtp:111 useinbandfec=1 a=rtpmap:126 telephone-event/8000 a=fmtp:126 0-15 a=sendrecv a=rtcp:30007 ....
Error is JsSIP:
Failed to set remote answer sdp: Called with a SDP without crypto enabled
Any help on this issue would be greatly appreciated!
best regards, Alexey
Hi,
Can you check if the original offer contains an "a=setup:actpass" attribute? I remember Firefox having a problem with this in some version. This attribute is required for DTLS-SRTP and Firefox was not sending it. It's fixed in later versions.
cheers
On 04/25/14 07:51, Alexey Rybalko wrote:
Hello!
I have been experimenting with drop-in replacement of old "rtpproxy-ng" module with new "rtpengine". Wondering what is wrong in my configuration: there are no security attributes in rtpengine answer on RTP/SAVPF offer. Neither "fingerprint" (DTLS) nor "crypto" (SDES).
I used Firefox 29 during this test.
Here's original offer :
INVITE sip:user5@..... SIP/2.0 Via: SIP/2.0/WS 9mk86fpn2d35.invalid;branch=z9hG4bK1997444 Max-Forwards: 69 To: sip:user5@...... From: "user4" sip:user4@......;tag=dvf1co8urv Call-ID: phmq9o62cv21timhfnpf CSeq: 4233 INVITE Proxy-Authorization: Digest algorithm=MD5, username="user4", realm="......", nonce="U1o8H1NaOvP3wxegsYCKOJX7S7DV/r1N", uri="sip:user5@......", response="44e7b16c55d3237f63e04b3c0b194f45" Contact: sip:user4@......;gr=urn:uuid:c193bcd4-aa2e-47ef-a106-22e60f5fde9e;ob Allow: ACK,CANCEL,BYE,OPTIONS,INVITE,MESSAGE Content-Type: application/sdp Supported: path, outbound, gruu User-Agent: JsSIP 0.3.7 Content-Length: 607
v=0 o=Mozilla-SIPUA-29.0 15825 0 IN IP4 0.0.0.0 s=SIP Call t=0 0 a=ice-ufrag:2102f082 a=ice-pwd:8733e5248a7fb087b40ea45b3ca6f634 *a=fingerprint:sha-256 32:AA:85:DB:D8:3C:E6:C3:46:07:11:9E:9F:54:B9:42:7F:5C:37:5F:9D:D1:AD:19:22:A3:AC:9C:6C:A5:A6:CD* m=audio 62290 *RTP/SAVPF* 109 0 8 101 c=IN IP4 ..... a=rtpmap:109 opus/48000/2 a=ptime:20 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv .....
Here's the snippet for translation SRTP-RTP:
rtpengine_offer("force trust-address symmetric replace-origin replace-session-connection ICE=force_relay *RTP/AVP*");
Here's final answer (from rtpengine):
SIP/2.0 200 OK Via: SIP/2.0/WS 9mk86fpn2d35.invalid;branch=z9hG4bK1997444 Record-Route: sip:......;lr;nat=yes Record-Route: sip:.....:15060;transport=udp;lr;ovid=3207d8cd Record-Route: sip:95f6551e81@.......:10080;transport=ws;lr;ovid=3207d8cd Contact: sip:user5@......1:49362 To: sip:user5@.....;tag=4d436110 From: "user4"sip:user4@....;tag=dvf1co8urv Call-ID: phmq9o62cv21timhfnpf CSeq: 4233 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp Supported: replaces, eventlist
User-Agent: X-Lite release 4.5.4 stamp 70864 Content-Length: 432
v=0 o=- 1398422264455879 3 IN IP4 ..... s=X-Lite 4 release 4.5.4 stamp 70864 c=IN IP4 ...... t=0 0 m=audio 30002 *RTP/SAVPF* 109 0 8 101 a=rtpmap:109 opus/48000/2 a=fmtp:109 useinbandfec=1 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=rtcp:30003 ....
Error from JsSIP:
{name: "INTERNAL_ERROR", message: "Could not negotiate answer SDP; cause = *NO_DTLS_FINGERPRINT*", __exposedProps__: Object}Here's the snippet for translation RTP-SRTP:
rtpengine_answer("force trust-address symmetric replace-origin replace-session-connection rtcp-mux-demux ICE=force *RTP/SAVPF* ");
There was another test with Chrome 34 with the same result.
Offer:
INVITE sip:user5@.... SIP/2.0 Via: SIP/2.0/WS ja9i6d3am6k8.invalid;branch=z9hG4bK6193236 Max-Forwards: 69 To: sip:user5@.... From: "user4" sip:user4@....;tag=jupqetdp1v Call-ID: 7jbhpjb4r4qt8m4s2pdb CSeq: 957 INVITE Proxy-Authorization: Digest algorithm=MD5, username="user4", realm=".....", nonce="U1pKZ1NaSTtLo2vjK9TGyBu6Axb+EtyN", uri="sip:user5@...", response="98f6275d3636664b611ff1411af982af" Contact: sip:user4@....;gr=urn:uuid:8cd4e797-7314-485f-b191-4a15a6581c42;ob Allow: ACK,CANCEL,BYE,OPTIONS,INVITE,MESSAGE Content-Type: application/sdp Supported: path, outbound, gruu User-Agent: JsSIP 0.3.7 Content-Length: 1586 v=0 o=- 7510391807340598328 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE audio a=msid-semantic: WMS ErnvtgCDe9aR6LWxNRgT83r0mxtyAV87LUxT m=audio 51672 *RTP/SAVPF *111 103 104 0 8 106 105 13 126 c=IN IP4 10.61.2.151 a=rtcp:51672 IN IP4 .... ...... a=ice-ufrag:EMn7uHfSS7ulRGU2 a=ice-pwd:FskTdhj7qT6ELP7uTIb+gquQ a=ice-options:google-ice *a=fingerprint:sha-256 46:6E:E0:18:4A:C5:06:A8:26:85:ED:FE:16:C1:86:5E:8D:BC:4D:D9:F2:1A:75:81:A1:A7:CE:5A:79:4D:B7:22* a=setup:actpass a=mid:audio a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=sendrecv a=rtcp-mux *a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:R6qaiU7Cm471zNF6f3Q87TyXbHjEt/VhLgUgY2ZZ a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:lch+mfN/hi9QmseWu+ss1M2vA8mwRh8GQYChaJvc* a=rtpmap:111 opus/48000/2 .... Answer:
SIP/2.0 200 OK Via: SIP/2.0/WS ja9i6d3am6k8.invalid;branch=z9hG4bK6193236 Record-Route: <sip:...;lr;nat=yes> Record-Route: <sip:....:15060;transport=udp;lr;ovid=3207d8cd> Record-Route: <sip:712a450958@...:10080;transport=ws;lr;ovid=3207d8cd> Contact: <sip:user5@10.61.2.151:49362 <http://sip:user5@10.61.2.151:49362>> To: <sip:user5@....>;tag=b8c8ee57 From: "user4"<sip:user4@...>;tag=jupqetdp1v Call-ID: 7jbhpjb4r4qt8m4s2pdb CSeq: 957 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp Supported: replaces, eventlist User-Agent: X-Lite release 4.5.4 stamp 70864 Content-Length: 432 v=0 o=- 1398425917116411 3 IN IP4 ... s=X-Lite 4 release 4.5.4 stamp 70864 c=IN IP4 .... t=0 0 m=audio 30006 *RTP/SAVPF* 111 0 8 126 a=rtpmap:111 opus/48000/2 a=fmtp:111 useinbandfec=1 a=rtpmap:126 telephone-event/8000 a=fmtp:126 0-15 a=sendrecv a=rtcp:30007 ....Error is JsSIP:
Failed to set remote answer sdp: Called with a SDP without crypto enabledAny help on this issue would be greatly appreciated!
best regards, Alexey
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hi, Richard!
Thank you for quick feedback!
There is no such attribute in SDP payload from the latest Mozilla (v.29).
v=0 o=Mozilla-SIPUA-29.0 371 0 IN IP4 0.0.0.0 s=SIP Call t=0 0 a=ice-ufrag:083b4837 a=ice-pwd:dac461d48770be5e1dae6c450e144bf3 a=fingerprint:sha-256 C3:AA:DB:75:D7:60:FC:B6:94:A7:81:4F:74:A2:FF:44:4B:17:AE:D3:64:37:37:D1:AC:1A:F5:D4:86:1E:4F:7A m=audio 52775 RTP/SAVPF 109 0 8 101 c=IN IP4 192.168.0.101 a=rtpmap:109 opus/48000/2 a=ptime:20 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=setup:actpass a=candidate:0 1 UDP 2130444543 192.168.0.101 52775 typ host a=candidate:0 2 UDP 2130444542 192.168.0.101 63139 typ host a=rtcp-mux
But it presents in SDP from Chrome (v.34)
v=0 o=- 1634904605592690072 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE audio a=msid-semantic: WMS C8ATLgPd2jIcc5q799L9XU3rTROMajedYbdI m=audio 51817 RTP/SAVPF 111 103 104 0 8 106 105 13 126 c=IN IP4 192.168.0.101 a=rtcp:51817 IN IP4 192.168.0.101 a=candidate:3350409123 1 udp 2122260223 192.168.0.101 51817 typ host generation 0 a=candidate:3350409123 2 udp 2122260223 192.168.0.101 51817 typ host generation 0 a=candidate:2301678419 1 tcp 1518280447 192.168.0.101 0 typ host generation 0 a=candidate:2301678419 2 tcp 1518280447 192.168.0.101 0 typ host generation 0 a=ice-ufrag:WyHALLFH6CaQmCIA a=ice-pwd:9BMkH9d7D9pfSjZmLSkunxrW a=ice-options:google-ice a=fingerprint:sha-256 46:6E:E0:18:4A:C5:06:A8:26:85:ED:FE:16:C1:86:5E:8D:BC:4D:D9:F2:1A:75:81:A1:A7:CE:5A:79:4D:B7:22 *a=setup:actpass* a=mid:audio a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=sendrecv a=rtcp-mux a=crypto:0 AES_CM_128_HMAC_SHA1_32 inline:cDj0wVDUUZ/1etNd9MFQjeqwn/ii3RsxQLraXUln a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:KKzZx0iwM2udfGNv+pBoB/BDVBvsFsMcQczVZDOQ ....
No success for both browsers. It's should be noticed that Chrome provides both SDES ("crypto") and DTLS ("fingerprint"+"setup:actpass") attibutes (does DTLS have priority in a such case?). However rtpengine doesn't provide such SRTP data. May be any suggestions?
kind regards, Alexey
2014-04-25 18:02 GMT+04:00 Richard Fuchs rfuchs@sipwise.com:
Hi,
Can you check if the original offer contains an "a=setup:actpass" attribute? I remember Firefox having a problem with this in some version. This attribute is required for DTLS-SRTP and Firefox was not sending it. It's fixed in later versions.
cheers
On 04/26/14 17:32, Alexey Rybalko wrote:
No success for both browsers. It's should be noticed that Chrome provides both SDES ("crypto") and DTLS ("fingerprint"+"setup:actpass") attibutes (does DTLS have priority in a such case?). However rtpengine doesn't provide such SRTP data. May be any suggestions?
It can't work with Firefox if it doesn't use the a=setup attribute, but it should work with Chrome. If it doesn't, please provide the complete syslog output from rtpengine for such a call.
cheers
"Failed to set remote answer sdp: Called with a SDP without crypto enabled" (Chrome)
RTPEngine log is attached.
regards, /A
2014-04-27 2:09 GMT+04:00 Richard Fuchs rfuchs@sipwise.com:
On 04/26/14 17:32, Alexey Rybalko wrote:
No success for both browsers. It's should be noticed that Chrome provides both SDES ("crypto") and DTLS ("fingerprint"+"setup:actpass") attibutes (does DTLS have priority in a such case?). However rtpengine doesn't provide such SRTP data. May be any suggestions?
It can't work with Firefox if it doesn't use the a=setup attribute, but it should work with Chrome. If it doesn't, please provide the complete syslog output from rtpengine for such a call.
cheers
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
On 04/26/14 18:24, Alexey Rybalko wrote:
"Failed to set remote answer sdp: Called with a SDP without crypto enabled" (Chrome)
RTPEngine log is attached.
Please try again with ICE=force instead of force_relay, or (more conservatively) ICE=remove in the offer and ICE=force in the answer. You will probably also need the option "rtcp-mux-demux" in the offer, as your non-RTC endpoint doesn't support rtcp-mux and Chrome isn't likely to be happy with its rtcp-mux offer being declined.
To answer your previous question: DTLS-SRTP does take priority over SDES, and what you should see in the outgoing answer is only the setup and fingerprint attributes, but no crypto attributes.
cheers
Hello!
2014-04-27 2:42 GMT+04:00 Richard Fuchs rfuchs@sipwise.com:
Please try again with ICE=force instead of force_relay, or (more conservatively) ICE=remove in the offer and ICE=force in the answer. You will probably also need the option "rtcp-mux-demux" in the offer, as your non-RTC endpoint doesn't support rtcp-mux and Chrome isn't likely to be happy with its rtcp-mux offer being declined.
Richard, I've tried the options you had recommended: "ICE=force" in offer and answer ("ICE=remove" in the offer works well too). The audio call was negotiated and traversed. Thank you very much!
2014-04-27 9:27 GMT+04:00 Juha Heinanen jh@tutpro.com:
Alexey Rybalko writes:
There is no such attribute in SDP payload from the latest Mozilla (v.29).
there *is* a=setup:actpass in above.
Juha,
thanks for the hint! Yesterday it was too late at night, I had missed that string J Today made a call from Mozilla to softphone.
regards, Alexey
Alexey Rybalko writes:
There is no such attribute in SDP payload from the latest Mozilla (v.29).
v=0 o=Mozilla-SIPUA-29.0 371 0 IN IP4 0.0.0.0 s=SIP Call t=0 0 a=ice-ufrag:083b4837 a=ice-pwd:dac461d48770be5e1dae6c450e144bf3 a=fingerprint:sha-256 C3:AA:DB:75:D7:60:FC:B6:94:A7:81:4F:74:A2:FF:44:4B:17:AE:D3:64:37:37:D1:AC:1A:F5:D4:86:1E:4F:7A m=audio 52775 RTP/SAVPF 109 0 8 101 c=IN IP4 192.168.0.101 a=rtpmap:109 opus/48000/2 a=ptime:20 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=sendrecv a=setup:actpass a=candidate:0 1 UDP 2130444543 192.168.0.101 52775 typ host a=candidate:0 2 UDP 2130444542 192.168.0.101 63139 typ host a=rtcp-mux
there *is* a=setup:actpass in above.
-- juha
Can you check if the original offer contains an "a=setup:actpass" attribute? I remember Firefox having a problem with this in some version. This attribute is required for DTLS-SRTP and Firefox was not sending it. It's fixed in later versions.
-
Alexey Rybalko -
Juha Heinanen -
Richard Fuchs