Transferring to Outside Lines from the IPCC ?

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 solely for the use of the
addressee(s) named above. This communication may contain
material protected by attorney-client, work product, or
other privileges. If you are not the intended recipient or
person responsible for delivering this confidential
communication to the intended recipient, you have received
this communication in error, and any review, use,
dissemination, forwarding, printing, copying, or other
distribution of this e-mail message and any attached files
is strictly prohibited. Dickstein Shapiro reserves the right
to monitor any communication that is created, received, or
sent on its network.  If you have received this confidential
communication in error, please notify the sender immediately
by reply e-mail message and permanently delete the original
message. 
> 
> To reply to our email administrator directly, send an
email to postmasterdicksteinshapiro.com
> 
> Dickstein Shapiro LLP
> http://www.DicksteinS
hapiro.com
>
============================================================
==================
> 
> 
>
------------------------------------------------------------
------------
> 
> _______________________________________________
> cisco-voip mailing list
> cisco-voippuck.nether.net
> h
ttps://puck.nether.net/mailman/listinfo/cisco-voip
_______________________________________________
cisco-voip mailing list
cisco-voippuck.nether.net
h
ttps://puck.nether.net/mailman/listinfo/cisco-voip

> 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.

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-voippuck.nether.net
h
ttps://puck.nether.net/mailman/listinfo/cisco-voip

>     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

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.
_______________________________________________
cisco-voip mailing list
cisco-voippuck.nether.net
h
ttps://puck.nether.net/mailman/listinfo/cisco-voip

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.


_______________________________________________
cisco-voip mailing list
cisco-voippuck.nether.net
h
ttps://puck.nether.net/mailman/listinfo/cisco-voip

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 <bobsmalltime.com> wrote:
> 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.
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voippuck.nether.net
> h
ttps://puck.nether.net/mailman/listinfo/cisco-voip
>
_______________________________________________
cisco-voip mailing list
cisco-voippuck.nether.net
h
ttps://puck.nether.net/mailman/listinfo/cisco-voip

> 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.
_______________________________________________
cisco-voip mailing list
cisco-voippuck.nether.net
h
ttps://puck.nether.net/mailman/listinfo/cisco-voip

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 <bobsmalltime.com> wrote:
> > 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.
> _______________________________________________
> cisco-voip mailing list
> cisco-voippuck.nether.net
> h
ttps://puck.nether.net/mailman/listinfo/cisco-voip
>
_______________________________________________
cisco-voip mailing list
cisco-voippuck.nether.net
h
ttps://puck.nether.net/mailman/listinfo/cisco-voip