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

Sat Nov 10 07:06:21 CST 2012

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

Joshua Colp commented on ASTERISK-19609:
----------------------------------------

SDP verification went into Canary and Dev which I think has introduced a regression exposed by the rather simplistic SDP that Asterisk returns. I have an issue open about it here:

http://code.google.com/p/webrtc/issues/detail?id=1079&colspec=ID%20Pri%20Mstone%20ReleaseBlock%20Area%20Status%20Owner%20Summary&start=200

> 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