[cisco-voip] FW: Getting Unity to work when in SRST mode.

Nick Matthews matthnick at gmail.com
Thu Feb 18 19:29:37 EST 2010 

You will need to do this debug on the other side of the ISDN (in your
central site with Unity) to see if that RDNIS is making it through the
big scary PSTN cloud.

-nick

On Thu, Feb 18, 2010 at 6:41 PM, Mathew Miller <miller.mathew at gmail.com> wrote:
> 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
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>

More information about the cisco-voip mailing list