Problem with notify messages on E1 line and AS5350

[vadoodetm]

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]

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

[vadoodetm]

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]

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]

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]

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]

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

[vadoodetm]

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]

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

[vadoodetm]

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]

Try configuring destination-pattern for a full lenght DID.

[luc.gillot]

Hi,

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

regards

Luc