Why doesn't the ISDN B-channel selection configuration work on my Cisco Voice Gateway?
I had the PRIs in a trunk group and had the IOS configuration setup to perform channel selection on the serial interfaces corresponding with our PRIs. However, the PRIs ignored the channel selection commands. How strange, I would have thought that the serial interface would be the most specific configuration option to define the hunting scheme. Well wouldn't you know, all of the hunt scheme magic is performed at the trunk group level. (I didn't know) The commands bellow illustrate how to configure the PRIs to hunt in a descending order which is typically my preference as carriers usually hunt in an ascending order.
router(config-trunk-group)#trunk group PRI
router(config-trunk-group)#hunt-scheme ?
sequential The interface with highest preference is selected
router(config-trunk-group)#hunt-scheme sequential ?
both Select from all available timeslots
router(config-trunk-group)#hunt-scheme sequential both ?
down Timeslots are selected in the descending order
router(config-trunk-group)#hunt-scheme sequential both down
This is a collection of my experiences around Cisco Collaboration. These technical notes are for me to look back on and jog my memory of my adventures in Collab. With any luck, they may be helpful for others too. (Your mileage may vary, this is not a replacement for official TAC support from Cisco and all the other usual disclaimers that go along with an unofficial tech blog.)
Showing posts with label PRI. Show all posts
Showing posts with label PRI. Show all posts
Thursday, March 21, 2019
Tuesday, September 11, 2018
Why's the mainline forwarded to a cell phone!?! (Cellphone Carrier plays error after 60 seconds)
Here's a "fun" one.
Symptom:
I received intermittent reports/questions about the main line, "being forwarded to a cell phone". I know there's no reason why I would have forwarded the mainline to a cell phone.
Troubleshooting:
I checked Cisco Communications Manager and confirmed the main line wasn't forwarded to another number. Then I began to call the mainline from a land line & a cell phone but could not to reproduce the reported problem. During the tests when an operator wasn't available after 90 seconds my call was routed to the auto attendant as designed. I checked the logs for the reported problem call and found a normal call clearing from the PSTN. Sadly, I wasn't any closer to finding where the end user's disconnect was.
Luckily, one of the reporting persons then sent me a video of an example problem call to the main line on her mobile phone. Her mobile phone rang for right around 60 seconds and then played the following message.
"
Welcome to Verizon wireless. The wireless customer you called is not available at this time Please try your call again later. Announcement 1 switch [redacted]
"
This helped explain the confusion around why users were reporting the main line was being forwarded to a cell phone. The Verizon error states that the "wireless customer" is not available.
I validated that the reporting user was indeed using a Verizon mobile phone. Armed with that information I repeated the test from a couple of other Verizon mobile phones and was able to consistently recreate the issue.
Issue:
Verizon Wireless pulled back the call at 60 seconds and played the following error message:
"
Welcome to Verizon wireless. The wireless customer you called is not available at this time Please try your call again later. Announcement 1 switch [redacted]
"
Work Around:
Modified the timers on the Cisco Communications Manager. Previously the system was configured to route calls to the auto attendant after 90 seconds. I discussed the issue with the customer and we decided to change the value to 30 seconds. Now, when an operator doesn't pick up the call within 30 seconds, the call is routed to the auto-attendant instead of being disconnected by our friends at Verizon.
Symptom:
I received intermittent reports/questions about the main line, "being forwarded to a cell phone". I know there's no reason why I would have forwarded the mainline to a cell phone.
Troubleshooting:
I checked Cisco Communications Manager and confirmed the main line wasn't forwarded to another number. Then I began to call the mainline from a land line & a cell phone but could not to reproduce the reported problem. During the tests when an operator wasn't available after 90 seconds my call was routed to the auto attendant as designed. I checked the logs for the reported problem call and found a normal call clearing from the PSTN. Sadly, I wasn't any closer to finding where the end user's disconnect was.
Luckily, one of the reporting persons then sent me a video of an example problem call to the main line on her mobile phone. Her mobile phone rang for right around 60 seconds and then played the following message.
"
Welcome to Verizon wireless. The wireless customer you called is not available at this time Please try your call again later. Announcement 1 switch [redacted]
"
This helped explain the confusion around why users were reporting the main line was being forwarded to a cell phone. The Verizon error states that the "wireless customer" is not available.
I validated that the reporting user was indeed using a Verizon mobile phone. Armed with that information I repeated the test from a couple of other Verizon mobile phones and was able to consistently recreate the issue.
Issue:
Verizon Wireless pulled back the call at 60 seconds and played the following error message:
"
Welcome to Verizon wireless. The wireless customer you called is not available at this time Please try your call again later. Announcement 1 switch [redacted]
"
Work Around:
Modified the timers on the Cisco Communications Manager. Previously the system was configured to route calls to the auto attendant after 90 seconds. I discussed the issue with the customer and we decided to change the value to 30 seconds. Now, when an operator doesn't pick up the call within 30 seconds, the call is routed to the auto-attendant instead of being disconnected by our friends at Verizon.
Monday, January 22, 2018
Where's my Caller-ID Calling Name Man? (PRI Inbound Calling Name in subsequent FACILITY)
We just had a new telco company install a voice PRI with the intention of replacing our existing telco company's PRI at one of our remote sites. After installing and testing the new voice PRI we realized that the inbound calling name was not displayed on the phones.
In this particular scenario the setup looked something like this:
PRI -----ISDN-----> Cisco ISR-G2 VG -----SIP-----> CUCM -----SCCP-----> Cisco IP Phone
We ran a "debug isdn q931" to troubleshoot the problem. Upon inspection we found that the calling party name was not being sent in the initial ISDN setup message. In fact, it indicated that the calling name would be send in a "subsequent FACILITY message".
interface Serial X/X/X:23
isdn supp-service name calling
Secondly, there is a problem in this scenario with the voice gateway sending a SIP invite to Communications Manager right after it gets the ISDN setup message. Since the initial ISDN setup message doesn't have the calling name the SIP invite will also be lacking the calling name. When we tested at this point the phones were showing "From pending" as the calling name. The work around for this issue is to introduce a delay before the voice gateway sends the SIP invite to CUCM. Each scenario may require a different amount of time. One can look at the debugs to find out how long it takes between the time the initial ISDN setup message is received and when the ISDN facility message with the name is received. In this particular case we tuned the delay to 500 milliseconds and it seems to work well. The command to delay the setup for 500 milliseconds is.
sip-ua
timers buffer-invite 500
For more information, Cisco also has a bug id CSCup91440 that references using a buffer-invite on individual dial peers.
Below are some samples of what the debugs looked like on a typical inbound telco call and the telco that sends the calling name in a later message.
Standard Telco "Before Debug"
(The actual telephone numbers have been changed to protect the innocent.)
507963: Jan 22 09:53:13.269: ISDN Se0/2/0:23 Q931: RX <- SETUP pd = 8 callref = 0x14D4
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98382
Exclusive, Channel 2
Facility i = 0x9F8B0100A11702010D020100800F4368696361676F202020202020494C
Protocol Profile = Networking Extensions
0xA11702010D020100800F4368696361676F202020202020494C
Component = Invoke component
Invoke Id = 13
Operation = CallingName
Name Presentation Allowed Extended
Name = Joshua Learn
Display i = 'Joshua Learn'
Calling Party Number i = 0x2180, '8005551212'
Plan:ISDN, Type:National
Called Party Number i = 0x80, '8885551212'
Plan:ISDN, Type:National
507964: Jan 22 09:53:13.269: ISDN Se0/2/0:23 Q931: Received SETUP callref = 0x94D4 callID = 0x13E4 switch = primary-ni interface = User
Subsequent Facility Message Telco "After"
(The actual telephone numbers have been changed to protect the innocent.)
040306: Jan 22 07:49:27.801 PST: ISDN Se0/2/0:23 Q931: RX <- SETUP pd = 8 callref = 0x1A22
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98381
Exclusive, Channel 1
Facility i = 0x9F8B0100A10F02016A06072A8648CE1500040A0100
Protocol Profile = Networking Extensions
0xA10F02016A06072A8648CE1500040A0100
Component = Invoke component
Invoke Id = 106
Operation = InformationFollowing (calling_name)
Name information in subsequent FACILITY message
Progress Ind i = 0x8281 - Call not end-to-end ISDN, may have in-band info
Calling Party Number i = 0x2183, '8005551212'
Plan:ISDN, Type:National
Called Party Number i = 0xA1, '8885551212'
Plan:ISDN, Type:National
040307: Jan 22 07:49:27.801 PST: ISDN Se0/2/0:23 Q931: Received SETUP callref = 0x9A22 callID = 0x1D81 switch = primary-ni interface = User
040308: Jan 22 07:49:27.805 PST: ISDN Se0/2/0:23 Q931: TX -> CALL_PROC pd = 8 callref = 0x9A22
Channel ID i = 0xA98381
Exclusive, Channel 1
040309: Jan 22 07:49:27.848 PST: ISDN Se0/2/0:23 Q931: RX <- FACILITY pd = 8 callref = 0x1A22
Facility i = 0x9F8B0100A11702016B020100800F332054524143452020202020202020
Protocol Profile = Networking Extensions
0xA11702016B020100800F332054524143452020202020202020
Component = Invoke component
Invoke Id = 107
Operation = CallingName
Name Presentation Allowed Extended
Name = Joshua Learn
Subscribe to:
Posts (Atom)
Integrating WebEx Calling and Communications Manager Express 2/2
This is the second post in the two post series. It will go into more detail on the configuration of the solutions and workarounds put in pla...
-
This is the second post in the two post series. It will go into more detail on the configuration of the solutions and workarounds put in pla...
-
It's been a long minute since I've run into this particular scenario. Unfortunately, I didn't have the solution in my notes s...
-
Let's say there is a Communications Manager Express and a PSTN SIP trunk to the telco that requires authentication. How does CME bind S...