Summary:	ASTERISK-07671: Redirecting Number (RDNIS) problem
Reporter:	inspired (inspired)	Labels:
Date Opened:	2006-09-04 07:54:49	Date Closed:	2007-06-21 14:17:07
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) PBX_differences.pdf
Description:	I have been debugging a problem together with my telco with setting Redirecting Number (RDNIS) from our PBX. The problem is that when Redirecting Number is set for a call, it won't go through. It stops at a "Sending PROGRESS" message from the Asterisk CLI. We debugged this for a few days, and involved Nortel as well. The switch at our telco is a DMS100. We have tried both switchtype=euroisdn and switchtype=dms100, but the problem is the same. See "additional information" for the email I got from Nortel. They are waiting for an answer to close the case. ERICS01CONSOLL is the connection identifier to our Asterisk server on the telco switch. Attached is also a PDF file which shows the differences in the SETUP messages on the switches. TROLL01FJORD is a switch where Redirecting Number works. ****** ADDITIONAL INFORMATION ****** I've attached a file which shows difference between 2 setup messages from TROLL01FJORD and ERICS01CONSOLL. Progress Indicator, Prog_Ind Location, CGN_Digits & RGN_DIGITS, CGN_SI, NI-PRI CGN_SI_PI parameters are different in both and these are makes the same call different results. Basicly  CGN_Digits & RGN_DIGITS are same in ERICS01CONSOLL, please investigate, and let me to close this case, at least confirm for SD now.
Comments:	By: Serge Vecher (serge-v) 2006-09-05 10:37:15 inspired: if you are using a Digium card, please contact Digium Technical Support at support@digium.com, so they can help you with tracking the issue down. If the issue is narrowed down to being a bug in libpri, please reopen the bug with relevant information posted. By: inspired (inspired) 2006-11-07 05:37:54.000-0600 This cannot be a problem related to a Digium card or any other hardware, since hardware does not touch Q.931 signalling at all. By: Roy Sigurd Karlsbakk (rkarlsba) 2006-11-07 05:43:55.000-0600 I beleive we have a similar problem. We're connecting to Nortel switches as well, and we can't make RDNIS work, although everything apart from this seems ok. roy By: Matthew Fredrickson (mattf) 2006-11-10 15:22:02.000-0600 Can you explain your setup better, like how asterisk is involved in this, what directions the messages are going, whether this is an inbound call or outbound, or if this is even a hairpin of some sort?  I don't think I understand your problem from what you have said well enough to effectively help you out. By: inspired (inspired) 2006-11-16 03:34:07.000-0600 Ok, here is the setup: A call comes in from caller ID 99221199 to number 21659090 which has set up call forwarding to 41958122. We forward this call to 41958122, and set Redirecting Number at the same time so that 99221199 shows up as caller ID on the display on  41958122. This is what redirecting number does. It sets the original caller ID on a forwarding or a transfer. By: Matthew Fredrickson (mattf) 2006-11-16 14:09:32.000-0600 So what your saying, is that asterisk receives an inbound call over the PRI.  You set the RDNIS on the call, and then do a hairpin back to the telco (dial back out on the PRI trunkgroup).  When you do this, the second call does not go through.  Is this correct? By: inspired (inspired) 2006-11-29 02:52:00.000-0600 Yes, mattf, that is correct. By: Serge Vecher (serge-v) 2007-02-28 13:42:42.000-0600 any new developments here? By: inspired (inspired) 2007-03-12 05:08:52 Not from my side. I am still waiting for you to take a look at it. By: Roy Sigurd Karlsbakk (rkarlsba) 2007-03-12 05:33:54 AFAICS, Asterisk is not doing anything wrong here. Q.931 states, in table 3-31 (SETUP message content), that Redirecting number is valid only in direction network-to-user, meaning the switch will discard the message according to standard. roy By: SR67 (soulreaver67) 2007-04-06 19:41:23 If you want to change the caller ID number the receiving party gets, you must set CLID in your PRI setup.  This has nothing to do with RDNIS, or with the Digium card, and has everything to do with your setup. Either have someone come out with a TestPAD2209 or rent one and have someone who knows how to use it, plug it into the PRI coming from the network (DMS100 I believe you said).  Set up the CLID and dial it-- you'll see the switch pick it up and take it.  Then connect it intrusive (between) the DMS and your Digium card and MONITOR the circuit.  Capture the ISDN frames and look at the decode to see exactly what you are actually generating. By: Roy Sigurd Karlsbakk (rkarlsba) 2007-04-07 04:07:11 Firstly, we're talking about RDNIS as of 'A calls B, B diverts to C, C sees A's number', so B sets CALLERID(number/ani) to B's number and CALLERID(rdnis) to A's number. This way CDR records will show B called C, which is correct according to billing, and C sees A's number. Now, Q.931 states that the 'call forward number 0x74', which is called rdnis in asterisk, is a network-to-user extension, meaning it doesn't matter how much you set it, since as long as you're the CPE (and you normally are), there's no way to signal to the switch to tell it to show another number than your own roy By: SR67 (soulreaver67) 2007-04-07 13:54:37 Remember, every PRI the telco assigns has a BTN (billing telephone number) associated with it.  That is how they track billing, not by CLID OR ANI-I/II (which are different).  You must tell the carrier that you want them to pass the CLID you send, instead of them overriding and displaying the BTN when you outdial. If I plug a TBERD into a Adtran MUX to jump from T1 up to DS3, that DS3 will hand off to a Tellabs Titan 5500, then will hand off across DSX3 to the 5E.  5E will trunk it back out to the 5500 onto a higher level circuit (like OC1 -main backbone intown), will deliver to a business switch just off the ring via fujitsu then lower order channel bank then to biz soft-pbx (like asterisk) which will see the incoming call.  It picks up and has been programmed to simply forward inbound calls to my cell. A = TBERD         Caller = 912XXXXXXX; Called = 678XXXXXXX; BTN = 770XXXXXXX B = ASTERISK      Caller = 912XXXXXXX; Forwrd = 303XXXXXXX; BTN = 770XXXXXXX C = CELL          Caller = 912XXXXXXX; Called = 303XXXXXXX; In this case, the cellphone rings with the original caller ID generated by the TBERD.  Circuit AB is billed for call from A->B.  Circuit BC is billed for call to B->C. Remember, your DMS100 switch-tech isn't the sharpest apple out there-- he doesn't know his stuff.  That is a major problem with carriers today.  I spend considerable time in COs teaching telco people how their equipment works and how to do their jobs.  Everything from correctly wiring ANDA boxes, to understand PMs from the 5500 to performing provisioning on the 5E. You cannot assume things work the way you think by what you've read or by what your carrier is telling you.  Or that your carrier (or their equipment) is following standards 100%.  And the _only_ way to get a carrier to straighten out their act is to show them you've put a test set on it and they aren't passing something as they should.  Get a TBERD out there and MONITOR what's really going on.  In 20minutes you can find out exactly where the problem is.  You'll also get the cause-codes back. Their switch is stopping the call because of something it doesn't like.  Plain and simple.  Either it isn't expecting the NPA, it's misconfigured in a variety of ways, or the TG's misprovisioned. Good luck. By: SR67 (soulreaver67) 2007-04-07 14:03:13 In Q.931, the Call essentially progresses this way: 1. Caller sends a SETUP to the Switch. 2. If the SETUP is OK, the switch sends a CALL PROCeeding to the Caller, and   then a SETUP to the Receiver. 3. The Receiver gets the SETUP. If it is OK, then it rings the phone and sends   an ALERTING message to the Switch. 4. The Switch forwards the ALERTING message to the Caller. 5. When the receiver answers the call, is sends a CONNECT message to the Switch 6. The Switch forwards the CONNECT message to the Caller. 7. The Caller sends a CONNECT ACKnowledge message to the Switch 8. The Switch forwards the CONNECT ACK message to the Receiver. 9. Done. The connection is now up. You need to determine where in this Layer 3 sequence, that "Sending Progress" is generated and then check everything you've done before then.  If that is RIGHT, then you know it's something the carrier is doing.  Misprovision, or Misoption related. Hope that helps. By: Roy Sigurd Karlsbakk (rkarlsba) 2007-04-07 15:19:28 We use asterisk CDR logs, so setting another callerid from asterisk will ruin our CDRs. Also, the way to send the call forward number (rdnis in asterisk) by the standard is to set call forward number 0x74 in the PRI SETUP, although this only works if you're on the network side, something you rarely are if using PRIs. In addition to this, some countries (or telcos) restrict the callerids to those that are allocated to a company. In norway, setting a callerid not in your own number range (including ported numbers, of cours) is prohibited. So just setting a new callerid is not OK, by standard or otherwise roy By: Matthew Fredrickson (mattf) 2007-06-21 14:17:06 This appears to be a limitation related to the network, since the rdnis value cannot be sent from user to network.