[asterisk-bugs] [JIRA] (ASTERISK-19609) SRTP to RTP bridging with two crypto lines in SDP does not work

Fri Nov 9 07:53:21 CST 2012

    [ https://issues.asterisk.org/jira/browse/ASTERISK-19609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=199485#comment-199485 ] 

José Luis Millán commented on ASTERISK-19609:
---------------------------------------------

Hi all,

This issue arises now using WebRTC, where multiple crypto lines are offered. Canary version of Chrome does it and it will do in next stable releases (And guess all other coming web browser implementations). Perhaps is time to 'fix'/'feature' multiple key management?

Any other debug information needed?

> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira