SRTP+TLS SIP extensions stops after a few weeks

Hi there.

I have about 300 SIP extensions (yealink T22) with TLS and SRTP enabled registered to asterisk 11.17.1 and everything seems to works as it should for few weeks.

BUT For a reason a can’t put my finger on the extensions with TLS and SRTP stop working while the others using udp still do. After that whenever a secure extension tries to start a call I see the following log lines:

[Jun 5 11:27:28] VERBOSE[28837][C-0001dfcb] netsock2.c: == Using SIP VIDEO TOS bits 136 [Jun 5 11:27:28] VERBOSE[28837][C-0001dfcb] netsock2.c: == Using SIP VIDEO CoS mark 6 [Jun 5 11:27:28] VERBOSE[28837][C-0001dfcb] netsock2.c: == Using SIP RTP TOS bits 184 [Jun 5 11:27:28] VERBOSE[28837][C-0001dfcb] netsock2.c: == Using SIP RTP CoS mark 5 [Jun 5 11:27:28] WARNING[28837][C-0001dfcb] chan_sip.c: Rejecting secure audio stream without encryption details: audio 11796 RTP/SAVP 0 8 18 101

A core restart fixes the problem until it happens again (It happened 2 times already) and saddly I couldn’t get debug on both ocasions.

Any thought on how to fix this?

Thankx!

SIP settings:

Global Settings:
----------------
  UDP Bindaddress:        0.0.0.0:5060
  TCP SIP Bindaddress:    Disabled
  TLS SIP Bindaddress:    aa.bb.cc.dd:5061
  Videosupport:           Yes
  Textsupport:            No
  Ignore SDP sess. ver.:  No
  AutoCreate Peer:        Off
  Match Auth Username:    No
  Allow unknown access:   Yes
  Allow subscriptions:    Yes
  Allow overlap dialing:  Yes
  Allow promisc. redir:   No
  Enable call counters:   Yes
  SIP domain support:     No
  Realm. auth:            No
  Our auth realm          asterisk
  Use domains as realms:  No
  Call to non-local dom.: Yes
  URI user is phone no:   No
  Always auth rejects:    Yes
  Direct RTP setup:       No
  User Agent:             Asterisk PBX 11.17.1
  SDP Session Name:       Asterisk PBX 11.17.1
  SDP Owner Name:         root
  Reg. context:           (not set)
  Regexten on Qualify:    No
  Trust RPID:             No
  Send RPID:              No
  Legacy userfield parse: No
  Send Diversion:         Yes
  Caller ID:              Unknown
  From: Domain:           
  Record SIP history:     Off
  Call Events:            Off
  Auth. Failure Events:   Off
  T.38 support:           No
  T.38 EC mode:           Unknown
  T.38 MaxDtgrm:          4294967295
  SIP realtime:           Disabled
  Qualify Freq :          1200000 ms
  Q.850 Reason header:    No
  Store SIP_CAUSE:        No

Network QoS Settings:
---------------------------
  IP ToS SIP:             CS3
  IP ToS RTP audio:       EF
  IP ToS RTP video:       AF41
  IP ToS RTP text:        CS0
  802.1p CoS SIP:         4
  802.1p CoS RTP audio:   5
  802.1p CoS RTP video:   6
  802.1p CoS RTP text:    5
  Jitterbuffer enabled:   No

Network Settings:
---------------------------
  SIP address remapping:  Disabled, no localnet list
  Externhost:             <none>
  Externaddr:             (null)
  Externrefresh:          10

Global Signalling Settings:
---------------------------
  Codecs:                 (gsm|ulaw|alaw|h263p|h264)
  Codec Order:            alaw:20,ulaw:20,gsm:20,h263p:0,h264:0
  Relax DTMF:             No
  RFC2833 Compensation:   No
  Symmetric RTP:          No
  Compact SIP headers:    No
  RTP Keepalive:          0 (Disabled)
  RTP Timeout:            240 
  RTP Hold Timeout:       600 
  MWI NOTIFY mime type:   application/simple-message-summary
  DNS SRV lookup:         Yes
  Pedantic SIP support:   Yes
  Reg. min duration       60 secs
  Reg. max duration:      3600 secs
  Reg. default duration:  120 secs
  Sub. min duration       60 secs
  Sub. max duration:      3600 secs
  Outbound reg. timeout:  20 secs
  Outbound reg. attempts: 0
  Outbound reg. retry 403:0
  Notify ringing state:   Yes
    Include CID:          No
  Notify hold state:      Yes
  SIP Transfer mode:      open
  Max Call Bitrate:       384 kbps
  Auto-Framing:           No
  Outb. proxy:            <not set> 
  Session Timers:         Refuse
  Session Refresher:      uas
  Session Expires:        1800 secs
  Session Min-SE:         90 secs
  Timer T1:               500
  Timer T1 minimum:       100
  Timer B:                32000
  No premature media:     Yes
  Max forwards:           70

Default Settings:
-----------------
  Allowed transports:     UDP
  Outbound transport:	  UDP
  Context:                from-sip-external
  Record on feature:      automon
  Record off feature:     automon
  Force rport:            Auto (No)
  DTMF:                   rfc2833
  Qualify:                0
  Keepalive:              0
  Use ClientCode:         No
  Progress inband:        Never
  Language:               pt_BR
  Tone zone:              <Not set>
  MOH Interpret:          default
  MOH Suggest:            
  Voice Mail Extension:   *97

The diagnostic provided indicates that the fault lies with the other side, but you need to provide detailed SIP logging to go any deeper (although, taking the message at face value, it may only confirm the message and that the fault is with the remote system.

Nothing in sip.conf would result in such a delayed failure, so I haven’t checked that.

Yes, the actual SIP signaling is really needed here to see the SDP. If there really is no crypto attribute from the other side then it would be the remote endpoint. If there is then there could be some bug in the SDP parsing in Asterisk.

It’s strange that affects all the secure SIP extensions at the same time and none of the others (dahdi and non secure SIP), for that alone I would think the culprit would be asterisk.

I’ll try to get the SIP debug if it happens again so I can get more information and post here again.

Thank you all!

What’s your version of libsrtp? There were a number of strange call issues that resulted from libsrtp bugs. You might want to try the latest 1.5.x release from Cisco’s libsrtp github page [1] if instead you’re currently using your distro’s include libsrtp package.

[1] - github.com/cisco/libsrtp/tree/v1.5.2

Hi Malcolmd. I’m currently using libsrtp 1.4.4 from Cisco. I’m going to upgrade to 1.5.X and post the results here.

thanks!

The problem persists and this time I got to capture the sip debug output.

The failed call was made on the phone 3390 to the phone on the extension 3808 (both with TLS and SRTP enabled). It is possible to see that the crypto attribute are set, and that asterisk didn’t accept the call (the other phone never got anything).

<--- SIP read from TLS:10.0.0.2:60930 --->
INVITE sip:3808@10.0.0.1:5061 SIP/2.0
Via: SIP/2.0/TLS 10.0.0.2:5062;branch=z9hG4bK1871008465
From: "CALLER" <sip:3390@10.0.0.1:5061>;tag=1403881527
To: <sip:3808@10.0.0.1:5061>
Call-ID: 80122811@10.0.0.2
CSeq: 1 INVITE
Contact: <sip:3390@10.0.0.2:5062;transport=TLS>
Content-Type: application/sdp
Allow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE, REFER, PUBLISH, UPDATE, MESSAGE
Max-Forwards: 70
User-Agent: Yealink SIP-T22P 7.61.0.80
Supported: replaces
Allow-Events: talk,hold,conference,refer,check-sync
Content-Length: 535

v=0
o=- 20002 20002 IN IP4 10.0.0.2
s=SDP data
c=IN IP4 10.0.0.2
t=0 0
m=audio 11784 RTP/SAVP 0 8 18 101
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:NzM3NTJjMTgxZThlODQwOTVhY2VjYjYxNDk2ZTkw
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:MmI2ZTJlZjdkZWYzMDY4ADQwNzdlNzIAMTBiYjVl
a=crypto:3 F8_128_HMAC_SHA1_80 inline:NWM0YzY5YTEzNTZhOGEwODJjODY1MDIzYmFhMWMw
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=fmtp:101 0-15
a=rtpmap:101 telephone-event/8000
a=ptime:20
a=sendrecv
<------------->
--- (14 headers 17 lines) ---
Sending to 10.0.0.2:60930 (NAT)
Using INVITE request as basis request - 80122811@10.0.0.2
Found peer '3390' for '3390' from 10.0.0.2:60930

<--- Reliably Transmitting (NAT) to 10.0.0.2:60930 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/TLS 10.0.0.2:5062;branch=z9hG4bK1871008465;received=10.0.0.2;rport=60930
From: "CALLER" <sip:3390@10.0.0.1:5061>;tag=1403881527
To: <sip:3808@10.0.0.1:5061>;tag=as74ba94ee
Call-ID: 80122811@10.0.0.2
CSeq: 1 INVITE
Server: Asterisk PBX 1.8.20.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="71997119"
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog '80122811@10.0.0.2' in 6400 ms (Method: INVITE)

<--- SIP read from TLS:10.0.0.2:60930 --->
ACK sip:3808@10.0.0.1:5061 SIP/2.0
Via: SIP/2.0/TLS 10.0.0.2:5062;branch=z9hG4bK1871008465
From: "CALLER" <sip:3390@10.0.0.1:5061>;tag=1403881527
To: <sip:3808@10.0.0.1:5061>;tag=as74ba94ee
Call-ID: 80122811@10.0.0.2
CSeq: 1 ACK
Content-Length: 0

<------------->
--- (7 headers 0 lines) ---

<--- SIP read from TLS:10.0.0.2:60930 --->
INVITE sip:3808@10.0.0.1:5061 SIP/2.0
Via: SIP/2.0/TLS 10.0.0.2:5062;branch=z9hG4bK1315610844
From: "CALLER" <sip:3390@10.0.0.1:5061>;tag=1403881527
To: <sip:3808@10.0.0.1:5061>
Call-ID: 80122811@10.0.0.2
CSeq: 2 INVITE
Contact: <sip:3390@10.0.0.2:5062;transport=TLS>
Authorization: Digest username="3390", realm="asterisk", nonce="71997119", uri="sip:3808@10.0.0.1:5061", response="00a262b95dd021140cb75be475734c36", algorithm=MD5
Content-Type: application/sdp
Allow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE, REFER, PUBLISH, UPDATE, MESSAGE
Max-Forwards: 70
User-Agent: Yealink SIP-T22P 7.61.0.80
Supported: replaces
Allow-Events: talk,hold,conference,refer,check-sync
Content-Length: 535

v=0
o=- 20002 20002 IN IP4 10.0.0.2
s=SDP data
c=IN IP4 10.0.0.2
t=0 0
m=audio 11784 RTP/SAVP 0 8 18 101
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:NzM3NTJjMTgxZThlODQwOTVhY2VjYjYxNDk2ZTkw
a=crypto:2 AES_CM_128_HMAC_SHA1_32 inline:MmI2ZTJlZjdkZWYzMDY4ADQwNzdlNzIAMTBiYjVl
a=crypto:3 F8_128_HMAC_SHA1_80 inline:NWM0YzY5YTEzNTZhOGEwODJjODY1MDIzYmFhMWMw
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=fmtp:101 0-15
a=rtpmap:101 telephone-event/8000
a=ptime:20
a=sendrecv
<------------->
--- (15 headers 17 lines) ---
Sending to 10.0.0.2:60930 (NAT)
Using INVITE request as basis request - 80122811@10.0.0.2
Found peer '3390' for '3390' from 10.0.0.2:60930
Found RTP audio format 0
Found RTP audio format 8
Found RTP audio format 18
Found RTP audio format 101
Found audio description format PCMU for ID 0
Found audio description format PCMA for ID 8
Found audio description format G729 for ID 18
Found audio description format telephone-event for ID 101

<--- Reliably Transmitting (NAT) to 10.0.0.2:60930 --->
SIP/2.0 488 Not acceptable here
Via: SIP/2.0/TLS 10.0.0.2:5062;branch=z9hG4bK1315610844;received=10.0.0.2;rport=60930
From: "CALLER" <sip:3390@10.0.0.1:5061>;tag=1403881527
To: <sip:3808@10.0.0.1:5061>;tag=as74ba94ee
Call-ID: 80122811@10.0.0.2
CSeq: 2 INVITE
Server: Asterisk PBX 1.8.20.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog '80122811@10.0.0.2' in 6400 ms (Method: INVITE)

<--- SIP read from TLS:10.0.0.2:60930 --->
ACK sip:3808@10.0.0.1:5061 SIP/2.0
Via: SIP/2.0/TLS 10.0.0.2:5062;branch=z9hG4bK1315610844
From: "CALLER" <sip:3390@10.0.0.1:5061>;tag=1403881527
To: <sip:3808@10.0.0.1:5061>;tag=as74ba94ee
Call-ID: 80122811@10.0.0.2
CSeq: 2 ACK
Content-Length: 0

<------------->
--- (7 headers 0 lines) ---
Really destroying SIP dialog '80122811@10.0.0.2' Method: INVITE

Any ideas?

System Data:
asterisk 11.17.1
CentOS 5.5
libsrtp 1.4.4
openssl 0.9.8e

I’ve given this matter up for a while, but I’ve accidentally found an issue on the asterisk bug-tracking (jira) that pretty much is what I’m experiencing.

https://issues.asterisk.org/jira/browse/ASTERISK-24291

I’ll get back to it soon.
Hope it helps anyone else.