 |
|
 |
|
|
 |
Transferring to Outside Lines from the IPCC ? |
 |
 |
|
|
05-29-07 06:11 PM
We have an odd problem. In our script on the CRS server, we transfer
calls to an external number for our backup helpdesk vendor. This works
fine when we insert their regular phone number which is 404-XXX-XXXX,
but when we enter the toll free number 800-XXX-XXXX that is forwarded to
the 404 number by the carrier, we get a busy signal. Is there anything
that I can change on the IPCC or the Call Manager that might be
preventing this call from transferring? We can call the 800 number
directly from our Call Manager phones without difficulty. Please let me
know if you guys have any ideas. Thank you!
Steve Miller
--------------------------------------------------------
This e-mail message and any attached files are confidential and are intended
solely for the use of the addressee(s) named above. This communication mayco
ntain material protected by attorney-client, work product, or other privileg
es. If you are not the intended recipient or person responsible fordeliverin
g this confidential communication to the intended recipient, you have receiv
ed this communication in error, and any review, use, dissemination, forwardi
ng, printing, copying, or other distribution of thise-mail message and any a
ttached files is strictly prohibited. Dickstein Shapiro reserves the right t
o monitor any communication that is created, received, or sent on its networ
k. If you have received this confidential communication in error, please no
tify the sender immediately by reply e-mailmessage and permanently delete th
e original message.
To reply to our email administrator directly, send an email to postmaster@di
cksteinshapiro.com
Dickstein Shapiro LLP
http://www.DicksteinShapiro.com
========================================
====================================
==
[ Post a follow-up to this message ]
|
|
|
 |
|
 |
|
 |
|
|
|
Re: Transferring to Outside Lines from the IPCC ? |
|
|
|
|
05-30-07 12:11 AM
Calling Search Space differences, perhaps? Does the call reach the gateway?
Try to check it with dialed number analyzer, perhaps ...
Can you debug the call on the gateway? Does it get there, if so, in what
form, etc.
regards,
Zoltan
Miller, Steve wrote:
> We have an odd problem. In our script on the CRS server, we transfer
> calls to an external number for our backup helpdesk vendor. This works
> fine when we insert their regular phone number which is 404-XXX-XXXX,
> but when we enter the toll free number 800-XXX-XXXX that is forwarded to
> the 404 number by the carrier, we get a busy signal. Is there anything
> that I can change on the IPCC or the Call Manager that might be
> preventing this call from transferring? We can call the 800 number
> directly from our Call Manager phones without difficulty. Please let me
> know if you guys have any ideas. Thank you!
>
> Steve Miller
>
> --------------------------------------------------------
> This e-mail message and any attached files are confidential and are intended solel
y for the use of the addressee(s) named above. This communication may contain materi
al protected by attorney-client, work product, or other privileges. If you are not t
he
intended recipient or person responsible for delivering this confidential co
mmunication to the intended recipient, you have received this communication
in error, and any review, use, dissemination, forwarding, printing, copying,
or other distribution of t
his e-mail message and any attached files is strictly prohibited. Dickstein
Shapiro reserves the right to monitor any communication that is created, rec
eived, or sent on its network. If you have received this confidential commu
nication in error, please n
otify the sender immediately by reply e-mail message and permanently delete the original mes
sage.
>
> To reply to our email administrator directly, send an email to postmaster@
dicksteinshapiro.com
>
> Dickstein Shapiro LLP
> http://www.DicksteinShapiro.com
> ========================================
==================================
====
>
>
> ------------------------------------------------------------------------
>
> ________________________________________
_______
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
[ Post a follow-up to this message ]
|
|
|
|
|
|
|
|
|
|
|
Re: Transferring to Outside Lines from the IPCC ? |
|
|
|
|
05-30-07 12:11 AM
> Miller, Steve wrote:[vbcol=seagreen]
Check your Q931 traces; does it look like this? (I'm also about to
start troubleshooting this issue, so I don't have an answer).
If the site dials the 800 number directly, it works, but if they use a
site-wide speed dial that's a CFA on a line that's attached to a
"SpeedDial" CTI port, it doesn't work. (*660 is the speed dial)
May 29 10:47:40.923: ISDN Se0/1/0:23 Q931: Applying typeplan for sw-type
0xD is 0x2 0x1, Calling num 213928
May 29 10:47:40.923: ISDN Se0/1/0:23 Q931: Applying typeplan for sw-type
0xD is 0x2 0x1, Called num 18005797372
May 29 10:47:40.923: ISDN Se0/1/0:23 Q931: TX -> SETUP pd = 8 callref =
0x06A3
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98382
Exclusive, Channel 2
Calling Party Number i = 0x21A1, '213928'
Plan:ISDN, Type:National
Called Party Number i = 0xA1, '18005797372'
Plan:ISDN, Type:National
Redirecting Number i = '!', 0x008F, '??*660'
Plan:ISDN, Type:National
May 29 10:47:41.015: ISDN Se0/1/0:23 Q931: RX <- CALL_PROC pd = 8
callref = 0x86A3 Channel ID i = 0xA98382 Exclusive, Channel 2
May 29 10:47:41.023: ISDN Se0/1/0:23 Q931: RX <- PROGRESS pd = 8
callref = 0x86A3
Cause i = 0x80FF - Interworking error; unspecified
Progress Ind i = 0x8088 - In-band info or appropriate now available
May 29 10:47:44.935: ISDN Se0/1/0:23 Q931: TX -> DISCONNECT pd = 8
callref = 0x06A3 Cause i = 0x8090 - Normal call clearing
May 29 10:47:45.015: ISDN Se0/1/0:23 Q931: RX <- RELEASE pd = 8 callref
= 0x86A3
May 29 10:47:45.019: ISDN Se0/1/0:23 Q931: TX -> RELEASE_COMP pd = 8
callref = 0x06A3
[ Post a follow-up to this message ]
|
|
|
|
|
|
|
|
|
|
|
Re: Transferring to Outside Lines from the IPCC ? |
|
|
|
|
05-30-07 06:11 AM
Just a thought, Do you have dedicated LD circuits? If so are you routing
sending that 800s via those circuits? The 800 calls can not be sent out LD
circuits. They must go out the local.
On 5/29/07, Robert Kulagowski <bob@smalltime.com> wrote:
>
>
> Check your Q931 traces; does it look like this? (I'm also about to
> start troubleshooting this issue, so I don't have an answer).
>
> If the site dials the 800 number directly, it works, but if they use a
> site-wide speed dial that's a CFA on a line that's attached to a
> "SpeedDial" CTI port, it doesn't work. (*660 is the speed dial)
>
> May 29 10:47:40.923: ISDN Se0/1/0:23 Q931: Applying typeplan for sw-type
> 0xD is 0x2 0x1, Calling num 213928
> May 29 10:47:40.923: ISDN Se0/1/0:23 Q931: Applying typeplan for sw-type
> 0xD is 0x2 0x1, Called num 18005797372
> May 29 10:47:40.923: ISDN Se0/1/0:23 Q931: TX -> SETUP pd = 8 callref =
> 0x06A3
> Bearer Capability i = 0x8090A2
> Standard = CCITT
> Transfer Capability = Speech
> Transfer Mode = Circuit
> Transfer Rate = 64 kbit/s
> Channel ID i = 0xA98382
> Exclusive, Channel 2
> Calling Party Number i = 0x21A1, '213928'
> Plan:ISDN, Type:National
> Called Party Number i = 0xA1, '18005797372'
> Plan:ISDN, Type:National
> Redirecting Number i = '!', 0x008F, '??*660'
> Plan:ISDN, Type:National
>
> May 29 10:47:41.015: ISDN Se0/1/0:23 Q931: RX <- CALL_PROC pd = 8
> callref = 0x86A3 Channel ID i = 0xA98382 Exclusive, Channel 2
>
> May 29 10:47:41.023: ISDN Se0/1/0:23 Q931: RX <- PROGRESS pd = 8
> callref = 0x86A3
> Cause i = 0x80FF - Interworking error; unspecified
> Progress Ind i = 0x8088 - In-band info or appropriate now
> available
>
> May 29 10:47:44.935: ISDN Se0/1/0:23 Q931: TX -> DISCONNECT pd = 8
> callref = 0x06A3 Cause i = 0x8090 - Normal call clearing
>
> May 29 10:47:45.015: ISDN Se0/1/0:23 Q931: RX <- RELEASE pd = 8 callref
> = 0x86A3
>
> May 29 10:47:45.019: ISDN Se0/1/0:23 Q931: TX -> RELEASE_COMP pd = 8
> callref = 0x06A3
> ________________________________________
_______
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
[ Post a follow-up to this message ]
|
|
|
|
|
|
|
|
|
|
|
Re: Transferring to Outside Lines from the IPCC ? |
|
|
|
|
05-30-07 06:11 PM
Check the CTI Port's CSS and calling permissions.
From: cisco-voip-bounces@puck.nether.net
[mailto:cisco-voip-bounces@puck.nether.net] On Behalf Of Kent Roberts
Sent: Tuesday, May 29, 2007 10:30 PM
To: Robert Kulagowski
Cc: cisco-voip@puck.nether.net
Subject: Re: [cisco-voip] Transferring to Outside Lines from the IPCC ?
Just a thought, Do you have dedicated LD circuits? If so are you
routing sending that 800s via those circuits? The 800 calls can not be
sent out LD circuits. They must go out the local.
On 5/29/07, Robert Kulagowski <bob@smalltime.com> wrote:
[vbcol=seagreen]
> Miller, Steve wrote:
Check your Q931 traces; does it look like this? (I'm also about to
start troubleshooting this issue, so I don't have an answer).
Ifthe site dials the 800 number directly, it works, but if they use a
site-wide speed dial that's a CFA on a line that's attached to a
"SpeedDial" CTI port, it doesn't work. (*660 is the speed dial)
May 29 10:47:40.923: ISDN Se0/1/0:23 Q931: Applying typeplan for sw-type
0xD is 0x2 0x1, Calling num 213928
May 29 10:47:40.923 : ISDN Se0/1/0:23 Q931: Applying typeplan for
sw-type
0xD is 0x2 0x1, Called num 18005797372
May 29 10:47:40.923: ISDN Se0/1/0:23 Q931: TX -> SETUP pd = 8 callref =
0x06A3
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98382
Exclusive, Channel 2
Calling Party Number i = 0x21A1, '213928'
Plan:ISDN, Type:National
Called Party Number i = 0xA1, '18005797372'
Plan:ISDN, Type:National
Redirecting Number i = '!', 0x008F, '??*660'
Plan:ISDN, Type:National
May 29 10:47:41.015: ISDN Se0/1/0:23 Q931: RX <- CALL_PROC pd = 8
callref = 0x86A3 Channel ID i = 0xA98382 Exclusive, Channel 2
May 29 10:47:41.023: ISDN Se0/1/0:23 Q931: RX <- PROGRESS pd = 8
callref = 0x86A3
Cause i = 0x80FF- Interworking error; unspecified
Progress Ind i = 0x8088 - In-band info or appropriate now
available
May 29 10:47:44.935: ISDN Se0/1/0:23 Q931: TX -> DISCONNECT pd = 8
callref = 0x06A3 Cause i = 0x8090 - Normal call clearing
May 29 10:47:45.015: ISDN Se0/1/0:23 Q931: RX <- RELEASE pd = 8 callref
= 0x86A3
May 29 10:47:45.019: ISDN Se0/1/0:23 Q931: TX -> RELEASE_COMP pd = 8
callref = 0x06A3
________________________________________
_______
cisco-voip mailing list
cisco-voip@puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
-----------------------------------------
Disclaimer:
This e-mail communication and any attachments may contain
confidential and privileged information and is for use by the
designated addressee(s) named above only. If you are not the
intended addressee, you are hereby notified that you have received
this communication in error and that any use or reproduction of
this email or its contents is strictly prohibited and may be
unlawful. If you have received this communication in error, please
notify us immediately by replyingto this message and deleting it
from your computer. Thank you.
[ Post a follow-up to this message ]
|
|
|
|
|
|
|
|
|
|
|
Re: Transferring to Outside Lines from the IPCC ? |
|
|
|
|
05-30-07 06:11 PM
> Check your Q931 traces; does it look like this? (I'm also about to
> start troubleshooting this issue, so I don't have an answer).
>
> If the site dials the 800 number directly, it works, but if they use a
> site-wide speed dial that's a CFA on a line that's attached to a
> "SpeedDial" CTI port, it doesn't work. (*660 is the speed dial)
>
> May 29 10:47:40.923: ISDN Se0/1/0:23 Q931: Applying typeplan for sw-ty
pe
> 0xD is 0x2 0x1, Calling num 213928
> May 29 10:47:40.923 : ISDN Se0/1/0:23 Q931: Applying typeplan for
> sw-type
> 0xD is 0x2 0x1, Called num 18005797372
> May 29 10:47:40.923: ISDN Se0/1/0:23 Q931: TX -> SETUP pd = 8 callref
=
> 0x06A3
> Bearer Capability i = 0x8090A2
> Standard = CCITT
> Transfer Capability = Speech
> Transfer Mode = Circuit
> Transfer Rate = 64 kbit/s
> Channel ID i = 0xA98382
> Exclusive, Channel 2
> Calling Party Number i = 0x21A1, '213928'
> Plan:ISDN, Type:National
> Called Party Number i = 0xA1, '18005797372'
> Plan:ISDN, Type:National
> Redirecting Number i = '!', 0x008F, '??*660'
> Plan:ISDN, Type:National
>
> May 29 10:47:41.015: ISDN Se0/1/0:23 Q931: RX <- CALL_PROC pd = 8
> callref = 0x86A3 Channel ID i = 0xA98382 Exclusive, Channel 2
>
> May 29 10:47:41.023: ISDN Se0/1/0:23 Q931: RX <- PROGRESS pd = 8
> callref = 0x86A3
> Cause i = 0x80FF - Interworking error; unspecified
> Progress Ind i = 0x8088 - In-band info or appropriate now
> available
Kent Roberts wrote:
> Just a thought, Do you have dedicated LD circuits? If so are you
> routing sending that 800s via those circuits? The 800 calls can not be
> sent out LD circuits. They must go out the local.
We do have dedicated LD, but 0/1/0 is the local circuit; dialing
manually from the phone (instead of using the "speed dial") sends the
call out the same PRI. The only difference is that "Redirecting Number"
stuff which is hosing things up.
[ Post a follow-up to this message ]
|
|
|
|
|
|
|
|
|
|
|
Re: Transferring to Outside Lines from the IPCC ? |
|
|
|
|
05-31-07 06:11 PM
Kent Roberts wrote:
> If all the perms are correct, cti ports, css, route paterns, etc. then
> its fun time... 
My most unfavorite words!
All the CSS, etc, is correct; there are other "virtual lines" that do
work (that are also CFAs), so I'm trying to isolate if it's just the
800's that have a problem, or all of them.
[ Post a follow-up to this message ]
|
|
|
|
|
|
|
|
|
|
|
Re: Transferring to Outside Lines from the IPCC ? |
|
|
|
|
05-31-07 06:11 PM
robert,
you definately have a rdnis problem. i can think of two ways to fix this.
with mgcp you can uncheck the 'enable outbound rdnis' on the t1 pri
mgcp ccmadmin page.
with h323 you need to use a voice translation profile on your gateway
to strip the redirected number info before you sent your q931 setup
msg.
justin
On 5/31/07, Robert Kulagowski <bob@smalltime.com> wrote:
> Kent Roberts wrote:
>
> My most unfavorite words!
>
> All the CSS, etc, is correct; there are other "virtual lines" that do
> work (that are also CFAs), so I'm trying to isolate if it's just the
> 800's that have a problem, or all of them.
>
>
> ________________________________________
_______
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
[ Post a follow-up to this message ]
|
|
|
|
|
|
|
|
|
|
|
Re: Transferring to Outside Lines from the IPCC ? |
|
|
|
|
05-31-07 06:11 PM
> you definately have a rdnis problem. i can think of two ways to fix this.
> with h323 you need to use a voice translation profile on your gateway
> to strip the redirected number info before you sent your q931 setup
> msg.
Third way - uncheck "Redirecting Number IE Delivery - Outbound" on the
gateway configuration page?
Because I've got it checked now - I'll have to wait until things quiet
down and try it out.
Thanks for the clue.
[ Post a follow-up to this message ]
|
|
|
|
|
|
|
|
|
|
|
Re: Transferring to Outside Lines from the IPCC ? |
|
|
|
|
05-31-07 06:11 PM
ya thats what i meant.
make sure you arent using rdnis for centralized vm with voice over
pstn as it will break that functionality.
On 5/31/07, Robert Kulagowski <bob@smalltime.com> wrote:
>
>
> Third way - uncheck "Redirecting Number IE Delivery - Outbound" on the
> gateway configuration page?
>
> Because I've got it checked now - I'll have to wait until things quiet
> down and try it out.
>
> Thanks for the clue.
> ________________________________________
_______
> cisco-voip mailing list
> cisco-voip@puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
[ Post a follow-up to this message ]
|
|
|
|
|
|
|
|
Sponsored Links |
|
|
|
|
 |
All times are GMT. The time now is 06:12 AM. |
 |
|
|
 |
|
 |
|
|
 |
|
Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
|
HTML code is OFF
vB code is ON
Smilies are ON
[IMG] code is OFF
|
|
|
|
Medical and Health forum | Computer Games Reviews | Graphics design forum
|
 |
|
 |
|
