[cisco-voip] FW: Getting Unity to work when in SRST mode.
Mathew Miller
miller.mathew at gmail.com
Thu Feb 18 18:41:03 EST 2010
Do you have allow redirecting number inbound enabled on the hub site mgcp gateway in CallManager?
On Feb 18, 2010, at 4:56 PM, Monica Hardy wrote:
> I found a debug that I ran while I was in SRST mode. You can see that RDNIS shows up sometimes, so now I am really confused as to why
> Unity does not recognize the extension:
>
> 000838: Feb 12 02:34:13.521: ISDN Se0/0/0:23 Q931: Sending SETUP callref = 0x008F callID = 0x8010 switch = primary-ni interface = User
> 000839: Feb 12 02:34:13.521: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x008F
> Bearer Capability i = 0x8090A2
> Standard = CCITT
> Transfer Capability = Speech
> Transfer Mode = Circuit
> Transfer Rate = 64 kbit/s
> Channel ID i = 0xA98397
> Exclusive, Channel 23
> Calling Party Number i = 0x0183, '91XXXXX334'
> Plan:ISDN, Type:Unknown
> Called Party Number i = 0x81, '16XXXXX2499'
> Plan:ISDN, Type:Unknown
> Redirecting Number i = 0x010082, '2206' ------THIS IS THE EXTENSION IN Unity
> Plan:ISDN, Type:Unknown
> 000840: Feb 12 02:34:13.569: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x808F
> Channel ID i = 0xA98397
> Exclusive, Channel 23
> 000841: Feb 12 02:34:15.929: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x808F
> Progress Ind i = 0x8488 - In-band info or appropriate now available
> 000842: Feb 12 02:34:16.033: ISDN Se0/0/0:23 Q931: RX <- CONNECT pd = 8 callref = 0x808F
> 000843: Feb 12 02:34:16.037: %ISDN-6-CONNECT: Interface Serial0/0/0:22 is now connected to 16XXXXX2499 N/A
> 000844: Feb 12 02:34:16.037: %ISDN-6-CONNECT: Interface Serial0/0/0:22 is now connected to 16XXXXX2499 N/A
> 000845: Feb 12 02:34:16.037: ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x008F
> 000846: Feb 12 02:34:16.045: ISDN Se0/0/0:23 Q931: TX -> CONNECT pd = 8 callref = 0x8224
> 000847: Feb 12 02:34:16.073: ISDN Se0/0/0:23 Q931: RX <- CONNECT_ACK pd = 8 callref = 0x0224
> 000848: Feb 12 02:34:16.073: %ISDN-6-CONNECT: Interface Serial0/0/0:0 is now connected to 91XXXXX334 N/A
> 000849: Feb 12 02:34:16.073: %ISDN-6-CONNECT: Interface Serial0/0/0:0 is now connected to 91XXXXX334 N/A
> 000850: Feb 12 02:34:30.601: ISDN Se0/0/0:23 Q931: RX <- DISCONNECT pd = 8 callref = 0x0224
> Cause i = 0x8090 - Normal call clearing
> 000851: Feb 12 02:34:30.605: %ISDN-6-DISCONNECT: Interface Serial0/0/0:0 disconnected from 91XXXXX334 , call lasted 14 seconds
> 000852: Feb 12 02:34:30.605: ISDN Se0/0/0:23 Q931: TX -> RELEASE pd = 8 callref = 0x8224
> 000853: Feb 12 02:34:30.613: %ISDN-6-DISCONNECT: Interface Serial0/0/0:22 disconnected from 16XXXXX2499 , call lasted 14 seconds
> 000854: Feb 12 02:34:30.613: ISDN Se0/0/0:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x008F
> Cause i = 0x8090 - Normal call clearing
> 000855: Feb 12 02:34:30.633: ISDN Se0/0/0:23 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x0224
> 000856: Feb 12 02:34:30.637: ISDN Se0/0/0:23 Q931: RX <- RELEASE pd = 8 callref = 0x808F
> 000857: Feb 12 02:34:30.645: ISDN Se0/0/0:23 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x008F
> 000858: Feb 12 02:36:27.572: ISDN Se0/0/0:23 Q931: Applying typeplan for sw-type 0xD is 0x0 0x1, Calling num 91XXXX0206
>
>
> 000859: Feb 12 02:36:27.576: ISDN Se0/0/0:23 Q931: Sending SETUP callref = 0x0090 callID = 0x8011 switch = primary-ni interface = User
> 000860: Feb 12 02:36:27.576: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x0090
> Bearer Capability i = 0x8090A2
> Standard = CCITT
> Transfer Capability = Speech
> Transfer Mode = Circuit
> Transfer Rate = 64 kbit/s
> Channel ID i = 0xA98397
> Exclusive, Channel 23
> Progress Ind i = 0x8183 - Origination address is non-ISDN
> Calling Party Number i = 0x0180, '91XXXX0206'
> Plan:ISDN, Type:Unknown
> Called Party Number i = 0x81, '16XXXXX2499'
> Plan:ISDN, Type:Unknown
> 000861: Feb 12 02:36:27.672: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x8090
> Channel ID i = 0xA98397
> Exclusive, Channel 23
> 000862: Feb 12 02:36:30.096: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x8090
> Progress Ind i = 0x8488 - In-band info or appropriate now available
> 000863: Feb 12 02:36:30.320: ISDN Se0/0/0:23 Q931: RX <- CONNECT pd = 8 callref = 0x8090
> 000864: Feb 12 02:36:30.328: %ISDN-6-CONNECT: Interface Serial0/0/0:22 is now connected to 16XXXXX2499 N/A
> 000865: Feb 12 02:36:30.328: %ISDN-6-CONNECT: Interface Serial0/0/0:22 is now connected to 1XXXXX02499 N/A
> 000866: Feb 12 02:36:30.328: ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x0090
> 000867: Feb 12 02:36:35.464: %ISDN-6-DISCONNECT: Interface Serial0/0/0:22 disconnected from 16XXXXX2499 , call lasted 5 seconds
> 000868: Feb 12 02:36:35.464: ISDN Se0/0/0:23 Q931: TX -> DISCONNECT pd = 8 callref = 0x0090
> Cause i = 0x8090 - Normal call clearing
> 000869: Feb 12 02:36:35.496: ISDN Se0/0/0:23 Q931: RX <- RELEASE pd = 8 callref = 0x8090
> 000870: Feb 12 02:36:35.500: ISDN Se0/0/0:23 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x0090
> From: Monica Hardy
> Sent: Thursday, February 18, 2010 2:35 PM
> To: cisco-voip at puck.nether.net
> Subject: Getting Unity to work when in SRST mode.
>
> Hello everyone,
> I have read a few articles, but I am not sure if any of these have my exact scenario.
> I can get to Unity fine from this remote location when the MGCP gateway is up and running fine.
> We use 4 digit extensions and Unity is configured with the same 4 digit extension.
> This remote location has a PRI to the PSTN.
>
> When in SRST mode when you call in from a cell phone to the user’s extension or if the user hit’s the messages button they are
> just sent to the general unity mailbox and not their specific mailbox.
>
> I am checking with the carrier to see if RDNIS is configured on the PRI.
>
> This is a little different scenario because I have a translation pattern
> translating the incoming 4 digits received from 0[1-2]XX to 22XX on the SRST GW:
> voice translation-rule 1
> rule 1 /^0[1-2]\(..$\)/ /22\1/
>
> voice translation-profile inboundtrans
> translate called 1
>
> This rule is applied to the dial-peers as
>
> translation-profile incoming inboundtrans
>
> I also have an outgoing translation rule that translates the 22XX extension to the full Correct DID number on outgoing calls:
> !
> voice translation-rule 3
> rule 1 /^228./ /9137480200\1/
> rule 2 /^\(229\)\(.$\)/ /9XXXX8019\2/
> rule 3 /^\(220\)\(.$\)/ /9XXXX8020\2/
> rule 4 /^\(221\)\(.$\)/ /9XXXX8021\2/
> rule 5 /^\(222\)\(.$\)/ /9XXXX8022\2/
> rule 6 /^\(223\)\(.$\)/ /9XXXX8023\2/
> rule 7 /^\(224\)\(.$\)/ /9XXXX8024\2/
> rule 8 /^\(225\)\(.$\)/ /9XXXX8025\2/
> rule 9 /^\(226\)\(.$\)/ /9XXXX8026\2/
> rule 10 /^\(227\)\(.$\)/ /9XXXX8027\2/
> !
> !
> This is applied to the call-manager-fallback
> translation-profile incoming OUT1
>
> Under call-manager-fallback I also have these vm settings configured:
>
> voicemail 916XXXX02499
> call-forward busy 916XXXX02499
> call-forward noan 91XXXX02499 timeout 10
>
> How do I make Unity see the 4 digit extension so that the caller can get dumped into the correct mailbox, or the user can still hit the messages button to get his messages.
>
> Are my outgoing translation patterns an issue?
>
> I am really unable right now to do any testing so I am trying to figure out what I need to configure put it in place and then take a downtime as I will have a small window.
>
> Any help to point me in the right direction would be greatly appreciated.
>
> -Monica
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20100218/278825d2/attachment.html>
More information about the cisco-voip
mailing list