[asterisk-bugs] [JIRA] (ASTERISK-19609) SRTP to RTP bridging with two crypto lines in SDP does not work
Alex A. Welzl (JIRA)
noreply at issues.asterisk.org
Wed Mar 11 06:47:35 CDT 2015
[ https://issues.asterisk.org/jira/browse/ASTERISK-19609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=225328#comment-225328 ]
Alex A. Welzl commented on ASTERISK-19609:
------------------------------------------
The issue is reproducible – at least in Asterisk 1.8. We were facing the same behaviour. Our phones are being configured using TLS/SRTP towards the Asterisk whereas external calls are being terminated via UDP/RTP to the carrier. Internal calls worked without any issues, external calls had sometimes problems as described in that issue earlier. Sometimes, that was the real trouble! By switching back the phones to non-encrypted communication, it worked without any trouble – but that was not a solution.
After deep investigation with wireshark and perfect assistance from our carrier, we found out that if the carrier’s RTP stream starts very quick after the 200OK (connect) and there was no early media possibility before, because of missing 183 with sdp (as this was not generated at the destination PBX), we are facing the RTP issue again. We are talking about some milliseconds too early here. As a quick fix, our carrier configured “a pause” on his side and waits until Asterisk starts sending RTP packets. The downside of the hotfix is that T.38 faxes won’t work.
Message Flow:
Asterisk Carrier
Invite->
<-100 Trying
<-200 OK with SDP
ACK->
So please start re-investigating the issue.
> 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