[asterisk-bugs] [JIRA] (ASTERISK-19609) SRTP to RTP bridging with two crypto lines in SDP does not work
Matt Jordan (JIRA)
noreply at issues.asterisk.org
Wed Feb 25 16:03:35 CST 2015
[ https://issues.asterisk.org/jira/browse/ASTERISK-19609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=225115#comment-225115 ]
Matt Jordan commented on ASTERISK-19609:
----------------------------------------
I don't think this issue is a bug.
# I've tested with older models of phones that offer multiple crypto keys and - as I mentioned earlier in the history here - that works (and has worked for some time).
# Browsers no longer offer SDES-SRTP, since that's a MUST NOT implement in WebRTC. So we're unlikely to know what happened there at this point (or care).
As it is, I'm going to go ahead and close this out as "Can't Reproduce". If that happens to not be the case, and someone can reproduce an issue where an offer with multiple keys bridged with another channel causes a loss of audio, please comment on the issue and I'll be happy to re-open it.
> SRTP to RTP bridging with two crypto lines in SDP does not work
> ---------------------------------------------------------------
>
> Key: ASTERISK-19609
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-19609
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Channels/chan_sip/SRTP, Core/RTP
> Affects Versions: 1.8.10.1
> Reporter: Denis
> Assignee: Denis
> Attachments: full.log
>
>
> There are some issues with bridging incoming SRTP call with two crypto line in SDP to an outgoing RTP call.
> If I dial from a pbx the demo-congrats extension in the asterisk, then SRTP works and I can hear the demo sound.
> If I dial from a pbx an extension that gets dialed out to another sip channel, then the session gets established, but not SRTP/RTP flows through asterisk. I can see PBX sending SRTP, but no SRTP comes from asterisk to the PBX and no RTP at all on the dial out side.
> If I disable SRTP on the pbx and dial out, then bridging works just fine.
> It seams like asterisk can hanle two crypto line when calling internal demo-congrats extension, but can not bridge such call.
> {noformat}
> Incoming call from a PBX to asterisk with two crypto lines:
> <--- SIP read from TLS:10.62.150.23:49827 --->
> INVITE sip:+12345678 at 10.62.150.68;user=phone SIP/2.0
> FROM: "user"<sip:+87654321 at pbx.ngn.local;user=phone>;epid=89E6832516;tag=f834316a34
> TO: <sip:+12345678 at 10.62.150.68;user=phone>
> CSEQ: 17940 INVITE
> CALL-ID: 1374c9e4-8c72-4e19-898f-f928cfda3934
> MAX-FORWARDS: 70
> VIA: SIP/2.0/TLS 10.62.150.23:49827;branch=z9hG4bK38dcd6e3
> CONTACT: <sip:pbx.ngn.local:5067;transport=Tls;ms-opaque=f3721e55bc7f9ef9>
> CONTENT-LENGTH: 523
> SUPPORTED: 100rel
> CONTENT-TYPE: application/sdp
> ALLOW: ACK
> Allow: CANCEL,BYE,INVITE,PRACK,UPDATE
> v=0
> o=- 164 1 IN IP4 10.62.150.23
> s=session
> c=IN IP4 10.62.150.23
> b=CT:1000
> t=0 0
> m=audio 49188 RTP/SAVP 97 101 13 0 8
> c=IN IP4 10.62.150.23
> a=rtcp:49189
> a=label:Audio
> a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:D/WNrgIRlJGl/eNZLSThRIVb7LwMm6DMw+Uj6yfm|2^31|1:1
> a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:Q8Fp7ixgaQoY4oCSzPjIUm0Hp8ORT3Jw0KVX7mVA|2^31
> a=sendrecv
> a=rtpmap:97 RED/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=rtpmap:13 CN/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=ptime:20
> <------------->
> [Mar 30 18:02:44] DEBUG[15515] sip/sdp_crypto.c: SRTP policy activated
> [Mar 30 18:02:44] DEBUG[15515] chan_sip.c: Processing media-level (audio) SDP a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:D/WNrgIRlJGl/eNZLSThRIVb7LwMm6DMw+Uj6yfm|2^31|1:1... OK.
> [Mar 30 18:02:44] DEBUG[15515] chan_sip.c: We've already processed a crypto attribute, skipping 'crypto:2 AES_CM_128_HMAC_SHA1_80 inline:Q8Fp7ixgaQoY4oCSzPjIUm0Hp8ORT3Jw0KVX7mVA|2^31'
> [Mar 30 18:02:44] DEBUG[15515] chan_sip.c: Processing media-level (audio) SDP a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:Q8Fp7ixgaQoY4oCSzPjIUm0Hp8ORT3Jw0KVX7mVA|2^31... UNSUPPORTED.
> <--- Reliably Transmitting (no NAT) to 10.62.150.23:49827 --->
> SIP/2.0 200 OK^M
> Via: SIP/2.0/TLS 10.62.150.23:49827;branch=z9hG4bK38dcd6e3;received=10.62.150.23^M
> From: "user"<sip:+12345678 at pbx.ngn.local;user=phone>;epid=89E6832516;tag=f834316a34^M
> To: <sip:+87654321 at 10.62.150.68;user=phone>;tag=as6a1debea^M
> Call-ID: 1374c9e4-8c72-4e19-898f-f928cfda3934^M
> CSeq: 17940 INVITE^M
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH^M
> Supported: replaces, timer^M
> Contact: <sip:+87654321 at 10.62.150.68:5067;transport=TLS>^M
> Content-Type: application/sdp^M
> Content-Length: 347^M
> ^M
> v=0^M
> o=root 698426991 698426992 IN IP4 10.62.150.68^M
> s=session^M
> c=IN IP4 10.62.150.68^M
> t=0 0^M
> m=audio 19264 RTP/SAVP 8 101^M
> a=rtpmap:8 PCMA/8000^M
> a=rtpmap:101 telephone-event/8000^M
> a=fmtp:101 0-16^M
> a=silenceSupp:off - - - -^M
> a=ptime:20^M
> a=sendrecv^M
> a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:si8OjhGNpsinTR2T6M4WGtC/Zd2o83b6zosXRiO2^M
> <------------>
> [Mar 30 18:02:52] DEBUG[15516][C-00000006] chan_sip.c: Trying to put 'SIP/2.0 200' onto TLS socket destined for 10.62.150.23:49827
> [Mar 30 18:02:52] DEBUG[15516][C-00000006] features.c: bridge answer set, chan answer set
> [Mar 30 18:02:52] DEBUG[15516][C-00000006] features.c: Removing dialed interfaces datastore on SIP/dialout-00000009 since we're bridging
> {noformat}
> for SRTP to work with life_time parameter I commented out following lines in sdp_crypto.c:
> {code}
> // if (lifetime) {
> // ast_log(LOG_NOTICE, "Crypto life time unsupported: %s\n", attr);
> // continue;
> // }
> {code}
> Aterisk version: Asterisk SVN-trunk-r360886M
>
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list