10-08-2013 07:56 AM - edited 03-16-2019 07:46 PM
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
10-08-2013 08:09 AM
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
10-09-2013 01:11 AM
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
10-10-2013 03:46 AM
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.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: