Send cisco-voip mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/cisco-voip
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of cisco-voip digest..."
Today's Topics:
1. Re: traces for remote destinations? (Daniel Pagan)
2. Re: traces for remote destinations? (Erick Wellnitz)
3. Re: traces for remote destinations? (Daniel Pagan)
4. Re: traces for remote destinations? (Eric Pedersen)
5. Re: traces for remote destinations? (Erick Wellnitz)
6. Re: Upgrading from UCCX 5.0.2 to 7.0.2 Screen Pop not working
(Grace Maximuangu)
7. Re: SPA8000 to 2851 FXO Connection (Abebe Amare)
8. Sweden Dial Plan. Overlap sending? (Nate VanMaren)
----------------------------------------------------------------------
Message: 1
Date: Thu, 22 Aug 2013 16:06:00 +0000
From: Daniel Pagan <[email protected]>
To: Erick Wellnitz <[email protected]>, cisco-voip
<[email protected]>
Subject: Re: [cisco-voip] traces for remote destinations?
Message-ID:
<a4f4beead515f947ac82d086a78c70f660343...@nyc-exch-mb01.fidelus.com>
Content-Type: text/plain; charset="us-ascii"
If you're referring to outbound routing (not matching RemDest w/ calling
number), then my first step would be to check if digit analysis is being
attempted to the remote destination -- search for dd="<DialedNumber>" including
quotes. Perhaps the call is failing at DA (wrong rerouting css).
If you don't see DA for the destination number, then I'd take a step back and
see if LineControl is sending the call to the RDP (in addition to the user's
phone devices). Marking the 2nd CI in Notepad++ should lead you to the
LineControl instance located slightly below DA results. The dispatch to all
devices lines should list all the IP phone devices receiving the call,
including the RDP.
I've also found that searching for "initRemDest" helps for finding a remote
destination being dialed.
So.. I guess the order should be...
1. Traces set to detailed (sorry.. had to say it...)
2. Use 2nd CI to determine if LineControl is dispatching the call to the
RDP... if yes then..
3. Search for "initRemDest" - should show what destination is being
dialed. Also useful if you're not sure how to find the CI.
4. Few lines below initRemDest should be the DA results - if successful
then next is determining the status of the outbound call attempt. If no
successful DA results are found, then likely a Rerouting CSS issue on the
profile.
Hope this helps
From: cisco-voip [mailto:[email protected]] On Behalf Of Erick
Wellnitz
Sent: Thursday, August 22, 2013 11:07 AM
To: cisco-voip
Subject: [cisco-voip] traces for remote destinations?
CUCM version 9.1
What should I be looking for in the SDL traces to troubleshoot Remote
Destination issues? Im not finding anything concrete.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130822/7fad7946/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 22 Aug 2013 12:36:29 -0500
From: Erick Wellnitz <[email protected]>
To: Daniel Pagan <[email protected]>
Cc: cisco-voip <[email protected]>
Subject: Re: [cisco-voip] traces for remote destinations?
Message-ID:
<CAK0wOsC7WipGfY-jqb5GgNH=7keqchrfs1fnxx5czvu5z92...@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
I did get it working. Set dedicated rerouting CSS with only the outbound
PT defined and unchecked then checked the line association box.
I'm still going to sift through the traces with this info and see what I
can dig up.
On Thu, Aug 22, 2013 at 11:06 AM, Daniel Pagan <[email protected]> wrote:
> If you?re referring to outbound routing (not matching RemDest w/ calling
> number), then my first step would be to check if digit analysis is being
> attempted to the remote destination -- search for *dd=?<**DialedNumber**>?
> *including quotes. Perhaps the call is failing at DA (wrong rerouting
> css).****
>
> ** **
>
> If you don?t see DA for the destination number, then I?d take a step back
> and see if LineControl is sending the call to the RDP (in addition to the
> user?s phone devices). Marking the 2nd CI in Notepad++ should lead you to
> the LineControl instance located slightly below DA results. The dispatch to
> all devices lines should list all the IP phone devices receiving the call,
> including the RDP.****
>
> ** **
>
> I?ve also found that searching for ?*initRemDest*? helps for finding a
> remote destination being dialed.****
>
> ** **
>
> So.. I guess the order should be?****
>
> ** **
>
> **1. **Traces set to detailed (sorry.. had to say it?)****
>
> **2. **Use 2nd CI to determine if LineControl is dispatching the
> call to the RDP? if yes then..****
>
> **3. **Search for ?*initRemDest*? ? should show what destination is
> being dialed. Also useful if you?re not sure how to find the CI.****
>
> **4. **Few lines below initRemDest should be the DA results ? if
> successful then next is determining the status of the outbound call
> attempt. If no successful DA results are found, then likely a Rerouting CSS
> issue on the profile.****
>
> ** **
>
> Hope this helps****
>
> ** **
>
> *From:* cisco-voip [mailto:[email protected]] *On Behalf
> Of *Erick Wellnitz
> *Sent:* Thursday, August 22, 2013 11:07 AM
> *To:* cisco-voip
> *Subject:* [cisco-voip] traces for remote destinations?****
>
> ** **
>
> CUCM version 9.1****
>
> ****
>
> What should I be looking for in the SDL traces to troubleshoot Remote
> Destination issues? Im not finding anything concrete.****
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130822/4804fea6/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 22 Aug 2013 17:56:03 +0000
From: Daniel Pagan <[email protected]>
To: Erick Wellnitz <[email protected]>
Cc: cisco-voip <[email protected]>
Subject: Re: [cisco-voip] traces for remote destinations?
Message-ID:
<a4f4beead515f947ac82d086a78c70f660344...@nyc-exch-mb01.fidelus.com>
Content-Type: text/plain; charset="us-ascii"
Cool - I'd say if the line association box was the issue, then your traces
should show the RDP missing from the listed called devices for
"dispatchToAllDevices". For the successful call, you should see an additional
device listed by Line Control - that being the RDP. If it's the rerouting CSS,
the trace should show a missing digit analysis results for the DA matching
attempt.
From: Erick Wellnitz [mailto:[email protected]]
Sent: Thursday, August 22, 2013 1:36 PM
To: Daniel Pagan
Cc: cisco-voip
Subject: Re: [cisco-voip] traces for remote destinations?
I did get it working. Set dedicated rerouting CSS with only the outbound PT
defined and unchecked then checked the line association box.
I'm still going to sift through the traces with this info and see what I can
dig up.
On Thu, Aug 22, 2013 at 11:06 AM, Daniel Pagan
<[email protected]<mailto:[email protected]>> wrote:
If you're referring to outbound routing (not matching RemDest w/ calling
number), then my first step would be to check if digit analysis is being
attempted to the remote destination -- search for dd="<DialedNumber>" including
quotes. Perhaps the call is failing at DA (wrong rerouting css).
If you don't see DA for the destination number, then I'd take a step back and
see if LineControl is sending the call to the RDP (in addition to the user's
phone devices). Marking the 2nd CI in Notepad++ should lead you to the
LineControl instance located slightly below DA results. The dispatch to all
devices lines should list all the IP phone devices receiving the call,
including the RDP.
I've also found that searching for "initRemDest" helps for finding a remote
destination being dialed.
So.. I guess the order should be...
1. Traces set to detailed (sorry.. had to say it...)
2. Use 2nd CI to determine if LineControl is dispatching the call to the
RDP... if yes then..
3. Search for "initRemDest" - should show what destination is being
dialed. Also useful if you're not sure how to find the CI.
4. Few lines below initRemDest should be the DA results - if successful
then next is determining the status of the outbound call attempt. If no
successful DA results are found, then likely a Rerouting CSS issue on the
profile.
Hope this helps
From: cisco-voip
[mailto:[email protected]<mailto:[email protected]>]
On Behalf Of Erick Wellnitz
Sent: Thursday, August 22, 2013 11:07 AM
To: cisco-voip
Subject: [cisco-voip] traces for remote destinations?
CUCM version 9.1
What should I be looking for in the SDL traces to troubleshoot Remote
Destination issues? Im not finding anything concrete.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130822/8e46b060/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 22 Aug 2013 18:11:21 +0000
From: Eric Pedersen <[email protected]>
To: Erick Wellnitz <[email protected]>, Daniel Pagan
<[email protected]>
Cc: cisco-voip <[email protected]>
Subject: Re: [cisco-voip] traces for remote destinations?
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Was it an upgrade to 9.1? We ran into CSCue58307 and had to uncheck and recheck
the RD line associates after we upgraded.
From: cisco-voip [mailto:[email protected]] On Behalf Of Erick
Wellnitz
Sent: 22 August 2013 11:36 AM
To: Daniel Pagan
Cc: cisco-voip
Subject: Re: [cisco-voip] traces for remote destinations?
I did get it working. Set dedicated rerouting CSS with only the outbound PT
defined and unchecked then checked the line association box.
I'm still going to sift through the traces with this info and see what I can
dig up.
On Thu, Aug 22, 2013 at 11:06 AM, Daniel Pagan
<[email protected]<mailto:[email protected]>> wrote:
If you're referring to outbound routing (not matching RemDest w/ calling
number), then my first step would be to check if digit analysis is being
attempted to the remote destination -- search for dd="<DialedNumber>" including
quotes. Perhaps the call is failing at DA (wrong rerouting css).
If you don't see DA for the destination number, then I'd take a step back and
see if LineControl is sending the call to the RDP (in addition to the user's
phone devices). Marking the 2nd CI in Notepad++ should lead you to the
LineControl instance located slightly below DA results. The dispatch to all
devices lines should list all the IP phone devices receiving the call,
including the RDP.
I've also found that searching for "initRemDest" helps for finding a remote
destination being dialed.
So.. I guess the order should be...
1. Traces set to detailed (sorry.. had to say it...)
2. Use 2nd CI to determine if LineControl is dispatching the call to the
RDP... if yes then..
3. Search for "initRemDest" - should show what destination is being
dialed. Also useful if you're not sure how to find the CI.
4. Few lines below initRemDest should be the DA results - if successful
then next is determining the status of the outbound call attempt. If no
successful DA results are found, then likely a Rerouting CSS issue on the
profile.
Hope this helps
From: cisco-voip
[mailto:[email protected]<mailto:[email protected]>]
On Behalf Of Erick Wellnitz
Sent: Thursday, August 22, 2013 11:07 AM
To: cisco-voip
Subject: [cisco-voip] traces for remote destinations?
CUCM version 9.1
What should I be looking for in the SDL traces to troubleshoot Remote
Destination issues? Im not finding anything concrete.
The contents of this message may contain confidential and/or privileged
subject matter. If this message has been received in error, please contact
the sender and delete all copies. Like other forms of communication,
e-mail communications may be vulnerable to interception by unauthorized
parties. If you do not wish us to communicate with you by e-mail, please
notify us at your earliest convenience. In the absence of such
notification, your consent is assumed. Should you choose to allow us to
communicate by e-mail, we will not take any additional security measures
(such as encryption) unless specifically requested.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130822/09b95801/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 22 Aug 2013 14:29:50 -0500
From: Erick Wellnitz <[email protected]>
To: Eric Pedersen <[email protected]>
Cc: cisco-voip <[email protected]>
Subject: Re: [cisco-voip] traces for remote destinations?
Message-ID:
<cak0woscsivb2f+g6fk6zv58lvibmbi2d9tto-todx3ewrto...@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
No upgrade between the time they were working and stopped working.
On Thu, Aug 22, 2013 at 1:11 PM, Eric Pedersen
<[email protected]>wrote:
> Was it an upgrade to 9.1? We ran into CSCue58307 and had to uncheck and
> recheck the RD line associates after we upgraded.****
>
> ** **
>
> *From:* cisco-voip [mailto:[email protected]] *On Behalf
> Of *Erick Wellnitz
> *Sent:* 22 August 2013 11:36 AM
> *To:* Daniel Pagan
> *Cc:* cisco-voip
> *Subject:* Re: [cisco-voip] traces for remote destinations?****
>
> ** **
>
> I did get it working. Set dedicated rerouting CSS with only the outbound
> PT defined and unchecked then checked the line association box.****
>
> ****
>
> I'm still going to sift through the traces with this info and see what I
> can dig up.****
>
> ** **
>
> On Thu, Aug 22, 2013 at 11:06 AM, Daniel Pagan <[email protected]> wrote:
> ****
>
> If you?re referring to outbound routing (not matching RemDest w/ calling
> number), then my first step would be to check if digit analysis is being
> attempted to the remote destination -- search for *dd=?<**DialedNumber**>?
> *including quotes. Perhaps the call is failing at DA (wrong rerouting
> css).****
>
> ****
>
> If you don?t see DA for the destination number, then I?d take a step back
> and see if LineControl is sending the call to the RDP (in addition to the
> user?s phone devices). Marking the 2nd CI in Notepad++ should lead you to
> the LineControl instance located slightly below DA results. The dispatch to
> all devices lines should list all the IP phone devices receiving the call,
> including the RDP.****
>
> ****
>
> I?ve also found that searching for ?*initRemDest*? helps for finding a
> remote destination being dialed.****
>
> ****
>
> So.. I guess the order should be?****
>
> ****
>
> 1. Traces set to detailed (sorry.. had to say it?)****
>
> 2. Use 2nd CI to determine if LineControl is dispatching the call
> to the RDP? if yes then..****
>
> 3. Search for ?*initRemDest*? ? should show what destination is
> being dialed. Also useful if you?re not sure how to find the CI.****
>
> 4. Few lines below initRemDest should be the DA results ? if
> successful then next is determining the status of the outbound call
> attempt. If no successful DA results are found, then likely a Rerouting CSS
> issue on the profile.****
>
> ****
>
> Hope this helps****
>
> ****
>
> *From:* cisco-voip [mailto:[email protected]] *On Behalf
> Of *Erick Wellnitz
> *Sent:* Thursday, August 22, 2013 11:07 AM
> *To:* cisco-voip
> *Subject:* [cisco-voip] traces for remote destinations?****
>
> ****
>
> CUCM version 9.1****
>
> ****
>
> What should I be looking for in the SDL traces to troubleshoot Remote
> Destination issues? Im not finding anything concrete.****
>
> ** **
>
> The contents of this message may contain confidential and/or privileged
> subject matter. If this message has been received in error, please contact
> the sender and delete all copies. Like other forms of communication,
> e-mail communications may be vulnerable to interception by unauthorized
> parties. If you do not wish us to communicate with you by e-mail, please
> notify us at your earliest convenience. In the absence of such
> notification, your consent is assumed. Should you choose to allow us to
> communicate by e-mail, we will not take any additional security measures
> (such as encryption) unless specifically requested.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130822/7997eed5/attachment-0001.html>
------------------------------
Message: 6
Date: Thu, 22 Aug 2013 16:03:02 -0400
From: Grace Maximuangu <[email protected]>
To: "Ryan LaFountain (rlafount)" <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [cisco-voip] Upgrading from UCCX 5.0.2 to 7.0.2 Screen
Pop not working
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Hey Ryan,
I know I am still working on the screen shots, did you take a look at what I
sent, I am wondering if this is going to turn into some development work or
what is the workaround to getting this issue resolved.
Please advice
Tks
:-:gm
Grace Maximuangu
Voice Solutions Engineer
Black Box Network Services
Cell: 213.268.6342
[email protected]<mailto:[email protected]>
www.blackbox.com<http://www.blackbox.com/>
[cid:[email protected]]
From: Ryan LaFountain (rlafount) [mailto:[email protected]]
Sent: Tuesday, August 20, 2013 7:36 AM
To: Grace Maximuangu; [email protected]
Subject: Re: [cisco-voip] Upgrading from UCCX 5.0.2 to 7.0.2 Screen Pop not
working
Hi Grace,
This sounds like two issues here. The first is that the workflow configuration
went missing during the upgrade to 7.0(2). There have been a couple of issues
around this, some known like those listed on page 27 in the link below and some
unknown where we've never been able to get to the bottom of why workflow
information wasn't retained after the upgrade.
http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/crs/express_7_0/installation/guide/cad702ccxig-cm.pdf
The second issue seems to be that even after you've recreated the workflow, the
screen pop doesn't work. Can you describe or send screenshots of what the
workflow configuration is and what the agent is experiencing when it 'does not
work'?
Thank you,
Ryan LaFountain
Unified Contact Center
Cisco Services
Direct: +1 919 392 9898
Email: [email protected]<mailto:[email protected]>
Hours: M - F 9:00am - 5:00pm
From: Grace Maximuangu
<[email protected]<mailto:[email protected]>>
Date: Monday, August 19, 2013 4:14 PM
To: "[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Subject: [cisco-voip] Upgrading from UCCX 5.0.2 to 7.0.2 Screen Pop not working
Please advice, the after the upgrade, workflows had to be manually added, but
Screen Pop does not work, I just saw a post on Cisco UCCX forum, please has
anyone ran into the issue and how did this get resolved. And any references on
how to solve this issue would be highly appreciated
CAD is only capable of passing enterprise data to another application. It
cannot perform database lookups on its own. Your options are:
1) If it is browser-based, you can execute an HTTP POST or GET within the
integrated browser.
2) If the application will accept it, you can pass an IPC call
(Inter-Process Communication) to it. This is a formatted UDP packet that CAD
would send, typically on a loopback address, to a port the other application is
listening on.
3) If the action can be repeated with a consistent series of key strokes,
you can call a macro to replay that key sequence, effectively paste the data
into the correct field, and execute the search.
You can use the Cisco Desktop Administrator User Guide for CAD 6.6 for Unified
CM<http://www.cisco.com/en/US/docs/voice_ip_comm/cust_contact/contact_center/crs/express_7_0/user/guide/cda66ug-cm.pdf>
as documentation on how to setup workflows within CAD.
You will need to use Enterprise Data to pass the caller ID information (or
anything else you want CAD to get). This has been covered on the forum many
times. Here is one example to get you
started:https://supportforums.cisco.com/message/1047577#1047577
Please see the post from Cisco forum
:-:gm
Grace Maximuangu
Voice Solutions Engineer
Black Box Network Services
[cid:[email protected]]
________________________________
This email and any files transmitted with it are confidential and are intended
for the sole use of the individual to whom they are addressed. Black Box
Corporation reserves the right to scan all e-mail traffic for restricted
content and to monitor all e-mail in general. If you are not the intended
recipient or you have received this email in error, any use, dissemination or
forwarding of this email is strictly prohibited. If you have received this
email in error, please notify the sender by replying to this email.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130822/2b93f679/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 4336 bytes
Desc: image001.jpg
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130822/2b93f679/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 4336 bytes
Desc: image002.jpg
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130822/2b93f679/attachment-0003.jpg>
------------------------------
Message: 7
Date: Fri, 23 Aug 2013 09:51:06 +0300
From: Abebe Amare <[email protected]>
To: cisco voip <[email protected]>
Subject: Re: [cisco-voip] SPA8000 to 2851 FXO Connection
Message-ID:
<CANrv87hFQtnZELHaLjggi1=u+nfcndvidnuj_9sxlzoulnf...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I ask this because of a unique setup a client has. There is no wire line
PSTN provider where they are and they get PSTN access from VSAT provider
EMC. Currently they have an AudioCodes voip gateway with four FXS ports
connection to 4-port FXO card on 2851. The 2851 is configured as a SIP
trunk on CUCM.
Now EMC brought a Linksys SPA8000 with 8 FXS ports. What is the best
possible way to connection those FXS ports? If I Put an additional FXO card
on the 2851, the connection is straight forward as in the AudioCodes?
Thanks in Advance.
Abebe
On Thu, Aug 22, 2013 at 5:34 PM, Abebe Amare <[email protected]> wrote:
> Dears,
>
> Is it possible to connect the SPA8000 to 2851 4-port FXO card and
> configure as normal FXO ports?
>
> Regards,
>
> Abebe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130823/518be0a3/attachment-0001.html>
------------------------------
Message: 8
Date: Fri, 23 Aug 2013 15:04:40 +0000
From: Nate VanMaren <[email protected]>
To: cisco voip <[email protected]>
Subject: [cisco-voip] Sweden Dial Plan. Overlap sending?
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Group,
I am deploying a site in Sweden and looking at the dial plan, I don't see any
way to create patterns that do not have inter-digit timeout, because almost
every area code has different sized minimum and maximum length
(http://www.pts.se/upload/Ovrigt/Tele/Nummerfragor/Sv_nrplan_telefoni_enl_TU-T_rek_E.164.pdf)
I have done overlap sending to the PSTN in Germany because their dial-plan is
also impossible to load in CM, so I am thinking maybe Sweden also uses overlap
sending?.
Does anyone on the group have experience with the Sweden dial plan, or know if
Sweden does overlap sending?
Thanks,
-Nate
NOTICE: This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any unauthorized
review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply email and destroy all
copies of the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://puck.nether.net/pipermail/cisco-voip/attachments/20130823/a6b23ba7/attachment-0001.html>
------------------------------
Subject: Digest Footer
_______________________________________________
cisco-voip mailing list
[email protected]
https://puck.nether.net/mailman/listinfo/cisco-voip
------------------------------
End of cisco-voip Digest, Vol 118, Issue 20
*******************************************
