[asterisk-users] chan_dahdi.c: Don't know what to do with frame type '10'

2015-04-17 Thread Dmitry Melekhov

Hello!

I see large enough amount of such messages on one of our asterisks.
There are no complains from users, so I may be they are harmless.
Could you tell me what can it be?

Thank you!

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
  http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-users


Re: [asterisk-users] chan_dahdi.c: Don't know what to do with frame type '10'

2015-04-17 Thread Shaun Ruffell
On Fri, Apr 17, 2015 at 05:05:41PM +0400, Dmitry Melekhov wrote:
 Hello!
 
 I see large enough amount of such messages on one of our asterisks.
 There are no complains from users, so I may be they are harmless.
 Could you tell me what can it be?
 
 Thank you!

Frame type '10' is a CNG (Comfort Noise Generation) frame. This is a
frame that, instead of carrying audio, carries a command to for the
receiver to generate comfort noise for a length of time to the
local user.  

chan_dahdi is not currently capable of generating comfort noise in
response to receiving one of these frames.

I think it's safe to ignore them.  Alternatively, if the comfort
noise packets are generated from SIP endpoints that you have control
over, you could see if there are any options to disable generation
of those frames.

-- 
Shaun Ruffell
Digium, Inc. | Linux Kernel Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: www.digium.com  www.asterisk.org

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users


[asterisk-users] Asterisk 11 SRTP: unsupported crypto parameters: UNENCRYPTED_SRTCP

2015-04-17 Thread Satish Barot
Hi All,

I have Asterisk 11 talking to Avaya over SIP trunk using TLS and SRTP.
On incoming calls from Avaya asterisk complains of 'unsupported crypto
parameters: UNENCRYPTED_SRTCP' and rejects the call with '488 Not
acceptable here'

Doesn't Asterisk support  UNENCRYPTED_SRTCP as crypto parameters in sdp?

FYI SDP looks like this.

v=0
o=- 1429194215 1 IN IP4 XX.XX.XX.XX
s=-
c=IN IP4 XX.XX.XX.XX
b=TIAS:64000
t=0 0
a=avf:avc=n prio=n
a=csup:avf-v0
m=audio 50096 RTP/SAVP 0 18 120
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:120 telephone-event/8000
a=ptime:20
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:zUVSWsFB/WjVtLxXojBT7zbNvuQ4BkOwcCkD/AjM|2^20 UNENCRYPTED_SRTCP

And on CLI I see,

DEBUG[1568][C-] sip/sdp_crypto.c: local_key64
7vXot5kn/sl/GYv5ENN6yW0PZZapQ00c++biLgoX len 40
WARNING[1568][C-] sip/sdp_crypto.c: Unsupported crypto parameters:
UNENCRYPTED_SRTCP
DEBUG[1568][C-] chan_sip.c: Processing media-level (audio) SDP
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:zUVSWsFB/WjVtLxXojBT7zbNvuQ4BkOwcCkD/AjM|2^20 UNENCRYPTED_SRTCP...
UNSUPPORTED OR FAILED.
WARNING[1568][C-] chan_sip.c: Rejecting secure audio stream without
encryption details: audio 50096 RTP/SAVP 0 18 120
VERBOSE[1568][C-] chan_sip.c:
--- Reliably Transmitting (NAT) to XX.XX.XX.XX:5061 ---
SIP/2.0 488 Not acceptable here

Thanking in advance for any inputs.

--Satish
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

[asterisk-users] Why is CDR(recordingfile) not being written to the database despite being set in the dialplan?

2015-04-17 Thread Alex Villací­s Lasso


I am using Asterisk 11.17.1 with my program that uses AMI Originate calls to generate a bunch of calls for a callcenter. The PBX configuration is handled by FreePBX 2.11. I want to understand the dialplan behavior in order to figure out why the 
CDR(recordingfile) is blank on the CDR records despite the dialplan setting it.


My program generates the calls by setting Channel=Local/NUMBERTODIAL@from-internal and by setting Exten=QUEUENUM, Context=from-internal, Priority=1 . The FreePBX-generated dialplan results in the following trace as seen in the Asterisk console. In 
particular, please note that CDR(recordingfile) is being set in Local/9991416445@from-internal-017b;1 :


-- Executing [9991416445@from-internal:1] 
Macro(Local/9991416445@from-internal-017b;2, 
user-callerid,LIMIT,EXTERNAL,) in new stack
-- Executing [s@macro-user-callerid:1] 
Set(Local/9991416445@from-internal-017b;2, 
TOUCH_MONITOR=1429224932.21697) in new stack
-- Executing [s@macro-user-callerid:2] 
Set(Local/9991416445@from-internal-017b;2, AMPUSER=9991416445) in new 
stack
-- Executing [s@macro-user-callerid:3] 
GotoIf(Local/9991416445@from-internal-017b;2, 0?report) in new stack
...
-- Executing [s@sub-record-check:19] Set(Local/9991416445@from-internal-017b;2, 
__TIMESTR=20150416-175532) in new stack
-- Executing [s@sub-record-check:20] Set(Local/9991416445@from-internal-017b;2, 
__FROMEXTEN=9991416445) in new stack
-- Executing [s@sub-record-check:21] Set(Local/9991416445@from-internal-017b;2, 
__CALLFILENAME=out-9991416445-9991416445-20150416-175532-1429224932.21697) in new stack
-- Executing [s@sub-record-check:22] 
Goto(Local/9991416445@from-internal-017b;2, out,1) in new stack
-- Goto (sub-record-check,out,1)
-- Executing [out@sub-record-check:1] 
ExecIf(Local/9991416445@from-internal-017b;2, 
1?Set(__REC_POLICY_MODE=)) in new stack
-- Executing [out@sub-record-check:2] 
GosubIf(Local/9991416445@from-internal-017b;2, 
0?record,1(exten,9991416445,9991416445)) in new stack
-- Executing [out@sub-record-check:3] 
Return(Local/9991416445@from-internal-017b;2, ) in new stack
-- Executing [9991416445@from-internal:5] 
PlayTones(Local/9991416445@from-internal-017b;2, ring) in new stack
-- Executing [9991416445@from-internal:6] 
Dial(Local/9991416445@from-internal-017b;2, 
SIP/5547741200/019991416445,40,tTorR) in new stack
...
  == Using SIP RTP TOS bits 184
  == Using SIP RTP CoS mark 5
-- Called SIP/5547741200/0459991416445
-- SIP/5547741200-51cb is ringing

-- SIP/5547741200-51cb is ringing
-- SIP/5547741200-51cb is making progress passing it to 
Local/9991416445@from-internal-017b;2

-- SIP/5547741200-51cb is making progress passing it to 
Local/9991416445@from-internal-017b;2

-- SIP/5547741200-51cb is making progress passing it to 
Local/9991416445@from-internal-017b;2

-- SIP/5547741200-51cb is ringing
-- SIP/5547741200-51cb is making progress passing it to 
Local/9991416445@from-internal-017b;2
-- SIP/5547741200-51cb answered 
Local/9991416445@from-internal-017b;2
-- Executing [6001@from-internal:1] 
Macro(Local/9991416445@from-internal-017b;1, user-callerid,) in new 
stack
-- Executing [s@macro-user-callerid:1] 
Set(Local/9991416445@from-internal-017b;1, 
TOUCH_MONITOR=1429224932.21696) in new stack
-- Executing [s@macro-user-callerid:2] 
Set(Local/9991416445@from-internal-017b;1, AMPUSER=9991416445) in new 
stack
-- Executing [s@macro-user-callerid:3] 
GotoIf(Local/9991416445@from-internal-017b;1, 0?report) in new stack
-- Executing [s@macro-user-callerid:4] 
ExecIf(Local/9991416445@from-internal-017b;1, 
1?Set(REALCALLERIDNUM=9991416445)) in new stack
-- Executing [s@macro-user-callerid:5] 
Set(Local/9991416445@from-internal-017b;1, AMPUSER=) in new stack
...
-- Executing [6001@from-internal:29] Set(Local/9991416445@from-internal-017b;1, 
VQ_POSITION=) in new stack
-- Executing [6001@from-internal:30] Set(Local/9991416445@from-internal-017b;1, 
__MIXMON_FORMAT=wav) in new stack
-- Executing [6001@from-internal:31] Set(Local/9991416445@from-internal-017b;1, 
MONITOR_OPTIONS=b) in new stack
-- Executing [6001@from-internal:32] 
Gosub(Local/9991416445@from-internal-017b;1, 
sub-record-check,s,1(q,6001,always)) in new stack
-- Executing [s@sub-record-check:1] Set(Local/9991416445@from-internal-017b;1, 
REC_POLICY_MODE_SAVE=) in new stack
-- Executing [s@sub-record-check:2] 
GotoIf(Local/9991416445@from-internal-017b;1, 1?check) in new stack
-- Goto (sub-record-check,s,7)
-- Executing [s@sub-record-check:7] Set(Local/9991416445@from-internal-017b;1, 
__MON_FMT=wav) in new stack
...
-- Executing [q@sub-record-check:1] 
GosubIf(Local/9991416445@from-internal-017b;1, 
1?recq,1(q,6001,9991416445)) in new stack
-- 

Re: [asterisk-users] Asterisk 11 SRTP: unsupported crypto parameters: UNENCRYPTED_SRTCP

2015-04-17 Thread Matthew Jordan
On Fri, Apr 17, 2015 at 6:16 AM, Satish Barot satish4aster...@gmail.com wrote:
 Hi All,

 I have Asterisk 11 talking to Avaya over SIP trunk using TLS and SRTP.
 On incoming calls from Avaya asterisk complains of 'unsupported crypto
 parameters: UNENCRYPTED_SRTCP' and rejects the call with '488 Not acceptable
 here'

 Doesn't Asterisk support  UNENCRYPTED_SRTCP as crypto parameters in sdp?

 FYI SDP looks like this.

 v=0
 o=- 1429194215 1 IN IP4 XX.XX.XX.XX
 s=-
 c=IN IP4 XX.XX.XX.XX
 b=TIAS:64000
 t=0 0
 a=avf:avc=n prio=n
 a=csup:avf-v0
 m=audio 50096 RTP/SAVP 0 18 120
 a=rtpmap:0 PCMU/8000
 a=rtpmap:18 G729/8000
 a=fmtp:18 annexb=no
 a=rtpmap:120 telephone-event/8000
 a=ptime:20
 a=crypto:1 AES_CM_128_HMAC_SHA1_80
 inline:zUVSWsFB/WjVtLxXojBT7zbNvuQ4BkOwcCkD/AjM|2^20 UNENCRYPTED_SRTCP

 And on CLI I see,

 DEBUG[1568][C-] sip/sdp_crypto.c: local_key64
 7vXot5kn/sl/GYv5ENN6yW0PZZapQ00c++biLgoX len 40
 WARNING[1568][C-] sip/sdp_crypto.c: Unsupported crypto parameters:
 UNENCRYPTED_SRTCP
 DEBUG[1568][C-] chan_sip.c: Processing media-level (audio) SDP
 a=crypto:1 AES_CM_128_HMAC_SHA1_80
 inline:zUVSWsFB/WjVtLxXojBT7zbNvuQ4BkOwcCkD/AjM|2^20 UNENCRYPTED_SRTCP...
 UNSUPPORTED OR FAILED.
 WARNING[1568][C-] chan_sip.c: Rejecting secure audio stream without
 encryption details: audio 50096 RTP/SAVP 0 18 120
 VERBOSE[1568][C-] chan_sip.c:
 --- Reliably Transmitting (NAT) to XX.XX.XX.XX:5061 ---
 SIP/2.0 488 Not acceptable here

 Thanking in advance for any inputs.


Asterisk is complaining because placing an UNENCRYPTED_SRTCP after
the lifetime parameter in a crypto attribute is part of RFC 4568
(Security Descriptions for Media Streams), which Asterisk does not
support.

You will need to see if the Avaya system can be configured to not send
the attribute.

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com  http://asterisk.org

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users