RDNIS

RDNIS is Redirected Dialed Number Information Service. RDNIS contains Type of Number (TON), Presentation, and Redirecting Number (RGN), and Reason (busy, no answer, etc.). When redirecting calls, the Originally Called Number (OCN) contains, as its name suggests, the number that was originally called.

The RGN identifies the telephone number redirecting a call. For example, if one forwards a call on busy from home to another number, RGN contains the home number. This is useful if, for example, one is running a voice mail system and wants one incoming number to which everyone can forward calls. The RGN can then be used to determine the appropriate mailbox. This usually only works on a PRI.

Q.931 supports RDNIS Type of Number (TON), Presentation, and Redirecting Number (RGN). It is (IE) 115 on a DMS-100 switch, IE 116 on National-ISDN-2.

A note about wireless phones: the 'forward all calls' feature does not necessarily send RDNIS, but 'forward when busy', 'forward when unavailable', and 'forward when unreachable' are supposed to send RDNIS. Functionality may depend on wireless provider more than PRI provider.

Groupe Telecom and Bell Canada both support this on their PRIs.

Asterisk note

Asterisk only supports RGN, and at that, it's wrongly placed in the channel's Caller*ID information. The RGN can be set or retrieved using the CALLERID(rdnis) function, such as Set(CALLERID(rdnis)=5551212). The Dial application also sets the RGN to the current extension, unless called within a macro, in which case the contents of ${MACRO_EXTEN} are used instead. This overwrites anything else set within the dialplan, which may not be what a dialplan author would expect. Although IAX2 supports RGN in IE 27 (actually misnamed RDNIS), it does not appear to be properly passed to a peer when placing outgoing calls.


SIP implementation

In an invite during a call transfer, the RDNIS information is in the Diversion: header

The Diversion: header appears to have finally disappeared from the IETF track.
It appears that the History-Info: header is going to end up in an RFC.

See also

RDNIS is Redirected Dialed Number Information Service. RDNIS contains Type of Number (TON), Presentation, and Redirecting Number (RGN), and Reason (busy, no answer, etc.). When redirecting calls, the Originally Called Number (OCN) contains, as its name suggests, the number that was originally called.

The RGN identifies the telephone number redirecting a call. For example, if one forwards a call on busy from home to another number, RGN contains the home number. This is useful if, for example, one is running a voice mail system and wants one incoming number to which everyone can forward calls. The RGN can then be used to determine the appropriate mailbox. This usually only works on a PRI.

Q.931 supports RDNIS Type of Number (TON), Presentation, and Redirecting Number (RGN). It is (IE) 115 on a DMS-100 switch, IE 116 on National-ISDN-2.

A note about wireless phones: the 'forward all calls' feature does not necessarily send RDNIS, but 'forward when busy', 'forward when unavailable', and 'forward when unreachable' are supposed to send RDNIS. Functionality may depend on wireless provider more than PRI provider.

Groupe Telecom and Bell Canada both support this on their PRIs.

Asterisk note

Asterisk only supports RGN, and at that, it's wrongly placed in the channel's Caller*ID information. The RGN can be set or retrieved using the CALLERID(rdnis) function, such as Set(CALLERID(rdnis)=5551212). The Dial application also sets the RGN to the current extension, unless called within a macro, in which case the contents of ${MACRO_EXTEN} are used instead. This overwrites anything else set within the dialplan, which may not be what a dialplan author would expect. Although IAX2 supports RGN in IE 27 (actually misnamed RDNIS), it does not appear to be properly passed to a peer when placing outgoing calls.


SIP implementation

In an invite during a call transfer, the RDNIS information is in the Diversion: header

The Diversion: header appears to have finally disappeared from the IETF track.
It appears that the History-Info: header is going to end up in an RFC.

See also

Created by: linde, Last modification: Sat 18 of Oct, 2008 (21:04 UTC) by smurfix
Please update this page with new information, just login and click on the "Edit" or "Discussion" tab. Get a free login here: Register Thanks! - Find us on Google+