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

Fri Feb 19 07:13:25 EST 2010

You mean CUE right? normal setup is ccm-cue when in mgcp mode users call
main# and get forwarded to AA, the route point takes over and send the call
back to the gw and everything works nice. now your in srst mode, wan is down
and i will assume you have a cue onboard so in srst your using local cue, do
you have the voicemail cmd in telephoney service to dial out to the main
unity so when in srst mode users press messages button and it outdials? that
resolves messges button issue.
when in srst cue acts on behalf you have to have local users mailboxes
configured on the cue, but this would confuse users as to where the vm goes
once wan is back up so general deliver mail box is best solution in srst...
tell your users thats just the way it is.. am i confusing you more or making
any sence?

On Thu, Feb 18, 2010 at 5:56 PM, Monica Hardy <Monica.Hardy at openwave.com>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/20100219/bba471db/attachment.html>