Cisco's vendor specific attributes and their format are followed as much as possible. Refer to the Cisco IOS Release 12.2 RADIUS VSA Voice Implementation Guide for a detailed description of these attributes. The Vendor Specific Attributes table lists the subset of VSAs that the VX system supports.
Note that the h323-call-origin (Call Direction) and h323-call-type are used to identify whether a CDR is ingress CDR or egress CDR. For ingress CDR the values of these fields are "originate" and "VoIP", where as for egress CDR the values will be "originate" and "Telephony". NET's Vendor id is 177.
|Table of Contents|
Vendor Specific Attributes
In order to match the Ingress and Egress CDRs, the h323-conf-id attribute should be used. This is true even if the Ingress or Egress Gateway is a Cisco Gateway.
To relate all the CDRs within an IVR session the h323-incoming-conf-id should be used.
Differences from Cisco
Difference from the Cisco implementation are listed below:
- For ANI authentication, the calling number is passed in the User-Name attribute.
- Cisco sends two accounting requests per call leg, where as the VX sends one two accounting requests per node in a call. For example in the scenario explained in section 1.2, Cisco generates 8 accounting requests where as VX generates only 4. VX generates one CDR for the ingress side and one more for egress side. The Ingress CDR is sent as the Call leg 2 cdr (h323-call-origin=originate, h323-call-type=VoIP) and the Egress CDR is sent as the Call leg 4 cdr (h323-call-origin=originate, h323-call-type=Telephony).
- Cisco sends accounting start request as soon as the incoming call is received, where as the VX sends it when the call is actually connected with the destination side.
- Cisco's vendor id is 9 and net.com's vendor id is 177.
- VX uses node id convention to identify nodes in the network, where as Cisco uses IP address convention. Therefore, when VX is used with BSP, the h323-remote-address will not have any value but the h323-remote-id will have the node id of the remote node.
VSAs NET-in-NAS-port and NET-out-NAS-port are used to indicate the shelf, slot, port, and channel information in the Accounting requests. The format of NET-in-NAS-port and NET-out-NAS-port attributes is "shelf:slot:port:channel". Example: "net-in-nas-port=0:0:0:21".
VSA net-default-pin is sent in all the Access requests where VX is auto filling the password with the user name. Example: "net-default-pin=1"
VSA net-dnis is sent in the Accounting requests. This field should indicate the actual number that the user dialed to reach the IVR. Example:"net-dnis=8005551212"
VSA net-initial-connect-time is sent in Accounting requests to indicate the time stamp of when the user was connected to the IVR to place this call.
VSA net-trunk-group indicates the incoming trunk group. This info may be used to substitute for carrier-id.
VSA net-call-cost may be used by the billing systems to assess the cost of the call, when two different databases are used: one for rating and one for CDRs.
NET-Specific Return Codes
The following are the potential values for the VSA h323-return-code in the access responses:
- net-need-pin (901): This return code is sent in the access response, if "net-default-pin" is present in the authentication requests and if the authentication failed. "net-default-pin" in the authentication requests indicates that the default PIN is sent in the request, before prompting the user to enter PIN (to handle the cards that do not have a PIN). The reason for sending a default PIN is for security (and RFC compliance) purposes. If there is a PIN associated with the card the RADIUS server should send an Access Reject with the disconnect cause of 901. Note that the RADIUS server should not authenticate the user if there is a PIN associated with the account (even if the default PIN matches the PIN associated), because a user's card number and PIN can be the same coincidentally.