[Home]

Summary:ASTERISK-02547: RDNIS is always empty
Reporter:Frederic Steinfels (fredo)Labels:
Date Opened:2004-10-06 12:56:40Date Closed:2011-06-07 14:10:16
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:The RDNIS variable is always empty no matter what technology I am using (zap/bri, sip, iax).

****** ADDITIONAL INFORMATION ******

The purpose of my application is this:
- when transfering a call blindly/unattended to an extension
- dial back to the transferer if the extension in question does not pick up within 10secs or is busy
- if the call is not picked up there either, send it to a queue

As is my understanding, I will have to use RDNIS in oder to send back the call if the desired extension is not available.

Unfortunately RDNIS is always blank so I was able to use DNID, unfortunately this is only working for local calls or in other words if the person that was called was directly/uniquely called by a Dial command and not by a queue. I also had to put in a few quirks in order to allow both ends of the calls to be correctly transfered and bounced back (all possiblities are covered on local direct calls). As RDNIS is still and always empty for me as well (I am using Asterisk CVS-HEAD-08/13/04-12:00:00-BRI-stuffed-0.1.0-RC4a), I can not solve my issues with calls originating externally.


DNID contains the CALLERID of the "picked up by local phone" at the "forwarding to another lcoal phone" event BUT ONLY if

local caller calling =>picked up by local phone => forwarding to another local phone

RDNIS is empty when/though DNID is working



DNID and RDNIS are empty if

external iax2 caller => picked up by local phone => forwarding to another  local phone




my forwarding context (set with TRANSFER_CONTEXT when the call was created in order to make sure THIS context is taken)

exten => _1X,1,GotoIf($[${LEN(${TRANSFER_CONTEXT})} = 0]?2:5)
exten => _1X,2,Macro(channel,${CALLERIDNUM},${CHANNEL})
exten => _1X,3,SetVar(CALLINGCHANNEL=${MYCHANNEL})
exten => _1X,4,Goto(7)
exten => _1X,5,Macro(channel,${DNID},${CHANNEL})
exten => _1X,6,SetVar(CALLINGCHANNEL=${MYCHANNEL})
exten => _1X,7,Macro(channel,${EXTEN},${CHANNEL})
exten => _1X,8,SetVar(CALLEDCHANNEL=${MYCHANNEL})
exten => _1X,9,NoOp,"CALLINGCHANNEL"
exten => _1X,10,NoOp,${CALLINGCHANNEL}
exten => _1X,11,NoOp,"CALLEDCHANNEL"
exten => _1X,12,NoOp,${CALLEDCHANNEL}
exten => _1X,13,NoOp,"TRANSFER_CONTEXT"
exten => _1X,14,NoOp(${LEN(${TRANSFER_CONTEXT})})
exten => _1X,15,NoOp,${TRANSFER_CONTEXT}
exten => _1X,16,NoOp,"RDNIS "
exten => _1X,17,NoOp,${RDNIS}
exten => _1X,18,NoOp,"DNID"
exten => _1X,19,NoOp,${DNID}
exten => _1X,20,NoOp,"EXTEN"
exten => _1X,21,NoOp,${EXTEN}
exten => _1X,22,SetVar(TRANSFER_CONTEXT=transfering)
exten => _1X,23,Dial(${CALLEDCHANNEL},10,tTm)
exten => _1X,24,Dial(${CALLEDCHANNEL}&${CALLINGCHANNEL},15,tTm)
exten => _1X,25,Queue(all-q|t)
exten => _1X,26,Hangup
exten => _1X,123,Goto(50)
exten => _1X,124,Goto(25)
exten => _1X,50,Wait(8)
exten => _1X,51,Goto(24)


[macro-channel]
exten => s,1,SetVar(MYCHANNEL=${ARG2})
exten => s,2,GotoIf($[${ARG1} = 11]?3:4)
exten => s,3,SetVar(MYCHANNEL=Zap/g3/11)
exten => s,4,GotoIf($[${ARG1} = 12]?5:6)
exten => s,5,SetVar(MYCHANNEL=Zap/g3/12)
exten => s,6,GotoIf($[${ARG1} = 13]?7:8)
exten => s,7,SetVar(MYCHANNEL=Sip/gs1@gs1)
exten => s,8,GotoIf($[${ARG1} = 14]?9:10)
exten => s,9,SetVar(MYCHANNEL=Sip/gs2@gs2)
exten => s,10,GotoIf($[${ARG1} = 17]?11:12)
exten => s,11,SetVar(MYCHANNEL=Sip/cisco1@cisco1)
exten => s,12,NoOp,${MYCHANNEL}





debug on local calls

  -- Executing NoOp("Zap/8-1", "CALLINGCHANNEL") in new stack
  -- Executing NoOp("Zap/8-1", "Sip/gs1@gs1") in new stack
  -- Executing NoOp("Zap/8-1", "CALLEDCHANNEL") in new stack
  -- Executing NoOp("Zap/8-1", "Zap/g3/11") in new stack
  -- Executing NoOp("Zap/8-1", "TRANSFER_CONTEXT") in new stack
  -- Executing NoOp("Zap/8-1", "11") in new stack
  -- Executing NoOp("Zap/8-1", "transfering") in new stack
  -- Executing NoOp("Zap/8-1", "RDNIS ") in new stack
  -- Executing NoOp("Zap/8-1", "") in new stack
  -- Executing NoOp("Zap/8-1", "DNID") in new stack
  -- Executing NoOp("Zap/8-1", "13") in new stack
  -- Executing NoOp("Zap/8-1", "EXTEN") in new stack
  -- Executing NoOp("Zap/8-1", "11") in new stack


debug on external calls

  -- Executing NoOp("IAX2/0435440706@0435440706/5", "CALLINGCHANNEL") in new stack
  -- Executing NoOp("IAX2/0435440706@0435440706/5", "IAX2/0435440706@0435440706/5") in new stack
  -- Executing NoOp("IAX2/0435440706@0435440706/5", "CALLEDCHANNEL") in new stack
  -- Executing NoOp("IAX2/0435440706@0435440706/5", "Zap/g3/12") in new stack
  -- Executing NoOp("IAX2/0435440706@0435440706/5", "TRANSFER_CONTEXT") in new stack
  -- Executing NoOp("IAX2/0435440706@0435440706/5", "11") in new stack
  -- Executing NoOp("IAX2/0435440706@0435440706/5", "transfering") in new stack
  -- Executing NoOp("IAX2/0435440706@0435440706/5", "RDNIS ") in new stack
  -- Executing NoOp("IAX2/0435440706@0435440706/5", "") in new stack
  -- Executing NoOp("IAX2/0435440706@0435440706/5", "DNID") in new stack
  -- Executing NoOp("IAX2/0435440706@0435440706/5", "") in new stack
  -- Executing NoOp("IAX2/0435440706@0435440706/5", "EXTEN") in new stack
  -- Executing NoOp("IAX2/0435440706@0435440706/5", "12") in new stack
Comments:By: Mark Spencer (markster) 2004-10-06 19:35:20

Are you seeing RDNIS come in over the PRI?  It's only going to be there if the call was referred *and* they are giving you RDNIS information.
By: Frederic Steinfels (fredo) 2004-10-07 02:08:28

I do not have a PRI. I have a BRI and several IAX2 accounts. Anyway I do not really care about wheter an external call was referred or not. The problem I have is that I want blind transfers to bounce back to the transferrer if not answered within a certain amount of time or if busy. Therefore I need to know who issued the transfer. DNID is helping a bit but not if the referring phone was not called by a distinct dial command (group dial, queue dial; then it's empty AFAIK).
As is my (and those who documented it on voip-info.org) understanding of RDNIS, it should work this way. I could life with it if RDNIS was not transferred to external PBXs but I do not think it is so hard for asterisk to remember it.

If you are saying that's not what RDNIS is for, please consider this as a feature request and add a RDNIS2 variable always containing the referer.
Or fix to DNID variable to always contain the party that was called even on group/queue dials (which would make RDNIS=DNID, right?)
By: Brian West (bkw918) 2004-10-07 15:34:54

RDNIS isn't ment for this.  You can accomplish this in other ways in your dialplan.
By: Frederic Steinfels (fredo) 2004-10-07 16:07:55

Please give me a hint what you mean by other ways? Furthermore if you are sure RDNIS wasn't meant for this, you are saying the info on voip-info.org is wrong.
http://www.voip-info.org/tiki-index.php?page=RDNIS and http://www.voip-info.org/tiki-index.php?page=Asterisk%20variables
By: Mark Spencer (markster) 2004-10-07 17:13:36

Anybody using RDNIS that can confirm that it is not broken for PRI?
By: Brian West (bkw918) 2004-10-07 17:52:17

Redirected Dial Number Id Service --- so yes the wiki is WRONG on what it is.
By: Frederic Steinfels (fredo) 2004-10-07 18:05:51

Thanks for the answer bkw918 but this does not help me. What is the difference between a call that is transferred on an asterisk box or externally?

Even if RDNIS is really meant for some external PSTN or whatever, how can one reconnect a call to the transferrer? Yes, I was trying to use DNID and CALLERIDNUM but there are scenarious where that does not work (as described).

Maybe this question is silly but am I the only one having this problem? I do not think so. There are already two people monitoring this bug and varous threads in the mailinglist have not come up with a 100% working solution. Reconnecting the call with the previous channel is no solution as the channel information stored internally is missing important information.
By: Brian West (bkw918) 2004-10-07 18:09:33

I agree asterisk needs something in the channel struct to know who we were bridged to last.. sorta RDNIS like for internal transfers and redirects so you can have a call come back to the person that transfered it.
By: Frederic Steinfels (fredo) 2004-10-07 18:32:47

Although I don't get it why RDNIS should be handled differently on external or internal calls, I am very happy that you agree with me that my rquest is not too far fetched.
By: Mark Spencer (markster) 2004-10-08 00:11:33

Something like ${DIALEDPEERNAME} or ${DIALEDPEERNUMBER} ?
By: Frederic Steinfels (fredo) 2004-10-08 01:42:12

Yes, sounds great!
By: Mark Spencer (markster) 2004-10-08 01:47:36

Uhm those are already there.
By: Frederic Steinfels (fredo) 2004-10-08 02:00:02

Thanks. Indeed, this was briefly announced in the mailing list but not mentioned on the wiki page. Besides of various other variables that are not mentioned there...
Although I have never edited wiki yet, I'll see what I can do.
By: Frederic Steinfels (fredo) 2004-10-08 02:22:26

I have to bother you again. Those variables do not work as expected; I think it is obvious.

I was checking the contents of ${DIALEDPEERNAME} or ${DIALEDPEERNUMBER} in case of a transfer. DIALEDPEERNUMBER contained the channel name like, for example 'SIP/gs1-8b21'. DIALEDPEERNUMBER contained the part of the channel after the technology, in this case 'gs1-8b21'.

In other words, DIALEDPEERNUMBER is of absolutely no use and DIALEDPEERNAME should be renamed to DIALEDCHANNEL and a new set variables (DIALEDPEERNUMBER, DIALEDPEERNAME) has to be created.
By: Frederic Steinfels (fredo) 2004-10-08 05:22:54

As is my impression, the whole thing could be a major design problem in asterisk.

Quick fix: would it be possible to supply a magic number to the dial string or queue members that will be filled into the DNID variable or DIALEDPEERNUMBER variable in the moment the call is connected as it is not possible for the extension logic to find out who is going to pick up the call in a multi-channel dial or queue dial.
By: Brian West (bkw918) 2004-10-12 10:18:44

*hint* Cut  ... Show application cut
By: Frederic Steinfels (fredo) 2004-10-12 17:00:31

I see what you mean. For example if I have SIP/gs1-8b21, I should cut after and including the dash and use SIP/gs1 as callback.

This would be a very very ugly fix that might be working on a few technologies by accident if you hardcode/parse this variable in the dialplan.
For example the extension from which the call/transfer originated is lost and therefore backconnecting to that technology without knowing the extension will or could fail.

Example on ISDN/Zap/BRI:
In the dial command I'm using Dial(Zap/g3/extension). Asterisk will remember this as Zap/7 for example (or Zap/anynumber). The "g3" in the example stands for the port number (3 for example) where you can plug in an RJ45 isdn cable. Each port/cable has two channels. The phones connected to that port do not care on which channel they are called. As Asterisk is just remembering Zap/7, connecting back to Zap/7 will fail for two reasons:
- Zap/7 could be in use/busy although the second channel on that wire could be free but could not be accessed as this information (g3) was lost
- Due to the lack of the extension and the fact that ISDN phones will only ring/respond if they are called by their proper extension

I am not sure wheter none, some or all sip phones require the extension information or wheter that's configurable but that won't make it any better.
By: drwho17 (drwho17) 2004-10-26 09:38:44

In response to markster, I'm not able to get the RDNIS value via PRI from my provider, from multiple outside networks (Verizon, Nextel). My PRI provider claims to be sending all the info they receive. I have a pri debug on the span available at http://pastebin.com/113828, I'm only receiving the original calledfrom, and the forwarded to, not the original calledto. Please advise if there is something specific I should look for on the PRI debug

edited on: 10-26-04 10:22
By: Clod Patry (junky) 2004-10-26 12:32:51

maybe that sound a bit off-topic but that's will give more info.
I've a 900 number (900-123-5678) which is linked to a local number (514-555-9876).
BELL isnt sending the 900 number, just the dnis.
Brief, you need to have your own way to link the dnis (514-555-9876) to the real number (900-123-4567). It's probably a database, a hashtable, but you need to deal with this dnis.

So in ur extension.conf, you need to do something like:

exten => 5145559876,1,NoOP(mooooo);


you could ask them, how many digits they are sending to you.
make sure you have DEL0 (10 digits).
in some PRI in here, we have DEL3, and we're getting only 4 digits (the last one). BELL plans to change the DEL3 for sending 7 digits instead of 4. When i had the formation there, it was in developement.


try it, and if you need to NoOp it, use the var ${DNID}.

it works fine on my side.
By: drwho17 (drwho17) 2004-10-26 13:40:53

Thanks, but that's not exactly the same situation. I must have the original called number, it's how I will identify the users voicemail boxes as they are forwarded into the same extension. My situation looks like the following

Caller A dials B's number, B forwards to C which is the voicemail extension for all users. I identify the users voicemailbox by B's number, like

exten => _5172078360,1,VoiceMail,${RDNIS}

But since it's empty it's not working. My goal is to use one extension for all incoming voicemails.

edited on: 10-26-04 14:06
By: Brian West (bkw918) 2004-10-26 14:37:41

drwho17 then your telco isn't setting/sending the rdnis.  Get a bat and beat them with it.  Also post a pri intense debug span X and make a call that redirects.  Also you can drop the _ since your not doing a pattern match.

bkw
By: cotcomsol (cotcomsol) 2004-10-27 00:23:48

I'm having the same problem with a PRI and not receiving RDNIS.  I have the switch in the same building and have access to it, so I can check things there if it helps, but it is configured to send all data it can.

Here is my intensive pri debug while calling:

< [ 00 01 01 2f ]

< Supervisory frame:
< SAPI: 00  C/R: 0 EA: 0
<  TEI: 000        EA: 1
< Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
< N(R): 023 P/F: 1
< 0 bytes of data
-- ACKing all packets from 22 to (but not including) 23
-- Since there was nothing left, stopping T200 counter
-- Stopping T203 counter since we got an ACK
-- Nothing left, starting T203 counter
-- Got RR response to our frame
-- Restarting T203 counter

< [ 02 01 2e 2e 08 02 00 1e 05 04 03 80 90 a2 18 04 e9 80 83 81 1e 02 82 83 6c 0c 21 80 34 30 36 36 32 34 30 30 30 33 70 0b a1 34 30 36 36 32 34 30 30 37 30 ]

< Informational frame:
< SAPI: 00  C/R: 1 EA: 0
<  TEI: 000        EA: 1
< N(S): 023   0: 0
< N(R): 023   P: 0
< 47 bytes of data
-- ACKing all packets from 22 to (but not including) 23
-- Since there was nothing left, stopping T200 counter
-- Stopping T203 counter since we got an ACK
-- Nothing left, starting T203 counter
< Protocol Discriminator: Q.931 (8)  len=47
< Call Ref: len= 2 (reference 30/0x1E) (Originator)
< Message type: SETUP (5)
< [04 03 80 90 a2]
< Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer capability: Speech (0)
<                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
<                              Ext: 1  User information layer 1: u-Law (34)
< [18 04 e9 80 83 81]
< Channel ID (len= 6) [ Ext: 1  IntID: Explicit, PRI Spare: 0, Exclusive Dchan: 0
<                        ChanSel: Reserved
<                       Ext: 1  DS1 Identifier: 0
<                       Ext: 1  Coding: 0   Number Specified   Channel Type: 3
<                       Ext: 1  Channel: 1 ]
< [1e 02 82 83]
< Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Public network serving the local user (2)
<                               Ext: 1  Progress Description: Calling equipment is non-ISDN. (3) ]
< [6c 0c 21 80 34 30 36 36 32 34 30 30 30 33]
< Calling Number (len=14) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
<                           Presentation: Presentation permitted, user number not screened (0) '4066240003' ]
< [70 0b a1 34 30 36 36 32 34 30 30 37 30]
< Called Number (len=13) [ Ext: 1  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '4066240070' ]
Sending Receiver Ready (24)

> [ 02 01 01 30 ]
> Supervisory frame:
> SAPI: 00  C/R: 1 EA: 0
>  TEI: 000        EA: 1
> Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
> N(R): 024 P/F: 0
> 0 bytes of data
-- Restarting T203 counter
-- Restarting T203 counter

> [ 00 01 2e 30 08 02 80 1e 02 18 03 a9 83 81 ]

> Informational frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 000        EA: 1
> N(S): 023   0: 0
> N(R): 024   P: 0
> 10 bytes of data
-- Restarting T203 counter
Stopping T_203 timer
Starting T_200 timer
> Protocol Discriminator: Q.931 (8)  len=10
> Call Ref: len= 2 (reference 32798/0x801E) (Terminator)
> Message type: CALL PROCEEDING (2)
> [18 03 a9 83 81]
> Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0
>                        ChanSel: Reserved
>                       Ext: 1  Coding: 0   Number Specified   Channel Type: 3
>                       Ext: 1  Channel: 1 ]
   -- Executing ^[[1;36;40mVoiceMail^[[0;37;40m("^[[1;35;40mZap/1-1^[[0;37;40m", "^[[1;35;40mu^[[0;37;40m") in new stack
^M^[[1;30;40m    -- ^[[0;37;40mAccepting call from '4066240003' to '4066240070' on channel 0/1, span 1
^M
> [ 00 01 30 30 08 02 80 1e 07 18 03 a9 83 81 1e 02 81 82 ]
> Informational frame:
> SAPI: 00  C/R: 0 EA: 0
>  TEI: 000        EA: 1
> N(S): 024   0: 0
> N(R): 024   P: 0
> 14 bytes of data
T_200 timer already going (2)
> Protocol Discriminator: Q.931 (8)  len=14
> Call Ref: len= 2 (reference 32798/0x801E) (Terminator)
> Message type: CONNECT (7)
> [18 03 a9 83 81]
> Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0, Exclusive Dchan: 0
>                        ChanSel: Reserved
>                       Ext: 1  Coding: 0   Number Specified   Channel Type: 3
>                       Ext: 1  Channel: 1 ]
> [1e 02 81 82]
> Progress Indicator (len= 4) [ Ext: 1  Coding: CCITT (ITU) standard (0) 0: 0   Location: Private network serving the local user (1)
>                               Ext: 1  Progress Description: Called equipment is non-ISDN. (2) ]

< [ 00 01 01 30 ]
< Supervisory frame:
< SAPI: 00  C/R: 0 EA: 0
<  TEI: 000        EA: 1
< Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
< N(R): 024 P/F: 0
< 0 bytes of data
-- ACKing all packets from 22 to (but not including) 24
-- ACKing packet 23, new txqueue is 24 (-1 means empty)
-- Something left to transmit (24), restarting T200 counter

< [ 00 01 01 32 ]

< Supervisory frame:
< SAPI: 00  C/R: 0 EA: 0
<  TEI: 000        EA: 1
< Zero: 0     S: 0 01: 1  [ RR (receive ready) ]
< N(R): 025 P/F: 0
< 0 bytes of data
-- ACKing all packets from 23 to (but not including) 25
-- ACKing packet 24, new txqueue is -1 (-1 means empty)
-- Since there was nothing left, stopping T200 counter
-- Nothing left, starting T203 counter
-- Restarting T203 counter

< [ 02 01 30 32 08 02 00 1e 0f ]

< Informational frame:
< SAPI: 00  C/R: 1 EA: 0
<  TEI: 000        EA: 1
< N(S): 024   0: 0
< N(R): 025   P: 0
< 5 bytes of data
-- ACKing all packets from 24 to (but not including) 25
-- Since there was nothing left, stopping T200 counter
-- Stopping T203 counter since we got an ACK
-- Nothing left, starting T203 counter
< Protocol Discriminator: Q.931 (8)  len=5
< Call Ref: len= 2 (reference 30/0x1E) (Originator)
< Message type: CONNECT ACKNOWLEDGE (15)
Sending Receiver Ready (25)
By: Paul Cadach (pcadach) 2004-10-31 10:55:22.000-0600

Check ticket ASTERISK-2716 - it contains patch for app_dial to pass RDNIS information when channel driver informs that call must be forwarded.

And, as answer to Mark's question, RDNIS is coming over the PRI correctly (double redirecting number IE is bug of either Huawei's C&C08 exchange where I have PRI connection or cellular network which I used to make redirection):
< Protocol Discriminator: Q.931 (8)  len=77
< Call Ref: len= 2 (reference 1201/0x4B1) (Originator)
< Message type: SETUP (5)
< [a1]
< Sending Complete (len= 1)
< [04 03 80 90 a3]
< Bearer Capability (len= 5) [ Ext: 1  Q.931 Std: 0  Info transfer capability: Speech (0)
<                              Ext: 1  Trans mode/rate: 64kbps, circuit-mode (16)
<                              Ext: 1  User information layer 1: A-Law (35)
< [18 03 a1 83 9c]
< Channel ID (len= 5) [ Ext: 1  IntID: Implicit, PRI Spare: 0, Preferred Dchan: 0
<                        ChanSel: Reserved
<                       Ext: 1  Coding: 0   Number Specified   Channel Type: 3
<                       Ext: 1  Channel: 28 ]
< [6c 0c 21 83 33 33 33 32 31 37 31 39 33 35]
< Calling Number (len=14) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
<                           Presentation: Presentation allowed of network provided number (3) '3332171935' ]
< [70 0b a1 33 32 33 32 32 30 30 39 39 35]
< Called Number (len=13) [ Ext: 1  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1) '3232200995' ]
< [74 0d 21 00 81 33 33 33 32 31 37 31 39 33 36]
< Redirecting Number (len=15) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
<                               Ext: 0 Presentation: Presentation permitted, user number not screened (0)
<                               Ext: 1 Reason: Forwarded on busy (1) '3332171936' ]
< [74 0d 21 00 80 33 33 33 32 31 37 31 39 33 36]
< Redirecting Number (len=15) [ Ext: 0  TON: National Number (2)  NPI: ISDN/Telephony Numbering Plan (E.164/E.163) (1)
<                               Ext: 0 Presentation: Presentation permitted, user number not screened (0)
<                               Ext: 1 Reason: Unknown (0) '3332171936' ]
< [7d 02 91 81]
< IE: High-layer Compatibility (len = 4)
By: Paul Cadach (pcadach) 2004-11-05 10:46:23.000-0600

2junky - any updates on this ticket? Any news from your telco about providing calling/redirecting party information?
By: Mark Spencer (markster) 2004-11-07 11:21:50.000-0600

Okay given pcadach's confirmation that it's working in CVS, I'm going to close this one out.