SNR doesn't work when the call comes from a H.323 gateway

mcaldogne · ‎10-08-2013

Hello!

We are implementing SNR (remote destination profiles and mobile identity) in our company, but we have a problem when the call comes from PSTN via H.323 gateway.

The ip-phone continue to ring but the call will not be connected to the remote destination.

If the caller is another ip-phone registred on the CUCM or comes from a ICT it works correctly.

Here the debug q931 of the H323 gateway:

Oct 8 16:39:27.975: ISDN Se0/0/0:15 Q931: RX <- SETUP pd = 8 callref = 0x0058

Sending Complete

Bearer Capability i = 0x8090A3

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA98385

Exclusive, Channel 5

Calling Party Number i = 0x0183, '*********'

Plan:ISDN, Type:Unknown

Called Party Number i = 0xA1, '********** '

Plan:ISDN, Type:National

Oct 8 16:39:27.975: ISDN Se0/0/0:15 Q931: Received SETUP callref = 0x8058 callID = 0x1203 switch = primary-net5 interface = User

Oct 8 16:39:27.979: ISDN Se0/0/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0x8058

Channel ID i = 0xA98385

Exclusive, Channel 5

Oct 8 16:39:28.007: ISDN Se0/0/0:15 Q931: TX -> ALERTING pd = 8 callref = 0x8058

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

Oct 8 16:39:28.015: ISDN Se0/0/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x0 0x1, Calling num 03484002309

Oct 8 16:39:28.015: ISDN Se0/0/0:15 Q931: Sending SETUP callref = 0x173C callID = 0x96BD switch = primary-net5 interface = User

Oct 8 16:39:28.015: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x173C

Bearer Capability i = 0x8090A3

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA9838C

Exclusive, Channel 12

Calling Party Number i = 0x0181, '**********'

Plan:ISDN, Type:Unknown

Called Party Number i = 0xA0, '**********'

Plan:Unknown, Type:National

Oct 8 16:39:28.323: ISDN Se0/0/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0x973C

Channel ID i = 0xA9838C

Exclusive, Channel 12

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

Oct 8 16:39:28.335: ISDN Se0/0/0:15 Q931: RX <- DISCONNECT pd = 8 callref = 0x973C

Cause i = 0x8281 - Unallocated/unassigned number

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

Oct 8 16:39:28.335: ISDN Se0/0/0:15 Q931: call_disc: PI received in disconnect; Postpone sending RELEASE for callid 0x96BD

Oct 8 16:39:42.563: ISDN Se0/0/0:15 Q931: RX <- DISCONNECT pd = 8 callref = 0x0058

Cause i = 0x849F - Normal, unspecified

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

Oct 8 16:39:42.563: ISDN Se0/0/0:15 Q931: TX -> RELEASE pd = 8 callref = 0x8058

Oct 8 16:39:42.579: ISDN Se0/0/0:15 Q931: TX -> RELEASE pd = 8 callref = 0x173C

Oct 8 16:39:42.631: ISDN Se0/0/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x0058

Oct 8 16:39:42.663: ISDN Se0/0/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x973C

CUCM 8.6(2)

VG 2921 IOS c2900-universalk9-mz.SPA.153-2.T.bin

Any ideas?

Thanks in advanced.

Mirko

Chris Deren · ‎10-08-2013

What is the "Called Party Number i = 0xA0, " showing? Does it include proper prefix?

Can you do "debug voice dialpeer" to see if it matches egress dial peer?

Chris

mcaldogne · ‎10-09-2013

Thank you for your reply.

From "debug voice dialpeer" I can see that the right outgoing dial-peer match.

The call will be routed when I call the mobile number

directly, or when I set a CFA to the same number on the IP-phone.

When I compare the debugs these seem to be identical.

Regards,

Mirko

mcaldogne · ‎10-10-2013

The issue has been solved!

It's happened because by forwarding to the PSTN the numbering-type of the called party number was set to "national", although those was a mobile device.

We created a new route-pattern on the CUCM to overwrite the "called party numbering type" in unknow to solve this issue.