Problem with notify messages on E1 line and AS5350

vadoodetm · ‎09-05-2012

Hi,

I have a AS5350 with E1 2 PRI DFC on it. E1 line is terminated on the cisco AS5350 and then there is a trunk between this and an Asterisk server. The setup works fine and all incoming calls are forwarded to asterisk server and properly handled.

Problem is, when during a call the other party presses number 2 during a call, which cisco gateway takes it as a notify message and does not send it to the asetrisk server. All other numbers work just fine.

I wonder if there is some way to instruct gateway to send dtmf to voip server.

here is the partial configuration for the device:

controller E1 3/0

pri-group timeslots 1-31

!

controller E1 3/1

pri-group timeslots 1-31

!

voice service voip

allow-connections h323 to h323

allow-connections h323 to sip

allow-connections sip to h323

allow-connections sip to sip

signaling forward unconditional

fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback none

!

isdn switch-type primary-net5

!

interface Serial3/0:15

no ip address

encapsulation ppp

isdn switch-type primary-net5

isdn incoming-voice modem 56

isdn global-disconnect

isdn send-alerting

isdn sending-complete

no keepalive

no fair-queue

!

interface Serial3/1:15

no ip address

encapsulation ppp

isdn switch-type primary-net5

isdn overlap-receiving T302 1000

isdn incoming-voice modem

isdn global-disconnect

isdn send-alerting

isdn sending-complete

no keepalive

no fair-queue

!

voice-port 3/0:D

input gain 10

output attenuation -5

echo-cancel coverage 24

no vad

cptone DE

timeouts ringing 30

timeouts wait-release 1

bearer-cap Speech

!

voice-port 3/1:D

input gain 10

output attenuation -5

echo-cancel coverage 24

no vad

cptone DE

timeouts ringing 30

timeouts wait-release 1

bearer-cap Speech

!

mgcp fax t38 ecm

!

dial-peer voice 200 voip

description TO-Asterisk

destination-pattern .T

voice-class codec 5060

session protocol sipv2

session target ipv4:172.21.0.40:5060

session transport udp

dtmf-relay rtp-nte

dtmf-interworking rtp-nte

no vad

!

paolo bevilacqua · ‎09-05-2012

You can change dtmf-relay method to something that your open source "PBX", or it's phones, understand.

vadoodetm · ‎09-05-2012

In fact, gateway does not relay anything when this number is pressed. I do not receive anything on PBX side. Below is what happens on the gateway when caller enters anything other than 2 and when he enters 2 (logs from gateway)

================== when any other digit is input

===========================================

May 19 14:07:24.728: ISDN Se3/1:15 Q931: RX <- SETUP pd = 8 callref = 0x6175

Sending Complete

Bearer Capability i = 0x8090A3

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA98398

Exclusive, Channel 24

Calling Party Number i = 0x0083, '00919115zzzz'

Plan:Unknown, Type:Unknown

Called Party Number i = 0x81, 'yyyyy'

Plan:ISDN, Type:Unknown

May 19 14:07:24.728: ISDN Se3/1:15 Q931: Received SETUP callref = 0xE175 callID = 0x0533 switch = primary-net5 interface = User

May 19 14:07:24.736: ISDN Se3/1:15 Q931: TX -> CALL_PROC pd = 8 callref = 0xE175

Channel ID i = 0xA98398

Exclusive, Channel 24

May 19 14:07:24.748: ISDN Se3/1:15 Q931: TX -> CONNECT pd = 8 callref = 0xE175

May 19 14:07:24.780: ISDN Se3/1:15 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x6175

May 19 14:07:33.175: ISDN Se3/1:15 Q931: RX <- DISCONNECT pd = 8 callref = 0x6175

Cause i = 0x8290 - Normal call clearing

Progress Ind i = 0x8288 - In-band info or appropriate now available

May 19 14:07:33.175: ISDN Se3/1:15 Q931: call_disc: Global disconnect configured; Postpone sending RELEASE for callid 0x533

May 19 14:07:33.179: ISDN Se3/1:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0xE175

Cause i = 0x8090 - Normal call clearing

================== when number 2 is input

===========================================

May 16 12:10:46.416: ISDN Se3/1:15 Q931: RX <- SETUP pd = 8 callref = 0x5FF5

Sending Complete

Bearer Capability i = 0x8090A3

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA9839B

Exclusive, Channel 27

Calling Party Number i = 0x0083, '00919115zzzz'

Plan:Unknown, Type:Unknown

Called Party Number i = 0x81, 'yyyyy'

Plan:ISDN, Type:Unknown

May 16 12:10:46.416: ISDN Se3/1:15 Q931: Received SETUP callref = 0xDFF5 callID = 0x039C switch = primary-net5 interface = User

May 16 12:10:46.424: ISDN Se3/1:15 Q931: TX -> CALL_PROC pd = 8 callref = 0xDFF5

Channel ID i = 0xA9839B

Exclusive, Channel 27

May 16 12:10:46.432: ISDN Se3/1:15 Q931: TX -> CONNECT pd = 8 callref = 0xDFF5

May 16 12:10:46.468: ISDN Se3/1:15 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x5FF5

May 16 12:10:51.903: ISDN Se3/1:15 Q931: RX <- NOTIFY pd = 8 callref = 0x5FF5

Notification Ind i = 0xF9

May 16 12:10:51.903: ISDN Se3/1:15 Q931: TX -> STATUS pd = 8 callref = 0xDFF5

Cause i = 0x80E427 - Invalid information element contents

Call State i = 0x0A

May 16 12:10:54.791: ISDN Se3/1:15 Q931: RX <- NOTIFY pd = 8 callref = 0x5FF5

Notification Ind i = 0xFA

May 16 12:10:54.791: ISDN Se3/1:15 Q931: TX -> STATUS pd = 8 callref = 0xDFF5

Cause i = 0x80E427 - Invalid information element contents

Call State i = 0x0A

May 16 12:10:58.935: ISDN Se3/1:15 Q931: RX <- DISCONNECT pd = 8 callref = 0x5FF5

Cause i = 0x8290 - Normal call clearing

Progress Ind i = 0x8288 - In-band info or appropriate now available

May 16 12:10:58.935: ISDN Se3/1:15 Q931: call_disc: Global disconnect configured; Postpone sending RELEASE for callid 0x39C

May 16 12:10:58.939: ISDN Se3/1:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0xDFF5

Cause i = 0x8095 - Call rejected

paolo bevilacqua · ‎09-05-2012

You have to ask your telco why they do not relay digits in-band after call is connected.

However, you have to prove that nothing is received first, while it is received, but not handled by your thirdy party device, as I was suggesting before.

Also I don't know what is the reason for which they send "NOTIFY" message, that the router doesn't even accept.

vadoodetm · ‎09-05-2012

Thank you Paolo for the comment.

I think destination-pattern thing is just fine. My problem occurs during a call. I mean when during the call, a caller tries to press 2 to send a DTMF tone to IVR, it fails. All other digits work.

vadoodetm · ‎09-05-2012

We need this behaviour. We want to answer the call as soos as caller stops dialing more numbers. this is done using this interdigit timeout.

I mean if the caller dials 5 numbers he sill be directed to attendant, and if 7 he will be directed to the appropriate extension.

But the original problem I have, happens during a call. I mean while the call is established. Is it related to destination-pattern?

paolo bevilacqua · ‎09-05-2012

I have edited my post above, becase that as that apparently has nothing to do with overlap digits, as I erroneously indicated before.

vadoodetm · ‎09-08-2012

Paolo Bevilacqua wrote:

You have to ask your telco why they do not relay digits in-band after call is connected.

However, you have to prove that nothing is received first, while it is received, but not handled by your thirdy party device, as I was suggesting before.

Also I don't know what is the reason for which they send "NOTIFY" message, that the router doesn't even accept.

The odd thing is, we only see the that when incoming call comes from celluar phones. If the calling number is a landline, everything works fine.

paolo bevilacqua · ‎09-08-2012

That normally indicates an issue with overlap receiving. Because a cellephons sends the full number at once, while landline can use overlap.

vadoodetm · ‎09-08-2012

Paolo Bevilacqua wrote:

That normally indicates an issue with overlap receiving. Because a cellephons sends the full number at once, while landline can use overlap.

Any hints on how can I troubleshoot this? Or at least how I can make sure what the real cause of the problem is? The other hint is that DID also works fine both from landline and cellular.

paolo bevilacqua · ‎09-08-2012

Try configuring destination-pattern for a full lenght DID.

luc.gillot · ‎01-20-2015

Hi,

Do you find the root cause of your issue because I am facing the same problem with my gateway.

regards

Luc