TBwiki - User contributions [en]

Text Call Detail Records

2018-03-27T12:52:37Z

Manon Bélanger: /* Information related to signaling */

Text [[call detail record|call detail records]] (CDR) can be used on the [[TMG800]], [[TMG3200]] or [[TMG7800]]. The Call Detail Records are saved in a log file on a local disk. There is an entry done for each call leg, at the start of a call and at the end of the call. In addition, the system can be configured to update the CDRs periodically.

The format of the CDR traces is defined by configuration, using variables that are replaced by the Gateway application when writing to the log.

For example, the following variable will be replaced by the called number:
@{CalledNumber}

In order to save disk space and simplify the archiving and backup of CDR log files, this log file is automatically archived (gzipped) and rotated every N seconds, as specified by the system configuration.

== Configuration ==
'''Refer to the appropriate Toolpack release:'''
*[[Toolpack:Enabling_CDR_C|Web Portal v2.9, 2.10, 3.0: CDR configuration]]
*[[Toolpack:Enabling_CDR_B|Web Portal v2.8: CDR configuration]]
<div class="mw-collapsible mw-collapsed" data-collapsetext="other versions" data-expandtext="Click here for other versions" style="width: 400px;">
*[[Toolpack:Enabling_CDR_A|Web Portal v2.7: CDR configuration]]
*[[Toolpack:Enabling_RADIUS_A|Web Portal v2.6: CDR configuration]]
</div>

== CDR Text Variables ==
The following variables can be used to define the CDR log format in [[Parameter: CDR format (start)|CDR format (start)]], [[Parameter: CDR format (update)|CDR format (update)]] and [[Parameter: CDR format (end)|CDR format (end)]] configuration fields.

=== Variables used for identifying call (or call leg) in general ===
@{StatusType}: Indicates the type of record ("Start", "Update" or "End").
@{LegId}: Unique Id for this leg (32 bits value).
@{OtherLegId}: Id of the other call leg joined with current call leg.
@{SessionId}: Unique call identifier for two joined and answered call legs, including failed outgoing call attempts (route retry)
Formatted as 4 values of 32 bits, printed as 4 blocks of 8 hexadecimal characters separated by a space
Ex: a939d169 299ffcd0 00000000 00000000
Note: Call Transfer Target legs have separate SessionId. If you need an id to correlate a transferred call
to the original call, use @{OriginalSessionId}.
Note: Toolpack 2.9 and above support globally unique SessionId (unique across separate TMedia systems)
@{OriginalSessionId}: Refers to @{SessionId} of the original legs for this call, in case of call transfer.
In fact, Transfer Target leg has a different value for @{SessionId}, but can be linked with the original call
legs through @{OriginalSessionId}.
@{LinkId}: Same meaning as @{OriginalSessionId}, but presented as a 32 bits integer value.
For all Ids above, please see [[Text_Call_Detail_Records_(CDR)#Known_limitations|Known Limitations]] below for notes about uniqueness of these values.

=== Timestamps ===
@{AlertTime}: Time where the call has started ringing.
Note: Supported on release 2.7 and up only.
@{ConnectedTime}: Time where the call was answered (and connected with another leg) (in number of seconds since epoch)
@{ConnectedTime:format}: Same as @{ConnectedTime} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
@{ConnectedTimeUtc:format}:Same as @{ConnectedTime:format} but printed in UTC time, rather than local time zone.
@{CallDuration}: Call duration in seconds (not available in the "start" CDR log)
Note: Supported on release 2.7 and up only.
@{CallDurationMs}: Call duration in milliseconds (end - connected time) (not available in the "start" CDR log)
Note: Supported on release 2.7 and up only.
@{EndTime}: Time where the call has started terminating (in number of seconds since epoch).
Note that slightly differs from the @{Timestamp}, since the 'End' CDR trace is printed once the call has
finished terminating,
while @{EndTime} reports the time where the call has started terminating (upon hangup for example).
@{EndTime:format}: Same as @{EndTime} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
@{EndTimeUtc:format}: Same as @{EndTime:format} but printed in UTC time, rather than local time zone.
@{RingingDuration}: Ringing duration in seconds (connected - start time)
Note: Supported on release 2.7 and up only.
@{RingingDurationMs}: Ringing duration in milliseconds (connected - start time)
Note: Supported on release 2.7 and up only.
@{StartTime}: Time where the call was created (in number of seconds since epoch)
@{StartTime:format}: Same as @{StartTime} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
@{StartTimeUtc:format}: Same as @{StartTime:format} but printed in UTC time, rather than local time zone.
@{Timestamp}: Time where this CDR log entry was written.
Should not be used for billing purposes. Use @{EndTime} for billing @{EndTime} reports the time where
the call has started terminating (hangup), while @{Timestamp} the time where signaling confirmed the termination.
@{Timestamp:format}: Same as @{Timestamp} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
@{TimestampUtc:format}: Same as @{Timestamp:format} but printed in UTC time, rather than local time zone.

=== Information related to signaling ===
@{CalledNumber}: Called number
@{CallingNumber}: Calling number
@{CallingPresentation}: Calling presentation: "Unspecified", "NotAvailable", "Allowed", "Restricted", "AddressRestricted" or "NameRestricted"
Note: Supported on release 2.7 and up only.
@{CallingSubscriberNumber}: Second calling number (ISDN) or Generic number of type "additional calling party number" (SS7)
Note: Supported on release 2.7.43 and up only.
@{CallType}: Call type ("Telephony" or "VOIP")
@{IncomingNAP}: Name of the NAP that originated this call (incoming call leg's NAP name).
Note: Supported on release 2.7 and up only.
@{NAP}: Name of the NAP this call leg is from
@{OriginatorName}: Direction of the call:
- "answer" (incoming call leg) - "originate" (outgoing call leg)
Note: In release 2.6 and earlier, the direction of the call is as follows:
- "originate" (incoming call leg) - "answer" (outgoing call leg)
In release 2.7, the CDR option "Reverse CDR call origin" in Gateway configuration provide the same values as in release 2.6.
@{OriginalCalledNumber}: Original called number
Note: Supported on release 2.7 and up only.
@{Protocol}: Type of protocol used ("SS7", "ISDN", or "SIP")
@{RedirectingNumber}: Redirecting number
Note: Supported on release 2.7 and up only.
@{TerminationCause}: Cause of the call termination, printed as an integer value (refering enum TBCMC_CALL_REASON_CODE)
@{TerminationCauseString}: Cause of the call termination, printed as a string value
@{OriginalCause}: Original cause of the call termination (before it was converted to protocol-specific cause for current call leg), printed as a string value (refering enum TBCMC_CALL_REASON_CODE)
@{TerminationSource}: Identifies the cause of the leg termination:
- "TermInd": Terminating indication has been received on this leg
- "JoinedTermInd": Terminating indication has been received on the leg joined to current leg,
and has been forwarded to current leg
- "App": Call control application has asked to drop the call
- "Engine": Toolpack engine has decided to terminate this call
(generally due to local errors like disconnected TMedia)
@{UserName}: Static value: 100.
@{SipCallId}: Content of the "call-id" SIP header
@{ChargeIndicator}: For TDM (SS7 and CAS R2); received charge indicator in Alert message.
@{LocalSipIP}: For SIP calls, IP address locally used for this call leg.
Note: Supported on release 3.0.70 and up only.
@{LocalSipPort}: For SIP calls, UDP port locally used for this call leg.
Note: Supported on release 3.0.70 and up only.
@{RemoteSipIP}: For SIP calls, IP address of the remote peer for this call leg.
Note: Supported on release 3.0.70 and up only.
@{RemoteSipPort}: For SIP calls, UDP port of the remote peer for this call leg.
Note: Supported on release 3.0.70 and up only.

=== Information related to media ===
@{Codec}: Codec used for this call ("G711" for example)
@{LocalMediaInfo}: Protocol type dependent information on the call leg (local information for SIP calls).
For TDM (Telephony) calls (SS7 or ISDN): "trunk_name:timeslot_nb".
For VOIP calls (SIP): "codec@ip:port" (IP and Port locally used for receiving RTP)
@{LocalMediaIP}: For VOIP calls, RTP IP address locally used for this call leg.
@{LocalMediaPort}: For VOIP calls, RTP UDP port locally used for this call leg.
@{RemoteMediaInfo}: Protocol type dependent information on the call leg (remote information SIP calls).
For TDM (Telephony) calls (SS7 or ISDN): "trunk_name:timeslot_nb".
For VOIP calls (SIP): "codec@ip:port" (IP and Port TMedia is sending RTP to)
@{RemoteMediaIP}: For VOIP calls, RTP IP address of the remote peer for this call leg.
@{RemoteMediaPort}: For VOIP calls, RTP UDP port of the remote peer for this call leg.
@{TimeslotNumber}: For TDM (Telephony) calls, timeslot number that this call was using for audio.
@{TrunkName}: For TDM (Telephony) calls, name of the trunk that this call was using for audio.

=== Statistics ===
The call statistics variable allow to print RTP, RTCP and T38 statistics in the text CDR logs.
* Available '''only in the "end" CDR entry'''
* Available in release '''2.7.103''' and above only

Example:
* Pkt=@{Stat:Rtp:Rx:Packets}/@{Stat:Rtp:Tx:Packets}, Err=@{Stat:Rtp:Rx:Errors}/@{Stat:Rtp:Tx:Errors}

Refer to the following pages for the list of statistics:
* [[Call_statistics_format_C|Call statistics format for Toolpack 3.0 or later]]
* [[Call_statistics_format_B|Call statistics format for Toolpack 2.9 or 2.10]]
* [[Call_statistics_format_A|Call statistics format for Toolpack 2.8]]
* [[Call_statistics_format_A|Call statistics format for Toolpack 2.7.103 or later]]

=== Information related to routing ===
@{ApplicationName}: Name of the application that has written this log ("Gateway")
@{RouteAttribute:attr}: Replaced by the value of a custom route attribute, for the selected
route. This will apply only to outgoing call legs that were made from routing.
Eligible route attributes are:
Route name: Use attribute "route_name". Ex: @{RouteAttribute:route_name}
Route set name: Use attribute "routeset_name". Ex: @{RouteAttribute:routeset_name}
Custom route attribute column: Use the custom attribute name. Ex: @{RouteAttribute:priority}
Routing script parameters: Use the route attribute name provided by routing script.
Ex: If script provides: route[:my_param]="myval"
Then it's included in CDR with @{RouteAttribute:my_param}]
***** Important note: This parameter cannot be retrieved after a switchover of the active to
the standby Toolpack host.
It's thus recommended to insert this information in the "Start" CDR entry,
rather than the "End" CDR entry.
@{ScriptAttribute:attr}: Replaced by the value of a routing script attribute stored in params[:bridge].
This will apply for incoming and outgoing call legs.
Eligible script attributes are:
Custom CDR value: Use attribute "CustomCdrValue". Ex: @{ScriptAttribute:CustomCdrValue}
Script parameters: Use the attribute name provided by routing script.
Ex: If script provides: params[:bridge][:my_param]="myval"
Then it's included in CDR with @{ScriptAttribute:my_param}
***** Important note: This parameter cannot be retrieved after a switchover of the active to
the standby Toolpack host.
It's thus recommended to insert this information in the "Start" CDR entry,
rather than the "End" CDR entry.

=== Deprecated values: ===
@{MediaInfo}: Same as @{RemoteMediaInfo}
@{RemoteIP}: Same as @{RemoteMediaIP}
@{RemotePort}: Same as @{RemoteMediaPort}

== CDR sample ==
=== Call sample with Start and End records ===
2013-02-07 10:19:04.640-0500,BEG,SessionId='f2685706 00000000 00000000 00000000',LegId='0xF2685706',StartTime='1360250341',ConnectedTime='1360250344',Calling='',Called='123',NAP='NAP_SIP',Protocol='SIP',Direction='answer'
2013-02-07 10:19:04.640-0500,BEG,SessionId='f2685706 00000000 00000000 00000000',LegId='0x72685C1F',StartTime='1360250344',ConnectedTime='1360250344',Calling='',Called='123',NAP='NAP_SIP2',Protocol='SIP',Direction='originate'
2013-02-07 10:19:07.562-0500,END,SessionId='f2685706 00000000 00000000 00000000',LegId='0x72685C1F',StartTime='1360250344',ConnectedTime='1360250344',EndTime='1360250347',FreedTime='1360250347',TerminationCause='TOOLPACK_NORMAL',TerminationSource='App',Calling='',Called='123',NAP='NAP_SIP2',Direction='originate'
2013-02-07 10:19:07.656-0500,END,SessionId='f2685706 00000000 00000000 00000000',LegId='0xF2685706',StartTime='1360250341',ConnectedTime='1360250344',EndTime='1360250347',FreedTime='1360250347',TerminationCause='TOOLPACK_NORMAL',Termination Source='App',Calling='',Called='123',NAP='NAP_SIP',Direction='answer'

== Redundancy ==

In a [[TMG7800]] configuration, with redundant TMG-Control servers, or [[TMG3200]]/[[TMG800]] in 1+1 configuration, only the active server writes the CDR logs. Since the active server may change over time, CDR parsing must take into account that CDR logs may be found in files from the two servers.

The analysis of the logs for the purpose of extracting billing information must be done after combining the two logs, from both TMG-Control servers, sorting the entries by timestamp for example. See how to [[TMG:Retrieve_Text_CDR|Retrieve Text CDR here]].

== CDR entry loss due to switchover ==
In some situations (during HA switchover for example), some CDR entries may be lost.

The following guide lines provide information on how to deal with these corner cases:

[[Call_Detail_Records_Entry_Loss|Deal with CDR entries loss]]

== Retrieving Text CDRs ==

There are 2 ways to retrieve the text CDR manually or automatically. The procedures are described in [[TMG:Retrieve_Text_CDR|Retrieve Text CDR]].

== Notes ==
*This mode of operation is not recommended for [[TMG800]] or [[TMG3200]] with a flash disk (last shipment January 2011). However, the [[TMG800]] or [[TMG3200]] with SATA or SSD disk option is OK (use command [[Get Product Type|tbinfo]]: if the command can be executed, the disk is SATA or SSD).
*TelcoBridges does not recommend storing CDR logs via network file systems (NFS or other). We highly recommend writing to a local hard drive and have developed a background script that moves the gzipped log segments for backup or analysis.

[[Category:Revise on Major]]

SIP session timers

2018-01-18T20:33:40Z

Manon Bélanger: Adding explanation about session refresh timer.

{{DISPLAYTITLE:SIP Session timers}}

== SIP Session Timer Support ==
SIP provides a mechanism by which both user agents and proxies can determine whether a given SIP session is still active. This mechanism is referred to as a Session Timer and is described in RFC 4028 “Session Timers in SIP”. This specification defines a keep alive mechanism for SIP sessions.
 
The SIP Session Timer Support feature adds the capability to periodically refresh Session Initiation Protocol (SIP) sessions by sending repeated INVITE requests. The repeated INVITE requests, or re-INVITEs, are sent during an active call leg to allow user agents (UAs) or proxies to determine the status of a SIP session. Without this keep alive mechanism, proxies that remember incoming and outgoing requests (stateful proxies) may continue to retain the call state needlessly. If a UA fails to send a BYE message at the end of a session or if the BYE message is lost because of network problems, a stateful proxy does not know that the session has ended. The re-INVITES ensure that active sessions stay active and completed sessions are terminated.

== Prerequisites for SIP Session Timer Support ==
No special prerequisites, SIP Session Timer is available for all TMedia Toolpack versions that released.

== Role of the User Agents ==
The initial INVITE request establishes the duration of the session and may include a Session-Expires header and a Min-SE header. These headers indicate the session timer value required by the user agent client (UAC). A receiving user agent server (UAS) or proxy can lower the session timer value, but not lower than the value of the Min-SE header. If the session timer duration is lower than the configured minimum, the proxy or UAS can also send out a 422 response message. If the UAS or proxy finds that the session timer value is acceptable, it copies the Session-Expires header into the 2xx class response.
A UAS or proxy can insert a Session-Expires header in the INVITE if the UAC did not include one. Thus a UAC can receive a Session-Expires header in a response even if none was present in the request.
In the 2xx response, the refresher parameter in the Session-Expires header indicates who performs the re-INVITES. For example, if the parameter contains the value UAC, the UAC performs the refreshes. For compatibility issues, only one of the two user agents needs to support the session timer feature, and in that case, the UA that supports the feature performs the refreshes. The other UA interprets the refreshes as repetitive INVITEs and ignores them.
Re-INVITEs are processed identically to INVITE requests, but go out in predetermined session intervals. Re-INVITEs carry the new session expiration time. The UA responsible for generating re-INVITE requests sends a re-INVITE out before the session expires. If there is no response, the UA sends a BYE request to terminate the call before session expiration. If a re-INVITE is not sent before the session expiration, either the UAC or the UAS can send a BYE.
If the 2xx response does not contain a Session-Expires header, there is no session expiration and re-INVITES do not need to be sent.

== Session-Expires Header==

The Session-Expires header field conveys the session interval for a SIP session. It is placed only in INVITE or UPDATE requests, as well as in any 2xx response to an INVITE or UPDATE. The absolute minimum for the Session-Expires header field is 90 seconds. This value represents a bit more than twice the duration that a SIP transaction can take in the event of a timeout. This allows sufficient time for a UA to attempt a refresh at the halfpoint of the session interval, and for that transaction to complete normally before the session expires. However, 1800 seconds (30 minutes) is RECOMMENDED as the value for the Session-Expires header field. In other words, SIP entities MUST be prepared to handle Session-Expires header field values of any duration greater than 90 seconds, but entities that insert the Session-Expires header field SHOULD NOT choose values of less than 30 minutes.
The syntax of the Session-Expires header field is as follows:
Session-Expires = ("Session-Expires" / "x") HCOLON delta-seconds
*(SEMI se-params)
se-params = refresher-param / generic-param
refresher-param = "refresher" EQUAL ("uas" / "uac")
The refresher parameter is optional in the initial INVITE, although the UAC can set it to UAC to indicate that it will do the refreshes. The 200 OK response must have the refresher parameter set.
Min-SE Header
Because of the processing load of INVITE requests you can configure a minimum timer value that the proxy, UAC, and UAS can accept. The proxy, UAC, and UAS. The Min-SE command sets the minimum timer, and it is conveyed in the Min-SE header in the initial INVITE request.
When making a call, the presence of the Min-SE header informs the UAS and any proxies of the minimum value that the UAC accepts for the session timer duration, in seconds. The default value is 1800 seconds (30 minutes). By not reducing the session timer below the value set, the UAS and proxies prevent the UAC from having to reject a call with a 422 error. Once set, the Min-SE command value affects all calls originated by the router. If the Min-SE header is not present, the UA accepts any value.
The syntax of the Min-SE header is:
Min-SE = "Min-SE" ":" delta-seconds
422 Response Message
If the value of the Session-Expires header is too small, the UAS or proxy rejects the call with a 422 Session Timer Too Small response message. With the 422 response message, the proxy or UAS includes a Min-SE header indicating the minimum session value it can accept. The UAC may then retry the call with a larger session timer value.
If a 422 response message is received after an INVITE request, the UAC can retry the INVITE.

== How to configure ==
Session Timer Configurable under:
SIP -> SIP Stack -> Session Timer
Please visit toolpack configuration for each toolpack version for detail: [[Toolpack:Creating_a_SIP_Stack_D|Web Portal SIP Configuration]]

Note: The recommended value for “Default session timer” is not less than 30 Mins (1800 Sec) and for Min-SE it is recommended value is not less than 90 sec.
To make new configuration take effect:
* Validate the configuration from the system
* Activate the new configuration.
 

== SIP Session Timer Call Flows Example ==
==== General SIP Session Timer call flow ====
TMG/TSBC requests session timer by including Session-Expires: 1800 and Min SE: 256 header on the INVITE. TMG/TSBC receives 200 OK that set session timer to 1800 seconds and TMG/TSBC as the refresher. TMG/TSBC starts a 900 seconds session refresh timer, which is half of the 1800 seconds of the session timer to make sure the refresh is processed before the session expires. After refresh timer expires, TMG/TSBC sends out refresh request with Session-Expires value set to current value 1800 seconds and refresher to UAC. TMG/TSBC receives 200 OK and resets the timer. Once again TMG/TSBC sends out refresh request after session refresh timer expire. Finally, call ended in clear manner and Bye send to remote proxy, TMG/TSBC receives 200 OK.
 
[[File:SIP_session_timer_example_1.png|350px]]
 

==== Sip Session Expire too Small ====

SIP Proxy send invite to TMG/TSBC by including Min SE: 50 SIP header on the INVITE message.
TMG/TSBC reply with 422, Session timer too small as Min-SE value is set to 90 in TMG/TSBC and SIP Proxy send acknowledge to TMG/TSBC and call terminated.
 
[[File:SIP_session_timer_too_small.png|350px]]
 

==== TMG/TSBC is UAS and does the refresh ====

TMG/TSBC receives INVITE that has supported header with option tag ‘timer’ and Session-Expires header with 1800 seconds value with refresher=uas. TMG/TSBC starts 900 seconds session refresh timer. After refresh timer expires, TMG/TSBC sends out refresh request with Session-Expires value set to current value 1800 seconds, refresher is set to UAC so that ensure TMG/TSBC will always perform refresh. TMG/TSBC receives 200 OK and resets the timer. Once again TMG/TSBC sends out refresh request after session refresh timer expires, but now the SIP Proxy crashed so that TMG/TSBC receives 408 Request Timeout. TMG/TSBC sends out BYE and the call is terminated.
 
[[File:SIP_session_timer_uas_refresher.png|350px]]
 

==== TMG or SBC is UAS and SIP Proxy does the refresh ====

TMG/TSBC receives INVITE that has supported header with option tag ‘timer’. TMG/TSBC sends 200 OK and requests session timer by including require header with tag ‘timer’ and Session-Expires header. The session interval is set to 1800 seconds and refresher is the SIP Proxy. TMG/TSBC receives session refresh request before the session end timer expires. TMG/TSBC sends 200 OK back and set refresher to UAC so that the role of refresher doesn’ t change. TMG/TSBC restarts 1800 seconds session end timer. Now the Sip Proxy crashes and no refresh request sent. 1800 seconds later the session end timer expires, TMG/TSBC sends out BYE and terminates the call.
 
[[File:SIP_session_timer_proxy_refresher.png|350px]]
 

==== TMG/TSBC is UAC and Requests Session Timer ====

TMG/TSBC invite by including Session-Expires header and Min SE on the INVITE. TMG/TSBC receives 200 OK that set session timer to 1800 seconds and TMG/TSBC as the refresher. TMG/TSBC starts 900 seconds session refresh timer. After refresh timer expires, TMG/TSBC sends out refresh request with Session-Expires value set to current value 1800 seconds and refresher to UAC. TMG/TSBC receives 200 OK and resets the timer. Once again TMG/TSBC sends out refresh request after session refresh timer expires, but now the (SIP) Proxy crashed so that TMG/TSBC receives 408 Request Timeout. TMG/TSBC sends out BYE and the call is terminated.
 
[[File:SIP_session_timer_uac_refresher.png|350px]]
 

==== TMG/TSBC is UAC and (SIP) Proxy does the refresh ====
TMG/TSBC sends INVITE that has supported header with option tag ‘timer’ and Session-Expires to request session timer. The remote gateway accepts it. The session interval is set to 1800 seconds and refresher is the remote gateway. TMG/TSBC starts 1800 seconds session end timer. TMG/TSBC receives session refresh request before the session end timer expires. TMG/TSBC sends 200 OK back and set refresher to UAC so that the role of refresher doesn’t change. TMG/TSBC restarts 1800 seconds session end timer. Now the remote gateway crashes and no refresh request sent. 1800 seconds later the session end timer expires, TMG/TSBC sends out BYE and terminates the call.
 
[[File:SIP_session_timer_proxy_uac_refresher.png|350px]]
 

Reference: https://tools.ietf.org/html/rfc4028#section-4

SIP session timers

2018-01-18T19:33:18Z

Manon Bélanger: Replaced IMG by TMG/TSBC

{{DISPLAYTITLE:SIP Session timers}}

== SIP Session Timer Support ==
SIP provides a mechanism by which both user agents and proxies can determine whether a given SIP session is still active. This mechanism is referred to as a Session Timer and is described in RFC 4028 “Session Timers in SIP”. This specification defines a keep alive mechanism for SIP sessions.
 
The SIP Session Timer Support feature adds the capability to periodically refresh Session Initiation Protocol (SIP) sessions by sending repeated INVITE requests. The repeated INVITE requests, or re-INVITEs, are sent during an active call leg to allow user agents (UAs) or proxies to determine the status of a SIP session. Without this keep alive mechanism, proxies that remember incoming and outgoing requests (stateful proxies) may continue to retain the call state needlessly. If a UA fails to send a BYE message at the end of a session or if the BYE message is lost because of network problems, a stateful proxy does not know that the session has ended. The re-INVITES ensure that active sessions stay active and completed sessions are terminated.

== Prerequisites for SIP Session Timer Support ==
No special prerequisites, SIP Session Timer is available for all TMedia Toolpack versions that released.

== Role of the User Agents ==
The initial INVITE request establishes the duration of the session and may include a Session-Expires header and a Min-SE header. These headers indicate the session timer value required by the user agent client (UAC). A receiving user agent server (UAS) or proxy can lower the session timer value, but not lower than the value of the Min-SE header. If the session timer duration is lower than the configured minimum, the proxy or UAS can also send out a 422 response message. If the UAS or proxy finds that the session timer value is acceptable, it copies the Session-Expires header into the 2xx class response.
A UAS or proxy can insert a Session-Expires header in the INVITE if the UAC did not include one. Thus a UAC can receive a Session-Expires header in a response even if none was present in the request.
In the 2xx response, the refresher parameter in the Session-Expires header indicates who performs the re-INVITES. For example, if the parameter contains the value UAC, the UAC performs the refreshes. For compatibility issues, only one of the two user agents needs to support the session timer feature, and in that case, the UA that supports the feature performs the refreshes. The other UA interprets the refreshes as repetitive INVITEs and ignores them.
Re-INVITEs are processed identically to INVITE requests, but go out in predetermined session intervals. Re-INVITEs carry the new session expiration time. The UA responsible for generating re-INVITE requests sends a re-INVITE out before the session expires. If there is no response, the UA sends a BYE request to terminate the call before session expiration. If a re-INVITE is not sent before the session expiration, either the UAC or the UAS can send a BYE.
If the 2xx response does not contain a Session-Expires header, there is no session expiration and re-INVITES do not need to be sent.

== Session-Expires Header==

The Session-Expires header field conveys the session interval for a SIP session. It is placed only in INVITE or UPDATE requests, as well as in any 2xx response to an INVITE or UPDATE. The absolute minimum for the Session-Expires header field is 90 seconds. This value represents a bit more than twice the duration that a SIP transaction can take in the event of a timeout. This allows sufficient time for a UA to attempt a refresh at the halfpoint of the session interval, and for that transaction to complete normally before the session expires. However, 1800 seconds (30 minutes) is RECOMMENDED as the value for the Session-Expires header field. In other words, SIP entities MUST be prepared to handle Session-Expires header field values of any duration greater than 90 seconds, but entities that insert the Session-Expires header field SHOULD NOT choose values of less than 30 minutes.
The syntax of the Session-Expires header field is as follows:
Session-Expires = ("Session-Expires" / "x") HCOLON delta-seconds
*(SEMI se-params)
se-params = refresher-param / generic-param
refresher-param = "refresher" EQUAL ("uas" / "uac")
The refresher parameter is optional in the initial INVITE, although the UAC can set it to UAC to indicate that it will do the refreshes. The 200 OK response must have the refresher parameter set.
Min-SE Header
Because of the processing load of INVITE requests you can configure a minimum timer value that the proxy, UAC, and UAS can accept. The proxy, UAC, and UAS. The Min-SE command sets the minimum timer, and it is conveyed in the Min-SE header in the initial INVITE request.
When making a call, the presence of the Min-SE header informs the UAS and any proxies of the minimum value that the UAC accepts for the session timer duration, in seconds. The default value is 1800 seconds (30 minutes). By not reducing the session timer below the value set, the UAS and proxies prevent the UAC from having to reject a call with a 422 error. Once set, the Min-SE command value affects all calls originated by the router. If the Min-SE header is not present, the UA accepts any value.
The syntax of the Min-SE header is:
Min-SE = "Min-SE" ":" delta-seconds
422 Response Message
If the value of the Session-Expires header is too small, the UAS or proxy rejects the call with a 422 Session Timer Too Small response message. With the 422 response message, the proxy or UAS includes a Min-SE header indicating the minimum session value it can accept. The UAC may then retry the call with a larger session timer value.
If a 422 response message is received after an INVITE request, the UAC can retry the INVITE.

== How to configure ==
Session Timer Configurable under:
SIP -> SIP Stack -> Session Timer
Please visit toolpack configuration for each toolpack version for detail: [[Toolpack:Creating_a_SIP_Stack_D|Web Portal SIP Configuration]]

Note: The recommended value for “Default session timer” is not less than 30 Mins (1800 Sec) and for Min-SE it is recommended value is not less than 90 sec.
To make new configuration take effect:
* Validate the configuration from the system
* Activate the new configuration.
 

== SIP Session Timer Call Flows Example ==
==== General SIP Session Timer call flow ====
TMG/TSBC requests session timer by including Session-Expires: 1800 and Min SE: 256 header on the INVITE. TMG/TSBC receives 200 OK that set session timer to 1800 seconds and TMG/TSBC as the refresher. TMG/TSBC starts 900 seconds session refresh timer. After refresh timer expires, TMG/TSBC sends out refresh request with Session-Expires value set to current value 1800 seconds and refresher to UAC. TMG/TSBC receives 200 OK and resets the timer. Once again TMG/TSBC sends out refresh request after session refresh timer expire. Finally, call ended in clear manner and Bye send to remote proxy, TMG/TSBC receives 200 OK.
 
[[File:SIP_session_timer_example_1.png|350px]]
 

==== Sip Session Expire too Small ====

SIP Proxy send invite to TMG/TSBC by including Min SE: 50 SIP header on the INVITE message.
TMG/TSBC reply with 422, Session timer too small as Min-SE value is set to 90 in TMG/TSBC and SIP Proxy send acknowledge to TMG/TSBC and call terminated.
 
[[File:SIP_session_timer_too_small.png|350px]]
 

==== TMG/TSBC is UAS and does the refresh ====

TMG/TSBC receives INVITE that has supported header with option tag ‘timer’ and Session-Expires header with 1800 seconds value with refresher=uas. TMG/TSBC starts 900 seconds session refresh timer. After refresh timer expires, TMG/TSBC sends out refresh request with Session-Expires value set to current value 1800 seconds, refresher is set to UAC so that ensure TMG/TSBC will always perform refresh. TMG/TSBC receives 200 OK and resets the timer. Once again TMG/TSBC sends out refresh request after session refresh timer expires, but now the SIP Proxy crashed so that TMG/TSBC receives 408 Request Timeout. TMG/TSBC sends out BYE and the call is terminated.
 
[[File:SIP_session_timer_uas_refresher.png|350px]]
 

==== TMG or SBC is UAS and SIP Proxy does the refresh ====

TMG/TSBC receives INVITE that has supported header with option tag ‘timer’. TMG/TSBC sends 200 OK and requests session timer by including require header with tag ‘timer’ and Session-Expires header. The session interval is set to 1800 seconds and refresher is the SIP Proxy. TMG/TSBC receives session refresh request before the session end timer expires. TMG/TSBC sends 200 OK back and set refresher to UAC so that the role of refresher doesn’ t change. TMG/TSBC restarts 1800 seconds session end timer. Now the Sip Proxy crashes and no refresh request sent. 1800 seconds later the session end timer expires, TMG/TSBC sends out BYE and terminates the call.
 
[[File:SIP_session_timer_proxy_refresher.png|350px]]
 

==== TMG/TSBC is UAC and Requests Session Timer ====

TMG/TSBC invite by including Session-Expires header and Min SE on the INVITE. TMG/TSBC receives 200 OK that set session timer to 1800 seconds and TMG/TSBC as the refresher. TMG/TSBC starts 900 seconds session refresh timer. After refresh timer expires, TMG/TSBC sends out refresh request with Session-Expires value set to current value 1800 seconds and refresher to UAC. TMG/TSBC receives 200 OK and resets the timer. Once again TMG/TSBC sends out refresh request after session refresh timer expires, but now the (SIP) Proxy crashed so that TMG/TSBC receives 408 Request Timeout. TMG/TSBC sends out BYE and the call is terminated.
 
[[File:SIP_session_timer_uac_refresher.png|350px]]
 

==== TMG/TSBC is UAC and (SIP) Proxy does the refresh ====
TMG/TSBC sends INVITE that has supported header with option tag ‘timer’ and Session-Expires to request session timer. The remote gateway accepts it. The session interval is set to 1800 seconds and refresher is the remote gateway. TMG/TSBC starts 1800 seconds session end timer. TMG/TSBC receives session refresh request before the session end timer expires. TMG/TSBC sends 200 OK back and set refresher to UAC so that the role of refresher doesn’t change. TMG/TSBC restarts 1800 seconds session end timer. Now the remote gateway crashes and no refresh request sent. 1800 seconds later the session end timer expires, TMG/TSBC sends out BYE and terminates the call.
 
[[File:SIP_session_timer_proxy_uac_refresher.png|350px]]
 

Reference: https://tools.ietf.org/html/rfc4028#section-4

Toolpack:Retrieving Call Trace C

2017-11-08T15:38:48Z

Manon Bélanger: First version of the page with an added section for fraud call removal

=== '''''Applies to version(s) v3.0''''' ===
{{DISPLAYTITLE:Retrieving Call Trace}}

====Retrieving calls from memory====

1- Click '''Call Trace''' in the navigation panel

[[Image:RetrievingCallTrace_0.png]]

2- Set various parameters for call trace, such as
*Time and date range
*Called or calling number
*Network Access Point (NAP)
*Incoming or outgoing calls
*Call Duration, Reason Code
*Active call
[[Image:RetrievingCallTrace_1.png]]

Once you are satisfied with the filter criteria, click '''Apply'''

The filter results are displayed.

[[Image:FileAccessingCallTrace_2.png]]

====Dropping an active call====

1- Select the call to drop in the results window.

====View detailed call traces for a call====

1- Select a call in the results window to display further information about the call.

2- Choose the concerned call entry to view the details.
* Click '''Download Audio File'''

[[Image:FileAccessingCallTrace_3.png]]

3- You can choose to export the call trace file as an HTML file.
* Click '''Export'''

[[Image:FileAccessingCallTrace_4.png]]

4- For active calls, you can also choose to drop the call.
* Click '''Drop call'''

==== Retrieving calls from files ====
By default, the system stores up to 10,000 call legs in memory. If the call is no longer in memory, it may be retrieved by using information from the uctdata log files.
To search for calls that are no longer in memory, do the following:

1- Start [[How_to_use_tbx_cli_tools_remote_program|tbx_cli_tools_remote]] 
2- Select tbuctwriter 
3- To know which files are available, as well as the start and end time of each file, use the following options:
* 'p' to print all uctdata files on disk

To load a file into memory for viewing with the Web Portal: 
* Option 'o' followed by the data filename (uctdata*)

Use the Web Portal to search for calls using the appropriate filter criteria. The memory will not be overwritten until you restore normal process.

To restore normal process: 

*Option ‘c’ to clear memory
*Option ‘l’ to have calls put in memory again

By default the file is located in the following path:
<pre>/lib/tb/toolpack/setup/12358/2.8/apps/tbuctwriter/uctdata*</pre>

Tctrl Version 3.0

2017-11-07T21:44:46Z

Manon Bélanger: Fixing link for sip registration forwarding

== Features ==

The [[Tctrl]] provides the following [[:category:Tsbc Features|''T''sbc features]].

 

{| cellpadding="0" border="0" style="width: 820px; height: 383px; text-align: center;" class="wikitable"
|-
! width="500" | Features
! width="150" | Enhancement'''1'''
! width="150" | Release
|-
! colspan="3" | SBC Product
|-
| style="text-align:left;" | [[TSBC-SW|New Session Border Controller (SBC) product called TSBC-SW]]
|
| 3.0
|-
! colspan="3" | SIP
|-
| style="text-align:left;" | [[Sip_registration_forwarding|SIP registration forwarding]]
|
| 3.0
|-
|}

Toolpack:Tsbc IP Network Settings 3.0

2017-04-25T13:47:16Z

Manon Bélanger: Add link

__NOTOC__
==TSBC-HW-SRV / Customer supplied hardware / Virtual Machines==

===IP Network===

{|
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Virtual Port
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add VLAN
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Interface
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Port Range
|-
| valign="top" |
*[[Toolpack:Configuring_Virtual_Port_SBC_C|Configuring an IP Virtual Port]]
| valign="top" |
*[[Toolpack:Configuring_Vlan_SBC_A|Configuring a VLAN]]
| valign="top" |
*[[Toolpack:Configuring_IP_Interface_SBC_A|Configuring IP Interfaces]]
| valign="top" |
*[[Toolpack:Creating_an_IP_Port_Range_F|Create an IP port range]]
|}

|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Use Cases
|-
| valign="top" |
*[[Toolpack:TSBC-SW Network Configuration|TSBC-SW Network Configuration]]
|}
|}

===NAT===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | NAT Traversal
|-
| valign="top" |
*[[Create_NAT_Traversal_C|Create NAT Traversal]]
|}

===Transcoding Units===
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add transcoding units
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Configure transcoding network
|-
| valign="top" |
*[[Toolpack:Show_Hardware_Units_A|Show Hardware units menu]]
*[[Toolpack:Adding_a_Transcoding_Unit_A|Add transcoding units]]
| valign="top" |
*[[Toolpack:Configuring_Virtual_Port_SBC_B|Configuring an IP Virtual Port]]
*[[Toolpack:Configuring_VoIP_Interfaces_E|Configuring IP Interfaces]]
|}

==TSBC-HW-0/TSBC-HW-680/TSBC-HW-2700==

===New Hardware===
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add telecom hardware
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add 1+1 group
|-
| valign="top" |
*[[Toolpack:Adding_an_Adapter_F|Add telecom hardware]]
| valign="top" |
*[[Toolpack:Creating_a_1%2B1_Group_C|Add 1+1 group]]
|}

===IP Network===

{|
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Virtual Port
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Interface
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Port Range
|-
| valign="top" |
*[[Toolpack:Configuring_Virtual_Port_SBC_B|Configuring an IP Virtual Port]]
| valign="top" |
*[[Toolpack:Configuring_VoIP_Interfaces_E|Configuring IP Interfaces]]
| valign="top" |
*[[Toolpack:Creating_an_IP_Port_Range_E|Create an IP port range]]
|}
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Use Cases
|-
| valign="top" |
*[[Toolpack:Network Configuration|Network Configuration]]
|}
|}

===NAT===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | NAT Traversal
|-
| valign="top" |
*[[Create_NAT_Traversal_C|Create NAT Traversal]]
|}

Toolpack:Show Hardware Units A

2017-04-25T13:46:39Z

Manon Bélanger: First version

=== '''''Applies to version v3.0''''' ===
{{DISPLAYTITLE:Show Hardware Units menu}}

'''To show Hardware Units menu:'''

1- Click '''Configurations''' in the navigation panel

[[New image needed]]

2- Select the desired configuration in the '''Configurations List'''.

[[New image needed - only one active configuration]]

3- Click '''Web Profiles''' to modify the web portal profile.

[[Image:WebProfile_Select_B.png]]

4- Check '''Hardware Unit'''

[[New image needed]]

5- Click '''Save'''.
The Hardware Units menu will appear for the selected configuration

Toolpack:Tsbc IP Network Settings 3.0

2017-04-25T13:33:12Z

Manon Bélanger:

__NOTOC__
==TSBC-HW-SRV / Customer supplied hardware / Virtual Machines==

===IP Network===

{|
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Virtual Port
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add VLAN
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Interface
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Port Range
|-
| valign="top" |
*[[Toolpack:Configuring_Virtual_Port_SBC_C|Configuring an IP Virtual Port]]
| valign="top" |
*[[Toolpack:Configuring_Vlan_SBC_A|Configuring a VLAN]]
| valign="top" |
*[[Toolpack:Configuring_IP_Interface_SBC_A|Configuring IP Interfaces]]
| valign="top" |
*[[Toolpack:Creating_an_IP_Port_Range_F|Create an IP port range]]
|}

|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Use Cases
|-
| valign="top" |
*[[Toolpack:TSBC-SW Network Configuration|TSBC-SW Network Configuration]]
|}
|}

===NAT===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | NAT Traversal
|-
| valign="top" |
*[[Create_NAT_Traversal_C|Create NAT Traversal]]
|}

===Transcoding Units===
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add transcoding units
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Configure transcoding network
|-
| valign="top" |
*[[Toolpack:Show Hardware units menu|Show Hardware units menu]]
*[[Toolpack:Adding_a_Transcoding_Unit_A|Add transcoding units]]
| valign="top" |
*[[Toolpack:Configuring_Virtual_Port_SBC_B|Configuring an IP Virtual Port]]
*[[Toolpack:Configuring_VoIP_Interfaces_E|Configuring IP Interfaces]]
|}

==TSBC-HW-0/TSBC-HW-680/TSBC-HW-2700==

===New Hardware===
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add telecom hardware
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add 1+1 group
|-
| valign="top" |
*[[Toolpack:Adding_an_Adapter_F|Add telecom hardware]]
| valign="top" |
*[[Toolpack:Creating_a_1%2B1_Group_C|Add 1+1 group]]
|}

===IP Network===

{|
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Virtual Port
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Interface
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Port Range
|-
| valign="top" |
*[[Toolpack:Configuring_Virtual_Port_SBC_B|Configuring an IP Virtual Port]]
| valign="top" |
*[[Toolpack:Configuring_VoIP_Interfaces_E|Configuring IP Interfaces]]
| valign="top" |
*[[Toolpack:Creating_an_IP_Port_Range_E|Create an IP port range]]
|}
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Use Cases
|-
| valign="top" |
*[[Toolpack:Network Configuration|Network Configuration]]
|}
|}

===NAT===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | NAT Traversal
|-
| valign="top" |
*[[Create_NAT_Traversal_C|Create NAT Traversal]]
|}

Toolpack:Tsbc IP Network Settings 3.0

2017-04-25T13:32:49Z

Manon Bélanger: Adding links for transcoding

__NOTOC__
==TSBC-HW-SRV / Customer supplied hardware / Virtual Machines==

===IP Network===

{|
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Virtual Port
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Vlan
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Interface
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Port Range
|-
| valign="top" |
*[[Toolpack:Configuring_Virtual_Port_SBC_C|Configuring an IP Virtual Port]]
| valign="top" |
*[[Toolpack:Configuring_Vlan_SBC_A|Configuring a VLAN]]
| valign="top" |
*[[Toolpack:Configuring_IP_Interface_SBC_A|Configuring IP Interfaces]]
| valign="top" |
*[[Toolpack:Creating_an_IP_Port_Range_F|Create an IP port range]]
|}

|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Use Cases
|-
| valign="top" |
*[[Toolpack:TSBC-SW Network Configuration|TSBC-SW Network Configuration]]
|}
|}

===NAT===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | NAT Traversal
|-
| valign="top" |
*[[Create_NAT_Traversal_C|Create NAT Traversal]]
|}

===Transcoding Units===
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add transcoding units
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Configure transcoding network
|-
| valign="top" |
*[[Toolpack:Show Hardware units menu|Show Hardware units menu]]
*[[Toolpack:Adding_a_Transcoding_Unit_A|Add transcoding units]]
| valign="top" |
*[[Toolpack:Configuring_Virtual_Port_SBC_B|Configuring an IP Virtual Port]]
*[[Toolpack:Configuring_VoIP_Interfaces_E|Configuring IP Interfaces]]
|}

==TSBC-HW-0/TSBC-HW-680/TSBC-HW-2700==

===New Hardware===
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add telecom hardware
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add 1+1 group
|-
| valign="top" |
*[[Toolpack:Adding_an_Adapter_F|Add telecom hardware]]
| valign="top" |
*[[Toolpack:Creating_a_1%2B1_Group_C|Add 1+1 group]]
|}

===IP Network===

{|
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Virtual Port
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Interface
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Port Range
|-
| valign="top" |
*[[Toolpack:Configuring_Virtual_Port_SBC_B|Configuring an IP Virtual Port]]
| valign="top" |
*[[Toolpack:Configuring_VoIP_Interfaces_E|Configuring IP Interfaces]]
| valign="top" |
*[[Toolpack:Creating_an_IP_Port_Range_E|Create an IP port range]]
|}
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Use Cases
|-
| valign="top" |
*[[Toolpack:Network Configuration|Network Configuration]]
|}
|}

===NAT===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | NAT Traversal
|-
| valign="top" |
*[[Create_NAT_Traversal_C|Create NAT Traversal]]
|}

Toolpack:Tsbc IP Network Settings 3.0

2017-04-25T13:30:46Z

Manon Bélanger: Adding link to VLAN

__NOTOC__
==TSBC-HW-SRV / Customer supplied hardware / Virtual Machines==

===IP Network===

{|
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Virtual Port
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Vlan
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Interface
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Port Range
|-
| valign="top" |
*[[Toolpack:Configuring_Virtual_Port_SBC_C|Configuring an IP Virtual Port]]
| valign="top" |
*[[Toolpack:Configuring_Vlan_SBC_A|Configuring a VLAN]]
| valign="top" |
*[[Toolpack:Configuring_IP_Interface_SBC_A|Configuring IP Interfaces]]
| valign="top" |
*[[Toolpack:Creating_an_IP_Port_Range_F|Create an IP port range]]
|}

|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Use Cases
|-
| valign="top" |
*[[Toolpack:TSBC-SW Network Configuration|TSBC-SW Network Configuration]]
|}
|}

===NAT===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | NAT Traversal
|-
| valign="top" |
*[[Create_NAT_Traversal_C|Create NAT Traversal]]
|}

===Transcoding Units===
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add transcoding units
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Configure transcoding network
|-
| valign="top" |
*[[Toolpack:Show Hardware units menu|Show Hardware units menu]]
*[[Toolpack:Adding_a_Transcoding_Unit_A|Add transcoding units]]
| valign="top" |
*[[Toolpack:Configuring an IP Virtual Port|Configuring an IP Virtual Port]]
*[[Toolpack:Configuring IP Interfaces|Configuring IP Interfaces]]
|}

==TSBC-HW-0/TSBC-HW-680/TSBC-HW-2700==

===New Hardware===
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add telecom hardware
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add 1+1 group
|-
| valign="top" |
*[[Toolpack:Adding_an_Adapter_F|Add telecom hardware]]
| valign="top" |
*[[Toolpack:Creating_a_1%2B1_Group_C|Add 1+1 group]]
|}

===IP Network===

{|
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Virtual Port
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Interface
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Port Range
|-
| valign="top" |
*[[Toolpack:Configuring_Virtual_Port_SBC_B|Configuring an IP Virtual Port]]
| valign="top" |
*[[Toolpack:Configuring_VoIP_Interfaces_E|Configuring IP Interfaces]]
| valign="top" |
*[[Toolpack:Creating_an_IP_Port_Range_E|Create an IP port range]]
|}
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Use Cases
|-
| valign="top" |
*[[Toolpack:Network Configuration|Network Configuration]]
|}
|}

===NAT===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | NAT Traversal
|-
| valign="top" |
*[[Create_NAT_Traversal_C|Create NAT Traversal]]
|}

Toolpack:Configuring Vlan SBC A

2017-04-25T13:29:56Z

Manon Bélanger: First version of the page

=== '''''Applies to version(s): v3.0''''' ===
{{DISPLAYTITLE:Configuring a VLAN}}

After you create a virtual port, you must create a new VLAN.

 

== To configure a VLAN ==

1. Select '''IP Interfaces''' from the navigation panel

[[New image needed - under Hosts]] 

2. Click the '''Virtual Ports''' tab.
*Select a Virtual Port

[[New image needed]] 

4. Create a VLAN that uses this virtual port
*Click '''Create new Host VLAN'''

[[New image needed]] 

5. Configure the new VLAN

*Enter a name for the VLAN
*If the port is to be used untagged, make sure '''Untagged''' is checked.
*If the port is to be used with a 802.1Q tag, uncheck '''Untagged''' and enter a VLAN ID.
*Click '''Create'''

[[new image needed]] 

==List of Parameters==

* [[Parameter: Name|Name]]
* [[Parameter: Untagged|Untagged]]
* [[Parameter: VLAN id|VLAN id]]

Toolpack:Configuring Virtual Port SBC C

2017-04-25T13:25:04Z

Manon Bélanger: Remove VLAN, moved to another page

=== '''''Applies to version(s): v3.0''''' ===
{{DISPLAYTITLE:Configuring a Virtual Port}}

One or more virtual ports can be created to manage IP traffic.

 

== To configure a virtual port ==

1. Select '''IP Interfaces''' from the navigation panel

[[New image needed - under Hosts]] 

2. Click the '''Virtual Ports''' tab.
*Click '''Create New Virtual Port'''

[[New image needed]] 

3. Configure the virtual port.

*Enter a name for the virtual port
*Select the host(s) to which the virtual port is assigned
*Select a physical port to which the virtual port is assigned

*Click '''Create'''

[[new image needed]] 

==List of Parameters==

* [[Parameter: Name|Name]]
* [[Parameter: Hosts|Hosts]]
* [[Parameter: Physical ports|Physical Ports]]

Toolpack:Configuring Virtual Port SBC C

2017-04-25T13:04:09Z

Manon Bélanger: Adding vlan configuration to virtual port configuration

=== '''''Applies to version(s): v3.0''''' ===
{{DISPLAYTITLE:Configuring a Virtual Port}}

One or more virtual ports can be created to manage IP traffic.

 

== To configure a virtual port ==

1. Select '''IP Interfaces''' from the navigation panel

[[New image needed - under Hosts]] 

2. Click the '''Virtual Ports''' tab.
*Click '''Create New Virtual Port'''

[[New image needed]] 

3. Configure the virtual port.

*Enter a name for the virtual port
*Select the host(s) to which the virtual port is assigned
*Select a physical port to which the virtual port is assigned

*Click '''Create'''

[[new image needed]] 

4. Create a VLAN that uses this virtual port
*Click '''Create new Host VLAN'''

[[New image needed]] 

5. Configure the VLAN

*Enter a name for the VLAN

[[new image needed]] 

==List of Parameters==

* [[Parameter: Name|Name]]
* [[Parameter: Hosts|Hosts]]
* [[Parameter: Physical ports|Physical Ports]]

Toolpack:Configuring VoIP Interfaces E

2017-04-25T12:49:14Z

Manon Bélanger: Fix comment

=== '''''Applies to version(s): v3.0''''' ===
{{DISPLAYTITLE:Configuring VoIP Interfaces}}

The IP interface of the VoIP0 and VoIP1 ports can be configured by setting the following:

*IP Address
*Netmask
*Gateway

 

== To configure a VoIP0 or VoIP1 port ==

1. Select '''IP Interfaces''' from the navigation panel:

[[New image needed - under Hardware Units]]

 2. Click the '''IP Interfaces''' tab.
*Click '''Create New IP Interface'''

[[Image:Voip_Interface_1a.png]]

 3. Configure the IP port:

*Enter a name for the interface
*Select a service to use for the IP inteface
*Select a '''Virtual port''' from which IP packets will exit.
*Indicate whether or not to use DHCP to automatically get an IP address for this port. (selecting this option removes the need to enter and IP address, Netmask, and Gateway)
*Enter an '''IP address'''
*Enter a '''Netmask'''
*Enter a '''gateway address'''
*Click '''Save'''

'''Note:''' IP addresses using different virtual ports must be on different subnets. 

[[New image needed]]

 

4. The changes are displayed in the IP interfaces information panel:

[[New image needed]]

 

5. Activate the configuration

Systems -> Edit -> Activate

6. It is necessary to reboot the adapters if you are using the vlan from 3441 to 3450 only.

Status -> Adapters -> Click on the adapter Serial Number -> Reboot adapter

It will take about 1.5 minutes to restart the unit.

'''Note:''' in a 1+1 system, both units must be restarted.

== List of Parameters ==

*[[Parameter: Interface name|Interface name]]
*[[Parameter: Services to use|Services to use]]
*[[Parameter: Virtual port|Virtual port]]
*[[Parameter: Use DHCP|Use dynamic IP]]
*[[Parameter: IP Address|IP Address]]
*[[Parameter: Netmask|Netmask]]
*[[Parameter: Gateway|Gateway]]

Toolpack:Tsbc IP Network Settings 3.0

2017-04-20T14:45:22Z

Manon Bélanger: Adding link for transcoding unit

__NOTOC__
==TSBC-HW-SRV / Customer supplied hardware / Virtual Machines==

===IP Network===

{|
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Virtual Port
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Vlan
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Interface
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Port Range
|-
| valign="top" |
*[[Toolpack:Configuring_Virtual_Port_SBC_C|Configuring an IP Virtual Port]]
| valign="top" |
*[[Toolpack:Configuring a Vlan|Configuring a Vlan]]
| valign="top" |
*[[Toolpack:Configuring_IP_Interface_SBC_A|Configuring IP Interfaces]]
| valign="top" |
*[[Toolpack:Creating_an_IP_Port_Range_F|Create an IP port range]]
|}

|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Use Cases
|-
| valign="top" |
*[[Toolpack:TSBC-SW Network Configuration|TSBC-SW Network Configuration]]
|}
|}

===NAT===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | NAT Traversal
|-
| valign="top" |
*[[Create_NAT_Traversal_C|Create NAT Traversal]]
|}

===Transcoding Units===
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add transcoding units
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Configure transcoding network
|-
| valign="top" |
*[[Toolpack:Show Hardware units menu|Show Hardware units menu]]
*[[Toolpack:Adding_a_Transcoding_Unit_A|Add transcoding units]]
| valign="top" |
*[[Toolpack:Configuring an IP Virtual Port|Configuring an IP Virtual Port]]
*[[Toolpack:Configuring IP Interfaces|Configuring IP Interfaces]]
|}

==TSBC-HW-0/TSBC-HW-680/TSBC-HW-2700==

===New Hardware===
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add telecom hardware
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add 1+1 group
|-
| valign="top" |
*[[Toolpack:Adding_an_Adapter_F|Add telecom hardware]]
| valign="top" |
*[[Toolpack:Creating_a_1%2B1_Group_C|Add 1+1 group]]
|}

===IP Network===

{|
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Virtual Port
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Interface
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Port Range
|-
| valign="top" |
*[[Toolpack:Configuring_Virtual_Port_SBC_B|Configuring an IP Virtual Port]]
| valign="top" |
*[[Toolpack:Configuring_VoIP_Interfaces_E|Configuring IP Interfaces]]
| valign="top" |
*[[Toolpack:Creating_an_IP_Port_Range_E|Create an IP port range]]
|}
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Use Cases
|-
| valign="top" |
*[[Toolpack:Network Configuration|Network Configuration]]
|}
|}

===NAT===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | NAT Traversal
|-
| valign="top" |
*[[Create_NAT_Traversal_C|Create NAT Traversal]]
|}

Toolpack:Adding a Transcoding Unit A

2017-04-20T14:44:49Z

Manon Bélanger: First version

=== '''''Applies to version v3.0''''' ===
{{DISPLAYTITLE:Adding Transcoding Unit}}

'''To add a transcoding unit:'''

1- Click '''Hardware Units''' in the navigation panel

[[New image needed - after adding it to the web profile]]

2- Click '''Create New Unit''', to add a new hardware device

[[Image:Hardware_1_A.png]]

3- Enter information for the following parameters:
* Enter a '''name''' for the hardware device
* Enter the '''serial number''' of the new hardware device (filling in the Serial Number field will cause auto-completion of the field to occur).
* Select '''TDM and/or IP''' from the Type field.
* Enter the location in which the hardware device is installed.
* Enter a meaningful description about the use or purpose of the hardware device.
* Select '''Enabled''' from the Target State field.
* Select the type of TDM lines that the hardware device will support.
* Leave the Is N+1 Backup field empty.
* Provide the amount of time in seconds, that the system will wait for calls to complete before shutting down for an upgrade.
* Click '''Create'''

[[New image needed]]

4- Verify that the '''Unit was successfully created''' message appears, and that the newly added hardware device appears in the '''Hardware List'''.

[[Image:Hardware_4_A.png]]

==List of Parameters==

* [[Parameter: Name|Name]]
* [[Parameter: Serial|Serial]]
* [[Parameter: Adapter Type|Type]]
* [[Parameter: Location|Location]]
* [[Parameter: Description|Description]]
* [[Parameter: Target State|Target State]]
* [[Parameter: TDM Lines Type|TDM Lines Type]]
* [[Parameter: Is N+1 Backup|Is N+1 Backup]]
* [[Parameter: Graceful Upgrade Timeout|Graceful Upgrade Timeout]]

 

<div class="mw-collapsible mw-collapsed" data-collapsetext="Advanced Parameters" data-expandtext="Advanced Parameters" style="width: 400px;">
{| class="wikitable"
|-
* [[Parameter: Enable management port redundancy|Enable management port redundancy]]
* [[Parameter: Enable HTTP access|Enable HTTP access]]
* [[Parameter: Enable Telnet access|Enable Telnet access]]
* [[Parameter: Enable V.34 FAX|Enable V.34 FAX]]
* [[Parameter: Enable V.152 VBD|Enable V.152 VBD]]
* [[Parameter: ISDN primary CPU load|ISDN primary CPU load]]
* [[Parameter: Load CAS on secondary CPU|Load CAS on secondary CPU]]
* [[Parameter: Load ISUP on secondary CPU|Load ISUP on secondary CPU]]
* [[Parameter: Load M2PA on secondary CPU|Load M2PA on secondary CPU]]
* [[Parameter: Load M2UA on secondary CPU|Load M2UA on secondary CPU]]
* [[Parameter: Load M3UA on secondary CPU|Load M3UA on secondary CPU]]
* [[Parameter: Load SIP on secondary CPU|Load SIP on secondary CPU]]
* [[Parameter: Load IUA on secondary CPU|Load IUA on secondary CPU]]
* [[Parameter: Load LAPD on secondary CPU|Load LAPD on secondary CPU]]
* [[Parameter: Increase SIP Stack Allowed RAM|Increase SIP Stack Allowed RAM]]
* [[Parameter: SIP Dynamic memory size|SIP Dynamic memory size]]
* [[Parameter: SIP Event memory size|SIP Event memory size]]
* [[Parameter: SIP Signal memory size|SIP Signal memory size]]
* [[Parameter: SIP Signal pool sizes|SIP Signal pool sizes]]

* Reduced Timer
** [[Parameter: Timer Start Threshold|Start Threshold]]
** [[Parameter: Timer Stop Threshold|Stop Threshold]]

* Congestion
** [[Parameter: Congestion Start Threshold|Start Threshold]]
** [[Parameter: Congestion Stop Threshold|Stop Threshold]]

* Critical Congestion
** [[Parameter: Critical Congestion Start Threshold|Start Threshold]]
** [[Parameter: Critical Congestion Stop Threshold|Stop Threshold]]

* [[Parameter: TDM Companding|TDM Companding]]
* [[Parameter: VOIP Codec Mode|VOIP Codec Mode]]
* [[Parameter: Fixed density for G711 (20 ms packets)|Fixed density for G711 (20 ms packets)]]
* [[Parameter: Fixed density for G711 (10 ms packets)|Fixed density for G711 (10 ms packets)]]
* [[Parameter: Fixed density for G711 (5 ms packets)|Fixed density for G711 (5 ms packets)]]
* [[Parameter: Fixed density for G726 (20 ms packets)|Fixed density for G726 (20 ms packets)]]
* [[Parameter: Fixed density for G726 (10 ms packets)|Fixed density for G726 (10 ms packets)]]
* [[Parameter: Fixed density for G729A|Fixed density for G729A]]
* [[Parameter: Fixed density for G723|Fixed density for G723]]
* [[Parameter: Fixed density for G728|Fixed density for G728]]
* [[Parameter: Fixed density for G729EG 8 Kbps|Fixed density for G729EG 8 Kbps]]
* [[Parameter: Fixed density for G729EG 11.8 Kbps|Fixed density for G729EG 11.8 Kbps]]
* [[Parameter: Fixed density for AMR|Fixed density for AMR]]
* [[Parameter: Fixed density for EVRC|Fixed density for EVRC]]
* [[Parameter: Fixed density for QCELP8|Fixed density for QCELP8]]
* [[Parameter: Fixed density for QCELP13|Fixed density for QCELP13]]
* [[Parameter: Fixed density for SMV|Fixed density for SMV]]
* [[Parameter: Fixed density for EFR|Fixed density for EFR]]
* [[Parameter: Fixed density for T38|Fixed density for T38]]
* [[Parameter: Fixed density for ECHO high-latency|Fixed density for ECHO high-latency]]
* [[Parameter: Fixed density for ECHO medium-latency|Fixed density for ECHO medium-latency]]
* [[Parameter: Fixed density for ECHO low-latency|Fixed density for ECHO low-latency]]
* [[Parameter: Fixed density for FR|Fixed density for FR]]
* [[Parameter: Fixed density for ILBC 13 Kbps|Fixed density for ILBC 13 Kbps]]
* [[Parameter: Fixed density for ILBC 15 Kbps|Fixed density for ILBC 15 Kbps]]
* [[Parameter: Fixed density for G722.2|Fixed density for G722.2]]
|}
</div>

 

<div class="mw-collapsible mw-collapsed" data-collapsetext="Call Rate Limiting Parameters" data-expandtext="Call Rate Limiting Parameters" style="width: 400px;">
{| class="wikitable"
|-
* [[Parameter: Maximum SS7 calls per second|Maximum SS7 calls per second]]
* [[Parameter: Maximum SS7 call burst|Maximum SS7 call burst]]
* [[Parameter: Maximum ISDN calls per second|Maximum ISDN calls per second]]
* [[Parameter: Maximum ISDN call burst|Maximum ISDN call burst]]
* [[Parameter: Maximum CAS calls per second|Maximum CAS calls per second]]
* [[Parameter: Maximum CAS call burst|Maximum CAS call burst]]
* [[Parameter: Maximum SIP calls per second|Maximum SIP calls per second]]
* [[Parameter: Maximum SIP call burst|Maximum SIP call burst]]
* [[Parameter: Maximum total calls per second|Maximum total calls per second]]
* [[Parameter: Maximum total call burst|Maximum total call burst]]
|}
</div>

<div class="mw-collapsible mw-collapsed" data-collapsetext="Congestion Threshold" data-expandtext="Congestion Threshold" style="width: 400px;">
{| class="wikitable"
|-
* [[Parameter: Number of calls per period|Number of calls per period]]
* [[Parameter: Period Duration|Period Duration]]

|}
</div>

Toolpack:Tsbc IP Network Settings 3.0

2017-04-20T14:18:28Z

Manon Bélanger: Add link for 1+1

__NOTOC__
==TSBC-HW-SRV / Customer supplied hardware / Virtual Machines==

===IP Network===

{|
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Virtual Port
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Vlan
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Interface
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Port Range
|-
| valign="top" |
*[[Toolpack:Configuring_Virtual_Port_SBC_C|Configuring an IP Virtual Port]]
| valign="top" |
*[[Toolpack:Configuring a Vlan|Configuring a Vlan]]
| valign="top" |
*[[Toolpack:Configuring_IP_Interface_SBC_A|Configuring IP Interfaces]]
| valign="top" |
*[[Toolpack:Creating_an_IP_Port_Range_F|Create an IP port range]]
|}

|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Use Cases
|-
| valign="top" |
*[[Toolpack:TSBC-SW Network Configuration|TSBC-SW Network Configuration]]
|}
|}

===NAT===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | NAT Traversal
|-
| valign="top" |
*[[Create_NAT_Traversal_C|Create NAT Traversal]]
|}

===Transcoding Units===
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add transcoding units
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Configure transcoding network
|-
| valign="top" |
*[[Toolpack:Show Hardware units menu|Show Hardware units menu]]
*[[Toolpack:Add transcoding units|Add transcoding units]]
| valign="top" |
*[[Toolpack:Configuring an IP Virtual Port|Configuring an IP Virtual Port]]
*[[Toolpack:Configuring IP Interfaces|Configuring IP Interfaces]]
|}

==TSBC-HW-0/TSBC-HW-680/TSBC-HW-2700==

===New Hardware===
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add telecom hardware
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add 1+1 group
|-
| valign="top" |
*[[Toolpack:Adding_an_Adapter_F|Add telecom hardware]]
| valign="top" |
*[[Toolpack:Creating_a_1%2B1_Group_C|Add 1+1 group]]
|}

===IP Network===

{|
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Virtual Port
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Interface
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Port Range
|-
| valign="top" |
*[[Toolpack:Configuring_Virtual_Port_SBC_B|Configuring an IP Virtual Port]]
| valign="top" |
*[[Toolpack:Configuring_VoIP_Interfaces_E|Configuring IP Interfaces]]
| valign="top" |
*[[Toolpack:Creating_an_IP_Port_Range_E|Create an IP port range]]
|}
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Use Cases
|-
| valign="top" |
*[[Toolpack:Network Configuration|Network Configuration]]
|}
|}

===NAT===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | NAT Traversal
|-
| valign="top" |
*[[Create_NAT_Traversal_C|Create NAT Traversal]]
|}

Toolpack:Tsbc IP Network Settings 3.0

2017-04-20T14:17:47Z

Manon Bélanger: Add link for adapter

__NOTOC__
==TSBC-HW-SRV / Customer supplied hardware / Virtual Machines==

===IP Network===

{|
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Virtual Port
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Vlan
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Interface
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Port Range
|-
| valign="top" |
*[[Toolpack:Configuring_Virtual_Port_SBC_C|Configuring an IP Virtual Port]]
| valign="top" |
*[[Toolpack:Configuring a Vlan|Configuring a Vlan]]
| valign="top" |
*[[Toolpack:Configuring_IP_Interface_SBC_A|Configuring IP Interfaces]]
| valign="top" |
*[[Toolpack:Creating_an_IP_Port_Range_F|Create an IP port range]]
|}

|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Use Cases
|-
| valign="top" |
*[[Toolpack:TSBC-SW Network Configuration|TSBC-SW Network Configuration]]
|}
|}

===NAT===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | NAT Traversal
|-
| valign="top" |
*[[Create_NAT_Traversal_C|Create NAT Traversal]]
|}

===Transcoding Units===
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add transcoding units
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Configure transcoding network
|-
| valign="top" |
*[[Toolpack:Show Hardware units menu|Show Hardware units menu]]
*[[Toolpack:Add transcoding units|Add transcoding units]]
| valign="top" |
*[[Toolpack:Configuring an IP Virtual Port|Configuring an IP Virtual Port]]
*[[Toolpack:Configuring IP Interfaces|Configuring IP Interfaces]]
|}

==TSBC-HW-0/TSBC-HW-680/TSBC-HW-2700==

===New Hardware===
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add telecom hardware
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add 1+1 group
|-
| valign="top" |
*[[Toolpack:Adding_an_Adapter_F|Add telecom hardware]]
| valign="top" |
*[[Toolpack:Add 1+1 group|Add 1+1 group]]
|}

===IP Network===

{|
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Virtual Port
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Interface
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Port Range
|-
| valign="top" |
*[[Toolpack:Configuring_Virtual_Port_SBC_B|Configuring an IP Virtual Port]]
| valign="top" |
*[[Toolpack:Configuring_VoIP_Interfaces_E|Configuring IP Interfaces]]
| valign="top" |
*[[Toolpack:Creating_an_IP_Port_Range_E|Create an IP port range]]
|}
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Use Cases
|-
| valign="top" |
*[[Toolpack:Network Configuration|Network Configuration]]
|}
|}

===NAT===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | NAT Traversal
|-
| valign="top" |
*[[Create_NAT_Traversal_C|Create NAT Traversal]]
|}

Toolpack:Tsbc IP Network Settings 3.0

2017-04-20T14:08:40Z

Manon Bélanger: Adding link for virtual port

__NOTOC__
==TSBC-HW-SRV / Customer supplied hardware / Virtual Machines==

===IP Network===

{|
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Virtual Port
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Vlan
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Interface
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Port Range
|-
| valign="top" |
*[[Toolpack:Configuring_Virtual_Port_SBC_C|Configuring an IP Virtual Port]]
| valign="top" |
*[[Toolpack:Configuring a Vlan|Configuring a Vlan]]
| valign="top" |
*[[Toolpack:Configuring_IP_Interface_SBC_A|Configuring IP Interfaces]]
| valign="top" |
*[[Toolpack:Creating_an_IP_Port_Range_F|Create an IP port range]]
|}

|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Use Cases
|-
| valign="top" |
*[[Toolpack:TSBC-SW Network Configuration|TSBC-SW Network Configuration]]
|}
|}

===NAT===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | NAT Traversal
|-
| valign="top" |
*[[Create_NAT_Traversal_C|Create NAT Traversal]]
|}

===Transcoding Units===
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add transcoding units
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Configure transcoding network
|-
| valign="top" |
*[[Toolpack:Show Hardware units menu|Show Hardware units menu]]
*[[Toolpack:Add transcoding units|Add transcoding units]]
| valign="top" |
*[[Toolpack:Configuring an IP Virtual Port|Configuring an IP Virtual Port]]
*[[Toolpack:Configuring IP Interfaces|Configuring IP Interfaces]]
|}

==TSBC-HW-0/TSBC-HW-680/TSBC-HW-2700==

===New Hardware===
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add telecom hardware
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add 1+1 group
|-
| valign="top" |
*[[Toolpack:Add telecom hardware|Add telecom hardware]]
| valign="top" |
*[[Toolpack:Add 1+1 group|Add 1+1 group]]
|}

===IP Network===

{|
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Virtual Port
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Interface
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Port Range
|-
| valign="top" |
*[[Toolpack:Configuring_Virtual_Port_SBC_B|Configuring an IP Virtual Port]]
| valign="top" |
*[[Toolpack:Configuring_VoIP_Interfaces_E|Configuring IP Interfaces]]
| valign="top" |
*[[Toolpack:Creating_an_IP_Port_Range_E|Create an IP port range]]
|}
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Use Cases
|-
| valign="top" |
*[[Toolpack:Network Configuration|Network Configuration]]
|}
|}

===NAT===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | NAT Traversal
|-
| valign="top" |
*[[Create_NAT_Traversal_C|Create NAT Traversal]]
|}

Toolpack:Configuring Virtual Port SBC C

2017-04-20T14:05:32Z

Manon Bélanger: First version

Toolpack:Tsbc IP Network Settings 3.0

2017-04-20T13:56:55Z

Manon Bélanger: Add link for nat traversal

__NOTOC__
==TSBC-HW-SRV / Customer supplied hardware / Virtual Machines==

===IP Network===

{|
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Virtual Port
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Vlan
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Interface
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Port Range
|-
| valign="top" |
*[[Toolpack:Configuring an IP Virtual Port|Configuring an IP Virtual Port]]
| valign="top" |
*[[Toolpack:Configuring a Vlan|Configuring a Vlan]]
| valign="top" |
*[[Toolpack:Configuring_IP_Interface_SBC_A|Configuring IP Interfaces]]
| valign="top" |
*[[Toolpack:Creating_an_IP_Port_Range_F|Create an IP port range]]
|}

|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Use Cases
|-
| valign="top" |
*[[Toolpack:TSBC-SW Network Configuration|TSBC-SW Network Configuration]]
|}
|}

===NAT===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | NAT Traversal
|-
| valign="top" |
*[[Create_NAT_Traversal_C|Create NAT Traversal]]
|}

===Transcoding Units===
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add transcoding units
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Configure transcoding network
|-
| valign="top" |
*[[Toolpack:Show Hardware units menu|Show Hardware units menu]]
*[[Toolpack:Add transcoding units|Add transcoding units]]
| valign="top" |
*[[Toolpack:Configuring an IP Virtual Port|Configuring an IP Virtual Port]]
*[[Toolpack:Configuring IP Interfaces|Configuring IP Interfaces]]
|}

==TSBC-HW-0/TSBC-HW-680/TSBC-HW-2700==

===New Hardware===
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add telecom hardware
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add 1+1 group
|-
| valign="top" |
*[[Toolpack:Add telecom hardware|Add telecom hardware]]
| valign="top" |
*[[Toolpack:Add 1+1 group|Add 1+1 group]]
|}

===IP Network===

{|
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Virtual Port
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Interface
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Port Range
|-
| valign="top" |
*[[Toolpack:Configuring_Virtual_Port_SBC_B|Configuring an IP Virtual Port]]
| valign="top" |
*[[Toolpack:Configuring_VoIP_Interfaces_E|Configuring IP Interfaces]]
| valign="top" |
*[[Toolpack:Creating_an_IP_Port_Range_E|Create an IP port range]]
|}
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Use Cases
|-
| valign="top" |
*[[Toolpack:Network Configuration|Network Configuration]]
|}
|}

===NAT===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | NAT Traversal
|-
| valign="top" |
*[[Create_NAT_Traversal_C|Create NAT Traversal]]
|}

Create NAT Traversal C

2017-04-20T13:55:44Z

Manon Bélanger: First version

=== '''''Applies to version(s): v3.0''''' ===
{{DISPLAYTITLE:Create a NAT Traversal}}

One or more NAT traversals can be configured to manage the IP connections traversing network address translation (NAT) gateways.

== To configure a NAT traversal ==

1. Select '''NATs''' from the navigation panel.

[[New image needed]] 

2. Click '''Create New NAT Traversal'''

[[Image:CreateNatTraversal_1.png]] 

3. Configure the following fields:

*Enter a name for the NAT Traversal.
*Set the local Nat traversal method to '''Force public IP'''.
*Enter the public IP address of the unit.
*Click '''Create'''

[[Image:CreateNatTraversal_2.png]] 

4. Verfiy that the '''NAT Configuration was successfully created''' message is displayed

[[Image:CreateNatTraversal_3.png]] 

==List of Parameters==

* [[Parameter: Name|Name]]
* [[Parameter: Method|Method]]
* [[Parameter: Public Interface|Public Interface]]

Toolpack:Tsbc IP Network Settings 3.0

2017-04-20T13:49:20Z

Manon Bélanger: Adding link for IP interfaces

__NOTOC__
==TSBC-HW-SRV / Customer supplied hardware / Virtual Machines==

===IP Network===

{|
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Virtual Port
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Vlan
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Interface
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Port Range
|-
| valign="top" |
*[[Toolpack:Configuring an IP Virtual Port|Configuring an IP Virtual Port]]
| valign="top" |
*[[Toolpack:Configuring a Vlan|Configuring a Vlan]]
| valign="top" |
*[[Toolpack:Configuring_IP_Interface_SBC_A|Configuring IP Interfaces]]
| valign="top" |
*[[Toolpack:Creating_an_IP_Port_Range_F|Create an IP port range]]
|}

|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Use Cases
|-
| valign="top" |
*[[Toolpack:TSBC-SW Network Configuration|TSBC-SW Network Configuration]]
|}
|}

===NAT===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | NAT Traversal
|-
| valign="top" |
*[[Toolpack:Create NAT Traversal|Create NAT Traversal]]
|}

===Transcoding Units===
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add transcoding units
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Configure transcoding network
|-
| valign="top" |
*[[Toolpack:Show Hardware units menu|Show Hardware units menu]]
*[[Toolpack:Add transcoding units|Add transcoding units]]
| valign="top" |
*[[Toolpack:Configuring an IP Virtual Port|Configuring an IP Virtual Port]]
*[[Toolpack:Configuring IP Interfaces|Configuring IP Interfaces]]
|}

==TSBC-HW-0/TSBC-HW-680/TSBC-HW-2700==

===New Hardware===
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add telecom hardware
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add 1+1 group
|-
| valign="top" |
*[[Toolpack:Add telecom hardware|Add telecom hardware]]
| valign="top" |
*[[Toolpack:Add 1+1 group|Add 1+1 group]]
|}

===IP Network===

{|
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Virtual Port
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Interface
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Port Range
|-
| valign="top" |
*[[Toolpack:Configuring_Virtual_Port_SBC_B|Configuring an IP Virtual Port]]
| valign="top" |
*[[Toolpack:Configuring_VoIP_Interfaces_E|Configuring IP Interfaces]]
| valign="top" |
*[[Toolpack:Creating_an_IP_Port_Range_E|Create an IP port range]]
|}
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Use Cases
|-
| valign="top" |
*[[Toolpack:Network Configuration|Network Configuration]]
|}
|}

===NAT===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | NAT Traversal
|-
| valign="top" |
*[[Sandbox:Create NAT Traversal|Create NAT Traversal]]
|}

Toolpack:Configuring IP Interface SBC A

2017-04-20T13:48:46Z

Manon Bélanger: First version

=== '''''Applies to version(s): v3.0''''' ===
{{DISPLAYTITLE:Configuring IP Interfaces}}

The IP interface of the LAN/WAN ports can be configured by setting the following:

*IP Address
*Netmask
*Gateway

 

== To configure a LAN/WAN IP interface ==

1. Select '''IP Interfaces''' from the navigation panel:

[[New image needed - under Hosts]]

 2. Click the '''IP Interfaces''' tab.
*Click '''Create New IP Interface'''

[[New image needed]]

 3. Configure the IP interface:

*Enter a name for the interface
*Select a service to use for the IP interface
*Select the '''Host VLAN''' from which IP packets will exit.
*Indicate whether or not to use DHCP to automatically get an IP address for this port. (selecting this option removes the need to enter and IP address, Netmask, and Gateway)
*Enter an '''IP address'''
*Enter a '''Netmask'''
*Enter a '''gateway address'''
*Click '''Save'''

[[New image needed]]

 

4. The changes are displayed in the IP interfaces information panel:

[[New image needed]]

 

5. Activate the configuration

Systems -> Edit -> Activate

== List of Parameters ==

*[[Parameter: Interface name|Interface name]]
*[[Parameter: Services to use|Services to use]]
*[[Parameter: Host VLAN|Host VLAN]]
*[[Parameter: Use DHCP|Use DHCP]]
*[[Parameter: IP Address|IP Address]]
*[[Parameter: Netmask|Netmask]]
*[[Parameter: Gateway|Gateway]]

Toolpack:Tsbc IP Network Settings 3.0

2017-04-20T13:39:27Z

Manon Bélanger: Adding link for IP interfaces

__NOTOC__
==TSBC-HW-SRV / Customer supplied hardware / Virtual Machines==

===IP Network===

{|
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Virtual Port
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Vlan
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Interface
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Port Range
|-
| valign="top" |
*[[Toolpack:Configuring an IP Virtual Port|Configuring an IP Virtual Port]]
| valign="top" |
*[[Toolpack:Configuring a Vlan|Configuring a Vlan]]
| valign="top" |
*[[Toolpack:Configuring IP Interfaces|Configuring IP Interfaces]]
| valign="top" |
*[[Toolpack:Creating_an_IP_Port_Range_F|Create an IP port range]]
|}

|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Use Cases
|-
| valign="top" |
*[[Toolpack:TSBC-SW Network Configuration|TSBC-SW Network Configuration]]
|}
|}

===NAT===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | NAT Traversal
|-
| valign="top" |
*[[Toolpack:Create NAT Traversal|Create NAT Traversal]]
|}

===Transcoding Units===
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add transcoding units
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Configure transcoding network
|-
| valign="top" |
*[[Toolpack:Show Hardware units menu|Show Hardware units menu]]
*[[Toolpack:Add transcoding units|Add transcoding units]]
| valign="top" |
*[[Toolpack:Configuring an IP Virtual Port|Configuring an IP Virtual Port]]
*[[Toolpack:Configuring IP Interfaces|Configuring IP Interfaces]]
|}

==TSBC-HW-0/TSBC-HW-680/TSBC-HW-2700==

===New Hardware===
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add telecom hardware
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add 1+1 group
|-
| valign="top" |
*[[Toolpack:Add telecom hardware|Add telecom hardware]]
| valign="top" |
*[[Toolpack:Add 1+1 group|Add 1+1 group]]
|}

===IP Network===

{|
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Virtual Port
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Interface
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Port Range
|-
| valign="top" |
*[[Toolpack:Configuring_Virtual_Port_SBC_B|Configuring an IP Virtual Port]]
| valign="top" |
*[[Toolpack:Configuring_VoIP_Interfaces_E|Configuring IP Interfaces]]
| valign="top" |
*[[Toolpack:Creating_an_IP_Port_Range_E|Create an IP port range]]
|}
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Use Cases
|-
| valign="top" |
*[[Toolpack:Network Configuration|Network Configuration]]
|}
|}

===NAT===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | NAT Traversal
|-
| valign="top" |
*[[Sandbox:Create NAT Traversal|Create NAT Traversal]]
|}

Toolpack:Configuring VoIP Interfaces E

2017-04-20T13:38:50Z

Manon Bélanger: First version

=== '''''Applies to version(s): v3.0''''' ===
{{DISPLAYTITLE:Configuring VoIP Interfaces}}

The IP interface of the VoIP0 and VoIP1 ports can be configured by setting the following:

*IP Address
*Netmask
*Gateway

 

== To configure a VoIP0 or VoIP1 port ==

1. Select '''IP Interfaces''' from the navigation panel:

[[New image needed - under Hardware Units]]

 2. Click the '''IP Interfaces''' tab.
*Click '''Create New IP Interface'''

[[Image:Voip_Interface_1a.png]]

 3. Configure the IP port:

*Enter a name for the interface
*Select a service to use for the IP inteface
*Select a '''Virtual port''' from which IP packets will exit.
*Indicate whether or not to use DHCP to automatically get an IP address for this port. (selecting this option removes the need to enter and IP address, Netmask, and Gateway)
*Enter an '''IP address'''
*Enter a '''Netmask'''
*Enter a '''gateway address'''
*Click '''Save'''

'''Note:''' The IP addresses of ETH0, ETH1, VOIP0 and VOIP1 must be on different subnets. 

[[New image needed]]

 

4. The changes are displayed in the IP interfaces information panel:

[[New image needed]]

 

5. Activate the configuration

Systems -> Edit -> Activate

6. It is necessary to reboot the adapters if you are using the vlan from 3441 to 3450 only.

Status -> Adapters -> Click on the adapter Serial Number -> Reboot adapter

It will take about 1.5 minutes to restart the unit.

'''Note:''' in a 1+1 system, both units must be restarted.

== List of Parameters ==

*[[Parameter: Interface name|Interface name]]
*[[Parameter: Services to use|Services to use]]
*[[Parameter: Virtual port|Virtual port]]
*[[Parameter: Use DHCP|Use dynamic IP]]
*[[Parameter: IP Address|IP Address]]
*[[Parameter: Netmask|Netmask]]
*[[Parameter: Gateway|Gateway]]

Toolpack:Tsbc IP Network Settings 3.0

2017-04-20T13:30:54Z

Manon Bélanger: Add link for virtual port

__NOTOC__
==TSBC-HW-SRV / Customer supplied hardware / Virtual Machines==

===IP Network===

{|
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Virtual Port
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Vlan
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Interface
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Port Range
|-
| valign="top" |
*[[Toolpack:Configuring an IP Virtual Port|Configuring an IP Virtual Port]]
| valign="top" |
*[[Toolpack:Configuring a Vlan|Configuring a Vlan]]
| valign="top" |
*[[Toolpack:Configuring IP Interfaces|Configuring IP Interfaces]]
| valign="top" |
*[[Toolpack:Creating_an_IP_Port_Range_F|Create an IP port range]]
|}

|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Use Cases
|-
| valign="top" |
*[[Toolpack:TSBC-SW Network Configuration|TSBC-SW Network Configuration]]
|}
|}

===NAT===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | NAT Traversal
|-
| valign="top" |
*[[Toolpack:Create NAT Traversal|Create NAT Traversal]]
|}

===Transcoding Units===
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add transcoding units
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Configure transcoding network
|-
| valign="top" |
*[[Toolpack:Show Hardware units menu|Show Hardware units menu]]
*[[Toolpack:Add transcoding units|Add transcoding units]]
| valign="top" |
*[[Toolpack:Configuring an IP Virtual Port|Configuring an IP Virtual Port]]
*[[Toolpack:Configuring IP Interfaces|Configuring IP Interfaces]]
|}

==TSBC-HW-0/TSBC-HW-680/TSBC-HW-2700==

===New Hardware===
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add telecom hardware
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add 1+1 group
|-
| valign="top" |
*[[Toolpack:Add telecom hardware|Add telecom hardware]]
| valign="top" |
*[[Toolpack:Add 1+1 group|Add 1+1 group]]
|}

===IP Network===

{|
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Virtual Port
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Interface
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Port Range
|-
| valign="top" |
*[[Toolpack:Configuring_Virtual_Port_SBC_B|Configuring an IP Virtual Port]]
| valign="top" |
*[[Toolpack:Configuring IP Interfaces|Configuring IP Interfaces]]
| valign="top" |
*[[Toolpack:Creating_an_IP_Port_Range_E|Create an IP port range]]
|}
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Use Cases
|-
| valign="top" |
*[[Toolpack:Network Configuration|Network Configuration]]
|}
|}

===NAT===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | NAT Traversal
|-
| valign="top" |
*[[Sandbox:Create NAT Traversal|Create NAT Traversal]]
|}

Toolpack:Tsbc IP Network Settings 3.0

2017-04-20T13:23:36Z

Manon Bélanger: Add links for port range

__NOTOC__
==TSBC-HW-SRV / Customer supplied hardware / Virtual Machines==

===IP Network===

{|
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Virtual Port
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Vlan
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Interface
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Port Range
|-
| valign="top" |
*[[Toolpack:Configuring an IP Virtual Port|Configuring an IP Virtual Port]]
| valign="top" |
*[[Toolpack:Configuring a Vlan|Configuring a Vlan]]
| valign="top" |
*[[Toolpack:Configuring IP Interfaces|Configuring IP Interfaces]]
| valign="top" |
*[[Toolpack:Creating_an_IP_Port_Range_F|Create an IP port range]]
|}

|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Use Cases
|-
| valign="top" |
*[[Toolpack:TSBC-SW Network Configuration|TSBC-SW Network Configuration]]
|}
|}

===NAT===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | NAT Traversal
|-
| valign="top" |
*[[Toolpack:Create NAT Traversal|Create NAT Traversal]]
|}

===Transcoding Units===
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add transcoding units
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Configure transcoding network
|-
| valign="top" |
*[[Toolpack:Show Hardware units menu|Show Hardware units menu]]
*[[Toolpack:Add transcoding units|Add transcoding units]]
| valign="top" |
*[[Toolpack:Configuring an IP Virtual Port|Configuring an IP Virtual Port]]
*[[Toolpack:Configuring IP Interfaces|Configuring IP Interfaces]]
|}

==TSBC-HW-0/TSBC-HW-680/TSBC-HW-2700==

===New Hardware===
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add telecom hardware
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add 1+1 group
|-
| valign="top" |
*[[Toolpack:Add telecom hardware|Add telecom hardware]]
| valign="top" |
*[[Toolpack:Add 1+1 group|Add 1+1 group]]
|}

===IP Network===

{|
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add Virtual Port
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Interface
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Add IP Port Range
|-
| valign="top" |
*[[Toolpack:Configuring an IP Virtual Port|Configuring an IP Virtual Port]]
| valign="top" |
*[[Toolpack:Configuring IP Interfaces|Configuring IP Interfaces]]
| valign="top" |
*[[Toolpack:Creating_an_IP_Port_Range_E|Create an IP port range]]
|}
|STYLE="vertical-align: top"|
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: none repeat scroll 0% 0% rgb(239, 239, 239); -moz-background-inline-policy: continuous;" | Use Cases
|-
| valign="top" |
*[[Toolpack:Network Configuration|Network Configuration]]
|}
|}

===NAT===

{| cellpadding="5" border="1" class="wikitable"
|-
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | NAT Traversal
|-
| valign="top" |
*[[Sandbox:Create NAT Traversal|Create NAT Traversal]]
|}

Toolpack:Configuring Virtual Port SBC B

2017-04-19T21:04:07Z

Manon Bélanger: First version of the page

=== '''''Applies to version(s): v3.0''''' ===
{{DISPLAYTITLE:Configuring a Virtual Port}}

One or more virtual ports can be created to manage IP traffic.

 

== To configure a virtual port ==

1. Select '''IP Interfaces''' from the navigation panel

[[New image needed - under Hardware units]] 

2. Click the '''Virtual Ports''' tab.
*Click '''Create New Virtual Port'''

[[Image:VirtualPort_0.png]] 

3. Configure the virtual port.

*Enter a name for the virtual port
*Select the hardware device to which the virtual port is assigned
*Enter a VLAN ID
*Select a physical port to which the virtual port is assigned

*Click '''Create'''

[[new image needed]] 

==List of Parameters==

* [[Parameter: Name|Name]]
* [[Parameter: Unit to create for|Unit to create for]]
* [[Parameter: Untagged|Untagged]]
* [[Parameter: VlAN ID|VLAN ID]]
* [[Parameter: Used by SBC|Used by SBC]]
* [[Parameter: Allow PING|Allow PING]]

Toolpack:Creating an IP Port Range E

2017-04-19T20:26:12Z

Manon Bélanger: Adding precision

=== '''''Applies to version(s): v3.0''''' ===
{{DISPLAYTITLE:Configuring an IP Port Range}}

A range of IP ports can be configured.

 

== To configure an RTP port range ==

1. Select '''IP Interfaces''' from the navigation panel:

[[New image needed - under hardware units]]

 2. Click the '''RTP Port Ranges''' tab:
*Click '''Create New RTP Port Ranges'''

[[Image:CreateIP_PortRange_0.png]]

 3. Configure the range of ports:

*Enter a name for the port range
*Select one or more IP interfaces
*Enter a minimum port number for the port range
*Enter a maximum port number for the port range
*Click '''Create'''

[[Image:CreateIP_PortRange_1.png]]

<div class="mw-collapsible mw-collapsed" data-collapsetext="Northbound Interface" data-expandtext="Northbound Interface" style="width: 400px;">

'''Path'''
<pre>
/configurations/@[configuration_name]/hardware_units/@[hardware_name]/rtp_port_ranges/Default
</pre>

'''Parameters (text)'''
<pre>
/configurations/@[configuration_name]/hardware_units/@[hardware_name]/rtp_port_ranges/Default
ip_interface = "@[hardware_name]"."@[port_name]"
name = "Default"
port_max = 60000
port_min = 10000
unique_name = "@[name]"
</pre>

'''Parameters (json)'''
<pre>
{
"ip_interface" : "@[hardware_name]"."@[port_name]",
"name" : "Default",
"port_max" : 60000,
"port_min" : 10000,
"unique_name" : "@[name]"
}
</pre>
</div>

== List of Parameters ==

*[[Parameter: Name|Name]]
*[[Parameter: RTP Port min|RTP Port min]]
*[[Parameter: RTP Port max|RTP Port max]]

Toolpack:Creating an IP Port Range E

2017-04-19T20:24:56Z

Manon Bélanger: Create page

=== '''''Applies to version(s): v3.0''''' ===
{{DISPLAYTITLE:Configuring an IP Port Range}}

A range of IP ports can be configured.

 

== To configure an RTP port range ==

1. Select '''IP Interfaces''' from the navigation panel:

[[New image needed]]

 2. Click the '''RTP Port Ranges''' tab:
*Click '''Create New RTP Port Ranges'''

[[Image:CreateIP_PortRange_0.png]]

 3. Configure the range of ports:

*Enter a name for the port range
*Select one or more IP interfaces
*Enter a minimum port number for the port range
*Enter a maximum port number for the port range
*Click '''Create'''

[[Image:CreateIP_PortRange_1.png]]

<div class="mw-collapsible mw-collapsed" data-collapsetext="Northbound Interface" data-expandtext="Northbound Interface" style="width: 400px;">

'''Path'''
<pre>
/configurations/@[configuration_name]/hardware_units/@[hardware_name]/rtp_port_ranges/Default
</pre>

'''Parameters (text)'''
<pre>
/configurations/@[configuration_name]/hardware_units/@[hardware_name]/rtp_port_ranges/Default
ip_interface = "@[hardware_name]"."@[port_name]"
name = "Default"
port_max = 60000
port_min = 10000
unique_name = "@[name]"
</pre>

'''Parameters (json)'''
<pre>
{
"ip_interface" : "@[hardware_name]"."@[port_name]",
"name" : "Default",
"port_max" : 60000,
"port_min" : 10000,
"unique_name" : "@[name]"
}
</pre>
</div>

== List of Parameters ==

*[[Parameter: Name|Name]]
*[[Parameter: RTP Port min|RTP Port min]]
*[[Parameter: RTP Port max|RTP Port max]]

How to change host password on Linux

2016-08-29T18:30:06Z

Manon Bélanger: Fixed typo

To better protect your system, it is '''required''' to change the default password. Please see this page http://www.usewisdom.com/computer/passwords.html for guidelines on how to choose a good password. Additionally it is always more secure to keep passwords in as less hands/heads as possible.

== Change the password ==

* Connect to your unit through [[TMG:Accessing_Device#SSH|SSH]]

* Enter the passwd command

:Example:
[root@TB003540 ~]# passwd

* The system will ask you to enter your new password twice

* For more information
man passwd

Toolpack monitoring sip simulator

2016-04-22T13:02:18Z

Manon Bélanger: Fixed typos. Also specified that RTP generation is optional.

[[Image:Monitoring_generator_overview.png|thumb|300px]]
The Toolpack Monitoring "SIP Generator" is a behavior that can be attached to a call flow, and that will send simulated SIP messages to a destination host, simulating that a SIP call is being monitored.

The SIP simulator sends SIP messages, but does not expect any reply from the destination.
It simulates both sides of the SIP call (simulating a sip "Invite" from one side, then "100-Trying" from the other side, etc.)

It can also send a copy of the monitored legs audio using RTP packets, as indicated in the SDP of the simulated SIP message (Invite, 183-Progress and 200-OK).

== SIP simulator call flow ==
Once attached to a call flow, the "SIP simulator" behavior will identify the "main" legs of the attached call flow (one incoming and one outgoing), and watch for call state changes of these legs.
Corresponding SIP messages are generated.

[[Image:SIP_simulator_call_flow.png|560px]]

=== Attaching to a monitoring call flow ===
The SIP simulator behavior can be attached to a standard call flow (CTBCAFBrige for example, which deals with a bridge between one incoming and one outgoing call legs).

It can also be attached to a "monitoring" call flow that receives call state change events from an analyzer (like an [[Toolpack_monitoring_isdn_analyzer|ISDN Analyzer]]).

In both cases, it will generate SIP messages based on the call state changes event received (call accepted, alerting, answered, etc...)

== SIP simulator configuration ==
The SIP simulator has multiple options that can be configured (from it's "parameters" class for developers, or from the Web Portal for Toolpack Gateway users).

=== RTP generation options ===
The SIP simulator can send RTP packets that contain a copy of the audio of the monitored call. These RTP packets are sent by a VOIP resource on the [[TMedia]] unit.

RTP generation options are:
* The VOIP Media NAP to generate RTP from. "None" will disable RTP generation. This NAP defines:
** The source IP interface, and port range to use
** A default "profile"
* A "profile" to use instead of the NAP's default profile. The profile will define:
** The codec to use (the SDP)
** The DTMF relay scheme ('''Note:''' only "in-band" and "RFC-2833" being available with the "SIP simulator")
** '''Note''': The "SIP" options available in the "profile" page in the web portal are ignored here
** Audio options (volume control, voice activity detection)
** RTCP options
** IP header "TOS" field

=== SIP generation options ===
The "SIP Simulator" will send SIP packets from the application using the following "source" options:
* Source "host" IP interface (or "ANY" to choose by subnet matching or default gateway)
* Source UDP port
* IP header "TOS" field for SIP packets

=== SIP messages formatting ===
The "SIP Simulator" offers configurable SIP messages content, which will be used when necessary by the "SIP Simulator"
* The simulated "from" IP address and port (can be "fictive" IP address representing one "side" of the call)
* The simulated "to" IP address and port (can be "fictive" IP address representing one "side" of the call)
* The SIP message text of each SIP message, built using [[toolpack_monitoring_sip_simulator_variables|well-known variables]], and user-defined variables.
** From caller:
*** SIP INVITE
*** SIP ACK (after the INVITE 200 OK)
*** SIP BYE
*** SIP CANCEL
*** SIP 200 OK (after BYE)
*** SIP ACK (after 487)
** From callee:
*** SIP 100 Trying
*** SIP 183 Session Progress
*** SIP 200 OK
*** SIP Decline
*** SIP BYE
*** SIP 200 OK (after BYE or CANCEL)
*** SIP 487 Request Terminated

=== Example SIP message configuration ===
INVITE sip:#{called}@#{callee_sip_ip}:#{callee_sip_port} SIP/2.0
Call-ID:#{call_id}
X-Monitored-Sender:#{sender_label}:#{sender}
X-Isdn-Info:interface-id:#{isdn_interface_id};channel-number:#{isdn_channel_number}
X-Example-Var:#{example_var}
To:<sip:#{sip_to}>
From:#{calling_display}<sip:#{sip_from}>;tag=#{caller_tag}
Remote-Party-ID:#{calling_private_display}<sip:#{calling_private}@#{caller_sip_ip}:#{caller_sip_port}>;party=calling;screen=#{calling_screening};privacy=#{calling_presentation};noa=#{calling_noa}
Privacy:#{calling_privacy}
Contact:sip:#{calling}@#{caller_sip_ip}:#{caller_sip_port}
Via:SIP/2.0/UDP #{caller_sip_ip}:#{caller_sip_port};branch=#{branch};rport
User-to-User:#{uui};encoding=text;purpose=isdn-interwork;content=isdn-uui
Date:#{date}
Timestamp:#{timestamp}
CSeq:#{cseq}
Max-Forwards:70
#{caller_content}

For more information about available variables used to generate the SIP messages (SIP headers and body), read the following article:
[[toolpack_monitoring_sip_simulator_variables|SIP Simulator messages formatting variables]]

=== SIP and RTP destination ===
The generated SIP messages are sent to the specified IP address and port.

The generated RTP packets are sent to the specified IP address (can be different from SIP destination IP address), using a port chosen from the NAP's port ranges, and indicated to the remote equipment through the SDP in the SIP messages ("INVITE", "183-Progress" and "200-OK").

== Using multiple destinations ==
If necessary, multiple redundant destinations can be configured. Each destination includes:
* SIP destination IP and port
* RTP destination IP
* Optional destination "TCP" polling IP and port
* A priority

=== Destination polling ===
To determine which destination is available, a "ping" will be made toward the destination SIP IP address.

In addition to the "ping", a "TCP" polling can be performed, by attempting a TCP connection to the given IP address and port.

A destination is considered available if the "ping" and the "TCP connection polling" (if used) both succeed.

The available destination with the highest priority will be chosen.

== Configuring SIP Simulators in Toolpack Web Portal ==
Developers can use SIP Simulators in their application by using class CTBCAFSipSimulator to define SIP simulator parameters and allocate SIP sender socket, and attach behavior CTBCAFCallBehaviorSipSimulator to their call flow.

Non-developers that use Toolpack system with built-in Gateway application can also use SIP Simulators and attach them to ISDN analyzers.

In the Web Portal, configuring SIP Simulators is done by:
* [[Toolpack_monitoring_isdn_analyzer#Configuring_ISDN_analyzers_in_Toolpack_Web_Portal|Creating Line Service Pairs, and ISDN analyzers]]
* Create IP interfaces (from the "IP Interfaces" section in the left menu)
** IP Interface(s) with RTP service (default "voip0" IP interface can be used here)
** Optional "Host" IP interface for service "H248/Radius", used as source IP interface for SIP messages generation
* Create a VOIP Media-only NAP (from the "NAPs" section in the left menu)
** Assign a "Port range" from the "RTP" IP interface created above
* Create SIP simulator
** Click on "Sip Simulators" section in the left menu
** Fill-out the required information in the page
** Create one or multiple SIP Simulator destinations (from the SIP Simulators configuration page)
* Associate this "SIP Simulator" to one or multiple [[Toolpack_monitoring_isdn_analyzer|ISDN Analyzer(s)]] (from the ISDN Analysers' configuration page)

For more information and step-by-step screen shots of the configuration of SIP Simulators, please refer to the [[Web Portal Tutorial Guide v2.9]].

Toolpack monitoring isdn analyzer

2016-04-22T12:46:18Z

Manon Bélanger: Minor corrections

[[Image:Monitoring_isdn_analyzer.png|thumb|300px]]
Toolpack ISDN Analyzer is a class that uses Media-only legs and monitoring API to capture HDLC frames from ISDN D-channel timeslot.

The captured ISDN HDLC frames are analyzed, to identify Q.921 and Q.931 frames from the HDLC frames.

Then, ISDN calls are identified from the analyzed Q.931 packets.

== Capturing each direction of each D-Channel ==
The ISDN analyzer will allocate a pair of TDM media-only call legs for each Line service of the ISDN stack that has a D-Channel (primary D-Channel, and backup D-Channel if appropriate).

* The primary Line service of the ISDN stack holds the primary D-channel (timeslot 16 for E1, timeslot 24 for T1/J1).
* For NFAS ISDN stacks, multiple Line services are used. An optional backup D-channel may be present among these line services.

== Typical ISDN analyzer call flow ==
A typical ISDN analyzer call goes as follows:
* ISDN Q.931 "SETUP" message is detected
** ISDN IEs are analyzed to extract relevant information
*** Call id
*** Channel identification
*** Calling/called numbers
*** And others...
** A new "analyzed" call context is created, bound with the call id
* ISDN Q.931 "PROCEEDING" is detected
** The call changes to "accepted" state
* ISDN Q.931 "ALERTING" is detected
** The call changes to "alerting" state
* ISDN Q.931 "CONNECT" is detected
** The call changes to "answered" state
* ISDN Q.931 "DISCONNECT" is detected
** The call changes to "terminating" state
* ISDN Q.931 "RELEASE" is detected
** The call changes to "terminated" state
* ISDN Q.931 "RELEASE_COMPLETE" is detected
** The call context is destroyed

=== Forwarding analyzed call states to application ===
Each analyzer has been provided a pointer to a "parent" application (a "user") to inform of call state changes.

This "user" is a class that implement the interface ITBCAFAnalyzerUser.

This interface will provide the "user" with the following callbacks from the analyzer, to report new calls and state changes:
* OnAnalyzerCallLegPresent: A new ISDN call was detected
* OnAnalyzerCallLegAccepted: A ISDN call is now "accepted"
* OnAnalyzerCallLegAlerting: A ISDN call is now "alerting" (ringing)
* OnAnalyzerCallLegAnswered: A ISDN call is now "answered"
* OnAnalyzerCallLegTerminating: A ISDN call is now "terminating"
* OnAnalyzerCallLegTerminated: A ISDN call is now terminated
* OnAnalyzerCallLegSuppInfo: Other ISDN message (non call-state affecting) was received

It's up to the user application to decide what should be done with analyzed calls and state changes.

== Line Service Pairs ==
ISDN analyzer is configured using "Line Service Pairs". In fact, in a monitoring environment, a monitored trunk is "tapped", and each direction of the trunk is "forked" and connected to the monitoring equipment (this is done by using a "Monitoring Patch Panel", provided by TelcoBridges).

Thus, each monitored trunk will be received twice on the monitoring equipment (one for each direction).

A "Line Service Pair" is indicating which Line services, on the monitoring equipment, correspond to the two directions of the same monitored trunk.

The ISDN analyzer is then configured using these "Line Service Pairs", and so it knows which line service to monitor for each direction of each monitored trunk.

== Configuring ISDN analyzers in Toolpack Web Portal ==
Developers can use ISDN analzyers in their application by using the class CTBCAFAnalyzerIsdn (which uses parameters defined by CTBCAFAnalyzerIsdnParams).

Non-developers that use Toolpack system with built-in Gateway application can also use ISDN analyzers to generate CDR logs or generate corresponding "monitoring" SIP calls to an external monitoring equipment.

In the Web Portal, using ISDN analyzers is done by:
* Enabling "Monitoring" in the "Web Profile"
** Click Configurations on the left menu
** Select the current configuration for editing
** Expand "Web Profile"
** Enable "Gateway Application" if not already done
** Enable "Monitoring"
* Create TDM Line Interfaces and Line Services (by using the "TDM Line Interfaces" section from the left menu)
** Make sure the line services "Length" is set to "Monitoring"
* Assign the TDM Line Services to a TDM Media NAP (by using the "NAPs" section from the left menu)
* Creating "Line Service Pairs"
** Click "Line Service Pairs" Section in the left menu
** Use "Create Line Service Pair" link to create one or multiple "line service pairs"
* Create a "ISDN Analyzer"
** Click "Create new ISDN Analyzer" link
** Fill-out the required information in the page

For more information and step-by-step screen shots of the configuration of ISDN analyzers, please refer to the [[Web Portal Tutorial Guide v2.9]].

Toolpack monitoring

2016-04-22T12:39:44Z

Manon Bélanger: Minor syntax corrections

The [[Tmonitor]] and [[Tmedia]] products both support [[Network_monitoring]].

Monitoring features can be controlled with the [[Toolpack API]].

Using these APIs, the Toolpack Gateway application supports built-in protocol analyzers that allow to monitor a TDM network, generate CDR logs and notify external applications of monitored TDM calls.

=== The Toolpack Monitoring API ===
[[Image:Monitoring_API_overview.png|thumb|300px]]
The Toolpack monitoring API consists of function calls on the call leg class:
* StartMonitoring
* StopMonitoring
Corresponding events notify the call flow of monitoring state
* OnMonitoringStarted
* OnMonitoringDataReceived

An application that need to do monitoring will first allocate media legs on the appropriate Line Service and Timeslot, then use the StartMonitoring function call to configure the monitoring parameters.
Among parameters, will be chosen:
* Mode (HDLC, SS7, CAS, RAW)
* Rate (64Kbps, 56Kbps, 48Kbps, 32Kbps, 16Kbps or 8Kbps)
* Timeslot sub-index (for rates of 32Kbps or less)

Once monitoring is started, the application (call flow) will be notified of captured data through OnMonitoringDataReceived.

For more information on this API, please refer to the following article, which covers the monitoring APIs:
[[CAF:_Working_With_Cmc_Call_Legs|Working with CMC Call Legs]]

For more general information about using call legs in your application, please refer to this article:
[[CAF:_Working_With_Call_Legs|Working with Call Legs]]

=== Built-in monitoring analyzers ===
[[Image:Monitoring_analyzer_overview.png|thumb|300px]]
The Toolpack framework include "analyzer" classes, that use the monitoring API to capture signaling messages on TDM links.

The [[Toolpack_monitoring_isdn_analyzer|ISDN Analyzer]] will capture HDLC messages on the IDSN D-Channel, and analyze them to rebuild the call state of monitored ISDN calls.

The user application can then be notified of a detected ISDN calls, and of any state change of this call (accepted, alerting, answered, terminating, terminated...).

For more information about the analyzer API, refer to appropriate header files in Toolpack source code.

=== Integration of monitoring analyzers in Toolpack Gateway ===
The analyzers are integrated into Toolpack's own Gateway application.
The Gateway application can be configured to monitor ISDN calls on the specified Line Services.

Upon detection of ISDN calls, the Gateway application can generate CDR logs, and also forward the information to "generators" that will generate message toward an external application that needs to be notified of monitored ISDN calls.

For information about the configuration of ISDN analyzers in Toolpack, please refer to the following article:
[[Toolpack_monitoring_isdn_analyzer|Toolpack ISDN Analyzer]]

=== Toolpack monitoring generators ===
[[Image:Monitoring_generator_overview.png|thumb|300px]]
The Gateway application can attach "generators" to analyzers. A "generator" is receiving the analyzer's detected calls state changes, and generates corresponding events toward an external application.

==== Toolpack SIP simulator ====
One of the "generators" provided with Toolpack is the "SIP Simulator".

This monitoring generator is
* simulating SIP messages that correspond to the ISDN state changes
* Forwarding captured TDM audio through RTP streams

Using this SIP simulator with a monitoring analyzer allows any SIP monitoring software to be able to monitor a TDM link (ISDN for example).

For information about the configuration of "SIP Simulators" in Toolpack, please refer to the following article:
[[Toolpack_monitoring_sip_simulator|Toolpack SIP Simulator]]

Northbound interface:RESTful

2016-01-13T14:29:14Z

Manon Bélanger: /* TelcoBridges RESTful Northbound Interface */

= TelcoBridges RESTful Northbound Interface =
Introduced in version 2.9, the [http://en.wikipedia.org/wiki/Representational_state_transfer RESTful API] allows the provisioning of a [[Tmedia]] VoIP gateway or a [[Tdev]] development platforman. The configuration of the device is seen as collections of resources than can be queried/modified through this interface.

HTTP requests are sent to the [[Toolpack_Application:web_server|web server]] using standard HTTP methods(e.g., GET, PUT, POST, or DELETE). Data exchanged in requests and responses is in [http://en.wikipedia.org/wiki/JSON JSON] format.

== Supported RFCs ==

TelcoBridges supports the following RFCs for RESTful API:

{| border="1"
|-
! Specification
! Supported
|-
| RFC 7159 The JavaScript Object Notation (JSON) Data Interchange Format
| align="center" | Yes
|-
| Extensible Markup Language (XML) 1.0 (Fifth Edition)
| align="center" | No
|-
| RFC 2617 HTTP Authentication: Basic and Digest Access Authentication
| align="center" | Basic Scheme Only
|-
| RFC 2109 HTTP State Management Mechanism
| align="center" | Yes
|}

== REST API overview ==
{| cellpadding="5" border="1" class="wikitable"
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | Resource
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | GET
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | PUT
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | POST
! width="200" style="background: rgb(239, 239, 239) none repeat scroll 0% 0%; -moz-background-clip: border; -moz-background-origin: padding; -moz-background-inline-policy: continuous;" | DELETE

|-
| valign="top" |
Collection URI <code><nowiki>http://host:port/@[collection_name]/</nowiki></code>
| '''List''' the resources that are part of the collection.
| Not used.
| '''Create''' a new element in the collection.
| Not used.
|-
| valign="top" |
Element URI <code><nowiki>http://host:port/@[collection_name]/@[resource_name]</nowiki></code>
| '''Retrieve''' a JSON representation of the specified member of the collection.
| '''Modify''' the specified member of the collection according to the JSON data in the HTTP request.
| Not used.
| '''Delete''' the specified member of the collection
|-
| valign="top" |
New Element URI <code><nowiki>http://host:port/@[collection_name]/new</nowiki></code>
| '''Retrieve''' a JSON representation of a new element of the collection with default values. This new element is not saved until a POST request is sent to create the element in the collection.
| N/A
| N/A
| N/A
|-
| valign="top" |
Status Element URI <code><nowiki>http://host:port/@[collection_name]/@[resource_name]/status</nowiki></code>
| '''Retrieve''' a JSON representation of the status of an element. This is only valid for elements in the active configuration, and it is not available for all element types.
| N/A
| N/A
| N/A
|}
=== Supported Methods ===

==== GET ====
List elements of a collection
GET /users
<- Content : {"root":{}}
<- Code : HTTP/1.0 200 OK
Read a specific element
GET /users/root
<- Content : {"name":"root","user_group":"Admin","pass":"Not Shown"}
<- Code : HTTP/1.0 200 OK
==== PUT ====
Update a configuration element
PUT /users/root
-> Content : {"pass":"MyNewSecret"}
<- Code : HTTP/1.0 200 OK
Omitted attributes in a PUT are left unchanged on the server.
==== POST ====
Create a configuration element into a collection
POST /users
-> Content : { "name" : "RogerFluffy", "user_group" : "nobody" , "pass" : "xyz" }
<- Code : HTTP/1.0 200 OK
Omitted attributes in a POST are being set to the 'default' value.
==== DELETE ====
Delete a configuration element from a collection
DELETE /users/RogerFluffy
<- Code : HTTP/1.0 200 OK
=== Elements ===
Elements are found under collection URIs. A collection is generally composed of multiple elements, with a different name for each element.
The element name must be provided during the '''POST''':
POST /users
-> Content : { "name" : "RogerFluffy", ... }
<- Code : HTTP/1.0 200 OK

Elements generally have attributes, and can also include collections. For example, for the configuration element ''MyCFG'', we can find the ''routes'' collection using the following URI:
/configurations/MyCFG/routes

=== Collections ===
URI with the plural form generally represent a collection of elements.
A collection can be composed of mutiple elements, or limited to 1.

For example, configuration are found under the following collection URI
/users
Likewise, the list of routes can be found on
/configurations/MyCFG/routes

When the collection is limited to 1 element, the element name is fixed.
For example, only one H.248 stack can be defined, therefore the name is fixed to ''gateway_h248''
The element name must be NOT be provided during the '''POST''':
POST /configurations/MyCFG/h248_stacks
-> Content : { "enabled" : true, "naps" : [ "NAP_TDM", "RTP_NAP"], ... }
<- Code : HTTP/1.0 200 OK

=== Recursivity ===
==== Non-recursive GET requests (default) ====
By default, requests are non-recursive. This means that when a GET request is made on a URI, only objects on that element will be returned.
GET /configurations/NewCFG
<- Content : {"name":"NewCFG", "notes":"This is a new demo configuration", "routes":{}, ... }
In the response, we see two attribute value pairs : '''name''' and '''notes''', along with another object named '''routes'''.
The later is a collection, and should be queried individually to get its sub-elements.
GET /configurations/NewCFG/routes
<- Content : {"Route1":{}, ...}
GET /configurations/NewCFG/routes/Routes1
<- Content : {"name":"Route1", "called":"5551212","calling":"", ...}
==== Recursive GET requests ====
It is possible to get all sub-elements from a GET by using the '''recursive=yes''' attribute on the URI.
GET /configurations/NewCFG?recursive=yes
<- Content : {
"name":"NewCFG",
"notes":"This is a new demo configuration",
"routes": {
"Route1": {
"name":"Route1",
"called":"5551212",
"calling":"", ...
},
"Route2": {
"name":"Route2",
"called":"5551314",
"calling":"", ...
}, ...
}
}
This is also true to get the content of all elements of a collection
GET /users?recursive=yes
<- Content : {
"RogerFluffy":{
"name":"RogerFluffy",
"user_group":"nobody",
"pass":"Not Shown"
},
"root":{
"name":"root",
"user_group":"Admin",
"pass":"Not Shown"
}
}
Note : recursive GET does not apply to status elements.
==== Recursive PUT/POST requests ====
The recursivity of a PUT/POST depends on the content. It is possible to specify the content of all sub-elements under a URI.
For example, to change the complete routing table, we could do something like:
PUT /configurations/NewCFG/routes
-> Content : {
"Route1": {
"name":"Route1",
"called":"5551212",
"calling":"", ...
},
"Route2": {
"name":"Route2",
"called":"5551314",
"calling":"", ...
}, ...
}
}
Or even change a complete configuration in a single PUT
PUT /configurations/NewCFG
-> Content : {
"name":"NewCFG",
"notes":"This is a new demo configuration",
"routes": {
"Route1": {
"name":"Route1",
"called":"6661212",
"calling":"", ...
},
"Route2": {
"name":"Route2",
"called":"6661314",
"calling":"", ...
}, ...
}
}

=== Documentation ===
It is possible to get the documentation for the attributes of an element from a GET by using the '''documentation=true''' attribute on the URI, either for the collection, an element or a new element.
GET /configurations?documentation=true
GET /configurations/NewCFG?documentation=true
GET /configurations/new?documentation=true
-> Content : {
"name": {
"description" : "Name of this configuration.",
"type" : "text",
},
"notes": {
"description" : "Free text field available to add any system/configuration information (this field is ignored by the system)",
"type" : "text",
}, ...
}
}
==== Recursive Documentation ====
It is possible to get documentation recursively by using both the '''documentation=true''' and the '''recursive=yes''' attributes on the URI.
GET /configurations?documentation=true&recursive=yes
-> Content : {
"name": {
"description" : "Name of this configuration.",
"type" : "text",
},
"notes": {
"description" : "Free text field available to add any system/configuration information (this field is ignored by the system)",
"type" : "text",
},
"routes": {
"called": {
"description" : "Called number to match this route. Leave empty to match any called number.",
"type" : "text",
},
"calling": {
"description" : "Calling number to match this route. Leave empty to match any calling number.",
"type" : "6661314",
}, ...
}, ...
}
=== Request Status code ===
The following result class are used to as HTTP status code to indicate the result of request.
* 2XX - success
* 3XX - redirection (304 Not Modified)
* 4XX - client error
* 5XX - server error

In Addition to HTTP status code, every HTTP response also inlcudes a JSON payload with a verbose message.
POST /configurations/MyCFG/h248_stacks
-> Content : { ... }
<- Code : HTTP/1.0 200 OK
<- Content : { "message" : "Tbgw h248 cfg creation failed: Public ip address can't be blank, Public ip address is invalid, Local ip address is invalid, Local ip address When not using virtual ip, an ip address must be entered"}

This ''message'' can be used to find the exact reason why a RESTful API call failed.

=== HTTP headers ===
The following HTTP header should be used in requests:
{| border="1"
|-
! HTTP Header
! Description
|-
| Host
| Mandatory
|-
| Authorization
| RFC2617 WWW Authentication, basic mode. Can be used on each requests, or first request only by using Cookie/Set-Cookie headers
|-
| Cookie
| RFC2109 HTTP Session management
|-
| Content-Type
|"application/json; charset=utf-8"
|-
| Content-Length
| Length of content for PUT and POST requests
|-
| User-Agent
| Optional
|-
| If-None-Match
| Optional (HTTP ETag/If-None-Match caching mechanism)
|-
| Cache-Control
| HTTP Cache control, use is optional
|-
| Connection
| "keep-alive"
|}

The following HTTP header are to be expected for a server response:
{| border="1"
|-
!HTTP Header
!Description
|-
| Authorization
| RFC2617 WWW Authentication
|-
| Set-Cookie
| RFC2109 HTTP Session management
|-
| Content-Type
| "application/json; charset=utf-8"
|-
| Content-Length
| Length of content
|-
| E-Tag
| Optional (HTTP ETag/If-None-Match caching mechanism)
|-
| Cache-Control
| Optional
|-
|Date
| Can be ignored
|-
| X-Runtime
| Can be ignored
|-
| X-Frame-Option
| To be ignored
|}

== API Access ==
=== HTTP port ===
The HTTP port for RESTful access is the same as for the Web interface. By default, HTTP port is 12358.
Therefore the RESTful URIs should looks something like: ''' <nowiki>http://TMG_IP_ADDR:12358/@[collection_name]/@[resource_name]</nowiki>'''

=== Credentials ===
The credentials (user/password) used to authenticate a RESTful client application are the same as for the WebPortal.
Users can be managed from the Web interface under /users. The same path is used to manage users by the RESTful interface.

Toolpack Application:tbconfig

2016-01-13T13:32:43Z

Manon Bélanger: /* Additional arguments */

== Role ==
tbconfig is used to provision the system using the RESTful API. It supports three different modes of operations : interactive mode, shell mode and command line mode.

== Interactive mode ==
This mode allows to explore and modify the configurations using arrow keys and simple commands. Multiple modifications can be made before they are applied to the unit. While inside the interactive mode, type the question mark (?) key to get a more detailed help.
*'''To launch the tool in interactive mode :'''
tbconfig

== Shell mode ==
This mode allows to explore and modify the configurations using cd (change directory), ls (list files) and other simple commands. Multiple modifications can be made before they are applied to the unit. While inside the shell mode, type "help" key to get a more detailed help.
*'''To launch the tool in shell mode :'''
tbconfig --shell

== Command line mode ==
This mode allows to export or import configurations to/from files. It also allows to instantly modify values.
*'''To use the tool in command line mode :'''
tbconfig [args]
*'''To get detailed commands examples :'''
tbconfig --help

== Additional arguments ==
By default, tbconfig sends HTTP requests to the [[Toolpack_Application:web_server|web server]] using 127.0.0.1:12358 with root/root as the username and password.
 This can be changed using the following arguments:
-h : [host] Host to connect to (IP address or domain name)
--port : [port] Port to use for connecting to HTTP server
-u : [user] User name to use for connecting to HTTP server
-p : [pass] Password to use for connecting to HTTP server

For example, if the TMG’s web server has been reconfigured to use port 80 and you want to log with user my_username and password my_secret_password, tbconfig should be invoked using the following parameters:
tbconfig --port 80 -u my_username -p my_secret_password

Unix environment variables can be set to avoid adding those parameters every time.
TBCONFIG_HOST : Replaces -h
TBCONFIG_PORT : Replaces --port
TBCONFIG_USER : Replaces -u
TBCONFIG_PASS : Replaces –p

== Use cases ==
* [[RESTful_API:_Exporting_a_configuration|Exporting a configuration]]
* [[RESTful_API:_Importing_a_configuration|Importing a configuration]]
* [[RESTful_API:_Activating_a_configuration|Activating a configuration]]

Northbound interface

2016-01-13T13:31:26Z

Manon Bélanger: /* Integration with EMS */

The Northbound interface allows a higher-level component to configure. This is particularly useful for deployment of large number of units in the field.

== TelcoBridges and Northbound interface ==
Starting with v2.9, EMS or the tbconfig tool can now configure the ''T''media through its Northbound interface.

== Configuration ==

The Northbound interface offers multiple ways to configure your system:

=== tbconfig ===
The [[Toolpack_Application:tbconfig|tbconfig]] tools allows user to directly modify your system's configuration through multiple modes:

* cli
* shell
* command line

More information about tbconfig [[Toolpack_Application:tbconfig|here]]

=== Integration with EMS ===
Introduced in version 2.9, the [http://en.wikipedia.org/wiki/Representational_state_transfer RESTful API] allows the provisioning of a [[Tmedia]] VoIP gateway or a [[Tdev]] development platform. The configuration of the device is seen as collections of resources than can be queried/modified through this interface.

HTTP requests are sent to the [[Toolpack_Application:web_server|web server]] using standard HTTP methods(e.g., GET, PUT, POST, or DELETE). Data exchanged in requests and responses is in [http://en.wikipedia.org/wiki/JSON JSON] format.

More information [[Northbound_interface:RESTful|here]]

== Dictionary ==
[[Web_Portal_Tutorial_Guide_v2.9|Dictionary v2.9]]

[[Category:Glossary]]
[[Category:Revise on Major]]

Northbound interface

2016-01-13T13:31:01Z

Manon Bélanger: /* tbconfig */

The Northbound interface allows a higher-level component to configure. This is particularly useful for deployment of large number of units in the field.

== TelcoBridges and Northbound interface ==
Starting with v2.9, EMS or the tbconfig tool can now configure the ''T''media through its Northbound interface.

== Configuration ==

The Northbound interface offers multiple ways to configure your system:

=== tbconfig ===
The [[Toolpack_Application:tbconfig|tbconfig]] tools allows user to directly modify your system's configuration through multiple modes:

* cli
* shell
* command line

More information about tbconfig [[Toolpack_Application:tbconfig|here]]

=== Integration with EMS ===
Introduced in version 2.9, the [http://en.wikipedia.org/wiki/Representational_state_transfer RESTful API] allows the provisioning of a [[Tmedia]] VoIP gateway or a [[Tdev]] development platforman. The configuration of the device is seen as collections of resources than can be queried/modified through this interface.

HTTP requests are sent to the [[Toolpack_Application:web_server|web server]] using standard HTTP methods(e.g., GET, PUT, POST, or DELETE). Data exchanged in requests and responses is in [http://en.wikipedia.org/wiki/JSON JSON] format.

More information [[Northbound_interface:RESTful|here]]

== Dictionary ==
[[Web_Portal_Tutorial_Guide_v2.9|Dictionary v2.9]]

[[Category:Glossary]]
[[Category:Revise on Major]]

Northbound interface

2016-01-13T13:30:43Z

Manon Bélanger: /* TelcoBridges and Northbound interface */

The Northbound interface allows a higher-level component to configure. This is particularly useful for deployment of large number of units in the field.

== TelcoBridges and Northbound interface ==
Starting with v2.9, EMS or the tbconfig tool can now configure the ''T''media through its Northbound interface.

== Configuration ==

The Northbound interface offers multiple ways to configure your system:

=== tbconfig ===
The [[Toolpack_Application:tbconfig|tbconfig]] tools allows user to directly modify your system's configuration trough multiple modes:

* cli
* shell
* command line

More information about tbconfig [[Toolpack_Application:tbconfig|here]]

=== Integration with EMS ===
Introduced in version 2.9, the [http://en.wikipedia.org/wiki/Representational_state_transfer RESTful API] allows the provisioning of a [[Tmedia]] VoIP gateway or a [[Tdev]] development platforman. The configuration of the device is seen as collections of resources than can be queried/modified through this interface.

HTTP requests are sent to the [[Toolpack_Application:web_server|web server]] using standard HTTP methods(e.g., GET, PUT, POST, or DELETE). Data exchanged in requests and responses is in [http://en.wikipedia.org/wiki/JSON JSON] format.

More information [[Northbound_interface:RESTful|here]]

== Dictionary ==
[[Web_Portal_Tutorial_Guide_v2.9|Dictionary v2.9]]

[[Category:Glossary]]
[[Category:Revise on Major]]

Toolpack Application:tbconfig

2015-10-13T19:35:16Z

Manon Bélanger: Adding arguments and links to use cases

== Role ==
tbconfig is used to provision the system using the RESTful API. It supports three different modes of operations : interactive mode, shell mode and command line mode.

== Interactive mode ==
This mode allows to explore and modify the configurations using arrow keys and simple commands. Multiple modifications can be made before they are applied to the unit. While inside the interactive mode, type the question mark (?) key to get a more detailed help.
*'''To launch the tool in interactive mode :'''
tbconfig

== Shell mode ==
This mode allows to explore and modify the configurations using cd (change directory), ls (list files) and other simple commands. Multiple modifications can be made before they are applied to the unit. While inside the shell mode, type "help" key to get a more detailed help.
*'''To launch the tool in shell mode :'''
tbconfig --shell

== Command line mode ==
This mode allows to export or import configurations to/from files. It also allows to instantly modify values.
*'''To use the tool in command line mode :'''
tbconfig [args]
*'''To get detailed commands examples :'''
tbconfig --help

== Additional arguments ==
By default, tbconfig sends HTTP requests to the [[Toolpack_Application:web_server|web server]] using 127.0.0.1:12358 with root/root as the username and password.
 This can be changed using the following arguments:
-h : [host] Host to connect to (IP address or domain name)
-port : [port] Port to use for connecting to HTTP server
-u : [user] User name to use for connecting to HTTP server
-p : [pass] Password to use for connecting to HTTP server

For example, if the TMG’s web server has been reconfigured to use port 80 and you want to log with user my_username and password my_secret_password, tbconfig should be invoked using the following parameters:
tbconfig -port 80 -u my_username -p my_secret_password

Unix environment variables can be set to avoid adding those parameters every time.
TBCONFIG_HOST : Replaces -h
TBCONFIG_PORT : Replaces -port
TBCONFIG_USER : Replaces -u
TBCONFIG_PASS : Replaces –p

== Use cases ==
* [[RESTful_API:_Exporting_a_configuration|Exporting a configuration]]
* [[RESTful_API:_Importing_a_configuration|Importing a configuration]]
* [[RESTful_API:_Activating_a_configuration|Activating a configuration]]

Toolpack Application:tbconfig

2015-10-13T14:57:23Z

Manon Bélanger: First version of the page

Routing script tutorial:Mini Development Guide

2014-11-11T20:44:08Z

Manon Bélanger: /* Script parameters protocol mapping */

== Call object ==

=== Get ===

Those function are used to get the call parameters. The possible parameters are described in the section "Call parameters"

called_number = caf_call.get :called

=== List_params ===

This function is used to retrieve the list of supported call parameters. For example to extract all the possible call params from the the call object and put it in hash.

caf_call.list_params.each {|param| call[param] = caf_call.get param }

=== Accept ===

This function is used to accept a call. It actually creates one outgoing route that gateway application will use to bridge the incoming call leg. If more than one outgoing route is "accepted", gateway will try them one by one in the same order they were accepted. If an outgoing call leg fails (according to 'route retry' parameters), the next route in line will be used.

This method takes 2 arguments, the call parameters (hash) and the route parameters (hash). Note that calling this method does NOT stop the flow of the script.

Apply route remapping rules

caf_call.accept out_call, route

=== Refuse ===

This function is used to set the reason code for the incoming call leg refusal. However, this function does NOT stop the flow of the script.

caf_call.refuse :reason => :temporary_failure

To immediately refuse the incoming call leg and stop processing the script, the script must raise an exception. Exiting the script by raising the exception overwrites any reason cause previously stored using refuse().

raise RoutingException, :no_route

The supported refusal cause values for both refuse() and raise() are described in the section "[[Routing_script_tutorial:Mini_Development_Guide#Reason_values|Reason values]]".

=== Script parameters protocol mapping ===

The following call parameters are available in the call object:

{| cellspacing="1" cellpadding="1" border="1" style="width: 921px; height: 805px;"
|-
! scope="col" | '''Script parameter name'''
! scope="col" | '''ISDN '''
! scope="col" | '''R2 CAS''' 
! scope="col" | '''SS7 '''
! scope="col" | '''SIP '''
! scope="col" | '''Comment '''
! scope="col" | '''Toolpack version '''
|-
| leg_id 
| N/A 
| N/A 
| N/A 
| N/A 
| Leg ID 
| 
|-
| session_id 
| N/A 
| N/A 
| N/A 
| N/A 
| Session ID 
| 
|-
| calling 
| Q931: 'Calling party number' IE - Number digits 
| ANI (Group B) 
| Q763: 'Calling party number' IE - address signals (*) 
| SIP:From - user-info 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead. 
| 
|-
| calling_noa 
| Q931: 'Calling party number' IE - Type of number 
| N/A 
| Q763: 'Calling party number' IE - nature of address indicator (*) 
| N/A 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead 
| 
|-
| calling_npi 
| Q931: 'Calling party number' IE - Numbering plan identification 
| N/A 
| Q763: 'Calling party number' IE - numbering plan indicator (*) 
| N/A 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead 
| 
|-
| calling_display 
| Q931: 'Display' IE - Display information 
Q931: 'Facility CNAM' IE when presentation is allowed for DMS/NI2 variants 
| N/A 
| Q763: 'Display information' IE - display information 
| SIP:From - display-name 
| 
| 
|-
| calling_display_type 
| Q931: 'Display' IE - Display information (present and/or first byte) 
| N/A 
| Q763: 'Display information' IE - present or not 
| N/A 
| 
| 
|-
| calling_presentation 
| Q931: 'Calling party number' IE - Presentation indicator 
| N/A 
| Q763: 'Calling party number' IE - address presentation restricted indicator 
|
SIP:From - display-name (displays 'anonymous' or not)

SIP:Remote-party-id - privacy 

| 
| 
|-
| calling_screening 
| Q931: 'Calling party number' IE - Screening indicator 
| N/A 
| Q763: 'Calling party number' IE - screening 
| SIP:Remote-party-id - screen 
| 
| 
|-
| calling_category 
| N/A 
| Call party category (Group A) 
| Q763: 'Calling party's category' IE - calling party's category 
|
SIP:From - cpc

SIP:P-asserted-identity - cpc 

| 
| 
|-
| calling_subscriber
(Generic Number / NDS) 
| Q931: 2nd 'Calling party number' IE - Number digits 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - Number digits 
|
SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| Requires option 'support 2 calling number IE' in the profile. This variable has priority over 'private_address' in the outgoing direction. 
| 
|-
| calling_subscriber_noa 
| Q931: 2nd 'Calling party number' IE - Type of number 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - nature of address indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| calling_subscriber_npi 
| Q931: 2nd 'Calling party number' IE - Numbering plan identification 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - numbering plan indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
 
| 
|-
| calling_subscriber_presentation 
| Q931: 2nd 'Calling party number' IE - Presentation indicator 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - presentation restricted indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| calling_subscriber_screening 
| Q931: 2nd 'Calling party number' IE - Screening indicator 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - screening 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| private_display 
| Q931: 'Facility CNAM' IE when presentation is restricted for DMS/NI2 variants 
| N/A 
| N/A 
|
SIP:P-asserted-identity - display-name 

SIP:Remote-party-id - display-name 

| 
| 
|-
| private_display_type 
| N/A 
| N/A 
| N/A 
| N/A 
| Indicate presence or not of the private calling information 
| 
|-
| private_address 
| N/A 
| N/A 
| N/A 
|
SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 

| 
| 
|-
| called 
| Q931: 'Called party number' IE - Number digits 
| DNIS (Group A) 
| Q763: 'Called party number' IE - address signals 
| SIP:To - user-info and host 
| 
| 
|-
| called_noa 
| Q931: 'Called party number' IE - Type of number 
| N/A 
| Q763: 'Called party number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| called_npi 
| Q931: 'Called party number' IE - Numbering plan identification 
| N/A 
| Q763: 'Called party number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| charge_number 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - address signals 
| N/A 
| 
| 
|-
| charge_number_noa 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| charge_number_npi 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| redirecting_number_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default redirecting number and original called number forwarding behavior from incoming to outgoing leg 
| 
|-
| redirecting_number 
| Q931: 'Redirecting number' 1st IE - Number digits 
| N/A 
| Q763: 'Redirecting number' IE - address signals 
| SIP:Diversion (2nd header) - display-name 
| 
| 
|-
| redirecting_number_noa 
| Q931: 'Redirecting number' 1st IE - Type of number 
| N/A 
| Q763: 'Redirecting number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| redirecting_number_npi 
| Q931: 'Redirecting number' 1st IE - Numbering plan identification 
| N/A 
| Q763: 'Redirecting number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| redirecting_number_presentation 
| Q931: 'Redirecting number' 1st IE - Presentation indicator 
| N/A 
| Q763: 'Redirecting number' IE - address presentation restricted indicator 
| SIP:Diversion (2nd header) - diversion-privacy 
| 
| 
|-
| redirecting_number_indicator 
| N/A 
| N/A 
| Q763: 'Redirection information' IE - redirecting indicator 
| N/A 
| 
| 
|-
| redirecting_number_reason 
| Q931: 'Redirecting number' 1st IE - Reason for redirection 
| N/A 
| Q763: 'Redirection information' IE - redirecting reason 
| SIP:Diversion (2nd header) - diversion-reason 
| 
| 
|-
| redirecting_number_counter 
| N/A 
| N/A 
| Q763: 'Redirection information' IE - redirection counter 
| SIP:Diversion (2nd header) - diversion-counter 
| 
| 
|-
| original_called_number
(OCN) 
| Q931: 'Redirecting number' 2nd IE - Number digits 
| N/A 
| Q763: 'Redirection number' IE - address signals 
| SIP:Diversion  (1st header) - display-name 
| 
| 
|-
| original_called_number_noa 
| Q931: 'Redirecting number' 2nd IE - Type of number 
| N/A 
| Q763: 'Redirection number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| original_called_number_npi 
| Q931: 'Redirecting number' 2nd IE - Numbering plan identification 
| N/A 
| Q763: 'Redirection number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| original_called_number_presentation 
| Q931: 'Redirecting number' 2nd IE - Presentation indicator 
| N/A 
| Q763: 'Redirection number' IE - address presentation restricted indicator 
| SIP:Diversion (1st header) - diversion-privacy 
| 
| 
|-
| original_called_number_reason 
| Q931: 'Redirecting number' 2nd IE - Reason for redirection 
| N/A 
| Q763: 'Redirection information' IE - original redirection reason 
| SIP:Diversion (1st header) - diversion-reason 
| 
| 
|-
| original_called_number_counter 
| N/A 
| N/A 
| N/A 
| SIP:Diversion (1st header) - diversion-counter 
| 
| 
|-
| ported_number 
| N/A 
| N/A 
| Q763: 'Called party number' IE - address signals 
| SIP:RequestURI - rn 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| ported_number_noa 
| N/A 
| N/A 
| Q763: 'Called party number' IE - nature of address indicator 
| N/A 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| ported_number_npi 
| N/A 
| N/A 
| Q763: 'Called party number' IE - numbering plan indicator 
| N/A 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| oli
(Originating line information) 
| 5ESS Codeset 6 OLI - Value 
| N/A 
| ANSI: 'Originating line information' IE - OLI 
|
SIP:From - oli

SIP:P-asserted-identity - oli 

| 
| 
|-
| request_uri 
| N/A 
| N/A 
| N/A 
| Complete Request URI string 
| 
| 
|-
| request_uri_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default URI forwarding behavior from incoming to outgoing leg 
| 
|-
| sip_header 
| N/A 
| N/A 
| N/A 
| Any header 
| Requires option 'Forward custom headers' in Profiles->SIP 
| 2.7.63 
|-
| nap
(Network Access Point) 
| N/A 
| N/A 
| N/A 
| N/A 
| Incoming leg NAP name (read-only) 
| 
|-
| type_of_network_identification 
| Q931: 'Transit network selection' IE - Type of network identification 
| N/A 
| Q763: 'Transit network selection' IE - Type of network identification 
| N/A 
| 
| 2.7 
|-
| network_identification 
| Q931: 'Transit network selection' IE - Network identification 
| N/A 
| Q763: 'Transit network selection' IE - Network identification 
| SIP: Request-Line - cic 
| 
| 2.7 
|-
| network_identification_plan 
| Q931: 'Transit network selection' IE - Network identification plan 
| N/A 
| Q763: 'Transit network selection' IE - Network identification plan 
| N/A 
| 
| 2.7 
|-
| location_number_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default location number forwarding behavior from incoming to outgoing leg 
| 2.7 
|-
| location_number 
| N/A 
| N/A 
| Q763: 'Location number' IE - address signals 
| N/A 
| 
| 2.7 
|-
| location_number_noa 
| N/A 
| N/A 
| Q763: 'Location number' IE - nature of address indicator 
| N/A 
| 
| 2.7 
|-
| location_number_npi 
| N/A 
| N/A 
| Q763: 'Location number' IE - numbering plan indicator 
| N/A 
| 
| 2.7 
|-
| location_number_presentation 
| N/A 
| N/A 
| Q763: 'Location number' IE - presentation restricted indicator 
| N/A 
| 
| 2.7 
|-
| location_number_screening 
| N/A 
| N/A 
| Q763: 'Location number' IE - screening 
| N/A 
| 
| 2.7 
|-
| mlpp_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| A script needs to set this to true if it wants to overwrite MLPP information in the outgoing leg. Otherwise, profile relay 'outgoing mode' applies automatically. 
| 2.7 
|-
| mlpp_look_for_busy 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - look ahead for busy 
| N/A 
| 
| 2.7 
|-
| mlpp_precedence_level 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - precedence level 
| SIP:Resource-Priority - q735 
| 
| 2.7 
|-
| mlpp_network_identity 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - network identity 
| N/A 
| 
| 2.7 
|-
| mlpp_service_domain 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - MLPP service domain 
| N/A 
| 
| 2.7 
|-
| called_isub 
| Q931: 'Called party subaddress' IE - subaddress information 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Called party subaddress' IE - subaddress information 
| SIP:To - isub parameter 
| 
| 2.7 
|-
| called_isub_type 
| Q931: 'Called party subaddress' IE - type of subaddress 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Called party subaddress' IE - type of subaddress 
| SIP:To - isub-encoding parameter 
| 
| 2.7 
|-
| calling_isub 
| Q931: 'Calling party subaddress' IE - subaddress information 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Calling party subaddress' IE - subaddress information 
| SIP:From - isub 
| 
| 2.7 
|-
| calling_isub_type 
| Q931: 'Callinf party subaddress' IE - type of subaddress 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Calling party subaddress' IE - type of subaddress 
| SIP:From - isub-encoding 
| 
| 2.7 
|-
| ss7_fci_default 
| N/A 
| N/A 
| Default forward call indicator (FCI) value. 
| N/A 
| Toolpack will overwrite FCI bits A, D, F, I and M with appropriate values according to call conditions 
| 2.7 
|-
| ss7_fci_force_mask 
| N/A 
| N/A 
| Mask to select bits from ss7_fci_default that must be forced. 
| N/A 
| Bits from ss7_fci_default which corresponding bit in ss7_fci_force_mask is set will be forced, and no more controlled by Toolpack 
| 2.7 
|-
| ss7_bci_default 
| N/A 
| N/A 
| Default backward call indicator (BCI) value. 
| N/A 
| Toolpack will overwrite BCI bits AB, I, K, M and N with appropriate values according to call conditions 
| 2.7 
|-
| ss7_bci_force_mask 
| N/A 
| N/A 
| Mask to select bits from ss7_bci_default that must be forced. 
| N/A 
| Bits from ss7_bci_default which corresponding bit in ss7_bci_force_mask is set will be forced, and no more controlled by Toolpack 
| 2.7 
|-
| tdm_ls_name
(Line Service or T1/E1 trunk) 
| Incoming leg line service name 
| Incoming leg line service name 
| Incoming leg line service name 
| N/A 
| (read-only) 
| 2.7 
|-
| tdm_timeslot_nb 
| Incoming leg timeslot number 
| Incoming leg timeslot number 
| Incoming leg timeslot number 
| N/A 
| (read-only) 
| 2.7 
|-
| rtp_local_addr 
| N/A 
| N/A 
| N/A 
| Incoming leg local SDP IP address 
| (read-only) 
| 2.7 
|-
| rtp_local_port 
| N/A 
| N/A 
| N/A 
| Incoming leg local SDP IP port 
| (read-only) 
| 2.7 
|-
| rtp_remote_addr 
| N/A 
| N/A 
| N/A 
| Incoming leg remote SDP IP address 
| (read-only) 
| 2.7 
|-
| rtp_remote_port 
| N/A 
| N/A 
| N/A 
| Incoming leg remote SDP IP port 
| (read-only) 
| 2.7 
|-
| ss7_cot_enabled 
| N/A 
| N/A 
| Requests SS7 in-call continuity test for this outgoing SS7 call 
| N/A 
| Toolpack will request continuity test on the timeslot before making the outgoing call. If COT fails, the call will be dropped (then another route may be attempted) 
| 2.8 
|-
| reverse_charging_indication 
| Incoming leg Reverse charging indication IE present 
| N/A 
| N/A 
| N/A 
| If set in routing script, will add Reverse charging indication IE in outgoing leg (also use reverse_charging_indication_forward_enabled) 
| 2.8.12 
|-
| reverse_charging_indication_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Enable forwarding of reverse charging indication from incoming to outgoing leg 
| 2.8.12 
|-
| sip_local_addr 
| N/A 
| N/A 
| N/A 
| Incoming leg local SIP IP address 
| (read-only) 
| 2.8.13 
|-
| sip_local_port 
| N/A 
| N/A 
| N/A 
| Incoming leg local SIP UDP port 
| (read-only) 
| 2.8.13 
|-
| sip_remote_addr 
| N/A 
| N/A 
| N/A 
| Incoming leg remote SIP IP address 
| (read-only) 
| 2.8.13 
|-
| sip_remote_port 
| N/A 
| N/A 
| N/A 
| Incoming leg remote SIP UDP port 
| (read-only) 
| 2.8.13 
|}

 

'''Notice:''' All values are documented in the '''noa_npi_remap.rb''' script and may change between major release.

=== Noa values ===

*<tt>unknown_number (0x2)</tt>
*<tt>international_number (0x4)</tt>
*<tt>national_number (0x3)</tt>
*<tt>subscriber_number (0x1)</tt>
*<tt>network_specific (0x5)</tt>
*<tt>network_routing_national_format (0x7)</tt>
*<tt>network_routing_international_format (0x8)</tt>
*<tt>abbreviated_number (0x6)</tt>
*<tt>subscriber_number_operator_requested (0x71)</tt>
*<tt>national_number_operator_requested (0x72)</tt>
*<tt>international_number_operator_requested (0x73)</tt>
*<tt>no_number_present_operator_requested (0x74)</tt>
*<tt>no_number_present_cut_through_call_to_carrier (0x75)</tt>
*<tt>test_line_test_code (0x77)</tt>
*<tt>non_unique_subscriber_number (0x71)</tt>
*<tt>non_unique_national_number (0x73)</tt>
*<tt>non_unique_international_number (0x74)</tt>
*<tt>call_950_numbe (0x76)</tt>
*<tt>special_number (0x73)</tt>
*<tt>national_number_with_transit_network_selection (0x74)</tt>
*<tt>international_number_with_transit_network_selection (0x75)</tt>

Those values will be remapped to the protocol specific NOA value. To provide protocol specific value:

*<tt>call_params[:called_noa] = 0x70</tt>

or

*<tt>call_params[:called_noa] = 112</tt>

=== Npi values ===

*<tt>unknown_number</tt>
*<tt>isdn</tt>
*<tt>telephony</tt>
*<tt>private</tt>
*<tt>data</tt>
*<tt>telex</tt>
*<tt>national</tt>

=== Calling Display Type values ===

*<tt>unspecified</tt> => Type is unspecified.
*<tt>calling_party_name</tt> => Type is 0xB1.

Those values will be remapped to the protocol specific Display Information Type value. To provide protocol specific value:

*<tt>call_params[:calling_display_type] = 0xB1</tt>

or

*<tt>call_params[:calling_display_type] = 177</tt>

=== Calling Display value ===

*<tt>call_params[:calling_display] = "Roger Fluffy"</tt>

=== Presentation values for Calling number, Calling Subscriber (Generic Number), Redirecting Number, Original Called Number (OCN) and Location Number ===

*<tt>unspecified</tt>
*<tt>not_available (0x2)</tt>
*<tt>allowed (0x0)</tt>
*<tt>restricted (0x1)</tt>
*<tt>addr_restricted</tt>
*<tt>name_restricted</tt>

=== Calling Party Category ===
values for calling_category
*<tt>unspecified</tt> <tt>(0xa)</tt>
*<tt>unknown</tt> <tt>(0x0)</tt>
*<tt>operator_french</tt> <tt>(0x1)</tt>
*<tt>operator_english</tt> <tt>(0x2)</tt>
*<tt>operator_german</tt> <tt>(0x3)</tt>
*<tt>operator_russian</tt> <tt>(0x4)</tt>
*<tt>operator_spanish</tt> <tt>(0x5)</tt>
*<tt>subscriber</tt> <tt>(0xa)</tt>
*<tt>subscriber_with_priority</tt> <tt>(0xb)</tt>
*<tt>data</tt> <tt>(0xc)</tt>
*<tt>test</tt> <tt>(0xd)</tt>
*<tt>payphone</tt> <tt>(0xf)</tt>

=== Screening values for Calling number, Calling Subscriber (Generic Number), and Location Number ===

*<tt>unspecified</tt>
*<tt>no (0x0)</tt>
*<tt>pass (0x1)</tt>
*<tt>fail (0x2)</tt>
*<tt>network_provided (0x3)</tt>

=== Redirecting indicator values ===

SS7:

*<tt>no_redirection</tt>
*<tt>call_rerouted</tt>
*<tt>call_rerouted_all_restricted</tt>
*<tt>call_diverted</tt>
*<tt>call_diverted_all_restricted</tt>
*<tt>call_rerouted_restricted</tt>
*<tt>call_diverted_restricted</tt>
*<tt>spare</tt>

=== Redirecting number, Original Called Number and Diversion Reason ===

ISDN:

*<tt>unknown</tt>
*<tt>busy</tt>
*<tt>no_reply</tt>
*<tt>deflection</tt>
*<tt>dte_out_of_order</tt>
*<tt>forwarding_by_called_dte</tt>
*<tt>unconditional</tt>

SS7:

*<tt>unknown</tt>
*<tt>busy (SIP: user-busy)</tt>
*<tt>no_reply (SIP: no-answer)</tt>
*<tt>unconditional</tt>
*<tt>deflection</tt>
*<tt>deflection_immediate</tt>
*<tt>mobile_not_reachable</tt>

=== OLI (originating line information) values ===

The OLI parameter is a string that represents an integer value from 0 to 255.

=== Information Transfer Capability values ===

information_transfer_capability:

*<tt>digital</tt>
*<tt>restricted_digital</tt>
*<tt>digital_with_tones</tt>
*<tt>speech</tt>
*<tt>3_1_khz_audio</tt>

=== redirecting_number_forward_enabled values ===

Controls forwarding or discarding of redirecting number (SIP: diversion header) to outgoing call leg.

Values for this parameter are "0", "1", "false" or "true. 0/false: Redirecting number (and original called number) is not forwarded to outgoing call leg 1/true: Redirecting number (and original called number) is forwarded to outgoing call leg The value for this parameter at input of routing script depends on the "Forward redirecting number" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

=== request_uri ===

Enables access to the Request-Line URI. 

For example, if the Request-Line is:
<pre>Request-Line: INVITE sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0</pre>
Then the retrieved request_uri will be "sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0". 

In the routing scripts, to retrieve only the called number, this script can be used: 
<pre> if call_params[:request_uri] && call_params[:request_uri] =~ /sip:(.*)@.*/
call_params[:called] = $1
end
</pre>
=== request_uri_forward_enabled values ===

Controls forwarding or discarding of request uri to outgoing call leg.The request uri is the information in the "Request-Line:" of the SIP INVITE message. 

Values for this parameter are "0", "1", "false" or "true. 

0/false: Request uri is not forwarded to outgoing call leg 

1/true: Request uri is forwarded to outgoing call leg 

The value for this parameter at input of routing script is always false. 

=== sip_header values ===
Contains a hash table of custom sip headers from the inbound call leg. Any custom sip header can be added to an outgoing call leg: 

<pre>call[ :sip_header ] = {"P-my-custom-header"=>"value1", "P-my-custom-header2"=>"value2", "P-my-custom-header3"=>"value3"}</pre>

* PCAP sample: [[File:TB_Custom_SIP_Headers.pcap]]

List of sip headers that will not appear in call[:sip_header] since they are already processed by the SIP stack:
<pre>
Accept Error-Info Remote-Party-ID
Accept-Contact Event Replaces
Accept-Encoding Expires Reply-To
Accept-Language From Request-Disposition
Alert-Info In-Reply-To Subject
Allow Max-Forwards Subscription-State
Allow-Events MIME-version Supported
Also Min-Expires Timestamp
Anonymity Min-SE To
Authorization Organization Unsupported
Authentication-Info Path User-Agent
Call-ID Priority Via
Call-Info Privacy Warning
Contact Proxy-Authenticate WWW-Authenticate
Content-Disposition Proxy-Authorization Require
Content-Encoding Proxy-Require Response-Key
Content-Language P-Media-Authorization Retry-After
Content-Length P-Preferred-Identity RPID-Privacy
Content-Type P-Asserted-Identity Route
CSeq RAck RSeq
RAck Reason Security-Client
Reason Record-Route Security-Server
Date Refer-To Security-Verify
Diversion Referred-By Server
Encryption Reject-Contact Service-Route
Session-Expires
</pre>

=== MLPP Precedence values ===

mlpp_look_for_busy:

*<tt>allowed</tt>
*<tt>path_reserved</tt>
*<tt>not_allowed</tt>

mlpp_precedence_level:

*<tt>flash_override</tt>
*<tt>flash</tt>
*<tt>immediate</tt>
*<tt>priority</tt>
*<tt>routine</tt>

mlpp_network_identity:

3 digits value from 0 to 999

mlpp_service_domain:

24 bits value from 0 to 16777215

=== ISUB subaddress information values ===

called_isub_type:
calling_isub_type:

*<tt>nsap</tt>
*<tt>nsap_ia5</tt>
*<tt>nsap_bcd</tt>
*<tt>user</tt>

called_isub:
calling_isub:

Digits for the subaddress information.

== Route parameters ==

All route may have these parameters:

*calling
*called
*nap
*remapped_calling
*remapped_called
*remapped_nap
*remapped_profile
*remapped_incoming_profile

Additionally it is possible to add dynamic route attributes in the web portal. These can be referenced by their name.

== Playing prompts announcements or tones ==

New feature in release 2.6, all bridges may have these parameters. These can be used to play IVR prompts or wav files in different states of the call flow, like playing an announcement when the caller dials in. You can also manage the User to User information element.

*announcement_tone
*call_progress_tone
*ring_tone
*max_call_duration
*call_duration_reason
*disconnect_tone
*uui
*uui_forward_enabled

The following sections show how to access those different parameters from '''inside''' a filter. The 'params' hash is the sole argument passed to a filter function and contains call, nap, route and bridge parameters. This hash is created by the base_routing.rb scripts to regroup all relevant information just before calling the filter functions.

=== Tone string format ===

All tone strings (:announcement_tone, :call_progress_tone, :ring_tone, :disconnect_tone) inside bridge parameters are using this format.
<pre>"file1.wav:repeat:start_off:end_off,file2.wav:repeat:start_off:end_off,file3.wav:repeat:start_off:end_off"
</pre>
optional repeat parameter: number of times to play the file (0 and 1 have the same result) optional start_off parameter : Start offset in milliseconds optional end_off parameter: End offset in milliseconds Example: "file1.wav,file2.wav:-1" will play file1.wav one time and then play file2.wav in loop. Example: "file1.wav:0:1000:3000,file2.wav:2:5000:10000" will play file1.wav from second 1 to second 3 then file2.wav from second 5 to second 10 two times. Example: "file1.wav:0:0:30000" will play file1.wav one time for a max duration of 30 seconds.

=== announcement_tone ===

params[:bridge][:announcement_tone] = "announcement.wav"

Prompt played on the incoming leg with the stream_server before any outgoing call is placed. The outgoing call occurs when the wav file is completed or when the "profile:Busy Tone max duration" is reached.

Options:
==== announcement_tone_answer ====
params[:bridge][:announcement_tone_answer] = "yes"

Answer the call before playing the announcement. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== call_progress_tone ===

params[:bridge][:call_progress_tone] = "no_route.wav"

Prompt played after "announcement_tone" when reason is not "ok" or when outgoing call disconnect before answer state. "none" value is used to bypass "profile:Generate Busy (Congestion) Tone" and to play no audio prompt.

==== call_progress_tone_answer ====
params[:bridge][:call_progress_tone_answer] = "yes"

Answer the call before playing the call progress tone. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== ring_tone ===

params[:bridge][:ring_tone] = "ringing.wav"

Prompt played between alerting state and answer state. Bypass any other ring back tone (RBT) configured in profile.

=== max_call_duration ===

params[:bridge][:max_call_duration] = "60000"

Maximum call duration in millisecond for the current bridge. This timer is started when entering answer state.

=== call_duration_reason ===

params[:bridge][:call_duration_reason] = :resource_unavailable

Drop both legs with this reason when call duration (:max_call_duration) is reached.

=== disconnect_tone ===

params[:bridge][:disconnect_tone] = "max_duration.wav"

Prompt played (on the incoming leg only) when call duration (:max_call_duration) is reached. Then the leg will be terminated with specified reason (:call_duration_reason).

==== disconnect_tone_answer ====
params[:bridge][:disconnect_tone_answer] = "yes"

Answer the call before playing the disconnect tone. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== UUI (user-to-user indication) values ===

Byte array represented as ruby String. Use ''bridge=params[:bridge]'', then ''bridge[:uui]'' to access the data.

To access the bytes in Ruby, use ruby String operator []. For example: bridge[:uui][0] will return the binary value of the first UUI byte.

Function each_byte can also be useful to iterate through all bytes of the UUI.

=== uui_forward_enabled values ===

Controls forwarding or discarding of UUI to outgoing call leg.

Values for this parameter are "0", "1", "false" or "true. 0/false: UUI is not forwarded to outgoing call leg 1/true: UUI is forwarded to outgoing call leg The value for this parameter at input of routing script depends on the "Forward UUI" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

=== Managing audio prompts through Web Portal ===
Audio prompts can be uploaded or deleted from the TMedia unit through the Web Portal:
[[Toolpack:Configuring_Audio_Prompts_A|Managing audio prompts]]

Prompts management must be done using the Web Portal of the primary server (in systems with redundant TMedia units or redundant host servers).
The file will automatically get replicated to the secondary server.

=== Managing audio prompts manually ===
Any file on the TMedia host file system can be played. This means it's possible to manage prompts through ssh/scp.

Provided paths are always relative to the "current working directory" of the tbstreamserver application:
/lib/tb/toolpack/setup/12358/2.7/apps/tbstreamserver/
(Where "2.7" may be replaced by the current major version of your system)

Absolute paths can also be provided.

== Recording call legs ==
Introduced in release 2.6.44, it's now possible to use routing scripts to ask for recording incoming and/or outgoing call legs.

See example filter script "call_recording" (created by default in Web Portal routing scripts starting with 2.6.44) for an example.

=== Recording the incoming call leg ===
To record the incoming call leg, the routing script (in a "after filter" for example) has to set the following parameter:

bridge[ :record_incoming ] = ""

=== Recording the outgoing call leg ===
To record the outgoing call leg, the routing script (in a "after filter" for example) has to set the following parameter, per route (the decision to record or not, or the file name to record to, can be set per matching route):

# Need to clone the routes in order to have the right to modify them
routes = clone_routes params[:routes]
routes.each do |route|
route[ :record_outgoing ] = ""
end
# Store modified routes back to the parameters for this outgoing call
params[:routes] = routes

=== Record the outgoing call leg within incoming leg's recorded file (mixing) ===
[...]
route[ :record_outgoing ] = "@{MixWithIncoming}"
[...]

=== Choosing file path to record to ===
The value assigned to ":record_incoming" or ":record_outgoing" is the path to record the file to.

The paths can be absolute, or relative. When relative, they are relative to the "tbstreamserver" application working directory, for example:
/lib/tb/toolpack/setup/12358/2.7/apps/tbstreamserver/

* Empty file name will default to a name that contains various information about the call:
** ''LinkId'': Id common between all legs of this call bridge
** ''LegId'': Unique Id for this leg
** ''Nap'': Current NAP name this call leg is from
** ''Direction'': "IN" or "OUT" (depends if call leg is incoming or outgoing leg)
** ''Calling'': The calling number of this call leg
** ''Called'': The called number of this call leg
** ''Protocol'': The signaling protocol of this call leg (SS7, ISDN, CAS, SIP)
** ''Media info'': Codec + IP/Port for SIP calls, Trunk/Timeslot for TDM calls
* To record outgoing call leg in the same audio file as incoming call leg (mixing), use the following:
** @{MixWithIncoming}: Record outgoing legs in same file as incoming legs
* Variables can be used to insert in the recording path information that's not already available from routing scripts:
** @{DefaultName}: Same file name (without parent folder path) as the one used when empty string is provided
*** Example: "73EBA698-F3D67B4B-NAP_SS7-IN-5550000-5550001-SS7-TRUNK_BELL_11-24.wav"
*** Example: "73EBA698-73EBA698-NAP_SIP-OUT-5550000-5550001-SIP-G723-10.3.10.101-1050.wav"
** @{DefaultPath}: Same path as the one used when empty string is provided
*** Example: "/lib/tb/toolpack/setup/12358/recorded_calls/73EBA698-F3D67B4B-NAP_SS7-IN-5550000-5550001-SS7-TRUNK_BELL_11-24.wav"
*** Example: "/lib/tb/toolpack/setup/12358/recorded_calls/73EBA698-73EBA698-NAP_SIP-OUT-5550000-5550001-SIP-G723-10.3.10.101-1050.wav"
** @{LinkId}: Current LinkId (Id common between all legs of this call bridge)
*** Example: "73EBA698"
** And all variables listed here: [[Customer_application_framework:play_audio_files#Helpful_variables_to_build_play_or_record_file_paths|Building play or record file path]]

== Authorization ==
Starting with release 2.7, it is possible to issue RADIUS authorization requests from routing scripts. To do so, the params[:authorization] object must be filled with the required RADIUS attributes and [[#Refuse|an exception must be raised]] with reason :authorization_required.

When the authorization is completed, the routing script is called again with the result. The params[:authorization] object will be filled with the RADIUS attributes from the response. The params[:authorization][:result] field will also contain a string indicating the result of the authorization:

* ''accept'': The authorization was successful.
* ''reject'': The authorization was refused.
* ''challenge'': The authorization was challenged.
* ''timeout'': The authorization was not answered.

== Call diversion options ==
It's possible to control the call flow when a call diversion information is received in the alerting state.

Two fields are available: bridge[ :diversion ] and bridge[ :diversion_reason ]

The internal release cause TOOLPACK_DIVERT_NOT_ALLOWED is used by gateway application to terminate both legs.

bridge[ :diversion ] = :allowed
The alert message will not be analyzed and the call will be progressed. Default behavior.
bridge[ :diversion ] = :not_allowed
If the alert message indicates that the call is diverted, the call will be released no matter the In-band information to allow
early media.
bridge[ :diversion ] = :not_allowed_w_early_media
The call will be released If the alert message indicates that the call is diverted with in-band information to allow early media.
bridge[ :diversion_reason ] = "*"
If the diversion is not allowed, the gateway will drop the call for any redirecting reason.
bridge[ :diversion_reason ] = []
bridge[ :diversion_reason ] << :busy
bridge[ :diversion_reason ] << :unconditional
If the diversion is not allowed, the redirecting reason will be analyzed and the call will only be dropped for the configured cases.

See section [[Routing_script_tutorial:Mini_Development_Guide#Redirecting_number_reason_values|Redirecting number reason values]].

== Call transfer requests ==
Toolpack allows to relay [[Call transfer]] requests from one leg to the other, or to process them locally (making another outgoing call to replace the call that requested the call transfer).

If the chosen [[Call transfer]] mode is to process requests locally, upon reception of a call transfer request (SIP REFER or ISDN Facility), routing script will be called once again, to select the routes for the new outgoing call (call transfer target).

=== How to route call transfer request ===
Routing of a call transfer request is done exactly like routing of a normal incoming call.
The routing script generally does not need any modification to support that.

In some cases, the routing script may want to use information related to the transfer request to perform routing, or to insert information in the outgoing call leg.
Additional information is provided to the routing script, allowing routing decisions using information from the call transfer request (SIP REFER or ISDN Facility).
See below...

=== params[ :call ] content during transfer request ===
When processing a call transfer request, the params[ :call ] hash contains the information from the inbound call (same as was passed to the routing script upon arrival of the inbound call)
call = params[ :call ] -> Information from original inbound call, with exception of call[ :called ]

One exception (convenient because it allows a unmodified routing script to process call transfer request the same way as any other routing request):
call[ :called ] -> Replaced by the called number from the call transfer request (also called "redirection number")
Complementary information:
call[ :original_called_number ] -> Contains the called number that was initially received from the incoming call, prior to call transfer request
call[ :redirecting_number ] -> Number of the call from which the call transfer request was received (generally equals to original_called_number)

These fields will also be included in the outgoing call made after routing:
* original called number and redirecting number are existing fields on SS7 and ISDN calls
* SIP "diversion" header is used for SIP calls

=== params[ :transfer ] content ===
(this if valid only for release 2.7.102 and above) 
When processing a call transfer request, information from the call transfer request message (SIP REFER, ISDN Facility) is provided in params[ :transfer ]:
transfer = params[ :transfer ]
The following field is always present:
transfer[ :original_nap ] -> Contains the NAP of the first call from which a call transfer request was received
transfer[ :redirecting_nap ] -> Contains the NAP of the call from which the current call transfer request was received
(same as :original_nap for the first call transfer, different for subsequent transfers)
Examples of other fields that may be present, when appropriate:
transfer[ :uui ] -> The UUI (user-to-user information) found in the call transfer request
transfer[ :sip_header ] -> Contains custom SIP headers from the call transfer request
transfer[ :request_uri ] -> Contains the SIP Request URI

These field are 'read-only'. They won't be included in the outgoing call, as they represent the content of the call transfer request, not the outgoing call to make.

To insert/modify attributes of the outgoing call, the parameters from params[ :call ] must be edited instead.

== Reason values ==

Check here for Termination Reason Cause codes: 

[[Termination_cause_codes|Termination Reason Cause codes]]
 

Example to refuse an incoming call leg.
raise RoutingException, :no_route

Reason cause strings available inside routing scripts:

List of Q.850 reason causes:
:unallocated_number
:no_route_to_network
:no_route_to_destination
:send_special_tone
:misdialled_trunk_prefix
:channel_unacceptable
:call_awarded_in_established_channel
:preemption
:reattempt
:ported_number
:normal_call_clearing
:user_busy
:no_user_responding
:no_answer_from_user
:subscriber_absent
:call_rejected
:number_changed
:redirection
:exchange_routing_error
:non_selected_user_clearing
:destination_out_of_order
:address_incomplete
:facility_rejected
:response_to_status_enquiry
:normal_unspecified
:no_circuit_available
:network_out_of_order
:frame_mode_out_of_service
:frame_mode_connection_operational
:temporary_failure
:switching_equipment_congestion
:access_information_discarded
:requested_circuit_not_available
:precedence_call_blocked
:resource_unavailable
:quality_of_service_not_available
:requested_facility_not_subscribed
:outgoing_calls_barred
:outgoing_calls_barred_within_cug
:incoming_calls_barred
:incoming_calls_barred_within_cug
:bearer_cap_not_authorized
:bearer_cap_not_available
:inconsistency_access_info
:service_not_available
:bearer_cap_not_implemented
:channel_type_not_implemented
:requested_facility_not_implemented
:only_restricted_digital_info
:service_not_implemented
:invalid_call_reference
:channel_does_not_exist
:call_identity_does_not_exist
:call_identity_in_use
:no_call_suspended
:call_has_been_cleared
:user_not_member_of_cug
:incompatible_destination
:non_existant_cug
:invalid_transit_network
:invalid_message_unspecified
:mandatory_ie_missing
:message_type_non_existent
:not_compatible_with_call_state
:ie_non_existent
:invalid_ie_content
:message_not_compatible
:recovery_on_timer_expiry
:parameter_non_existent_passed_on
:msg_with_non_recognized_param_discarded
:protocol_error
:interworking_unspecified

List of toolpack reason causes:

:toolpack_normal or :normal
:toolpack_resource_error or :resource_error
:toolpack_timeout or :timeout
:toolpack_no_route or :no_route
:toolpack_call_collision or :call_collision
:toolpack_sync_drop or :sync_drop
:toolpack_signaling_error or :signaling_error
:toolpack_locally_rejected or :locally_rejected
:toolpack_interface_not_available or :interface_not_available
:toolpack_reset_in_progress or :reset_in_progress
:toolpack_adapter_reject or :adapter_reject
:toolpack_missing_or_invalid_ie or :missing_or_invalid_ie
:toolpack_incoming_only or :incoming_only
:toolpack_system_configuration_changed or :system_configuration_changed
:toolpack_resource_no_more_available or :resource_no_more_available
:toolpack_incompatible_media or :incompatible_media
:toolpack_resource_allocation_failed or :resource_allocation_failed
:toolpack_data_path_not_available or :data_path_not_available
:toolpack_local_congestion or :local_congestion
:toolpack_authorization_required or :authorization_required
:toolpack_call_divert_is_not_allowed or :call_divert_is_not_allowed

List of SIP reason causes:

:400_bad_request
:401_unauthorized
:402_payment_required
:403_forbidden
:404_not_found
:405_method_not_allowed
:406_not_acceptable
:407_proxy_authentication_required
:408_request_timeout
:409_conflict
:410_gone
:413_request_entity_too_large
:414_request_URI_too_long
:415_unsupported_media
:416_unsupported_URI_scheme
:420_bad_extension
:421_extension_required
:422_session_timer_too_small
:423_interval_too_brief
:429_referrer_identity_error
:480_temporary_unavailable
:481_call_or_transaction_does_not_exist
:482_loop_detected
:483_too_many_hops
:484_address_incomplete
:485_ambiguous
:486_busy_here
:487_request_terminated
:488_not_acceptable_here
:489_bad_event
:491_retry_after
:500_server_internal_error
:501_not_implemented
:502_bad_gateway
:503_service_unavailable
:504_server_timeout
:505_version_unsupported
:513_message_too_large
:600_busy_everywhere
:603_decline
:604_not_exist_anywhere
:606_not_acceptable

== Nap status ==

All the status fields of the NAPs are provided for use by the routing scripts. See the nap status provider for more details on which fields are available in the CEngineStatTransNap.hpp file.

'''Notice:''' These values may change between major release.

Routing script call attribute name Description
--------------------------------------------------------------------------------------------
"signaling_type" Signaling type.
"inst_incoming_call_cnt" Instantaneous Count of incoming calls.
"inst_outgoing_call_cnt" Instantaneous Count of outgoing calls.
"available_cnt" Number of available circuits or channels.
"unavailable_cnt" Number of unavailable circuits or channels.
"availability_percent" Percentage of available circuits or channels.
"usage_percent" Percentage of used circuits or channels.
"unused_shared_percent" Percentage of used circuits or channels of this NAP available to make new calls with (taking into account shared with other NAPs)
"total_incoming_call_cnt" Total Count of incoming calls.
"asr_statistics_struct" Detailed Answer-Seizure Rate Statistics.
"global_asr_percent" Global calculated ASR percentage.
"total_outgoing_call_cnt" Total Count of outgoing calls.
"last_24h_asr_percent" Last 24 hours calculated ASR percentage.
"last_24h_outgoing_call_cnt" Last 24 hours outgoing calls.
"current_hour_asr_percent" Current hour calculated ASR percentage.
"current_hour_outgoing_call_cnt" Current hour outgoing calls.
"last_hour_asr_percent" Last hour calculated ASR percentage.
"last_hour_outgoing_call_cnt" Last hour outgoing calls.
"availability_detection_struct" Detailed availibility detection Statistics
"poll_remote_proxy" Remote proxy polling enabled
"is_available" Remote proxy actually available or not
"time_since_polling" Time since the last availibility polling
"time_available_seconds" Number of seconds since the NAP is available
"time_unavailable_seconds" Number of seconds since the NAP is unavailable
"registration_struct" Detailed registration Statistics
"register_to_proxy" Register to proxy enabled
"registered" Actually registered or not
"time_since_refresh" Time since the last refresh
"time_registered_seconds" Number of seconds since the NAP is registered
"time_not_registered_seconds" Number of seconds since the NAP is not registered

 If the nap status is part of a substructure, it's name in the routing scripts must be composed of the structure name appended by an underscore and the field name.

For example the name to use for the global [[ASR]] percentage is:

asr_statistics_struct_global_asr_percent

 It is also possible to add dynamic nap attributes in the web portal. These can be referenced by their name.

== Routing Script Tests ==
The Web portal features a tool for Testing Scripts. The user must enter parameters to simulate the incoming call and after pressing the Test button, will output selected routes and numbers. You do not need to activate the new routes, or the new scripts to use this test tool: It can be used to test the routing scripts and routing table before activating it.
This is available in the Routing Scripts section of the Web portal.

=== Test parameters ===
==== @call_params ====

That variable should contain a hash of call parameters that will passed to the routing script. This is equivalent to the incoming call parameters.

 

==== @nap_list ====

A list of hash containing the nap statuses. This is equivalent to the nap statuses at the time the call is to be routed.

'''The nap list is hashed by the nap names in UPPERCASE.''' It is important to consider this when creating new dynamic route or nap attributes that may nap names that will be used to fetch a status.

 

==== @params ====

A hash of hashes containing parameters. This hash contains bridge parameters and other kind of parameter groups may be added in the future.

Example: @params = {:bridge => {:announcement_tone, "announcement.wav"}}

 

----

 Back to [[Routing script tutorial|Routing Script Tutorial]].

[[category:Needs revising]]

Routing script tutorial:Mini Development Guide

2014-11-06T16:49:43Z

Manon Bélanger: /* Script parameters protocol mapping */

== Call object ==

=== Get ===

Those function are used to get the call parameters. The possible parameters are described in the section "Call parameters"

called_number = caf_call.get :called

=== List_params ===

This function is used to retrieve the list of supported call parameters. For example to extract all the possible call params from the the call object and put it in hash.

caf_call.list_params.each {|param| call[param] = caf_call.get param }

=== Accept ===

This function is used to accept a call. It actually creates one outgoing route that gateway application will use to bridge the incoming call leg. If more than one outgoing route is "accepted", gateway will try them one by one in the same order they were accepted. If an outgoing call leg fails (according to 'route retry' parameters), the next route in line will be used.

This method takes 2 arguments, the call parameters (hash) and the route parameters (hash). Note that calling this method does NOT stop the flow of the script.

Apply route remapping rules

caf_call.accept out_call, route

=== Refuse ===

This function is used to set the reason code for the incoming call leg refusal. However, this function does NOT stop the flow of the script.

caf_call.refuse :reason => :temporary_failure

To immediately refuse the incoming call leg and stop processing the script, the script must raise an exception. Exiting the script by raising the exception overwrites any reason cause previously stored using refuse().

raise RoutingException, :no_route

The supported refusal cause values for both refuse() and raise() are described in the section "[[Routing_script_tutorial:Mini_Development_Guide#Reason_values|Reason values]]".

=== Script parameters protocol mapping ===

The following call parameters are available in the call object:

{| cellspacing="1" cellpadding="1" border="1" style="width: 921px; height: 805px;"
|-
! scope="col" | '''Script parameter name'''
! scope="col" | '''ISDN '''
! scope="col" | '''R2 CAS''' 
! scope="col" | '''SS7 '''
! scope="col" | '''SIP '''
! scope="col" | '''Comment '''
! scope="col" | '''Toolpack version '''
|-
| leg_id 
| N/A 
| N/A 
| N/A 
| N/A 
| Leg ID 
| 
|-
| session_id 
| N/A 
| N/A 
| N/A 
| N/A 
| Session ID 
| 
|-
| calling 
| Q931: 'Calling party number' IE - Number digits 
| ANI (Group B) 
| Q763: 'Calling party number' IE - address signals (*) 
| SIP:From - user-info 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead. 
| 
|-
| calling_noa 
| Q931: 'Calling party number' IE - Type of number 
| N/A 
| Q763: 'Calling party number' IE - nature of address indicator (*) 
| N/A 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead 
| 
|-
| calling_npi 
| Q931: 'Calling party number' IE - Numbering plan identification 
| N/A 
| Q763: 'Calling party number' IE - numbering plan indicator (*) 
| N/A 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead 
| 
|-
| calling_display 
| Q931: 'Display' IE - Display information 
Q931: 'Facility CNAM' IE when presentation is allowed for DMS/NI2 variants 
| N/A 
| Q763: 'Display information' IE - display information 
| SIP:From - display-name 
| 
| 
|-
| calling_display_type 
| Q931: 'Display' IE - Display information (present and/or first byte) 
| N/A 
| Q763: 'Display information' IE - present or not 
| N/A 
| 
| 
|-
| calling_presentation 
| Q931: 'Calling party number' IE - Presentation indicator 
| N/A 
| Q763: 'Calling party number' IE - address presentation restricted indicator 
|
SIP:From - display-name (displays 'anonymous' or not)

SIP:Remote-party-id - privacy 

| 
| 
|-
| calling_screening 
| Q931: 'Calling party number' IE - Screening indicator 
| N/A 
| Q763: 'Calling party number' IE - screening 
| SIP:Remote-party-id - screen 
| 
| 
|-
| calling_category 
| N/A 
| Call party category (Group A) 
| Q763: 'Calling party's category' IE - calling party's category 
|
SIP:From - cpc

SIP:P-asserted-identity - cpc 

| 
| 
|-
| calling_subscriber
(Generic Number / NDS) 
| Q931: 2nd 'Calling party number' IE - Number digits 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - Number digits 
|
SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| Requires option 'support 2 calling number IE' in the profile. This variable has priority over 'private_address' in the outgoing direction. 
| 
|-
| calling_subscriber_noa 
| Q931: 2nd 'Calling party number' IE - Type of number 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - nature of address indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| calling_subscriber_npi 
| Q931: 2nd 'Calling party number' IE - Numbering plan identification 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - numbering plan indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
 
| 
|-
| calling_subscriber_presentation 
| Q931: 2nd 'Calling party number' IE - Presentation indicator 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - presentation restricted indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| calling_subscriber_screening 
| Q931: 2nd 'Calling party number' IE - Screening indicator 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - screening 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| private_display 
| Q931: 'Facility CNAM' IE when presentation is restricted for DMS/NI2 variants 
| N/A 
| N/A 
|
SIP:P-asserted-identity - display-name 

SIP:Remote-party-id - display-name 

| 
| 
|-
| private_display_type 
| N/A 
| N/A 
| N/A 
| N/A 
| Indicate presence or not of the private calling information 
| 
|-
| private_address 
| N/A 
| N/A 
| N/A 
|
SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 

| 
| 
|-
| called 
| Q931: 'Called party number' IE - Number digits 
| DNIS (Group A) 
| Q763: 'Called party number' IE - address signals 
| SIP:To - user-info and host 
| 
| 
|-
| called_noa 
| Q931: 'Called party number' IE - Type of number 
| N/A 
| Q763: 'Called party number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| called_npi 
| Q931: 'Called party number' IE - Numbering plan identification 
| N/A 
| Q763: 'Called party number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| charge_number 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - address signals 
| N/A 
| 
| 
|-
| charge_number_noa 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| charge_number_npi 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| redirecting_number_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default redirecting number and original called number forwarding behavior from incoming to outgoing leg 
| 
|-
| redirecting_number 
| Q931: 'Redirecting number' 1st IE - Number digits 
| N/A 
| Q763: 'Redirecting number' IE - address signals 
| SIP:Diversion (2nd header) - display-name 
| 
| 
|-
| redirecting_number_noa 
| Q931: 'Redirecting number' 1st IE - Type of number 
| N/A 
| Q763: 'Redirecting number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| redirecting_number_npi 
| Q931: 'Redirecting number' 1st IE - Numbering plan identification 
| N/A 
| Q763: 'Redirecting number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| redirecting_number_presentation 
| Q931: 'Redirecting number' 1st IE - Presentation indicator 
| N/A 
| Q763: 'Redirecting number' IE - address presentation restricted indicator 
| SIP:Diversion (2nd header) - diversion-privacy 
| 
| 
|-
| redirecting_number_indicator 
| N/A 
| N/A 
| Q763: 'Redirection information' IE - redirecting indicator 
| N/A 
| 
| 
|-
| redirecting_number_reason 
| Q931: 'Redirecting number' 1st IE - Reason for redirection 
| N/A 
| Q763: 'Redirection information' IE - redirecting reason 
| SIP:Diversion (2nd header) - diversion-reason 
| 
| 
|-
| redirecting_number_counter 
| N/A 
| N/A 
| Q763: 'Redirection information' IE - redirection counter 
| SIP:Diversion (2nd header) - diversion-counter 
| 
| 
|-
| original_called_number
(OCN) 
| Q931: 'Redirecting number' 2nd IE - Number digits 
| N/A 
| Q763: 'Redirection number' IE - address signals 
| SIP:Diversion  (1st header) - display-name 
| 
| 
|-
| original_called_number_noa 
| Q931: 'Redirecting number' 2nd IE - Type of number 
| N/A 
| Q763: 'Redirection number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| original_called_number_npi 
| Q931: 'Redirecting number' 2nd IE - Numbering plan identification 
| N/A 
| Q763: 'Redirection number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| original_called_number_presentation 
| Q931: 'Redirecting number' 2nd IE - Presentation indicator 
| N/A 
| Q763: 'Redirection number' IE - address presentation restricted indicator 
| SIP:Diversion (1st header) - diversion-privacy 
| 
| 
|-
| original_called_number_reason 
| Q931: 'Redirecting number' 2nd IE - Reason for redirection 
| N/A 
| Q763: 'Redirection information' IE - original redirection reason 
| SIP:Diversion (1st header) - diversion-reason 
| 
| 
|-
| original_called_number_counter 
| N/A 
| N/A 
| N/A 
| SIP:Diversion (1st header) - diversion-counter 
| 
| 
|-
| ported_number 
| N/A 
| N/A 
| Q763: 'Called party number' IE - address signals 
| SIP:RequestURI - rn 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| ported_number_noa 
| N/A 
| N/A 
| Q763: 'Called party number' IE - nature of address indicator 
| N/A 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| ported_number_npi 
| N/A 
| N/A 
| Q763: 'Called party number' IE - numbering plan indicator 
| N/A 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| oli
(Originating line information) 
| 5ESS Codeset 6 OLI - Value 
| N/A 
| ANSI: 'Originating line information' IE - OLI 
|
SIP:From - oli

SIP:P-asserted-identity - oli 

| 
| 
|-
| request_uri 
| N/A 
| N/A 
| N/A 
| Complete Request URI string 
| 
| 
|-
| request_uri_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default URI forwarding behavior from incoming to outgoing leg 
| 
|-
| sip_header 
| N/A 
| N/A 
| N/A 
| Any header 
| Requires option 'Forward custom headers' in Profiles->SIP 
| 2.7.63 
|-
| nap
(Network Access Point) 
| N/A 
| N/A 
| N/A 
| N/A 
| Incoming leg NAP name (read-only) 
| 
|-
| type_of_network_identification 
| Q931: 'Transit network selection' IE - Type of network identification 
| N/A 
| Q763: 'Transit network selection' IE - Type of network identification 
| N/A 
| 
| 2.7 
|-
| network_identification 
| Q931: 'Transit network selection' IE - Network identification 
| N/A 
| Q763: 'Transit network selection' IE - Network identification 
| SIP: Request-Line - cic 
| 
| 2.7 
|-
| network_identification_plan 
| Q931: 'Transit network selection' IE - Network identification plan 
| N/A 
| Q763: 'Transit network selection' IE - Network identification plan 
| N/A 
| 
| 2.7 
|-
| location_number_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default location number forwarding behavior from incoming to outgoing leg 
| 2.7 
|-
| location_number 
| N/A 
| N/A 
| Q763: 'Location number' IE - address signals 
| N/A 
| 
| 2.7 
|-
| location_number_noa 
| N/A 
| N/A 
| Q763: 'Location number' IE - nature of address indicator 
| N/A 
| 
| 2.7 
|-
| location_number_npi 
| N/A 
| N/A 
| Q763: 'Location number' IE - numbering plan indicator 
| N/A 
| 
| 2.7 
|-
| location_number_presentation 
| N/A 
| N/A 
| Q763: 'Location number' IE - presentation restricted indicator 
| N/A 
| 
| 2.7 
|-
| location_number_screening 
| N/A 
| N/A 
| Q763: 'Location number' IE - screening 
| N/A 
| 
| 2.7 
|-
| mlpp_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| A script needs to set this to true if it wants to overwrite MLPP information in the outgoing leg. Otherwise, profile relay 'outgoing mode' applies automatically. 
| 2.7 
|-
| mlpp_look_for_busy 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - look ahead for busy 
| N/A 
| 
| 2.7 
|-
| mlpp_precedence_level 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - precedence level 
| SIP:Resource-Priority - q735 
| 
| 2.7 
|-
| mlpp_network_identity 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - network identity 
| N/A 
| 
| 2.7 
|-
| mlpp_service_domain 
| N/A 
| N/A 
| Q763: 'MLPP precedence' IE - MLPP service domain 
| N/A 
| 
| 2.7 
|-
| called_isub 
| Q931: 'Called party subaddress' IE - subaddress information 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Called party subaddress' IE - subaddress information 
| SIP:To - isub parameter 
| 
| 2.7 
|-
| called_isub_type 
| Q931: 'Called party subaddress' IE - type of subaddress 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Called party subaddress' IE - type of subaddress 
| SIP:To - isub-encoding parameter 
| 
| 2.7 
|-
| calling_isub 
| Q931: 'Calling party subaddress' IE - subaddress information 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Calling party subaddress' IE - subaddress information 
| SIP:From - isub 
| 
| 2.7 
|-
| calling_isub_type 
| Q931: 'Callinf party subaddress' IE - type of subaddress 
| N/A 
| Q763: 'Access transport' IE - Q931: 'Calling party subaddress' IE - type of subaddress 
| SIP:From - isub-encoding 
| 
| 2.7 
|-
| ss7_fci_default 
| N/A 
| N/A 
| Default forward call indicator (FCI) value. 
| N/A 
| Toolpack will overwrite FCI bits A, D, F, I and M with appropriate values according to call conditions 
| 2.7 
|-
| ss7_fci_force_mask 
| N/A 
| N/A 
| Mask to select bits from ss7_fci_default that must be forced. 
| N/A 
| Bits from ss7_fci_default which corresponding bit in ss7_fci_force_mask is set will be forced, and no more controlled by Toolpack 
| 2.7 
|-
| ss7_bci_default 
| N/A 
| N/A 
| Default backward call indicator (BCI) value. 
| N/A 
| Toolpack will overwrite BCI bits AB, I, K, M and N with appropriate values according to call conditions 
| 2.7 
|-
| ss7_bci_force_mask 
| N/A 
| N/A 
| Mask to select bits from ss7_bci_default that must be forced. 
| N/A 
| Bits from ss7_bci_default which corresponding bit in ss7_bci_force_mask is set will be forced, and no more controlled by Toolpack 
| 2.7 
|-
| tdm_ls_name
(Line Service or T1/E1 trunk) 
| Incoming leg line service name 
| Incoming leg line service name 
| Incoming leg line service name 
| N/A 
| (read-only) 
| 2.7 
|-
| tdm_timeslot_nb 
| Incoming leg timeslot number 
| Incoming leg timeslot number 
| Incoming leg timeslot number 
| N/A 
| (read-only) 
| 2.7 
|-
| rtp_local_addr 
| N/A 
| N/A 
| N/A 
| Incoming leg local SDP IP address 
| (read-only) 
| 2.7 
|-
| rtp_local_port 
| N/A 
| N/A 
| N/A 
| Incoming leg local SDP IP port 
| (read-only) 
| 2.7 
|-
| rtp_remote_addr 
| N/A 
| N/A 
| N/A 
| Incoming leg remote SDP IP address 
| (read-only) 
| 2.7 
|-
| rtp_remote_port 
| N/A 
| N/A 
| N/A 
| Incoming leg remote SDP IP port 
| (read-only) 
| 2.7 
|-
| ss7_cot_enabled 
| N/A 
| N/A 
| Requests SS7 in-call continuity test for this outgoing SS7 call 
| N/A 
| Toolpack will request continuity test on the timeslot before making the outgoing call. If COT fails, the call will be dropped (then another route may be attempted) 
| 2.8 
|-
| reverse_charging_indication 
| Incoming leg Reverse charging indication IE present 
| N/A 
| N/A 
| N/A 
| If set in routing script, will add Reverse charging indication IE in outgoing leg (also use reverse_charging_indication_forward_enabled) 
| 2.8 
|-
| reverse_charging_indication_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Enable forwarding of reverse charging indication from incoming to outgoing leg 
| 2.8 
|}

 

'''Notice:''' All values are documented in the '''noa_npi_remap.rb''' script and may change between major release.

=== Noa values ===

*<tt>unknown_number (0x2)</tt>
*<tt>international_number (0x4)</tt>
*<tt>national_number (0x3)</tt>
*<tt>subscriber_number (0x1)</tt>
*<tt>network_specific (0x5)</tt>
*<tt>network_routing_national_format (0x7)</tt>
*<tt>network_routing_international_format (0x8)</tt>
*<tt>abbreviated_number (0x6)</tt>
*<tt>subscriber_number_operator_requested (0x71)</tt>
*<tt>national_number_operator_requested (0x72)</tt>
*<tt>international_number_operator_requested (0x73)</tt>
*<tt>no_number_present_operator_requested (0x74)</tt>
*<tt>no_number_present_cut_through_call_to_carrier (0x75)</tt>
*<tt>test_line_test_code (0x77)</tt>
*<tt>non_unique_subscriber_number (0x71)</tt>
*<tt>non_unique_national_number (0x73)</tt>
*<tt>non_unique_international_number (0x74)</tt>
*<tt>call_950_numbe (0x76)</tt>
*<tt>special_number (0x73)</tt>
*<tt>national_number_with_transit_network_selection (0x74)</tt>
*<tt>international_number_with_transit_network_selection (0x75)</tt>

Those values will be remapped to the protocol specific NOA value. To provide protocol specific value:

*<tt>call_params[:called_noa] = 0x70</tt>

or

*<tt>call_params[:called_noa] = 112</tt>

=== Npi values ===

*<tt>unknown_number</tt>
*<tt>isdn</tt>
*<tt>telephony</tt>
*<tt>private</tt>
*<tt>data</tt>
*<tt>telex</tt>
*<tt>national</tt>

=== Calling Display Type values ===

*<tt>unspecified</tt> => Type is unspecified.
*<tt>calling_party_name</tt> => Type is 0xB1.

Those values will be remapped to the protocol specific Display Information Type value. To provide protocol specific value:

*<tt>call_params[:calling_display_type] = 0xB1</tt>

or

*<tt>call_params[:calling_display_type] = 177</tt>

=== Calling Display value ===

*<tt>call_params[:calling_display] = "Roger Fluffy"</tt>

=== Presentation values for Calling number, Calling Subscriber (Generic Number), Redirecting Number, Original Called Number (OCN) and Location Number ===

*<tt>unspecified</tt>
*<tt>not_available (0x2)</tt>
*<tt>allowed (0x0)</tt>
*<tt>restricted (0x1)</tt>
*<tt>addr_restricted</tt>
*<tt>name_restricted</tt>

=== Calling Party Category ===
values for calling_category
*<tt>unspecified</tt> <tt>(0xa)</tt>
*<tt>unknown</tt> <tt>(0x0)</tt>
*<tt>operator_french</tt> <tt>(0x1)</tt>
*<tt>operator_english</tt> <tt>(0x2)</tt>
*<tt>operator_german</tt> <tt>(0x3)</tt>
*<tt>operator_russian</tt> <tt>(0x4)</tt>
*<tt>operator_spanish</tt> <tt>(0x5)</tt>
*<tt>subscriber</tt> <tt>(0xa)</tt>
*<tt>subscriber_with_priority</tt> <tt>(0xb)</tt>
*<tt>data</tt> <tt>(0xc)</tt>
*<tt>test</tt> <tt>(0xd)</tt>
*<tt>payphone</tt> <tt>(0xf)</tt>

=== Screening values for Calling number, Calling Subscriber (Generic Number), and Location Number ===

*<tt>unspecified</tt>
*<tt>no (0x0)</tt>
*<tt>pass (0x1)</tt>
*<tt>fail (0x2)</tt>
*<tt>network_provided (0x3)</tt>

=== Redirecting indicator values ===

SS7:

*<tt>no_redirection</tt>
*<tt>call_rerouted</tt>
*<tt>call_rerouted_all_restricted</tt>
*<tt>call_diverted</tt>
*<tt>call_diverted_all_restricted</tt>
*<tt>call_rerouted_restricted</tt>
*<tt>call_diverted_restricted</tt>
*<tt>spare</tt>

=== Redirecting number, Original Called Number and Diversion Reason ===

ISDN:

*<tt>unknown</tt>
*<tt>busy</tt>
*<tt>no_reply</tt>
*<tt>deflection</tt>
*<tt>dte_out_of_order</tt>
*<tt>forwarding_by_called_dte</tt>
*<tt>unconditional</tt>

SS7:

*<tt>unknown</tt>
*<tt>busy (SIP: user-busy)</tt>
*<tt>no_reply (SIP: no-answer)</tt>
*<tt>unconditional</tt>
*<tt>deflection</tt>
*<tt>deflection_immediate</tt>
*<tt>mobile_not_reachable</tt>

=== OLI (originating line information) values ===

The OLI parameter is a string that represents an integer value from 0 to 255.

=== Information Transfer Capability values ===

information_transfer_capability:

*<tt>digital</tt>
*<tt>restricted_digital</tt>
*<tt>digital_with_tones</tt>
*<tt>speech</tt>
*<tt>3_1_khz_audio</tt>

=== redirecting_number_forward_enabled values ===

Controls forwarding or discarding of redirecting number (SIP: diversion header) to outgoing call leg.

Values for this parameter are "0", "1", "false" or "true. 0/false: Redirecting number (and original called number) is not forwarded to outgoing call leg 1/true: Redirecting number (and original called number) is forwarded to outgoing call leg The value for this parameter at input of routing script depends on the "Forward redirecting number" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

=== request_uri ===

Enables access to the Request-Line URI. 

For example, if the Request-Line is:
<pre>Request-Line: INVITE sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0</pre>
Then the retrieved request_uri will be "sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0". 

In the routing scripts, to retrieve only the called number, this script can be used: 
<pre> if call_params[:request_uri] && call_params[:request_uri] =~ /sip:(.*)@.*/
call_params[:called] = $1
end
</pre>
=== request_uri_forward_enabled values ===

Controls forwarding or discarding of request uri to outgoing call leg.The request uri is the information in the "Request-Line:" of the SIP INVITE message. 

Values for this parameter are "0", "1", "false" or "true. 

0/false: Request uri is not forwarded to outgoing call leg 

1/true: Request uri is forwarded to outgoing call leg 

The value for this parameter at input of routing script is always false. 

=== sip_header values ===
Contains a hash table of custom sip headers from the inbound call leg. Any custom sip header can be added to an outgoing call leg: 

<pre>call[ :sip_header ] = {"P-my-custom-header"=>"value1", "P-my-custom-header2"=>"value2", "P-my-custom-header3"=>"value3"}</pre>

* PCAP sample: [[File:TB_Custom_SIP_Headers.pcap]]

List of sip headers that will not appear in call[:sip_header] since they are already processed by the SIP stack:
<pre>
Accept Error-Info Remote-Party-ID
Accept-Contact Event Replaces
Accept-Encoding Expires Reply-To
Accept-Language From Request-Disposition
Alert-Info In-Reply-To Subject
Allow Max-Forwards Subscription-State
Allow-Events MIME-version Supported
Also Min-Expires Timestamp
Anonymity Min-SE To
Authorization Organization Unsupported
Authentication-Info Path User-Agent
Call-ID Priority Via
Call-Info Privacy Warning
Contact Proxy-Authenticate WWW-Authenticate
Content-Disposition Proxy-Authorization Require
Content-Encoding Proxy-Require Response-Key
Content-Language P-Media-Authorization Retry-After
Content-Length P-Preferred-Identity RPID-Privacy
Content-Type P-Asserted-Identity Route
CSeq RAck RSeq
RAck Reason Security-Client
Reason Record-Route Security-Server
Date Refer-To Security-Verify
Diversion Referred-By Server
Encryption Reject-Contact Service-Route
Session-Expires
</pre>

=== MLPP Precedence values ===

mlpp_look_for_busy:

*<tt>allowed</tt>
*<tt>path_reserved</tt>
*<tt>not_allowed</tt>

mlpp_precedence_level:

*<tt>flash_override</tt>
*<tt>flash</tt>
*<tt>immediate</tt>
*<tt>priority</tt>
*<tt>routine</tt>

mlpp_network_identity:

3 digits value from 0 to 999

mlpp_service_domain:

24 bits value from 0 to 16777215

=== ISUB subaddress information values ===

called_isub_type:
calling_isub_type:

*<tt>nsap</tt>
*<tt>nsap_ia5</tt>
*<tt>nsap_bcd</tt>
*<tt>user</tt>

called_isub:
calling_isub:

Digits for the subaddress information.

== Route parameters ==

All route may have these parameters:

*calling
*called
*nap
*remapped_calling
*remapped_called
*remapped_nap
*remapped_profile
*remapped_incoming_profile

Additionally it is possible to add dynamic route attributes in the web portal. These can be referenced by their name.

== Playing prompts announcements or tones ==

New feature in release 2.6, all bridges may have these parameters. These can be used to play IVR prompts or wav files in different states of the call flow, like playing an announcement when the caller dials in. You can also manage the User to User information element.

*announcement_tone
*call_progress_tone
*ring_tone
*max_call_duration
*call_duration_reason
*disconnect_tone
*uui
*uui_forward_enabled

The following sections show how to access those different parameters from '''inside''' a filter. The 'params' hash is the sole argument passed to a filter function and contains call, nap, route and bridge parameters. This hash is created by the base_routing.rb scripts to regroup all relevant information just before calling the filter functions.

=== Tone string format ===

All tone strings (:announcement_tone, :call_progress_tone, :ring_tone, :disconnect_tone) inside bridge parameters are using this format.
<pre>"file1.wav:repeat:start_off:end_off,file2.wav:repeat:start_off:end_off,file3.wav:repeat:start_off:end_off"
</pre>
optional repeat parameter: number of times to play the file (0 and 1 have the same result) optional start_off parameter : Start offset in milliseconds optional end_off parameter: End offset in milliseconds Example: "file1.wav,file2.wav:-1" will play file1.wav one time and then play file2.wav in loop. Example: "file1.wav:0:1000:3000,file2.wav:2:5000:10000" will play file1.wav from second 1 to second 3 then file2.wav from second 5 to second 10 two times. Example: "file1.wav:0:0:30000" will play file1.wav one time for a max duration of 30 seconds.

=== announcement_tone ===

params[:bridge][:announcement_tone] = "announcement.wav"

Prompt played on the incoming leg with the stream_server before any outgoing call is placed. The outgoing call occurs when the wav file is completed or when the "profile:Busy Tone max duration" is reached.

Options:
==== announcement_tone_answer ====
params[:bridge][:announcement_tone_answer] = "yes"

Answer the call before playing the announcement. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== call_progress_tone ===

params[:bridge][:call_progress_tone] = "no_route.wav"

Prompt played after "announcement_tone" when reason is not "ok" or when outgoing call disconnect before answer state. "none" value is used to bypass "profile:Generate Busy (Congestion) Tone" and to play no audio prompt.

==== call_progress_tone_answer ====
params[:bridge][:call_progress_tone_answer] = "yes"

Answer the call before playing the call progress tone. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== ring_tone ===

params[:bridge][:ring_tone] = "ringing.wav"

Prompt played between alerting state and answer state. Bypass any other ring back tone (RBT) configured in profile.

=== max_call_duration ===

params[:bridge][:max_call_duration] = "60000"

Maximum call duration in millisecond for the current bridge. This timer is started when entering answer state.

=== call_duration_reason ===

params[:bridge][:call_duration_reason] = :resource_unavailable

Drop both legs with this reason when call duration (:max_call_duration) is reached.

=== disconnect_tone ===

params[:bridge][:disconnect_tone] = "max_duration.wav"

Prompt played (on the incoming leg only) when call duration (:max_call_duration) is reached. Then the leg will be terminated with specified reason (:call_duration_reason).

==== disconnect_tone_answer ====
params[:bridge][:disconnect_tone_answer] = "yes"

Answer the call before playing the disconnect tone. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== UUI (user-to-user indication) values ===

Byte array represented as ruby String. Use ''bridge=params[:bridge]'', then ''bridge[:uui]'' to access the data.

To access the bytes in Ruby, use ruby String operator []. For example: bridge[:uui][0] will return the binary value of the first UUI byte.

Function each_byte can also be useful to iterate through all bytes of the UUI.

=== uui_forward_enabled values ===

Controls forwarding or discarding of UUI to outgoing call leg.

Values for this parameter are "0", "1", "false" or "true. 0/false: UUI is not forwarded to outgoing call leg 1/true: UUI is forwarded to outgoing call leg The value for this parameter at input of routing script depends on the "Forward UUI" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

=== Managing audio prompts through Web Portal ===
Audio prompts can be uploaded or deleted from the TMedia unit through the Web Portal:
[[Toolpack:Configuring_Audio_Prompts_A|Managing audio prompts]]

Prompts management must be done using the Web Portal of the primary server (in systems with redundant TMedia units or redundant host servers).
The file will automatically get replicated to the secondary server.

=== Managing audio prompts manually ===
Any file on the TMedia host file system can be played. This means it's possible to manage prompts through ssh/scp.

Provided paths are always relative to the "current working directory" of the tbstreamserver application:
/lib/tb/toolpack/setup/12358/2.7/apps/tbstreamserver/
(Where "2.7" may be replaced by the current major version of your system)

Absolute paths can also be provided.

== Recording call legs ==
Introduced in release 2.6.44, it's now possible to use routing scripts to ask for recording incoming and/or outgoing call legs.

See example filter script "call_recording" (created by default in Web Portal routing scripts starting with 2.6.44) for an example.

=== Recording the incoming call leg ===
To record the incoming call leg, the routing script (in a "after filter" for example) has to set the following parameter:

bridge[ :record_incoming ] = ""

=== Recording the outgoing call leg ===
To record the outgoing call leg, the routing script (in a "after filter" for example) has to set the following parameter, per route (the decision to record or not, or the file name to record to, can be set per matching route):

# Need to clone the routes in order to have the right to modify them
routes = clone_routes params[:routes]
routes.each do |route|
route[ :record_outgoing ] = ""
end
# Store modified routes back to the parameters for this outgoing call
params[:routes] = routes

=== Record the outgoing call leg within incoming leg's recorded file (mixing) ===
[...]
route[ :record_outgoing ] = "@{MixWithIncoming}"
[...]

=== Choosing file path to record to ===
The value assigned to ":record_incoming" or ":record_outgoing" is the path to record the file to.

The paths can be absolute, or relative. When relative, they are relative to the "tbstreamserver" application working directory, for example:
/lib/tb/toolpack/setup/12358/2.7/apps/tbstreamserver/

* Empty file name will default to a name that contains various information about the call:
** ''LinkId'': Id common between all legs of this call bridge
** ''LegId'': Unique Id for this leg
** ''Nap'': Current NAP name this call leg is from
** ''Direction'': "IN" or "OUT" (depends if call leg is incoming or outgoing leg)
** ''Calling'': The calling number of this call leg
** ''Called'': The called number of this call leg
** ''Protocol'': The signaling protocol of this call leg (SS7, ISDN, CAS, SIP)
** ''Media info'': Codec + IP/Port for SIP calls, Trunk/Timeslot for TDM calls
* To record outgoing call leg in the same audio file as incoming call leg (mixing), use the following:
** @{MixWithIncoming}: Record outgoing legs in same file as incoming legs
* Variables can be used to insert in the recording path information that's not already available from routing scripts:
** @{DefaultName}: Same file name (without parent folder path) as the one used when empty string is provided
*** Example: "73EBA698-F3D67B4B-NAP_SS7-IN-5550000-5550001-SS7-TRUNK_BELL_11-24.wav"
*** Example: "73EBA698-73EBA698-NAP_SIP-OUT-5550000-5550001-SIP-G723-10.3.10.101-1050.wav"
** @{DefaultPath}: Same path as the one used when empty string is provided
*** Example: "/lib/tb/toolpack/setup/12358/recorded_calls/73EBA698-F3D67B4B-NAP_SS7-IN-5550000-5550001-SS7-TRUNK_BELL_11-24.wav"
*** Example: "/lib/tb/toolpack/setup/12358/recorded_calls/73EBA698-73EBA698-NAP_SIP-OUT-5550000-5550001-SIP-G723-10.3.10.101-1050.wav"
** @{LinkId}: Current LinkId (Id common between all legs of this call bridge)
*** Example: "73EBA698"
** And all variables listed here: [[Customer_application_framework:play_audio_files#Helpful_variables_to_build_play_or_record_file_paths|Building play or record file path]]

== Authorization ==
Starting with release 2.7, it is possible to issue RADIUS authorization requests from routing scripts. To do so, the params[:authorization] object must be filled with the required RADIUS attributes and [[#Refuse|an exception must be raised]] with reason :authorization_required.

When the authorization is completed, the routing script is called again with the result. The params[:authorization] object will be filled with the RADIUS attributes from the response. The params[:authorization][:result] field will also contain a string indicating the result of the authorization:

* ''accept'': The authorization was successful.
* ''reject'': The authorization was refused.
* ''challenge'': The authorization was challenged.
* ''timeout'': The authorization was not answered.

== Call diversion options ==
It's possible to control the call flow when a call diversion information is received in the alerting state.

Two fields are available: bridge[ :diversion ] and bridge[ :diversion_reason ]

The internal release cause TOOLPACK_DIVERT_NOT_ALLOWED is used by gateway application to terminate both legs.

bridge[ :diversion ] = :allowed
The alert message will not be analyzed and the call will be progressed. Default behavior.
bridge[ :diversion ] = :not_allowed
If the alert message indicates that the call is diverted, the call will be released no matter the In-band information to allow
early media.
bridge[ :diversion ] = :not_allowed_w_early_media
The call will be released If the alert message indicates that the call is diverted with in-band information to allow early media.
bridge[ :diversion_reason ] = "*"
If the diversion is not allowed, the gateway will drop the call for any redirecting reason.
bridge[ :diversion_reason ] = []
bridge[ :diversion_reason ] << :busy
bridge[ :diversion_reason ] << :unconditional
If the diversion is not allowed, the redirecting reason will be analyzed and the call will only be dropped for the configured cases.

See section [[Routing_script_tutorial:Mini_Development_Guide#Redirecting_number_reason_values|Redirecting number reason values]].

== Call transfer requests ==
Toolpack allows to relay [[Call transfer]] requests from one leg to the other, or to process them locally (making another outgoing call to replace the call that requested the call transfer).

If the chosen [[Call transfer]] mode is to process requests locally, upon reception of a call transfer request (SIP REFER or ISDN Facility), routing script will be called once again, to select the routes for the new outgoing call (call transfer target).

=== How to route call transfer request ===
Routing of a call transfer request is done exactly like routing of a normal incoming call.
The routing script generally does not need any modification to support that.

In some cases, the routing script may want to use information related to the transfer request to perform routing, or to insert information in the outgoing call leg.
Additional information is provided to the routing script, allowing routing decisions using information from the call transfer request (SIP REFER or ISDN Facility).
See below...

=== params[ :call ] content during transfer request ===
When processing a call transfer request, the params[ :call ] hash contains the information from the inbound call (same as was passed to the routing script upon arrival of the inbound call)
call = params[ :call ] -> Information from original inbound call, with exception of call[ :called ]

One exception (convenient because it allows a unmodified routing script to process call transfer request the same way as any other routing request):
call[ :called ] -> Replaced by the called number from the call transfer request (also called "redirection number")
Complementary information:
call[ :original_called_number ] -> Contains the called number that was initially received from the incoming call, prior to call transfer request
call[ :redirecting_number ] -> Number of the call from which the call transfer request was received (generally equals to original_called_number)

These fields will also be included in the outgoing call made after routing:
* original called number and redirecting number are existing fields on SS7 and ISDN calls
* SIP "diversion" header is used for SIP calls

=== params[ :transfer ] content ===
(this if valid only for release 2.7.102 and above) 
When processing a call transfer request, information from the call transfer request message (SIP REFER, ISDN Facility) is provided in params[ :transfer ]:
transfer = params[ :transfer ]
The following field is always present:
transfer[ :original_nap ] -> Contains the NAP of the first call from which a call transfer request was received
transfer[ :redirecting_nap ] -> Contains the NAP of the call from which the current call transfer request was received
(same as :original_nap for the first call transfer, different for subsequent transfers)
Examples of other fields that may be present, when appropriate:
transfer[ :uui ] -> The UUI (user-to-user information) found in the call transfer request
transfer[ :sip_header ] -> Contains custom SIP headers from the call transfer request
transfer[ :request_uri ] -> Contains the SIP Request URI

These field are 'read-only'. They won't be included in the outgoing call, as they represent the content of the call transfer request, not the outgoing call to make.

To insert/modify attributes of the outgoing call, the parameters from params[ :call ] must be edited instead.

== Reason values ==

Check here for Termination Reason Cause codes: 

[[Termination_cause_codes|Termination Reason Cause codes]]
 

Example to refuse an incoming call leg.
raise RoutingException, :no_route

Reason cause strings available inside routing scripts:

List of Q.850 reason causes:
:unallocated_number
:no_route_to_network
:no_route_to_destination
:send_special_tone
:misdialled_trunk_prefix
:channel_unacceptable
:call_awarded_in_established_channel
:preemption
:reattempt
:ported_number
:normal_call_clearing
:user_busy
:no_user_responding
:no_answer_from_user
:subscriber_absent
:call_rejected
:number_changed
:redirection
:exchange_routing_error
:non_selected_user_clearing
:destination_out_of_order
:address_incomplete
:facility_rejected
:response_to_status_enquiry
:normal_unspecified
:no_circuit_available
:network_out_of_order
:frame_mode_out_of_service
:frame_mode_connection_operational
:temporary_failure
:switching_equipment_congestion
:access_information_discarded
:requested_circuit_not_available
:precedence_call_blocked
:resource_unavailable
:quality_of_service_not_available
:requested_facility_not_subscribed
:outgoing_calls_barred
:outgoing_calls_barred_within_cug
:incoming_calls_barred
:incoming_calls_barred_within_cug
:bearer_cap_not_authorized
:bearer_cap_not_available
:inconsistency_access_info
:service_not_available
:bearer_cap_not_implemented
:channel_type_not_implemented
:requested_facility_not_implemented
:only_restricted_digital_info
:service_not_implemented
:invalid_call_reference
:channel_does_not_exist
:call_identity_does_not_exist
:call_identity_in_use
:no_call_suspended
:call_has_been_cleared
:user_not_member_of_cug
:incompatible_destination
:non_existant_cug
:invalid_transit_network
:invalid_message_unspecified
:mandatory_ie_missing
:message_type_non_existent
:not_compatible_with_call_state
:ie_non_existent
:invalid_ie_content
:message_not_compatible
:recovery_on_timer_expiry
:parameter_non_existent_passed_on
:msg_with_non_recognized_param_discarded
:protocol_error
:interworking_unspecified

List of toolpack reason causes:

:toolpack_normal or :normal
:toolpack_resource_error or :resource_error
:toolpack_timeout or :timeout
:toolpack_no_route or :no_route
:toolpack_call_collision or :call_collision
:toolpack_sync_drop or :sync_drop
:toolpack_signaling_error or :signaling_error
:toolpack_locally_rejected or :locally_rejected
:toolpack_interface_not_available or :interface_not_available
:toolpack_reset_in_progress or :reset_in_progress
:toolpack_adapter_reject or :adapter_reject
:toolpack_missing_or_invalid_ie or :missing_or_invalid_ie
:toolpack_incoming_only or :incoming_only
:toolpack_system_configuration_changed or :system_configuration_changed
:toolpack_resource_no_more_available or :resource_no_more_available
:toolpack_incompatible_media or :incompatible_media
:toolpack_resource_allocation_failed or :resource_allocation_failed
:toolpack_data_path_not_available or :data_path_not_available
:toolpack_local_congestion or :local_congestion
:toolpack_authorization_required or :authorization_required
:toolpack_call_divert_is_not_allowed or :call_divert_is_not_allowed

List of SIP reason causes:

:400_bad_request
:401_unauthorized
:402_payment_required
:403_forbidden
:404_not_found
:405_method_not_allowed
:406_not_acceptable
:407_proxy_authentication_required
:408_request_timeout
:409_conflict
:410_gone
:413_request_entity_too_large
:414_request_URI_too_long
:415_unsupported_media
:416_unsupported_URI_scheme
:420_bad_extension
:421_extension_required
:422_session_timer_too_small
:423_interval_too_brief
:429_referrer_identity_error
:480_temporary_unavailable
:481_call_or_transaction_does_not_exist
:482_loop_detected
:483_too_many_hops
:484_address_incomplete
:485_ambiguous
:486_busy_here
:487_request_terminated
:488_not_acceptable_here
:489_bad_event
:491_retry_after
:500_server_internal_error
:501_not_implemented
:502_bad_gateway
:503_service_unavailable
:504_server_timeout
:505_version_unsupported
:513_message_too_large
:600_busy_everywhere
:603_decline
:604_not_exist_anywhere
:606_not_acceptable

== Nap status ==

All the status fields of the NAPs are provided for use by the routing scripts. See the nap status provider for more details on which fields are available in the CEngineStatTransNap.hpp file.

'''Notice:''' These values may change between major release.

Routing script call attribute name Description
--------------------------------------------------------------------------------------------
"signaling_type" Signaling type.
"inst_incoming_call_cnt" Instantaneous Count of incoming calls.
"inst_outgoing_call_cnt" Instantaneous Count of outgoing calls.
"available_cnt" Number of available circuits or channels.
"unavailable_cnt" Number of unavailable circuits or channels.
"availability_percent" Percentage of available circuits or channels.
"usage_percent" Percentage of used circuits or channels.
"unused_shared_percent" Percentage of used circuits or channels of this NAP available to make new calls with (taking into account shared with other NAPs)
"total_incoming_call_cnt" Total Count of incoming calls.
"asr_statistics_struct" Detailed Answer-Seizure Rate Statistics.
"global_asr_percent" Global calculated ASR percentage.
"total_outgoing_call_cnt" Total Count of outgoing calls.
"last_24h_asr_percent" Last 24 hours calculated ASR percentage.
"last_24h_outgoing_call_cnt" Last 24 hours outgoing calls.
"current_hour_asr_percent" Current hour calculated ASR percentage.
"current_hour_outgoing_call_cnt" Current hour outgoing calls.
"last_hour_asr_percent" Last hour calculated ASR percentage.
"last_hour_outgoing_call_cnt" Last hour outgoing calls.
"availability_detection_struct" Detailed availibility detection Statistics
"poll_remote_proxy" Remote proxy polling enabled
"is_available" Remote proxy actually available or not
"time_since_polling" Time since the last availibility polling
"time_available_seconds" Number of seconds since the NAP is available
"time_unavailable_seconds" Number of seconds since the NAP is unavailable
"registration_struct" Detailed registration Statistics
"register_to_proxy" Register to proxy enabled
"registered" Actually registered or not
"time_since_refresh" Time since the last refresh
"time_registered_seconds" Number of seconds since the NAP is registered
"time_not_registered_seconds" Number of seconds since the NAP is not registered

 If the nap status is part of a substructure, it's name in the routing scripts must be composed of the structure name appended by an underscore and the field name.

For example the name to use for the global [[ASR]] percentage is:

asr_statistics_struct_global_asr_percent

 It is also possible to add dynamic nap attributes in the web portal. These can be referenced by their name.

== Routing Script Tests ==
The Web portal features a tool for Testing Scripts. The user must enter parameters to simulate the incoming call and after pressing the Test button, will output selected routes and numbers. You do not need to activate the new routes, or the new scripts to use this test tool: It can be used to test the routing scripts and routing table before activating it.
This is available in the Routing Scripts section of the Web portal.

=== Test parameters ===
==== @call_params ====

That variable should contain a hash of call parameters that will passed to the routing script. This is equivalent to the incoming call parameters.

 

==== @nap_list ====

A list of hash containing the nap statuses. This is equivalent to the nap statuses at the time the call is to be routed.

'''The nap list is hashed by the nap names in UPPERCASE.''' It is important to consider this when creating new dynamic route or nap attributes that may nap names that will be used to fetch a status.

 

==== @params ====

A hash of hashes containing parameters. This hash contains bridge parameters and other kind of parameter groups may be added in the future.

Example: @params = {:bridge => {:announcement_tone, "announcement.wav"}}

 

----

 Back to [[Routing script tutorial|Routing Script Tutorial]].

[[category:Needs revising]]

Routing script tutorial:Mini Development Guide

2014-01-17T15:20:55Z

Manon Bélanger: /* Script parameters protocol mapping */

== Call object ==

=== Get ===

Those function are used to get the call parameters. The possible parameters are described in the section "Call parameters"

called_number = caf_call.get :called

=== List_params ===

This function is used to retrieve the list of supported call parameters. For example to extract all the possible call params from the the call object and put it in hash.

caf_call.list_params.each {|param| call[param] = caf_call.get param }

=== Accept ===

This function is used to accept a call. It actually creates one outgoing route that gateway application will use to bridge the incoming call leg. If more than one outgoing route is "accepted", gateway will try them one by one in the same order they were accepted. If an outgoing call leg fails (according to 'route retry' parameters), the next route in line will be used.

This method takes 2 arguments, the call parameters (hash) and the route parameters (hash). Note that calling this method does NOT stop the flow of the script.

Apply route remapping rules

caf_call.accept out_call, route

=== Refuse ===

This function is used to set the reason code for the incoming call leg refusal. However, this function does NOT stop the flow of the script.

caf_call.refuse :reason => :temporary_failure

To immediately refuse the incoming call leg and stop processing the script, the script must raise an exception. Exiting the script by raising the exception overwrites any reason cause previously stored using refuse().

raise RoutingException, :no_route

The supported refusal cause values for both refuse() and raise() are described in the section "Reason values".

=== Script parameters protocol mapping ===

The following call parameters are available in the call object:

{| cellspacing="1" cellpadding="1" border="1" style="width: 921px; height: 805px;"
|-
! scope="col" | '''Script parameter name'''
! scope="col" | '''ISDN '''
! scope="col" | '''R2 CAS''' 
! scope="col" | '''SS7 '''
! scope="col" | '''SIP '''
! scope="col" | '''Comment '''
! scope="col" | '''Toolpack version '''
|-
| leg_id 
| N/A 
| N/A 
| N/A 
| N/A 
| Leg ID 
| 
|-
| session_id 
| N/A 
| N/A 
| N/A 
| N/A 
| Session ID 
| 
|-
| calling 
| Q931: 'Calling party number' IE - Number digits 
| ANI (Group B) 
| Q763: 'Calling party number' IE - address signals (*) 
| SIP:From - user-info 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead. 
| 
|-
| calling_noa 
| Q931: 'Calling party number' IE - Type of number 
| N/A 
| Q763: 'Calling party number' IE - nature of address indicator (*) 
| N/A 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead 
| 
|-
| calling_npi 
| Q931: 'Calling party number' IE - Numbering plan identification 
| N/A 
| Q763: 'Calling party number' IE - numbering plan indicator (*) 
| N/A 
| * In ANSI SS7 LNP networks, the IE 'generic address parameter' is used (when present) instead 
| 
|-
| calling_display 
| Q931: 'Display' IE - Display information 
Q931: 'Facility CNAM' IE when presentation is allowed for DMS/NI2 variants 
| N/A 
| Q763: 'Display information' IE - display information 
| SIP:From - display-name 
| 
| 
|-
| calling_display_type 
| Q931: 'Display' IE - Display information (present and/or first byte) 
| N/A 
| Q763: 'Display information' IE - present or not 
| N/A 
| 
| 
|-
| calling_presentation 
| Q931: 'Calling party number' IE - Presentation indicator 
| N/A 
| Q763: 'Calling party number' IE - address presentation restricted indicator 
|
SIP:From - display-name (displays 'anonymous' or not)

SIP:Remote-party-id - privacy 

| 
| 
|-
| calling_screening 
| Q931: 'Calling party number' IE - Screening indicator 
| N/A 
| Q763: 'Calling party number' IE - screening 
| SIP:Remote-party-id - screen 
| 
| 
|-
| calling_category 
| N/A 
| Call party category (Group A) 
| Q763: 'Calling party's category' IE - calling party's category 
|
SIP:From - cpc

SIP:P-asserted-identity - cpc 

| 
| 
|-
| calling_subscriber
(Generic Number / NDS) 
| Q931: 2nd 'Calling party number' IE - Number digits 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - Number digits 
|
SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| Requires option 'support 2 calling number IE' in the profile. This variable has priority over 'private_address' in the outgoing direction. 
| 
|-
| calling_subscriber_noa 
| Q931: 2nd 'Calling party number' IE - Type of number 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - nature of address indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| calling_subscriber_npi 
| Q931: 2nd 'Calling party number' IE - Numbering plan identification 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - numbering plan indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
 
| 
|-
| calling_subscriber_presentation 
| Q931: 2nd 'Calling party number' IE - Presentation indicator 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - presentation restricted indicator 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| calling_subscriber_screening 
| Q931: 2nd 'Calling party number' IE - Screening indicator 
| N/A 
| Q763: Generic number IE with type 'additional calling party number' - screening 
| SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 
| 
| 
|-
| private_display 
| Q931: 'Facility CNAM' IE when presentation is restricted for DMS/NI2 variants 
| N/A 
| N/A 
|
SIP:P-asserted-identity - display-name 

SIP:Remote-party-id - display-name 

| 
| 
|-
| private_display_type 
| N/A 
| N/A 
| N/A 
| N/A 
| Indicate presence or not of the private calling information 
| 
|-
| private_address 
| N/A 
| N/A 
| N/A 
|
SIP:P-asserted-identity - userinfo

SIP:Remote-party-id - user-info 

| 
| 
|-
| called 
| Q931: 'Called party number' IE - Number digits 
| DNIS (Group A) 
| Q763: 'Called party number' IE - address signals 
| SIP:To - user-info and host 
| 
| 
|-
| called_noa 
| Q931: 'Called party number' IE - Type of number 
| N/A 
| Q763: 'Called party number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| called_npi 
| Q931: 'Called party number' IE - Numbering plan identification 
| N/A 
| Q763: 'Called party number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| charge_number 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - address signals 
| N/A 
| 
| 
|-
| charge_number_noa 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| charge_number_npi 
| N/A 
| N/A 
| ANSI: 'Charge number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| redirecting_number_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default redirecting number and original called number forwarding behavior from incoming to outgoing leg 
| 
|-
| redirecting_number 
| Q931: 'Redirecting number' 1st IE - Number digits 
| N/A 
| Q763: 'Redirecting number' IE - address signals 
| SIP:Diversion (2nd header) - display-name 
| 
| 
|-
| redirecting_number_noa 
| Q931: 'Redirecting number' 1st IE - Type of number 
| N/A 
| Q763: 'Redirecting number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| redirecting_number_npi 
| Q931: 'Redirecting number' 1st IE - Numbering plan identification 
| N/A 
| Q763: 'Redirecting number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| redirecting_number_presentation 
| Q931: 'Redirecting number' 1st IE - Presentation indicator 
| N/A 
| Q763: 'Redirecting number' IE - address presentation restricted indicator 
| SIP:Diversion (2nd header) - diversion-privacy 
| 
| 
|-
| redirecting_number_indicator 
| N/A 
| N/A 
| Q763: 'Redirection information' IE - redirecting indicator 
| N/A 
| 
| 
|-
| redirecting_number_reason 
| Q931: 'Redirecting number' 1st IE - Reason for redirection 
| N/A 
| Q763: 'Redirection information' IE - redirecting reason 
| SIP:Diversion (2nd header) - diversion-reason 
| 
| 
|-
| redirecting_number_counter 
| N/A 
| N/A 
| Q763: 'Redirection information' IE - redirection counter 
| SIP:Diversion (2nd header) - diversion-counter 
| 
| 
|-
| original_called_number
(OCN) 
| Q931: 'Redirecting number' 2nd IE - Number digits 
| N/A 
| Q763: 'Redirection number' IE - address signals 
| SIP:Diversion  (1st header) - display-name 
| 
| 
|-
| original_called_number_noa 
| Q931: 'Redirecting number' 2nd IE - Type of number 
| N/A 
| Q763: 'Redirection number' IE - nature of address indicator 
| N/A 
| 
| 
|-
| original_called_number_npi 
| Q931: 'Redirecting number' 2nd IE - Numbering plan identification 
| N/A 
| Q763: 'Redirection number' IE - numbering plan indicator 
| N/A 
| 
| 
|-
| original_called_number_presentation 
| Q931: 'Redirecting number' 2nd IE - Presentation indicator 
| N/A 
| Q763: 'Redirection number' IE - address presentation restricted indicator 
| SIP:Diversion (1st header) - diversion-privacy 
| 
| 
|-
| original_called_number_reason 
| Q931: 'Redirecting number' 2nd IE - Reason for redirection 
| N/A 
| Q763: 'Redirection information' IE - original redirection reason 
| SIP:Diversion (1st header) - diversion-reason 
| 
| 
|-
| original_called_number_counter 
| N/A 
| N/A 
| N/A 
| SIP:Diversion (1st header) - diversion-counter 
| 
| 
|-
| ported_number 
| N/A 
| N/A 
| Q763: 'Called party number' IE - address signals 
| SIP:RequestURI - rn 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| ported_number_noa 
| N/A 
| N/A 
| Q763: 'Called party number' IE - nature of address indicator 
| N/A 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| ported_number_npi 
| N/A 
| N/A 
| Q763: 'Called party number' IE - numbering plan indicator 
| N/A 
| Only valid if SIP/SS7 supports LNP 
| 
|-
| oli
(Originating line information) 
| 5ESS Codeset 6 OLI - Value 
| N/A 
| ANSI: 'Originating line information' IE - OLI 
|
SIP:From - oli

SIP:P-asserted-identity - oli 

| 
| 
|-
| request_uri 
| N/A 
| N/A 
| N/A 
| Complete Request URI string 
| 
| 
|-
| request_uri_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default URI forwarding behavior from incoming to outgoing leg 
| 
|-
| sip_header 
| N/A 
| N/A 
| N/A 
| Any header 
| Requires option 'Forward custom headers' in Profiles->SIP 
| 2.7.63 
|-
| nap
(Network Access Point) 
| N/A 
| N/A 
| N/A 
| N/A 
| Incoming leg NAP name (read-only) 
| 
|-
| type_of_network_identification 
| Q931: 'Transit network selection' IE - Type of network identification 
| N/A 
| Q763: 'Transit network selection' IE - Type of network identification 
| N/A 
| 
| 2.7 
|-
| network_identification 
| Q931: 'Transit network selection' IE - Network identification 
| N/A 
| Q763: 'Transit network selection' IE - Network identification 
| SIP: Request-Line - cic 
| 
| 2.7 
|-
| network_identification_plan 
| Q931: 'Transit network selection' IE - Network identification plan 
| N/A 
| Q763: 'Transit network selection' IE - Network identification plan 
| N/A 
| 
| 2.7 
|-
| location_number_forward_enabled 
| N/A 
| N/A 
| N/A 
| N/A 
| Overwrite default location number forwarding behavior from incoming to outgoing leg 
| 2.7 
|-
| location_number 
| N/A 
| N/A 
| Q763: 'Location number' IE - address signals 
| N/A 
| 
| 2.7 
|-
| location_number_noa 
| N/A 
| N/A 
| Q763: 'Location number' IE - nature of address indicator 
| N/A 
| 
| 2.7 
|-
| location_number_npi 
| N/A 
| N/A 
| Q763: 'Location number' IE - numbering plan indicator 
| N/A 
| 
| 2.7 
|-
| location_number_presentation 
| N/A 
| N/A 
| Q763: 'Location number' IE - presentation restricted indicator 
| N/A 
| 
| 2.7 
|-
| location_number_screening 
| N/A 
| N/A 
| Q763: 'Location number' IE - screening 
| N/A 
| 
| 2.7 
|}

 

'''Notice:''' All values are documented in the '''noa_npi_remap.rb''' script and may change between major release.

=== Noa values ===

*<tt>unknown_number (0x2)</tt>
*<tt>international_number (0x4)</tt>
*<tt>national_number (0x3)</tt>
*<tt>subscriber_number (0x1)</tt>
*<tt>network_specific (0x5)</tt>
*<tt>network_routing_national_format (0x7)</tt>
*<tt>network_routing_international_format (0x8)</tt>
*<tt>abbreviated_number (0x6)</tt>
*<tt>subscriber_number_operator_requested (0x71)</tt>
*<tt>national_number_operator_requested (0x72)</tt>
*<tt>international_number_operator_requested (0x73)</tt>
*<tt>no_number_present_operator_requested (0x74)</tt>
*<tt>no_number_present_cut_through_call_to_carrier (0x75)</tt>
*<tt>test_line_test_code (0x77)</tt>
*<tt>non_unique_subscriber_number (0x71)</tt>
*<tt>non_unique_national_number (0x73)</tt>
*<tt>non_unique_international_number (0x74)</tt>
*<tt>call_950_numbe (0x76)</tt>
*<tt>special_number (0x73)</tt>
*<tt>national_number_with_transit_network_selection (0x74)</tt>
*<tt>international_number_with_transit_network_selection (0x75)</tt>

Those values will be remapped to the protocol specific NOA value. To provide protocol specific value:

*<tt>call_params[:called_noa] = 0x70</tt>

or

*<tt>call_params[:called_noa] = 112</tt>

=== Npi values ===

*<tt>unknown_number</tt>
*<tt>isdn</tt>
*<tt>telephony</tt>
*<tt>private</tt>
*<tt>data</tt>
*<tt>telex</tt>
*<tt>national</tt>

=== Calling Display Type values ===

*<tt>unspecified</tt> => Type is unspecified.
*<tt>calling_party_name</tt> => Type is 0xB1.

Those values will be remapped to the protocol specific Display Information Type value. To provide protocol specific value:

*<tt>call_params[:calling_display_type] = 0xB1</tt>

or

*<tt>call_params[:calling_display_type] = 177</tt>

=== Calling Display value ===

*<tt>call_params[:calling_display] = "Roger Fluffy"</tt>

=== Presentation values ===

*<tt>unspecified</tt>
*<tt>not_available (0x2)</tt>
*<tt>allowed (0x0)</tt>
*<tt>restricted (0x1)</tt>
*<tt>addr_restricted</tt>
*<tt>name_restricted</tt>

=== Calling Party Category ===
values for calling_category
*<tt>unspecified</tt> <tt>(0xa)</tt>
*<tt>unknown</tt> <tt>(0x0)</tt>
*<tt>operator_french</tt> <tt>(0x1)</tt>
*<tt>operator_english</tt> <tt>(0x2)</tt>
*<tt>operator_german</tt> <tt>(0x3)</tt>
*<tt>operator_russian</tt> <tt>(0x4)</tt>
*<tt>operator_spanish</tt> <tt>(0x5)</tt>
*<tt>subscriber</tt> <tt>(0xa)</tt>
*<tt>subscriber_with_priority</tt> <tt>(0xb)</tt>
*<tt>data</tt> <tt>(0xc)</tt>
*<tt>test</tt> <tt>(0xd)</tt>
*<tt>payphone</tt> <tt>(0xf)</tt>

=== Screening values ===

*<tt>unspecified</tt>
*<tt>no (0x0)</tt>
*<tt>pass (0x1)</tt>
*<tt>fail (0x2)</tt>
*<tt>network_provided (0x3)</tt>

=== Redirecting indicator values ===

SS7:

*<tt>no_redirection</tt>
*<tt>call_rerouted</tt>
*<tt>call_rerouted_all_restricted</tt>
*<tt>call_diverted</tt>
*<tt>call_diverted_all_restricted</tt>
*<tt>call_rerouted_restricted</tt>
*<tt>call_diverted_restricted</tt>
*<tt>spare</tt>

=== Redirecting number reason values ===

ISDN:

*<tt>unknown</tt>
*<tt>busy</tt>
*<tt>no_reply</tt>
*<tt>deflection</tt>
*<tt>dte_out_of_order</tt>
*<tt>forwarding_by_called_dte</tt>
*<tt>unconditional</tt>

SS7:

*<tt>unknown</tt>
*<tt>busy</tt>
*<tt>no_reply</tt>
*<tt>unconditional</tt>
*<tt>deflection</tt>
*<tt>deflection_immediate</tt>
*<tt>mobile_not_reachable</tt>

=== OLI (originating line information) values ===

The OLI parameter is a string that represents an integer value from 0 to 255.

 

=== redirecting_number_forward_enabled values ===

Controls forwarding or discarding of redirecting number (SIP: diversion header) to outgoing call leg.

Values for this parameter are "0", "1", "false" or "true. 0/false: Redirecting number (and original called number) is not forwarded to outgoing call leg 1/true: Redirecting number (and original called number) is forwarded to outgoing call leg The value for this parameter at input of routing script depends on the "Forward redirecting number" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

 

=== request_uri ===

Enables access to the Request-Line URI. 

For example, if the Request-Line is:
<pre>Request-Line: INVITE sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0</pre>
Then the retrieved request_uri will be "sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0". 

In the routing scripts, to retrieve only the called number, this script can be used: 
<pre> if call_params[:request_uri] && call_params[:request_uri] =~ /sip:(.*)@.*/
call_params[:called] = $1
end
</pre>
=== request_uri_forward_enabled values ===

Controls forwarding or discarding of request uri to outgoing call leg.The request uri is the information in the "Request-Line:" of the SIP INVITE message. 

Values for this parameter are "0", "1", "false" or "true. 

0/false: Request uri is not forwarded to outgoing call leg 

1/true: Request uri is forwarded to outgoing call leg 

The value for this parameter at input of routing script is always false. 

=== sip_header values ===
Contains a hash table of custom sip headers from the inbound call leg. Any custom sip header can be added to an outgoing call leg: 

<pre>call[ :sip_header ] = {"P-my-custom-header"=>"value1", "P-my-custom-header2"=>"value2", "P-my-custom-header3"=>"value3"}</pre>

* PCAP sample: [[File:TB_Custom_SIP_Headers.pap]]

List of sip headers that will not appear in call[:sip_header] since they are already processed by the SIP stack:
<pre>
Accept Error-Info Remote-Party-ID
Accept-Contact Event Replaces
Accept-Encoding Expires Reply-To
Accept-Language From Request-Disposition
Alert-Info In-Reply-To Subject
Allow Max-Forwards Subscription-State
Allow-Events MIME-version Supported
Also Min-Expires Timestamp
Anonymity Min-SE To
Authorization Organization Unsupported
Authentication-Info Path User-Agent
Call-ID Priority Via
Call-Info Privacy Warning
Contact Proxy-Authenticate WWW-Authenticate
Content-Disposition Proxy-Authorization Require
Content-Encoding Proxy-Require Response-Key
Content-Language P-Media-Authorization Retry-After
Content-Length P-Preferred-Identity RPID-Privacy
Content-Type P-Asserted-Identity Route
CSeq RAck RSeq
RAck Reason Security-Client
Reason Record-Route Security-Server
Date Refer-To Security-Verify
Diversion Referred-By Server
Encryption Reject-Contact Service-Route
Session-Expires
</pre>

== Route parameters ==

All route may have these parameters:

*calling
*called
*nap
*remapped_calling
*remapped_called
*remapped_nap
*remapped_profile

Additionally it is possible to add dynamic route attributes in the web portal. These can be referenced by their name.

== Playing prompts announcements or tones ==

New feature in release 2.6, all bridges may have these parameters. These can be used to play IVR prompts or wav files in different states of the call flow, like playing an announcement when the caller dials in. You can also manage the User to User information element.

*announcement_tone
*call_progress_tone
*ring_tone
*max_call_duration
*call_duration_reason
*disconnect_tone
*uui
*uui_forward_enabled

The following sections show how to access those different parameters from '''inside''' a filter. The 'params' hash is the sole argument passed to a filter function and contains call, nap, route and bridge parameters. This hash is created by the base_routing.rb scripts to regroup all relevant information just before calling the filter functions.

=== Tone string format ===

All tone strings (:announcement_tone, :call_progress_tone, :ring_tone, :disconnect_tone) inside bridge parameters are using this format.
<pre>"file1.wav:repeat:start_off:end_off,file2.wav:repeat:start_off:end_off,file3.wav:repeat:start_off:end_off"
</pre>
optional repeat parameter: number of times to play the file (0 and 1 have the same result) optional start_off parameter : Start offset in milliseconds optional end_off parameter: End offset in milliseconds Example: "file1.wav,file2.wav:-1" will play file1.wav one time and then play file2.wav in loop. Example: "file1.wav:0:1000:3000,file2.wav:2:5000:10000" will play file1.wav from second 1 to second 3 then file2.wav from second 5 to second 10 two times. Example: "file1.wav:0:0:30000" will play file1.wav one time for a max duration of 30 seconds.

=== announcement_tone ===

params[:bridge][:announcement_tone] = "announcement.wav"

Prompt played on the incoming leg with the stream_server before any outgoing call is placed. The outgoing call occurs when the wav file is completed or when the "profile:Busy Tone max duration" is reached.

Options:
==== announcement_tone_answer ====
params[:bridge][:announcement_tone_answer] = "yes"

Answer the call before playing the announcement. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== call_progress_tone ===

params[:bridge][:call_progress_tone] = "no_route.wav"

Prompt played after "announcement_tone" when reason is not "ok" or when outgoing call disconnect before answer state. "none" value is used to bypass "profile:Generate Busy (Congestion) Tone" and to play no audio prompt.

==== call_progress_tone_answer ====
params[:bridge][:call_progress_tone_answer] = "yes"

Answer the call before playing the call progress tone. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== ring_tone ===

params[:bridge][:ring_tone] = "ringing.wav"

Prompt played between alerting state and answer state. Bypass any other ring back tone (RBT) configured in profile.

=== max_call_duration ===

params[:bridge][:max_call_duration] = "60000"

Maximum call duration in millisecond for the current bridge. This timer is started when entering answer state.

=== call_duration_reason ===

params[:bridge][:call_duration_reason] = :resource_unavailable

Drop both legs with this reason when call duration (:max_call_duration) is reached.

=== disconnect_tone ===

params[:bridge][:disconnect_tone] = "max_duration.wav"

Prompt played (on the incoming leg only) when call duration (:max_call_duration) is reached. Then the leg will be terminated with specified reason (:call_duration_reason).

==== disconnect_tone_answer ====
params[:bridge][:disconnect_tone_answer] = "yes"

Answer the call before playing the disconnect tone. Default if argument not provided is "no", in which case call is only alerted with in-band media.

=== UUI (user-to-user indication) values ===

Byte array represented as ruby String. Use ''bridge=params[:bridge]'', then ''bridge[:uui]'' to access the data.

To access the bytes in Ruby, use ruby String operator []. For example: bridge[:uui][0] will return the binary value of the first UUI byte.

Function each_byte can also be useful to iterate through all bytes of the UUI.

=== uui_forward_enabled values ===

Controls forwarding or discarding of UUI to outgoing call leg.

Values for this parameter are "0", "1", "false" or "true. 0/false: UUI is not forwarded to outgoing call leg 1/true: UUI is forwarded to outgoing call leg The value for this parameter at input of routing script depends on the "Forward UUI" parameter in the "Advanced" section of the Gateway configuration page of the Web Portal. The script may change this value to override the Gateway configuration.

=== Managing audio prompts through Web Portal ===
Audio prompts can be uploaded or deleted from the TMedia unit through the Web Portal:
[[Toolpack:Configuring_Audio_Prompts_A|Managing audio prompts]]

Prompts management must be done using the Web Portal of the primary server (in systems with redundant TMedia units or redundant host servers).
The file will automatically get replicated to the secondary server.

=== Managing audio prompts manually ===
Any file on the TMedia host file system can be played. This means it's possible to manage prompts through ssh/scp.

Provided paths are always relative to the "current working directory" of the tbstreamserver application:
/lib/tb/toolpack/setup/12358/2.7/apps/tbstreamserver/
(Where "2.7" may be replaced by the current major version of your system)

Absolute paths can also be provided.

== Recording call legs ==
Introduced in release 2.6.44, it's now possible to use routing scripts to ask for recording incoming and/or outgoing call legs.

See example filter script "call_recording" (created by default in Web Portal routing scripts starting with 2.6.44) for an example.

=== Recording the incoming call leg ===
To record the incoming call leg, the routing script (in a "after filter" for example) has to set the following parameter:

bridge[ :record_incoming ] = ""

=== Recording the outgoing call leg ===
To record the outgoing call leg, the routing script (in a "after filter" for example) has to set the following parameter, per route (the decision to record or not, or the file name to record to, can be set per matching route):

# Need to clone the routes in order to have the right to modify them
routes = clone_routes params[:routes]
routes.each do |route|
route[ :record_outgoing ] = ""
end
# Store modified routes back to the parameters for this outgoing call
params[:routes] = routes

=== Record the outgoing call leg within incoming leg's recorded file (mixing) ===
[...]
route[ :record_outgoing ] = "@{MixWithIncoming}"
[...]

=== Choosing file path to record to ===
The value assigned to ":record_incoming" or ":record_outgoing" is the path to record the file to.

The paths can be absolute, or relative. When relative, they are relative to the "tbstreamserver" application working directory, for example:
/lib/tb/toolpack/setup/12358/2.7/apps/tbstreamserver/

* Empty file name will default to a name that contains various information about the call:
** ''LinkId'': Id common between all legs of this call bridge
** ''LegId'': Unique Id for this leg
** ''Nap'': Current NAP name this call leg is from
** ''Direction'': "IN" or "OUT" (depends if call leg is incoming or outgoing leg)
** ''Calling'': The calling number of this call leg
** ''Called'': The called number of this call leg
** ''Protocol'': The signaling protocol of this call leg (SS7, ISDN, CAS, SIP)
** ''Media info'': Codec + IP/Port for SIP calls, Trunk/Timeslot for TDM calls
* To record outgoing call leg in the same audio file as incoming call leg (mixing), use the following:
** @{MixWithIncoming}: Record outgoing legs in same file as incoming legs
* Variables can be used to insert in the recording path information that's not already available from routing scripts:
** @{DefaultName}: Same file name (without parent folder path) as the one used when empty string is provided
*** Example: "73EBA698-F3D67B4B-NAP_SS7-IN-5550000-5550001-SS7-TRUNK_BELL_11-24.wav"
*** Example: "73EBA698-73EBA698-NAP_SIP-OUT-5550000-5550001-SIP-G723-10.3.10.101-1050.wav"
** @{DefaultPath}: Same path as the one used when empty string is provided
*** Example: "recorded_calls/73EBA698-F3D67B4B-NAP_SS7-IN-5550000-5550001-SS7-TRUNK_BELL_11-24.wav"
*** Example: "recorded_calls/73EBA698-73EBA698-NAP_SIP-OUT-5550000-5550001-SIP-G723-10.3.10.101-1050.wav"
** @{LinkId}: Current LinkId (Id common between all legs of this call bridge)
*** Example: "73EBA698"
** @{LegId}: Current LegId (Unique Id for this leg)
*** Example: "F3D67B4B"
** @{Protocol}: Protocol type of current leg
*** Example: "SS7"
** @{Direction}: Direction of current leg (IN our OUT)
*** Example: "IN"
** @{PKG_HOME}: Path where packages are stored. Note: It's not recomended to use that path on redundant systems, package file replication may cause confusion in recorded files.
*** Example: "/lib/tb/toolpack/pkg"
** @{CURRENT_PKG}: Version of current package
*** Example: "2.6.45"
** @{PROMPT_PATH}: Default path where audio prompts are stored. Note: It's not recomended to use that path on redundant systems, package file replication may cause confusion in recorded files.
*** Example: "/lib/tb/toolpack/pkg/prompts"
** @{TBX_GW_PORT}: Current "System Id" (also called "Gateway Port")
*** Example: "12358"

== Authorization ==
Starting with release 2.7, it is possible to issue RADIUS authorization requests from routing scripts. To do so, the params[:authorization] object must be filled with the required RADIUS attributes and [[#Refuse|an exception must be raised]] with reason :authorization_required.

When the authorization is completed, the routing script is called again with the result. The params[:authorization] object will be filled with the RADIUS attributes from the response. The params[:authorization][:result] field will also contain a string indicating the result of the authorization:

* ''accept'': The authorization was successful.
* ''reject'': The authorization was refused.
* ''challenge'': The authorization was challenged.
* ''timeout'': The authorization was not answered.

== Call diversion options ==
It's possible to control the call flow when a call diversion information is received in the alerting state.

Two fields are available: bridge[ :diversion ] and bridge[ :diversion_reason ]

The internal release cause TOOLPACK_DIVERT_NOT_ALLOWED is used by gateway application to terminate both legs.

bridge[ :diversion ] = :allowed
The alert message will not be analyzed and the call will be progressed. Default behavior.
bridge[ :diversion ] = :not_allowed
If the alert message indicates that the call is diverted, the call will be released no matter the In-band information to allow
early media.
bridge[ :diversion ] = :not_allowed_w_early_media
The call will be released If the alert message indicates that the call is diverted with in-band information to allow early media.
bridge[ :diversion_reason ] = "*"
If the diversion is not allowed, the gateway will drop the call for any redirecting reason.
bridge[ :diversion_reason ] = []
bridge[ :diversion_reason ] << :busy
bridge[ :diversion_reason ] << :unconditional
If the diversion is not allowed, the redirecting reason will be analyzed and the call will only be dropped for the configured cases.

See section [[Routing_script_tutorial:Mini_Development_Guide#Redirecting_number_reason_values|Redirecting number reason values]].

== Reason values ==

Check here for Termination Reason Cause codes: 

[[Termination_cause_codes|Termination Reason Cause codes]]
 

== Nap status ==

All the status fields of the NAPs are provided for use by the routing scripts. See the nap status provider for more details on which fields are available in the CEngineStatTransNap.hpp file.

'''Notice:''' These values may change between major release.

Routing script call attribute name Description
--------------------------------------------------------------------------------------------
"signaling_type" Signaling type.
"inst_incoming_call_cnt" Instantaneous Count of incoming calls.
"inst_outgoing_call_cnt" Instantaneous Count of outgoing calls.
"available_cnt" Number of available circuits or channels.
"unavailable_cnt" Number of unavailable circuits or channels.
"availability_percent" Percentage of available circuits or channels.
"usage_percent" Percentage of used circuits or channels.
"unused_shared_percent" Percentage of used circuits or channels of this NAP available to make new calls with (taking into account shared with other NAPs)
"total_incoming_call_cnt" Total Count of incoming calls.
"asr_statistics_struct" Detailed Answer-Seizure Rate Statistics.
"global_asr_percent" Global calculated ASR percentage.
"total_outgoing_call_cnt" Total Count of outgoing calls.
"last_24h_asr_percent" Last 24 hours calculated ASR percentage.
"last_24h_outgoing_call_cnt" Last 24 hours outgoing calls.
"current_hour_asr_percent" Current hour calculated ASR percentage.
"current_hour_outgoing_call_cnt" Current hour outgoing calls.
"last_hour_asr_percent" Last hour calculated ASR percentage.
"last_hour_outgoing_call_cnt" Last hour outgoing calls.
"availability_detection_struct" Detailed availibility detection Statistics
"poll_remote_proxy" Remote proxy polling enabled
"is_available" Remote proxy actually available or not
"time_since_polling" Time since the last availibility polling
"time_available_seconds" Number of seconds since the NAP is available
"time_unavailable_seconds" Number of seconds since the NAP is unavailable
"registration_struct" Detailed registration Statistics
"register_to_proxy" Register to proxy enabled
"registered" Actually registered or not
"time_since_refresh" Time since the last refresh
"time_registered_seconds" Number of seconds since the NAP is registered
"time_not_registered_seconds" Number of seconds since the NAP is not registered

 If the nap status is part of a substructure, it's name in the routing scripts must be composed of the structure name appended by an underscore and the field name.

For example the name to use for the global [[ASR]] percentage is:

asr_statistics_struct_global_asr_percent

 It is also possible to add dynamic nap attributes in the web portal. These can be referenced by their name.

== Test parameters ==

=== @call_params ===

That variable should contain a hash of call parameters that will passed to the routing script. This is equivalent to the incoming call parameters.

 

=== @nap_list ===

A list of hash containing the nap statuses. This is equivalent to the nap statuses at the time the call is to be routed.

'''The nap list is hashed by the nap names in UPPERCASE.''' It is important to consider this when creating new dynamic route or nap attributes that may nap names that will be used to fetch a status.

 

=== @params ===

A hash of hashes containing parameters. This hash contains bridge parameters and other kind of parameter groups may be added in the future.

Example: @params = {:bridge => {:announcement_tone, "announcement.wav"}}

 

----

 Back to [[Routing script tutorial|Routing Script Tutorial]].

[[category:Needs revising]]

Toolpack:Modifying ISUP Userpart for SPIROU A

2014-01-16T13:57:16Z

Manon Bélanger: /* Applies to version(s): v2.6, v2.7. */

=== '''''Applies to version(s): v2.6, v2.7.''''' ===
{{DISPLAYTITLE:Modifying ISUP Userpart for SPIROU}}

This section assumes:
* '''SS7 ISUP is already configured'''

1- Select '''SS7-->ISUP''' from the navigation panel

2- Click on the '''Edit''' button for the ISUP stack you want to configure

3- In the '''Editing Userparts''' section, click on the ISUP userpart you want to configure

4- Select '''SPIROU''' in the '''Protocol Variant''' drop-down menu

5- A new checkbox '''Strict SPIROU validation''' appears once SPIROU Protocol Variant is selected.
*Check this new checkbox to make sure your configuraton is compliant with SPIROU.

6- Click '''Timers''' to expand the Timers section

7- Set '''T6 Timer''' between 60000 and 120000 ms (between 60 and 120 seconds)

8- Click '''Advanced Parameters''' to expand the Advanced Parameters section

9- Uncheck the '''Allow group messages''' option

10- Click the '''Save''' button

11- Verify that the '''"IsupUserpart was successfully updated"''' message is displayed

==List of Parameters==

* [[Parameter: Protocol Type|Protocol Variant]]
* [[Toolpack:Enabling_strict_SPIROU_validation A|Strict SPIROU validation]]
* [[Parameter: Isup Userpart Timers|Timers]]

Text Call Detail Records

2013-08-15T18:48:35Z

Manon Bélanger: /* Information related to signaling */

Text [[call detail record|call detail records]] (CDR) can be used on the [[TMG800]], [[TMG3200]] or [[TMG7800]]. The Call Detail Records are saved in a log file on a local disk. There is an entry done for each call leg, at the start of a call and at the end of the call. In addition, the system can be configured to update the CDRs periodically.

The format of the CDR traces is defined by configuration, using variables that are replaced by the Gateway application when writing to the log.

For example, the following variable will be replaced by the called number:
@{CalledNumber}

In order to save disk space and simplify the archiving and backup of CDR log files, this log file is automatically archived (gzipped) and rotated every N seconds, as specified by the system configuration.

== Enabling text CDR ==
The enabling of Text CDR is described in [[Toolpack:Enabling CDR A|Enabling CDR]].

== Available variables ==
The following variables exist and can be used to define the CDR log format.

=== Variables used for identifying call (or call leg) in general ===
*@{StatusType}: Indicates the type of record ("Start", "Update" or "End").
*@{LegId}: Unique Id for this leg (32 bits value, but may eventually be upgraded to 64 bits value).
*@{OtherLegId}: Id of the other call leg joined with current call leg.
*@{SessionId}: Unique call identifier for two joined and answered call legs, including failed outgoing call attempts (route retry)
Formatted as 4 values of 32 bits, printed as 4 blocks of 8 hexadecimal characters separated by a space
Ex: a939d169 299ffcd0 00000000 00000000
Note: Call Transfer Target legs have separate SessionId. If you need an id to correlate a transferred call
to the original call, use @{OriginalSessionId}.
*@{OriginalSessionId}: Refers to @{SessionId} of the original legs for this call, in case of call transfer.
In fact, Transfer Target leg has a different value for @{SessionId}, but can be linked with the original call
legs through @{OriginalSessionId}.
*@{LinkId}: Same meaning as @{OriginalSessionId}, but presented as a 32 bits integer value.
For all Ids above, please see [[Text_Call_Detail_Records_(CDR)#Known_limitations|Known Limitations]] below for notes about uniqueness of these values.

=== Timestamps ===
*@{AlertTime}: Time where the call has started ringing.
Note: Supported on release 2.7 and up only.
*@{ConnectedTime}: Time where the call was answered (and connected with another leg) (in number of seconds since epoch)
*@{ConnectedTime:format}: Same as @{ConnectedTime} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{ConnectedTimeUtc:format}:Same as @{ConnectedTime:format} but printed in UTC time, rather than local time zone.
*@{CallDuration}: Call duration in seconds (not available in the "start" CDR log)
Note: Supported on release 2.7 and up only.
*@{CallDurationMs}: Call duration in milliseconds (end - connected time) (not available in the "start" CDR log)
Note: Supported on release 2.7 and up only.
*@{EndTime}: Time where the call has started terminating (in number of seconds since epoch).
Note that slightly differs from the @{Timestamp}, since the 'End' CDR trace is printed once the call has
finished terminating,
while @{EndTime} reports the time where the call has started terminating (upon hangup for example).
*@{EndTime:format}: Same as @{EndTime} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{EndTimeUtc:format}: Same as @{EndTime:format} but printed in UTC time, rather than local time zone.
*@{RingingDuration}: Ringing duration in seconds (connected - start time)
Note: Supported on release 2.7 and up only.
*@{RingingDurationMs}: Ringing duration in milliseconds (connected - start time)
Note: Supported on release 2.7 and up only.
*@{StartTime}: Time where the call was created (in number of seconds since epoch)
*@{StartTime:format}: Same as @{StartTime} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{StartTimeUtc:format}: Same as @{StartTime:format} but printed in UTC time, rather than local time zone.
*@{Timestamp}: Time where this CDR log entry was written.
Should not be used for billing purposes. Use @{EndTime} for billing @{EndTime} reports the time where
the call has started terminating (hangup), while *@{Timestamp} the time where signaling confirmed the termination.
*@{Timestamp:format}: Same as @{Timestamp} but with custom print format (local time zone), using 'strftime' style, with added
support for @m replaced by milliseconds.
Example format: %Y-%m-%d %H:%M:%S.@m -> 2009-09-02 12:16:24.333
*@{TimestampUtc:format}: Same as @{Timestamp:format} but printed in UTC time, rather than local time zone.

=== Information related to signaling ===
*@{CalledNumber}: Called number
*@{CallingNumber}: Calling number
*@{CallingPresentation}: Calling presentation: "Unspecified", "NotAvailable", "Allowed", "Restricted", "AddressRestricted" or "NameRestricted"
Note: Supported on release 2.7 and up only.
*@{CallingSubscriberNumber}: Second calling number (ISDN) or Generic number of type "additional calling party number" (SS7)
Note: Supported on release 2.7.43 and up only.
*@{CallType}: Call type ("Telephony" or "VOIP")
*@{IncomingNAP}: Name of the NAP that originated this call (incoming call leg's NAP name).
Note: Supported on release 2.7 and up only.
*@{NAP}: Name of the NAP this call leg is from
*@{OriginatorName}: Direction of the call:
- "answer" (incoming call leg) - "originate" (outgoing call leg)
Note: In release 2.6 and earlier, the direction of the call is as follows:
- "originate" (incoming call leg) - "answer" (outgoing call leg)
In release 2.7, the CDR option "Reverse CDR call origin" in Gateway configuration provide the same values as in release 2.6.
*@{OriginalCalledNumber}: Original called number
Note: Supported on release 2.7 and up only.
*@{Protocol}: Type of protocol used ("SS7", "ISDN", or "SIP")
*@{RedirectingNumber}: Redirecting number
Note: Supported on release 2.7 and up only.
*@{TerminationCause}: Cause of the call termination, printed as an integer value (refering enum TBCMC_CALL_REASON_CODE)
*@{TerminationCauseString}: Cause of the call termination, printed as an string value
*@{TerminationSource}: Identifies the cause of the leg termination:
- "TermInd": Terminating indication has been received on this leg
- "JoinedTermInd": Terminating indication has been received on the leg joined to current leg,
and has been forwarded to current leg
- "App": Call control application has asked to drop the call
- "Engine": Toolpack engine has decided to terminate this call
(generally due to local errors like disconnected TMedia)
*@{UserName}: For SIP calls, name of the user.
*@{ChargeIndicator}: For TDM (SS7 and CAS R2); received charge indicator in Alert message.

=== Information related to media ===
*@{Codec}: Codec used for this call ("G711" for example)
*@{LocalMediaInfo}: Protocol type dependent information on the call leg (local information for SIP calls).
For TDM (Telephony) calls (SS7 or ISDN): "trunk_name:timeslot_nb".
For VOIP calls (SIP): "codec@ip:port" (IP and Port locally used for receiving RTP)
*@{LocalMediaIP}: For VOIP calls, RTP IP address locally used for this call leg.
*@{LocalMediaPort}: For VOIP calls, RTP UDP port locally used for this call leg.
*@{RemoteMediaInfo}: Protocol type dependent information on the call leg (remote information SIP calls).
For TDM (Telephony) calls (SS7 or ISDN): "trunk_name:timeslot_nb".
For VOIP calls (SIP): "codec@ip:port" (IP and Port TMedia is sending RTP to)
*@{RemoteMediaIP}: For VOIP calls, RTP IP address of the remote peer for this call leg.
*@{RemoteMediaPort}: For VOIP calls, RTP UDP port of the remote peer for this call leg.
*@{TimeslotNumber}: For TDM (Telephony) calls, timeslot number that this call was using for audio.
*@{TrunkName}: For TDM (Telephony) calls, name of the trunk that this call was using for audio.

=== Information related to routing ===
*@{ApplicationName}: Name of the application that has written this log ("Gateway")
*@{RouteAttribute:attr}: Replaced by the value of a custom route attribute, for the selected
route. This will apply only to outgoing call legs that were made from routing.
Eligible route attributes are:
Route set name: Use attribute "routeset_name". Ex: @{RouteAttribute:routeset_name}
Custom route attribute column: Use the custom attribute name. Ex: @{RouteAttribute:priority}
Routing script parameters: Use the route attribute name provided by routing script.
Ex: If script provides: route[:my_param]="myval"
Then it's included in CDR with @{RouteAttribute:my_param}]

=== Deprecated values: ===
*@{MediaInfo}: Same as @{RemoteMediaInfo}
*@{RemoteIP}: Same as @{RemoteMediaIP}
*@{RemotePort}: Same as @{RemoteMediaPort}

== Redundancy ==

In a [[TMG7800]] configuration, with redundant TMG-Control servers, only the active server writes the CDR logs. Since the active server may change over time, CDR parsing must take into account that CDR logs may be found in files from the two servers.

The analysis of the logs for the purpose of extracting billing information must be done after combining the two logs, from both TMG-Control servers, sorting the entries by timestamp for example. See how to [[TMG:Retrieve_Text_CDR|Retrieve Text CDR here]].

== CDR entry loss due to switchover ==
In some situations (during HA switchover for example), some CDR entries may be lost.

The following guide lines provide information on how to deal with these corner cases:

[[Call_Detail_Records_Entry_Loss|Deal with CDR entries loss]]

== Retrieving Text CDRs ==

There are 2 ways to retrieve the text CDR manually or automatically. The procedures are described in [[TMG:Retrieve_Text_CDR|Retrieve Text CDR]].

== Notes ==
*This mode of operation is not recommended for [[TMG800]] or [[TMG3200]] with a flash disk (last shipment January 2011). However, the [[TMG800]] or [[TMG3200]] with SATA or SSD disk option is OK (use command tbproduct: if the command can be executed, the disk is SATA or SSD).
*TelcoBridges does not recommend storing CDR logs via network file systems (NFS or other). We highly recommend writing to a local hard drive and have developed a background script that moves the gzipped log segments for backup or analysis.

[[category:Needs revising]]

Toolpack:RADIUS CDR attributes C

2013-08-15T18:45:53Z

Manon Bélanger: /* Applies to version(s): v2.7 */

{{DISPLAYTITLE:Toolpack:RADIUS CDR attributes}}
=== '''''Applies to version(s): v2.7''''' ===
This page contains the list of RADIUS attributes that are sent to a RADIUS accounting server.

From RFC 2865 and RFC 2866 (Accounting) :
{| cellpadding="5" border="1" class="wikitable"
|-
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Attribute ID
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | RADIUS IETF param name
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Type
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Toolpack CDR parameter
! width="610" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Description
|-
| align="center" | 1 
| User-Name
| align="center" | string 
| IncomingNAP
| Incoming NAP name
|-
| align="center" | 4 
| NAS-IP-Address
| align="center" | IP address 
| -
| IP address of the TMedia generating the CDR record
|-
| align="center" | 30 
| Called-Sation-Id
| align="center" | string 
| Called Number
| Called party number
|-
| align="center" | 31 
| Calling-Station-Id
| align="center" | string 
| Calling Number
| Calling party number
|-
| align="center" | 32 
| NAS-Identifier
| align="center" | string 
| Application Name
| Application name of the CDR provider
|-
| align="center" | 40 
| Acct-Status-Type
| align="center" | integer 
| -
| Start or Stop
|-
| align="center" | 44 
| Acct-Session-Id
| align="center" | integer 
| Leg Id
| Call Leg Identifier
|-
| align="center" | 46 
| Acct-Session-Time
| align="center" | integer 
| Session duration
| Duration of the call, in seconds. Corresponds to h323-disconnect-time minus h323-connect-time.
|}

Attribute ID 26, Vendor ID: 9 (Cisco)
{| cellpadding="5" border="1" class="wikitable"
|-
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Vendor specific attribute ID
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | RADIUS IETF param name
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Type
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Toolpack param
! width="610" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Description
|-
| align="center" | 2 
| Cisco-NAS-Port
| align="center" | string 
| NAP name
| Network Access Point name for the call leg
|-
| align="center" | 24 
| h323-conf-id
| align="center" | string 
| Unique Id
| Unique call identifier for the two initial legs (incoming and outgoing) - 128 bits integer formated as xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
|-
| align="center" | 25 
| h323-setup-time
| align="center" | string 
| Start Time
| Represent the call leg setup time - Coordinated Universal Time (UTC)
|-
| align="center" | 26 
| h323-call-origin
| align="center" | string 
| Originator Name
| "originate" for an outgoing leg - "answer" for an incoming leg
|-
| align="center" | 27 
| h323-call-type
| align="center" | string 
| Protocol Type
| If protocol is SIP the value is "VOIP", otherwise it is "Telephony"
|-
| align="center" | 28 
| h323-connect-time
| align="center" | string 
| Connected Time
| Represent the call leg answer time (connect time) - Coordinated Universal Time (UTC)
|-
| align="center" | 29 
| h323-disconnect-time
| align="center" | string 
| EndTime
| Represent the call leg disconnect time - Coordinated Universal Time (UTC)
|-
| align="center" | 30 
| h323-disconnect-cause
| align="center" | string 
| Termination Reason
| Q.931 disconnect (1 to 160) cause, TB Toolpack system cause (200 to 300) and SIP cause (400 to 600)
|-
| align="center" | 35 
| h323-incoming-conf-id
| align="center" | string 
| Unique Id
| Contains the original h323-conf-id in case of call transfer for subsequent outgoing legs - 128 bits integer formated as xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx
|-
| align="center" | 115
| release-source
| align="center" | string 
| Termination Source
| "localLeg" if this leg terminate the call or "connectedLeg" if its the connected leg - We use a Cisco string field with our own value definition
|-
|}

Attribute ID 26, Vendor ID: 21776 (TelcoBridges)
{| cellpadding="5" border="1" class="wikitable"
|-
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Vendor specific attribute ID
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | RADIUS IETF param name
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Type
! width="210" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Toolpack param
! width="610" style="background: none repeat scroll 0% 0% rgb(239, 239, 239);" | Description
|-
| align="center" | 9 
| Telcob-ChargeIndicator
| align="center" | String 
| ChargeIndicator
| Represent the charge indicator value
|-
| align="center" | 10 
| Telcob-Protocol
| align="center" | String 
| Protocol
| Protocol used for this LegID. Ex. SIP, ISDN, etc.
|-
| align="center" | 11 
| Telcob-Codec
| align="center" | String 
| Codec
| Codec used for this LegID
|-
| align="center" | 12 
| Telcob-RemoteIP
| align="center" | IP address 
| RemoteIP
| RemoteIP used for the media. This is only for VOIP.
|-
| align="center" | 13 
| Telcob-RemotePort
| align="center" | Integer 
| RemotePort
| RTP Port of the remote peer. This is only for VOIP.
|-
| align="center" | 14 
| Telcob-TrunkName
| align="center" | String 
| TrunkName
| Name of the trunk (ex. "LS004400E1_0_00"). 
This attribute is only for non-VOIP.
|-
| align="center" | 15 
| Telcob-TimeslotNumber
| align="center" | Integer 
| TimeslotNumber
| This is the Timeslot Number. 
This attribute is only for non-VOIP.
|-
| align="center" | 16 
| Telcob-MediaInfo
| align="center" | String 
| MediaInfo
| String that represents the MediaInfo (ex. "PCMU@10.3.10.124:20054" for SIP and "LS_T1_BITS_00:1" for ISDN)
|-
| align="center" | 17 
| Telcob-StartTime
| align="center" | String 
| StartTime
| String that represents the StartTime of the call.
|-
| align="center" | 18 
| Telcob-ConnectedTime
| align="center" | String 
| ConnectedTime
| String that represents the time when the call was connected
|-
| align="center" | 19 
| Telcob-EndTime
| align="center" | String 
| EndTime
| String that represents when the call was completed.
|-
| align="center" | 20 
| Telcob-TerminationCause
| align="center" | Integer 
| TerminationCause
| Integer that represents the Termination Cause
|-
| align="center" | 21 
| Telcob-Other-Leg-Id
| align="center" | Integer 
| Other-Leg-Id
| Integer that represents the other LegID bridged for this call
|-
| align="center" | 22 
| Telcob-TerminationCauseString
| align="center" | String 
| TerminationCauseString
| String that represents the TerminationCause, but in a String format.
|-
| align="center" | 23 
| Telcob-TerminationSource
| align="center" | String 
| TerminationSource
| String that represents the Termination Source
|-
| align="center" | 24 
| Telcob-LocalSipIP*
| align="center" | String 
| LocalSipIP
| IP Address that represents the Local IP used for SIP.
|-
| align="center" | 25 
| Telcob-LocalSipPort*
| align="center" | Integer 
| LocalSipPort
| Integer that represents the Local port used for SIP.
|-
| align="center" | 26 
| Telcob-LocalMediaIP
| align="center" | IPAddr 
| LocalMediaIP
| IP Address that represents the Local IP used for the media.
|-
| align="center" | 27 
| Telcob-LocalMediaPort
| align="center" | String 
| LocalMediaPort
| Integer that represents the Local port used for the media.
|-
| align="center" | 28 
| Telcob-LocalMediaInfo
| align="center" | String 
| LocalMediaInfo
| String that represents the Local Media Info.(ex. "PCMU@10.3.10.124:20054")
Only for VOIP calls.
|-
| align="center" | 29 
| Telcob-RemoteMediaInfo
| align="center" | String 
| RemoteMediaInfo
| String that represents the Remote Media Info.(ex. "PCMU@10.3.10.124:20054")
This is the same as Telcob-MediaInfo. Only for VOIP calls.
|-
| align="center" | 30 
| Telcob-Alert-Time
| align="center" | Integer 
| AlertTime
| Time where the call has started ringing.
|-
| align="center" | 31 
| Telcob-Redirecting-Number
| align="center" | String 
| RedirectingNumber
| Redirecting number
|-
| align="center" | 32 
| Telcob-Original-Called-Number
| align="center" | String 
| OriginalCalledNumber
| Original called number
|-
| align="center" | 33 
| Telcob-Calling-Presentation
| align="center" | String 
| CallingPresentation
| Calling presentation: "Unspecified", "NotAvailable", "Allowed", "Restricted", "AddressRestricted" or "NameRestricted"
|-
| align="center" | 34 
| Telcob-CallingSubscriberNumber
| align="center" | String 
| CallingSubscriberNumber
| Second calling number (ISDN) or Generic number of type additional calling party number (SS7)
|}
* = Not implemented.

Routing script tutorial:Mini Development Guide

2013-02-06T20:57:31Z

Manon Bélanger: Added new parameters available in 2.7

Routing script tutorial:Mini Development Guide

2013-02-06T20:27:50Z

Manon Bélanger: Added Needs revising category

Toolpack:Modifying Transit Network Selection Filters A

2013-01-16T18:15:01Z

Manon Bélanger: Changes for support of good release reason

=== '''''Applies to version(s): v2.6, v2.7.''''' ===
{{DISPLAYTITLE:Modifying Transit Network Selection Filters}}

== Before filter ==
This filter is '''specific to SPIROU'''. In SPIROU, the Network Identification used for Transit Network Selection can be added at the beginning of the called number, when Nature Of Address (NOA) is set to '''"international number with transit network selection"''' or '''"national number with transit network selection"'''. This example works for Network Identification of 4 digits, modify it to match the number of digits in your specific network.

<pre>
# Specific to Spirou, remaps called nature of address, removes selection prefix
# and uses it as the network_identification field
# This example will work for selection prefixes of 4 digits, modify .slice!(0..3) according to
# the length of the selection prefixes in your network
def transit_network_selection_before_filter params
#Reset value to false
@route_rejected = false

call = params[:call]
called_noa = call[:called_noa]

case called_noa
when 'international_number_with_transit_network_selection'
call[:called_noa] = 'international_number'
call[:network_identification] = call[:called].slice!(0..3)
when 'national_number_with_transit_network_selection'
call[:called_noa] = 'national_number'
call[:network_identification] = call[:called].slice!(0..3)
end

params

end
</pre>

== Route match ==
This filter allows to match routes according to the network_identification column when Transit Network Selection (TNS) is present. Calls will be routed normally if the TNS IE is not present.

See [[Toolpack:Adding_Network_Identification_Column_To_Routes_A|Add Network Identification column to Routes]].

<pre>
# Will only accept calls if no network identification is requested, or if
# the network identification of the route matches with the requested one
def transit_network_selection_route_match( route, call, nap_list )
requested_network_id = call[:network_identification]

if requested_network_id.nil?
return true
end

route_network_id = route[:network_identification]

if requested_network_id != route_network_id
#Keep track if a route was rejected because of transit network selection, to return the good release cause
@route_rejected = true
return false
end

return true
end
</pre>

== After filter ==
This filter removes the Transit Network Selection information from the route, after the information has been used to route the call. It also makes sure the correct release reason is sent when there is no route because no route matched the requested network identification. Do not use this filter if it is required to transmit the Transit Network Selection IE from the incoming leg to the outgoing leg.
<pre>
#Test to send the good release reason if there is no route
#Removes network identification, we do not want to transmit it in the outgoing call
def transit_network_selection_after_filter params
routes = params[ :routes ]
#If no routes where found because routes were rejected for transit network selection,
#raise an exception with the correct error code
raise RoutingException, :invalid_transit_network if (routes.empty? && @route_rejected == true)

call = params[:call]
call[:network_identification] = nil

params

end
</pre>