NumberGroup API

Contents

  1. Contents
  2. Introduction
  3. Approach and security
  4. Overview
  5. Methods
    1. Translation Request
    2. Translation Update
    3. Reservations
    4. CDR Feed

Introduction

The NumberGroup API is a Web Services API which provides machine-to-machine access to specific provisioning features, allowing an operator to easily integrate web sites and other third-party systems into the NumberGroup provisioning portal. This provides automated number assigning and ongoing management, enabling for example:

This API is an evolving feature of the NumberGroup network, we welcome suggestions and will accommodate any additional business requirements. For further information, please email support@numbergroup.com.

This document provides a developer with details of each API method supported and examples of how to call each method. For clarity, URL parameters are presented here without any URL encoding. It is assumed that the developer or any underlying API will provide URL encoded query parameters.

Approach and security

API calls can be issued from any host capable of issuing Web Services requests to standard the standard HTTPS port on the host api.numbergroup.com. Although some API calls may result in a chain of several commands to reach an ultimate goal, each command constitutes an end to end transaction and does not require a dialogue in which a single transaction is processed over several requests.

Clients should use our secure API using https://api.numbergroup.com/. This server uses Numbergroup's wildcard certificate however it is beneficial to allot any certificate from your client.

The API does not require authentication other than the presence of an API Key which identifies the account in which transactions are carried out against. There is no MD5 challenge.

The API is logged against each host which issues transactions. When a new host issues transaction against a unique API Key, the API allows the transaction to succeed but subsequently logs the new host address against a record of host addresses which have queried the given API Key. An email is sent to the account contact informing them of the new host. If you receive an email informing you of a new host but are not aware of the host, contact NumberGroup immediately and we will provide you with a new API Key, disabling the existing one.

Overview

The API is a standard Web Services API, exploiting an HTTP GET call for each method. Parameters should be provided by the client using URL encoded query parameters. The API presents a response contained in the body of the HTTP response in the format requested, supported response formats are JSON and XML.

For example in JSON:

http://api.numbergroup.com/translationrequest?api_key=xxxyyy&ddi_type=0800&translation=441234567890&format=json

Responds with:

{"translation":{"translates_to":441234567890,"ddi_type":800,"ddi":8000588026},"status":{"reason":"","type":"success"}}

And in XML:

http://api.numbergroup.com/translationrequest?api_key=xxxyyy&ddi_type=0800&translation=441234567890&format=xml

Responds with:

<?xml version="1.0"?>
<translationrequest>
  <status type="success" reason=""/>
  <translation>
    <ddi>08000588028</ddi>
    <ddi_type>0800</ddi_type>
    <translates_to>441234567890</translates_to>
  </translation>
</translationrequest>

Note that for JSON requests, an object is returned which contains a "status" object which includes a "type" pair to determine the success or failure or the response, allowing the client to determine whether or not to parse for additional results in the response. The XML document returned is encapsulated in an element which is always named after the method, like the JSON response the XML document always contains a status element to identify the success of the transaction.

Each method call requires an API Key which both identifies the caller and the account in which all requests should interact with. If you do not have an API Key, please contact Numbergroup to obtain one.
Each API Key has an allowed transaction limit, which is usually 1000 transactions per day. If your implementation is likely to require more transactions then please contact Numbergroup.

Methods

This section describes all of the methods which are available through the NumberGroup API. Each method is accessed through a root context at api.numbergroup.com, for example to request a translation, the method is accessed at http://api.numbergroup.com/translationrequest.

Each call to a method will respond with an object or element in the root of the response containing a "status" element or object which in turn contains a "type" pair or element containing either "success" or "fail" to indicate the outcome of the call. This gives the client an indication as to whether to attempt to locate the structure of the remainder of the response.

The method can be used to create a translation which is only available for a set number of days, for example if the client requesting the translation is part of an auction site then a "time to live" for the translation can be requested for the duration of the auction, after which the DDI will be unassigned and the DDI returned to the available pool. DDI TTL lifetimes can be extended using the translationupdate API method.

Translation Request

This method allows a client to request a DDI to be mapped to the account to which the API Key is associated, and for a basic translation to be mapped to the DDI. A translation request can be requested based on any of the following criteria:

When executing the request, the client must also specify the destination to which the DDI must be translated to. The translationrequest method only supports a basic "here to there" translation, to enable advanced functionality, such a voice messaging, issue the translationrequest with the basic destination criteria, then issue a translationupdate call to apply advanced parameters.

Usage

http://api.numbergroup.com/translationrequest?api_key=xxxyyy&ddi_type=01&ddi_subtype=01908&translation=4412340012345&ttl=30

Specifying the translation

The destination can be either a PSTN destination as services by the NumberGroup network, a SIP destination using unsolicited INVITEs, a SIP Trunk registered with the NumberGroup network, or a media stream, such as a Shoutcast Server. For each destination type, format the translation in URL encoding as per the following table:

Destination type
Format
Example
E.164
Fully International PSTN number, without leading zeros or pluses.
&translation=441234945001
SIP
SIP host specified only, NumberGroup adds the E.164 automatically as the user part of the SIP URI.
&translation=sip:sip.myserver.com
Fully qualified SIP
Full SIP URI, NumberGroup sends the INVITE to the URI specified.
&translation=sip:1001@sip.mypbx.com
Trunk
A Trunk ID registered with NumberGroup.
&translation=trunk:T-M00123456-001
Stream
A media stream accessible from the Internet.
&translation=stream:mp3.myiceserver.com/stream.mp3

Parameters

The parameters available in the query string are as follows:

Parameter
Usage
Required
api_key
The API Key relating to theallocate account to  against.
Yes
format
Result format, xml or json.
No
ddi_type
The type of number required, e.g. 01, 03, or 0800.
Yes
ddi_subtype
If "01" is selected for the ddi_type, this would be the area code you want, e.g. "01234".
No
translation
The destination to send all calls against this DDI to (see table above).
Yes
ddi
Optionally may be used to identify the exact E.164 to allocate.
No
ttl
If specified, the DDI will only be allocated for the number of days specified in the TTL.
No
name
If specified, sets the "name" field on selfcare
No

Response

The translationrequest API provides the following response.

<?xml version="1.0"?>
<translationrequest>
  <status type="success" reason=""/>
  <translation>
    <ddi>08444109713</ddi>
    <ddi_type>0844</ddi_type>
    <translates_to>447779263488</translates_to>
    <expires>2010-08-30 01:08:17</expires>
  </translation>
</translationrequest>

The <translation> element within the root <translationrequest> response is provided whenever a <status type="success"> status element response is provided. The supplied fields are:

Key
Format
Description
ddi
String
The DDI assigned, human readable.
ddi_type
String
The range the DDI was obtained from, e.g. 0800, 03 etc.
translation
String
The translation provided, converted into the platform accepted format.
expires
String (date/time)
The time in UTC the translation will expire, only provided if &ttl= is provided.

If a <translationrequest> response is provided containing a <status type="fail", reason="foo"> response, then the possible reasons are as follows:

Reason
Description
IP Address Blocked (aaa.bbb.ccc.ddd)
The requesting IP address has been blocked by the API for suspicious activity. Contact support@numbergroup.com for further information.
No API key specified
No &api_key=xxxyyy parameter was provided.
Invalid API key specified
The &api_key= parameter provided does not match a configured API key.
No translation specified
No &translation= parameter was specified.
No DDI or DDI Type specified
No &ddi= or &ddi_type= parameters were provided, at least one must be provided.
Invalid TTL
The &ttl= parameter could not be parsed into an amount of days.
Exceeded allowed transaction limits
The api key specified has issues too many transactions for the day or month, contact support@numbergroup.com.
Invalid ddi type
The &ddi_type= parameter could not be matched against a list of available DDI types.
Specified subtype does not exist
The &ddi_subtype= could not be found or is not allocated to the &ddi_type= group provided.
Cannot allocate requested DDI
The DDI requested could not be allocated, either because it does not exist or because it is reserved against another api key.
Internal account error
There is a problem with your account, contact support@numbergroup.com.
Invalid translation address
The &translation= provided could not be interpreted.
Unsupported translation destination
The &translation= provided could not be determined as billable against the account, usually this is because the PSTN destination provided is not supported.
DDI type or DDI does not match DDI type requested
The combination of &ddi_type= and &ddi= or &subtype= do not match our records.

Translation Update

The translationupdate method can be used to update the destination of an existing translation provided the existing translation is mapped to the same account as the API Key. It can also be used to remove a translation by specifying the &delete=1 parameter. A translation must exist in order to use this method, for advanced translation requests, use the translationrequest method followed by the translationupdate method.

The translationupdate method is used either to present a new destination to an existing translation, or to enhance the setup of a newly created translation. When updating a translation destination, if previously translationupdate had been used to set additional features such as voicemail, it is not necessary to repeat the features. Any parameters omitted from the request will not be overwritten.

Usage

http://api.numbergroup.com/translationrequest?api_key=xxxyyy&ddi=448001230987&translation=4412340012345,4419080087123&translation_mode=even&call_failure_mode=voicemail&alert_address=sales@numbergroup.com

Parameters

The parameters available in the query string are as follows:

Parameter
Usage
Required
api_key
The API Key relating to the account to update against.
Yes
format
Result format, xml or json.
No
translation
The destination to send all calls against this DDI to (see table above). Multiple translations destinations can be specified as comma separated values.
No
ddi
Used to identify the exact E.164 to update.
Yes
ttl
If specified, the DDI lifetime will only be extended for the number of days specified in the TTL.
No
translation_mode
When multiple translation addresses are specified, this determines the hunting strategy. This can be "inturn", "together" or "even". "even" is like "inturn" but the order is randomised each call.
No
alert_address
When &call_failure_mode= is specified, this is the email address to send alerts to.
No
call_failure_mode
When no destination answers the call, determines the next course of action. Can be either "NONE" for no further action, "EMALERT" for a missed call alert, or "EMVCEMAIL" for voicemail.
No
ring_timer
Determines the amount of time to allow destinations to ring before either moving to the next destination or sending an alert.
No
delete
When &delete=1 is present in the query string, the translation is removed and returned to the available pool. The DDI will cease to work.
No
name
If specified, sets the "name" field on selfcare
No

Response

The translationupdate method provides a similar response to translationupdate:

<?xml version="1.0"?>
<translationupdate>
  <status type="success" reason=""/>
  <translation>
    <ddi>448001230987</ddi>
    <ddi_type>01</ddi_type>
    <translates_to>4412340012345,4419080087123</translates_to>
  </translation>
</translationupdate>

Reservations

The reservations method allows a client to search for available (unallocated) DDIs, which are temporarily reserved for the client session and not presented to any other requester during the period of the reservation. This allows a client to be able to obtain a list of available DDIs, present them to a user through a different interface, then return to the API to allocate the DDI through a translationrequest method.

The reservations method uses a "session_id" key and parameter between the API and the client to identify multiple reservations sessions which the client and the API may have in progress simultaneously. It is important that the client maintains this session identifier uniquely for each user session throughout the process, as the DDI cannot be allocated unless the correct session identifier is passed as a parameter.

The process is as follows:

1. The client calls the reservations method:
http://api.numbergroup.com/reservations?api_key=xxxyyy&ddi_type=01&ddi_subtype=01234

2. The API responds with a list of up to 20 available DDIs matching the criteria provided:

<?xml version="1.0"?>
<reservations>
  <status type="success" reason=""/>
  <session_id value="nu4ko7a4sc"/>
    <ddi_list>
      <ddi_item>
        <ddi>441234945002</ddi>
        <display_as>01234945002</display_as></ddi_item>
      <ddi_item>
        <ddi>441234945005</ddi>
        <display_as>01234945005</display_as>
      </ddi_item>
      <ddi_item>
        <ddi>441234945006</ddi>
        <display_as>01234945006</display_as>
      </ddi_item>
      <ddi_item>
        <ddi>441234945008</ddi>
        <display_as>01234945008</display_as>
      </ddi_item>

      ... up to 20 DDIs provided

    </ddi_list>
</reservations>

3. The client handles the response and interacts with the end user.

4. The client reserves one or more DDIs from the list through the reservations API:

http://api.numbergroup.com/reservations?api_key=xxxyyy&ddi=441234945132&session_id=nu4ko7a4sc&reserve

5. The API responds to the reservation request:

<?xml version="1.0"?>
<reservations>
  <status type="success" reason="DDI Reserved"/>
</reservations>

6. The client calls the translationrequest method to allocate the DDI and set the translation:

http://api.numbergroup.com/translationrequest?api_key=xxxyyy&ddi=441234945132&translation=sip:user@sip.mydomain.com

7. The API acknowledges the translationrequest:

<?xml version="1.0"?>
<translationrequest>
  <status type="success" reason=""/>
  <translation>
    <ddi>01234945132</ddi>
    <ddi_type>01</ddi_type>
    <translates_to>sip:user@sip.mydomain.com</translates_to>
  </translation>
</translationrequest>

During the process, the initial reservations inquiry in step 1 and 2 reserved all DDIs returned for 10 minutes, after each reservation request in step 4 and 5 the API reserves each DDI for 24 hours. If a longer reservation time is required, the client can extend each reservation by re-issuing the query, after which the DDI will be reserved for 24 hours after each request.

Usage

http://api.numbergroup.com/reservations?api_key=xxxyy&ddi_type=01

Or to reserve a DDI:

http://api.numbergroup.com/reservations?api_key=xxxyyy&ddi=441234945132&session_id=nu4ko7a4sc&reserve

Parameters

Parameter
Usage
Required
api_key
The API Key relating to the account to reserve against.
Yes
format
Result format, xml or json.
No
ddi_type
The type of number required, e.g. 01, 03, or 0800.
Yes
ddi_subtype
If "01" is selected for the ddi_type, this would be the area code you want, e.g. "01234".
No
ddi_limit
When specified, limits the number of DDIs initially reserved and presented to the number specified, up to 20 DDIs.
No
session_id
If this is a returning request (i.e. a further call in regards to a call where a session_id was returned) then the session ID provided by us in the initial response.
In context
clear
When specified, instructs the API to remove any previous reservations requests relating to the specified session_id and return the DDIs to the available pool.
No
ddi
When reserving, specifies the DDI to be reserved.
No
reserve
When present in the query string, instructs the API to reserve the DDI provided in the &ddi= parameter.
No
cherish_band
When present, with an applicable Cherished number band, will return numbers from the applicable cherished number band.
No

Response

The reservations API provides one of two responses, one for initial DDI searches, another for reservations responses.

DDI searches

<?xml version="1.0"?>
<reservations>
  <status type="success" reason=""/>
  <session_id value="nu4ko7a4sc"/>
    <ddi_list>
      <ddi_item>
        <ddi>441234945002</ddi>
        <display_as>01234945002</display_as></ddi_item>
      <ddi_item>
        <ddi>441234945005</ddi>
        <display_as>01234945005</display_as>
      </ddi_item>
      <ddi_item>
        <ddi>441234945006</ddi>
        <display_as>01234945006</display_as>
      </ddi_item>
      <ddi_item>
        <ddi>441234945008</ddi>
        <display_as>01234945008</display_as>
      </ddi_item>

      ... up to 20 DDIs provided

    </ddi_list>
</reservations>

Within the root <reservations> element the <status> element should contain a type="success" attribute, if not the call has failed.

The root <reservations> element will also present a <session_id> attribute which must be provided with any reservations which refer to any DDIs provided in this response, otherwise the API will not make these DDIs available.

The list of available DDIs will be provided in a <ddi_list> element within the root <reservations> element. Each ddi is contained within a <ddi_item> element containing:
Reservations responses

<?xml version="1.0"?>
<reservations>
  <status type="success" reason="DDI Reserved"/>
</reservations>

Each reservation response provides a standard response with a <reservations> root element containing a <status type="success"> or <status type="fail> response.

CDR Feed

The CDR Feed enables a client to frequently query the NumberGroup API to receive newly completed calls. Once a call has completed the detail record for the call will be included in a future feed request made by the client. The CDR feed is designed so that the client does not necessary need to maintain a record of which CDRs it has already been provided. For each API Key the NumberGroup API records which CDRs have been sent and the format requests for the feed, therefore the client only needs to initiate the feed reqeust and the NumberGroup API will return any new CDR records generated since the last request.

Each feed request is limited to a maximum of 1000 records, a summary object within the feed results indicates whether the client should immediately call the API again as there are additional CDRs to be fetched. Additionally, due to the high volume of transactions running through the API, the feed is constrained so that if there are no additional CDRs available from the current fetch, the client must not initiate another fetch within the next 30 seconds. To ease implementation on the client, the feed presents a timer in seconds in the summary which informs the agent the number of seconds it must sleep before the next request is made, if additional CDRs are available this value will be zero, indicating the client may immediately issue another request, if no more CDRs are currently available the value will include a number of seconds to sleep before the next request. The client should obey this timer, if the client persists in issuing CDR queries the API will disable the CDR feed for the specified API key.

The CDR feed does not count against any defined transaction limits for the API and therefore does not count against any dauily or monthly API transaction limits.

By default, the first time the CDR feed is called a control record is created which begins to return CDRs for the account to which the API Key relates form the point in which the account was created. For larger accounts, it may take a long time to bring the CDR feed up to the desired point and it may be desirable to reset the feed to a specific start date, see the feed parameter &from_date=YYYY-MM-DD for more information.

The CDR feed differs from other feeds in that it only supports JSON results as the efficiency of XML would not be suited to such a large feed. Any attempt to request a feed using the &format=xml parameter will generate a valid XML result with a type="fail" indicating XML is not supported. It is not necessary to add &format=json to the request.

The CDR feed is controlled using a session_sequence value which increments. However, the client should not use this as a sequence for counting call records or for maintaining uniqueness across multiple API Keys. The value although apparently unique should not be considered so and does not reflect any relative historical ordering of call records. The true unique reference fore any call record should be the session_uuid pair.

Usage

http://api.numbergroup.com/cdrfeed?api_key=xxxyyy

The method is used to both initiate a feed and request call records. To initiate or reset a feed, specifying the columns required and the date to start the feed from:

http://api.numbergroup.com/cdrfeed?api_key=xxxyyy&from_date=2012-01-01&columns=session_sequence,session_uuid,inbound_originating_address,outbound_destination_address

Parameters

Parameter
Usage
Required
api_key
The API Key relating to the account to fetch CDRs from.
Yes
format
Available for compatibility, must be json.
No
max_records
May be used to reduce the max records for smaller servers. Cannot be used to increase the records beyond 1000.
No
last_sequence
Optionally specifies the CDR sequence which the feed must present CDRs above. For example, if &last_sequence=12345 is specified, the CDR feed will present only CDRs 12346 and above. Any subsequent feed request which does not provide a last_sequence will continue from the last CDR presented in this fetch, so last_sequence may be used to reset a feed if required.
No
from_date
Is used to initiate / reset a feed to present CDRs from a specified date. The format of the date presented must be YYYY-MM-DD.
No
columns
Provides a comma separated list of columns (keys) which the client requires. Can be used to limit the result size to only the data required by the client's application.
No

Response

{
 "summary": {
  "call_record_count": 3,
  "next_permitted_fetch_seconds": 0,
  "highest_session_sequence": 30143799
 },
 "call_records": [
  {
   "session_uuid": "5864648a-35f0-11e1-869e-e95c989c206d",
   "inbound_originating_address": "441908867468",
   "session_sequence": 30029881
  },
  {
   "session_uuid": "beccfaaa-35f2-11e1-83f7-712634b2db9e",
   "inbound_originating_address": "441908278782",
   "session_sequence": 30031511
  },
  {
   "session_uuid": "d7ec471c-36c8-11e1-b3a3-e95c989c206d",
   "inbound_originating_address": "441964626573",
   "session_sequence": 30143799
  }
 ],
 "status": {"type": "success"}
}

The response contains up to three objects:

Status object

"status": {"type": "success"}

"status": {"type": "fail", "reason": "No API key specified"}

The status object contains a "type" pair, which is either "success" or "fail" to indicate succes or failure. If the type is a fail then a "reason" pair will be provided which provides the reason for failure. A type of "fail" typically suggests no other objects will be presented in the response.

Summary object

"summary": { "call_record_count": 3, "next_permitted_fetch_seconds": 0, "highest_session_sequence": 30143799}
"summary": { "call_record_count": 0, "next_permitted_fetch_seconds": 30}

The summary object presents a control record which the client can use to scale the array in which is will receive the main "call_records" object in. The "call_record_count" pair will always indicate the number of call records presented in this response. If the call_record_count is zero, a call_records object will not be provided.

The summary object also provides a "highest_session_sequence" pair which the client can safely store and pass as the &last_sequence= parameter if it wishes to maintain the state of the feed itself, however the CDR feed also stores this value and will always present CDRs higher than this value if no &last_sequence= parameter is specified.

Finally, the "next_permitted_fetch_seconds" pair always provides the number of seconds in which the client must sleep before reissuing a CDR Feed request. If the response contains the most up to date number of CDRs available for this account, the next_permitted_fetch_seconds pair will contain a positive integer which must be obeyed. If however the response contains a subset of the CDRs available and another call must be made to produce an additional result containing more available CDRs then the "next_permitted_fetch_seconds" pair will have a value of 0 (zero) and the client is permitted to immediately reissue a request for more CDRs. Not that the presence of a call_records array does not indicate it is safe to immediately request additional records, if the call_records array represents all of the CDRs available then a "next_permitted_fetch_seconds" will contain an amount to sleep.

Call-records array

The call records array contains an array of objects which presents the call records in this response.

The pairs presented in the response will be limited to the pairs requested in the most recent call containing an &columns= parameter, however the list of pairs for each record is limited to the data which is available for the session, for example if an outbound call did not connect then the call record object will not provide an outbound_connected_utc pair.

call_records array pairs

The following table provides a list of pairs which may be provided in each call_record array object. The key for each pair may also be presented in the &columns= parameter as a comma separated list for the client to narrow down any responses. date/time responses are always in UTC and always formatted as "YYYY-MM-DD hh:mm:ss.0".

Note: In order to present call detail records to clients in the format they expect, the call_record array object presents a single record reflecting the origination and termination information together. Some applications in the NumberGroup network do not follow a strict "one in, one out" model. For example an incoming call may be forked to many outgoing calls simultaneously, the first answering session "wins" and is presented with the incoming session. This record represents all sessions as having none or one outbound leg, in the case of many outbound legs in a session, the leg presented in the object is the leg which enjoyed the largest call duration. In light of this, for accurate cost calculation the "session_total_charges" pair is presented and reflects the sum of all leg charges for the session and may differ to the sum of the inbound and outbound legs provided.

Key
Type
Description
session_sequence
Number (long)
The sequence ID for this CDR.
session_uuid
String (uuid)
The unique identifier for this CDR session, guaranteed unique for any session on any API Key.
session_started_utc
String (date/time)
The time in UTC which the call was initiated (arrived at the NumberGroup network).
charging_vector
String
Calls are transited through the Num berGroup network with a unique charging vector, which is maintained along the call path for as long as the call remains IP. This represents the P-Charging-Vector identity. If a charging vector is present when the call arrives at NumberGroup, it is preserved, otherwise NumberGroup generates a charging vector.
session_total_charges
Number (double)
The total amount of charges (or credits) in this session. This value is not necessarily the sum of the inbound and outbound charges, as some applications and call-flows within the NumberGroup network result in more than one connected outbound leg. The outbound leg presented in this record is the outbound leg which resulted in the longest call duration.
inbound_leg_id
String (uuid)
The unique identifier for this leg of this session, normally equals the session_uuid.
inbound_initiated_utc
String (date/time) The time at UTC the incoming leg was offered to the network.
inbound_connected_utc
String (date/time) The time at UTC the inbound leg was connected. If not present then the leg did not connect.
inbound_disconnected_utc
String (date/time) The time at UTC the inbound leg disconnected.
inbound_duration
Number (double) The charged duration of the inbound leg.
inbound_originating_address
String The network address presented to the network by the calling party. This address is typically unformatted, so may represent the CLI presented by the User Agent prior to manipulation in outbound trunk calls. To meet Ofcom regulations, withheld calls may be presented with the last few digits masked.
inbound_destination_address
String The destination address requested. For incoming calls, this is typically the E.164 address of the DDI dialled, for outbound trunk calls this is typically the destination dialled.
inbound_application
Number (integer) The application deployed for the instance of this leg. 1 = Number Translation, 2 = Egress SIP Trunking.
inbound_privacy_indicated
Boolean
Whether the network or user agent requested the CLI / ANI to be withheld.
inbound_zone_name
String The originating zone name this leg was billed using.
inbound_zone_id
String The originating zone Identifier this leg was billed using.
inbound_charge
Number (double) The charges applied for this call leg.
inbound_timeclass
String The timeclass this leg was billed using.
outbound_leg_id
String (uuid) The unique identifier for the outbound leg (typically differs from the session uuid).
outbound_initiated_utc
String (date/time) The time at UTC the network initiated this call.
outbound_connected_utc
String (date/time) The time at UTC the remote network connected this call.
outbound_disconnected_utc
String (date/time) The time at UTC this call was disconnected.
outbound_duration
Number (double) The billed duration of the outbound leg.
outbound_originating_address
String The network identity sent to the remote network for this call. To meet Ofcom regulations, withheld calls may be presented with the last few digits masked.
outbound_destination_address
String The destination address requested. For NTS calls this is the address the DDI was terminated on, either a PSTN address or the user part of the URI in a SIP call. For trunk termination, the trunk identifier is presented as the host part of the URI.
outbound_application
Number (integer)
The application deployed for the instance of this leg. 1 = Number Translation, 2 = Egress SIP Trunking.
outbound_privacy_indicated
Boolean
Whether the outbound leg was initiated with the withheld bit set.
outbound_zone_name
String The outbound zone name this leg was billed using.
outbound_zone_id
String The outbound zone ID this leg was billed using.
outbound_charge
Number (double) The charges applied for this call leg.
outbound_timeclass
String The timeclass this leg was billed using.