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

Monica Hardy Monica.Hardy at openwave.com
Thu Feb 18 17:56:18 EST 2010 

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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20100218/01568ffe/attachment.html>

More information about the cisco-voip mailing list