[asterisk-dev] s?rtp via SIP/TLS/TCP

James Cloos cloos at jhcloos.com
Tue Apr 21 10:22:00 CDT 2015


>>>>> "MJ" == Matthew Jordan <mjordan at digium.com> writes:

MJ> Guessing at what is occurring here: your phone is probably offering
MJ> optional/optimistic encryption. While optimistic encryption is
MJ> supported by chan_pjsip, currently, an offer with RTP/AVPF with crypto
MJ> attributes is currently rejected by chan_sip. See
MJ> https://issues.asterisk.org/jira/browse/ASTERISK-23989.

I tried each of off, mandatory and optional with identical results.

One example sdp, when the phone is set to mandatory (and with the ip redacted) is:

,----
| v=0       
| o=root 1828819213 1828819213 IN IP4 $IPADDR
| s=call    
| c=IN IP4 $IPADDR
| t=0 0     
| m=audio 62752 RTP/SAVP 9 0 18 101
| a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:CxgVn40i6OlTQXZOL7TqKxFIw3gsG8ycJg5TPQ/O
| a=direction:both
| a=rtpmap:9 G722/8000
| a=rtpmap:0 PCMU/8000
| a=rtpmap:18 G729/8000
| a=fmtp:18 annexb=no
| a=rtpmap:101 telephone-event/8000
| a=fmtp:101 0-15
| a=ptime:20
| a=sendrecv
`----

The optional cases had the RTP/SAVP block followed by an RTP/AVP block,
such as:

,----
| v=0
| o=root 801103701 801103701 IN IP4 $IPADDR
| s=call
| c=IN IP4 $IPADDR
| t=0 0
| m=audio 60420 RTP/SAVP 9 0 18 101
| a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:9kqlryikwVVgTiCPRKvpIYx4Ffv4aveN0LV6GK4g
| a=direction:both
| a=rtpmap:9 G722/8000
| a=rtpmap:0 PCMU/8000
| a=rtpmap:18 G729/8000
| a=fmtp:18 annexb=no
| a=rtpmap:101 telephone-event/8000
| a=fmtp:101 0-15
| a=ptime:20
| a=sendrecv
| m=audio 60420 RTP/AVP 9 0 18 101
| a=direction:both
| a=rtpmap:9 G722/8000
| a=rtpmap:0 PCMU/8000
| a=rtpmap:18 G729/8000
| a=fmtp:18 annexb=no
| a=rtpmap:101 telephone-event/8000
| a=fmtp:101 0-15
| a=ptime:20
| a=sendrecv
`----

I also made attempts w/o any srtp.

None worked w/o force_avp=yes.

I did, as you wrote, ignore the non-primary stream in the optional case:

,----
| Declining non-primary audio stream: audio 60420 RTP/AVP 9 0 18 101
`----

But the failure still occurred when no SAVP stream was sent.

I tested from anther phone on the same lan, which happened to be
registered over tcp instead of over tls, and that worked w/o any
force_avp setting in sip.conf.

TCP vs TLS was the only difference.  Until I added force_avp=yes, then
the both worked.

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6



More information about the asterisk-dev mailing list