[cisco-voip] PRI Redirectling number
Nick Marus
nmarus at gmail.com
Mon Dec 15 09:00:24 EST 2008
Here is essentially what i am trying to accomplish. Seems that blocking this
would defeat this type of setup.
http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a00807f54aa.shtml
On Sun, Dec 14, 2008 at 1:49 PM, Mark Holloway <mh at markholloway.com> wrote:
> The provider is going to use the redirecting number for billing purposes
> in the event you forwarding outside you local LATA. I'm fairly certain the
> provider is not going to pass the redirecting number in the ISDN setup on
> the second call leg. I would have to dig out my old ISDN books to validate
> this.
>
>
>
> *From:* cisco-voip-bounces at puck.nether.net [mailto:
> cisco-voip-bounces at puck.nether.net] *On Behalf Of *Nick Marus
> *Sent:* Saturday, December 13, 2008 9:53 PM
> *To:* cisco-voip at puck-nether.net
> *Subject:* [cisco-voip] PRI Redirectling number
>
>
>
> Anyone ever hear of a provider blocking the redirecting number field in a
> pri call? Or could it be something else???
>
> I have 2 sites. The calling site q931 debug shows the correct redirecting
> data. The receiving site does not get it. I have redirecting IE checked for
> both inbound and outbound calls on both pri's.
>
>
> Calling side:
>
> Calling Party Number i = 0x2183, 'XXXXXXXXXX'
> Plan:ISDN, Type:National
> Called Party Number i = 0x80, '1XXXXXXXXXX'
> Plan:Unknown, Type:Unknown
> Redirecting Number i = 0x000082, 'XXXXXXXXXX'
> Plan:Unknown, Type:Unknown
>
>
> Receiving Side.
>
> Dec 14 04:01:46.094: ISDN Se0/1/0:23 Q931: RX <- SETUP pd = 8 callref =
> 0x00A5
>
> Bearer Capability i = 0x8090A2
>
> Standard = CCITT
>
> Transfer Capability = Speech
>
> Transfer Mode = Circuit
>
> Transfer Rate = 64 kbit/s
>
> Channel ID i = 0xA98381
>
> Exclusive, Channel 1
>
> Facility i = 0x9F8B0100A10F02010106072A8648CE1500040A0100
>
> Protocol Profile = Networking Extensions
>
> 0xA10F02010106072A8648CE1500040A0100
>
> Component = Invoke component
>
> Invoke Id = 1
>
> Operation = InformationFollowing (calling_name)
>
> Name information in subsequent FACILITY
> message
>
> Progress Ind i = 0x8283 - Origination address is non-ISDN
>
> Calling Party Number i = 0x2183, 'XXXXXXXXXX'
>
> Plan:ISDN, Type:National
>
> Called Party Number i = 0x80, 'XXXX'
>
> Plan:Unknown, Type:Unknown
>
> Dec 14 04:01:46.110: ISDN Se0/1/0:23 Q931: TX -> CALL_PROC pd = 8 callref
> = 0x80A5
>
> Channel ID i = 0xA98381
>
> Exclusive, Channel 1
>
> Dec 14 04:01:46.114: ISDN Se0/1/0:23 Q931: TX -> ALERTING pd = 8 callref =
> 0x80A5
>
> Progress Ind i = 0x8088 - In-band info or appropriate now available
>
> Dec 14 04:01:46.186: ISDN Se0/1/0:23 Q931: TX -> CONNECT pd = 8 callref =
> 0x80A5
>
> Display i = 'VoiceMail'
>
> Dec 14 04:01:46.198: ISDN Se0/1/0:23 Q931: RX <- CONNECT_ACK pd = 8
> callref = 0x00A5
>
> Dec 14 04:01:46.402: ISDN Se0/1/0:23 Q931: RX <- FACILITY pd = 8 callref =
> 0x00A5
>
> Facility i =
> 0x9F8B0100A117020101020100800F41544C414E54412020202020204741
>
> Protocol Profile = Networking Extensions
>
> 0xA117020101020100800F41544C414E54412020202020204741
>
> Component = Invoke component
>
> Invoke Id = 1
>
> Operation = CallingName
>
> Name Presentation Allowed Extended
>
> Name = ATLANTA GA
>
> Dec 14 04:02:00.234: ISDN Se0/1/0:23 Q931: RX <- DISCONNECT pd = 8 callref
> = 0x00A5
>
> Cause i = 0x8090 - Normal call clearing
>
> Dec 14 04:02:00.250: ISDN Se0/1/0:23 Q931: TX -> RELEASE pd = 8 callref =
> 0x80A5
>
> Dec 14 04:02:00.282: ISDN Se0/1/0:23 Q931: RX <- RELEASE_COMP pd = 8
> callref = 0x00A5
>
>
> --
> Nick Marus
> nmarus at gmail.com
>
--
Nick Marus
nmarus at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20081215/b55edc65/attachment.html>
More information about the cisco-voip
mailing list