SN10100 can do a max of 128 SIP to SIP calls.

SN10200 can do a max of 1024 SIP to SIP calls.

Once this is added and the config is validated and applied, calls are then passed through without issue.

- Used when call routes are simple

- Label Routing:

- Used when call routes are extensive

- Scriptable Routing:

- Used to implement customer routing algorithms

- Examples: route retries, load-balancing

To enable CDRs please navigate to 'Menu -> Gateway -> Edit Configuration -> CDR Options' and check the box below:

 

Once this is marked CDR Options will reveal. In order to customize your CDR Output please expand "Text CDR parameters" field

CDR Format boxes will become available for filling in.

Each box represents one of 3 possible CDR states:

• Start
  
• Update
  
• End
  

and is populated with CDR field names with receive their values from system Channel Variables. Each pair should be created from:

Name='@{VariableString}' 

For a full list of Variables please see below.

Exmplary CDR format configuration:

Each CDR state begins with Timestamp value and keyword representing the state. Below you can find two examples of single call CDR:

 SIP -> ISDN

2015-05-12 18:20:37.410+0200,BEG,SessionId='a1ef6a38 00000000 00000000 00000000',LegId='0xA1EF6A38',StartTime='1431447634',ConnectedTime='1431447637',Calling='1000',Called='6001',NAP='NAP_SIP_FS5062',Protocol='SIP',Direction='originate'
2015-05-12 18:20:37.410+0200,BEG,SessionId='a1ef6a38 00000000 00000000 00000000',LegId='0x21EF9549',StartTime='1431447634',ConnectedTime='1431447637',Calling='1000',Called='116001',NAP='NAP_ISDN_SN4950E1_0',Protocol='ISDN',Direction='answer'
2015-05-12 18:20:41.694+0200,END,SessionId='a1ef6a38 00000000 00000000 00000000',LegId='0xA1EF6A38',StartTime='1431447634',ConnectedTime='1431447637',EndTime='1431447641',FreedTime='1431447641',TerminationCause='NORMAL',TerminationSource='TermInd',Calling='1000',Called='6001',NAP='NAP_SIP_FS5062',Direction='originate'
2015-05-12 18:20:41.796+0200,END,SessionId='a1ef6a38 00000000 00000000 00000000',LegId='0x21EF9549',StartTime='1431447634',ConnectedTime='1431447637',EndTime='1431447641',FreedTime='1431447641',TerminationCause='NORMAL_CALL_CLEARING',TerminationSource='JoinedTermInd',Calling='1000',Called='116001',NAP='NAP_ISDN_SN4950E1_0',Direction='answer'
 

ISDN -> SIP

2015-05-12 18:23:11.498+0200,BEG,SessionId='a1ef6a39 00000000 00000000 00000000',LegId='0xA1EF6A39',StartTime='1431447788',ConnectedTime='1431447791',Calling='1000',Called='216001',NAP='NAP_ISDN_SN4950E1_0',Protocol='ISDN',Direction='originate'
2015-05-12 18:23:11.499+0200,BEG,SessionId='a1ef6a39 00000000 00000000 00000000',LegId='0x21EF954A',StartTime='1431447788',ConnectedTime='1431447791',Calling='1000',Called='6001',NAP='NAP_SIP_FS5062',Protocol='SIP',Direction='answer'
2015-05-12 18:23:29.043+0200,END,SessionId='a1ef6a39 00000000 00000000 00000000',LegId='0xA1EF6A39',StartTime='1431447788',ConnectedTime='1431447791',EndTime='1431447808',FreedTime='1431447809',TerminationCause='NORMAL_CALL_CLEARING',TerminationSource='TermInd',Calling='1000',Called='216001',NAP='NAP_ISDN_SN4950E1_0',Direction='originate'
2015-05-12 18:23:29.044+0200,END,SessionId='a1ef6a39 00000000 00000000 00000000',LegId='0x21EF954A',StartTime='1431447788',ConnectedTime='1431447791',EndTime='1431447808',FreedTime='1431447809',TerminationCause='NORMAL_CALL_CLEARING',TerminationSource='JoinedTermInd',Calling='1000',Called='6001',NAP='NAP_SIP_FS5062',Direction='answer'

The following variables 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.

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, 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":        SmartMedia engine has decided to terminate this call
                                                (generally due to local errors like disconnected TelcoBoard)
@{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.

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 TelcoBoard 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 following variables allow to print call statistics in the text CDR logs.

There are some restrictions, however:

• Available only in the "end" CDR entry

• Available in release 2.7.103 and above only

@{Stat:stat_name}:         Get the specified statistic's value. Example: @{Stat:Rtp:Rx:Packets}.
                           Available statistics names:
                           RTP Rx (received IP packets):
                            - Rtp:Rx                             Summary of the Rx stats (Packets;CNPackets;SignalingPackets;Errors)
                            - Rtp:Rx:Packets:                    Number of packets received from the IP network (audio + comfort noise + signaling)
                            - Rtp:Rx:VoicePackets:               Number of voice (audio) packets received from the IP network
                            - Rtp:Rx:VoiceBytes:                 Number of payload bytes from voice (audio) packets received from the IP network
                            - Rtp:Rx:CNPackets:                  Number of comfort noise packets received from the IP network
                            - Rtp:Rx:SignalingPackets:           Number of signaling packets (like "Telephony events") received from the IP network
                            - Rtp:Rx:RFC2833Tones:               Number of RFC2833 tones received from the IP network, and played back to TDM
                            - Rtp:Rx:RedundantPackets:           Number of redundant packets received from the IP network (same sequence number received more than once)
                            - Rtp:Rx:MeanPower:                  Mean audio power (from IP to TDM direction), in dBov (0 the loudest, negative is softer level)
                                                                 (Available only for calls with Echo cancellation enabled, thus only TDM<->IP calls)
                            - Rtp:Rx:VoiceDuration:              Duration (in seconds) of voice (audio), from IP to TDM direction
                            - Rtp:Rx:PlayoutDelay:               Current IP to TDM audio delay in millisecond (adaptive jitter buffer delay) 
                            - Rtp:Rx:MaxPlayoutDelay:            Maximum (for the whole call) IP to TDM audio delay in millisecond (adaptive jitter buffer delay) 
                            - Rtp:Rx:SsrcChanges:                Number of changes of "SSRC" RTP header value (counting initial SSRC received as one)
                            - Rtp:Rx:Concealments:               Number of times decoder made audio concealment to preserve audio continuity
                                                                 (frequent upon first packet of a call, or after RFC2833 tones)
                            - Rtp:Rx:Echo:ERLLevel:              Attenuation of a signal from the received-out port to the send-in port of an echo canceller
                            - Rtp:Rx:Error:BufOverflows:         Number of packets dropped due to jitter buffer adaptation (to keep play-out delay low)
                            - Rtp:Rx:Error:SeqErrors:            Number of sequence errors detected among packets received from the IP network
                            - Rtp:Rx:Error:BadPackets:           Number of packets received with invalid header, or other error preventing proper audio decoding
                            - Rtp:Rx:Error:RFC2833BadPackets:    Number of RFC2833 signaling packets that could not be properly decoded
                            - Rtp:Rx:Error:LatePackets:          Number of packets that arrived after the moment they should have started to be played-out to TDM
                            - Rtp:Rx:Error:LostPackets:          Number of packets considered "lost" (never received for play-out to TDM)
                            - Rtp:Rx:Errors:                     Total of all "Rtp:Rx:Error:" statistics above
                          RTP Tx (sent IP packets):
                            - Rtp:Tx                             Summary of the Tx stats (Packets;CNPackets;SignalingPackets;Errors)
                            - Rtp:Tx:Packets:                    Number of packets sent to the IP network (audio + comfort noise + signaling)
                            - Rtp:Tx:VoicePackets:               Number of voice (audio) packets sent to the IP network
                            - Rtp:Tx:CNPackets:                  Number of comfort noise packets sent to the IP network
                            - Rtp:Tx:SignalingPackets:           Number of signaling packets (like "Telephony events") sent to the IP network
                            - Rtp:Tx:RFC2833Tones:               Number of RFC2833 tones sent to the IP network (relaying corresponding detected TDM tones)
                            - Rtp:Tx:MeanPower:                  Mean audio power (from TDM to IP direction), in dBov (0 the loudest, negative is softer level)
                                                                 (Available only for calls with Echo cancellation enabled, thus only TDM<->IP calls)
                            - Rtp:Tx:VoiceDuration:              Duration (in seconds) of voice (audio), from TDM to IP direction
                            - Rtp:Tx:Echo:ACOMLevel:             Attenuation of a signal from the receive-out port to the send-out port of an echo canceller
                            - Rtp:Tx:Error:LostPackets:          Number of packets considered "lost" by remote side (only available if RTCP is used)
                            - Rtp:Tx:Error:ArpFailure:           Number of failures to ARP remote IP address to send RTP packets to (preventing sending any packets)
                            - Rtp:Tx:Errors:                     Total of all "Rtp:Tx:Error:" statistics above
                          RTCP (only if RTCP is enabled on the profile):
                            - Rtcp                               Summary of the Rtcp stats (Packets;LostPackets;Jitter)
                            - Rtcp:Packets:                      Number of packets reported as received by remote equipment
                            - Rtcp:LostPackets:                  Number of packets reported as lost by remote equipment
                            - Rtcp:Jitter:                       Inter-packet interval jitter, in millisecond
                          T.38 Rx (from IP to TDM direction):
                            - T38:StateChanges:                  Number of T.38 state changes, through T.30 negotiation between FAX machines
                            - T38:Rx                             Summary of the Rx stats (Pages;Packets;Errors)
                            - T38:Rx:Pages:                      Number of FAX pages received from T.38 packets from the IP network
                            - T38:Rx:Packets:                    Number of T.38 packets received from the IP network
                            - T38:Rx:Bytes:                      Number of T.38 payload bytes from T.38 packets received from the IP network
                            - T38:Rx:Duration:                   Duration of the T.38 session from IP to TDM
                            - T38:Rx:PlayoutDelay:               Current IP to TDM audio delay in millisecond (re-modulation and jitter buffer delay) 
                            - T38:Rx:MaxPlayoutDelay:            Maximum IP to TDM audio delay in millisecond (re-modulation and jitter buffer delay) 
                            - T38:Rx:Error:BufOverflows:         Number of packets dropped because "from IP" jitter buffer is full
                            - T38:Rx:Error:BufUnderflows:        Number of times T.38 re-modulation to TDM had no data (received from IP) to re-modulate
                            - T38:Rx:Error:SeqErrors:            Number of sequence errors detected among packets received from the IP network
                            - T38:Rx:Error:BadPackets:           Number of packets received with invalid header, or other error preventing proper audio decoding
                            - T38:Rx:Errors:                     Total of all "T38:Rx:Error:" statistics above
                          T.38 Tx (to IP, from TDM direction):
                            - T38:Tx                             Summary of the Tx stats (Pages;Packets)
                            - T38:Tx:Pages:                      Number of FAX pages received from TDM, sent to T.38 packets to the IP network
                            - T38:Tx:Packets:                    Number of T.38 packets sent to the IP network
                            - T38:Tx:Bytes:                      Number of T.38 payload bytes from T.38 packets sent to the IP network
                            - T38:Tx:Duration:                   Duration of the T.38 session from TDM to IP
                            - T38:FromTdm:MeanPower:             Mean audio power received from TDM side, in dBov (0 the loudest, negative is softer level)

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 SmartMedia 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 SmartMedia host.
                                                   It's thus recommended to insert this information in the "Start" CDR entry,
                                                   rather than the "End" CDR entry.

Recommended procedure for Minor Upgrade performed with 'System View' CLI progress control (SmartMedia 2.8.63 to 2.8.68 as example)

Recommended procedure for Major Upgrade performed with 'System View' CLI progress control (SmartMedia 2.7 -> 2.8 as example)

Simplified upgrade procedure

Upload a release package

Note: This section is NOT service affective. It installs files for the newer release on the server's hard drive in a separate folder than current active release.

• Log in the web portal and click the 'Status' -> 'Hosts' tab.
• Click on one of the 'Ready host list' link.
• Select 'Upload Package' from the drop down box.
• Click the 'Browse...' button and select the software package.
• Once the file selected, click the 'Apply action' button.
• This process will take a while, depending on the speed of the connection to the Web Portal.  

Activate Release

Note: This section is service affective.

Once the new release version is installed, it is necessary to activate the new software version in the system.

Warning: This requires a restart of the SN10k platforms and will affect service until the new version activation is complete.

• Go to the 'Systems'
• Select the new release version in the 'Activate package' dropdown box.
• Press the 'Activate' button to start the new release activation.
• It will take a few minutes for the system to upgrade.
• Once complete, you will be able to go back to the home page and the new version will be installed and listed in the upper right hand corner.

Follow this link to get an illustrated instruction of the upgrade.

2. Click Edit from the IP Interfaces Information panel:

3. Configure the IP port:

• Indicate whether or not to use DHCP on this port
• Enter an IP address
• Enter a Netmask
• Enter a gateway address
• Click Save

Note: The IP addresses of VOIP0 and VOIP1 must be on different subnets. 

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

IMPORTANT! The system will display the following notice, describing steps to apply your new configuration:

5. Activate the configuration

Systems -> Activate configuration

6. Reboot the adapter (will drop active calls)

Status -> Hardware -> Click on the adapter Serial Number 

You will see a prompt Stating:

7. Use the drop down box next to “Reboot adapter” to select Yes, and then click “Apply states” at the bottom of the page.

It will take about 1.5 minutes to restart the unit.

-  A standard SN10100 unit

-  A +1 SN10100 unit

-  One or two 1+1 patch panels

In case of failure of the active unit, the exact configuration will transfer onto the standby unit. The standby unit is then automatically activated, and continues to route the calls. 

Network connection between units of the SN10100 1+1 system: 

All units of the SN10100 1+1 system need to be connected together using two Ethernet networks. These two networks must be:

-  Independent Ethernet networks

• two for redundancy
• independent to avoid interferences between them

-  Private (No up-link to the LAN)

• to avoid interferences with other equipments
• to isolate multiple SN10100 1+1 systems from each other

Networking configuration for SN10100 1+1 system:

Each unit of the SN10100 1+1 system has only two Ethernet interfaces (named voip0 and voip1). They must be shared for network communication with external world (SIP, RTP, Sigtran, H.248), and with private communication between the two SN10100 units of the system. 

Two private VLans must be created to establish private and redundant network communication path between the two units:

-  VLan IDs are provided to SN10100 units upon initial configuration through Web Portal

-  VLans configuration in the Ethernet switches that the SN10100 units are connected to must be

• Done before starting the SN10100 units for the first time by network operator
• Must be private to ONLY the two ports the SN10100 units are connected to

How to configure units of the SN10100 1+1 system:

Initial configuration:

The first time a SN10100 unit is started, it's not yet ready to connect to other units of a SN10100 1+1 system.
It must be told what role it will occupy (standalone unit, primary/secondary unit of a 1+1 system):

-  Make sure that the unit is properly connected to the network (as described above)

-  Make sure that the VLans are properly configured in the Ethernet switches that the units are connected to (SN10100 only)

-  Connect to the Web Portal of that SN10100 unit (http://[serial_number_of_your_unit]:12358)

-  Answer the questions:

• Role (standalone, new primary, replacement primary, or secondary unit)
• VLan IDs (for SN10100 only)

-  Wait for the SN10100 unit to configure itself

• Enable eth0/eth1 interfaces
• Detect other SN10100 unit of the 1+1 system
• Synchronize with other unit of the 1+1 system, if required

-  You should then be redirected to the "standard" SN10100 Web Portal where you can configure stacks and other functionalities of the SN10100

Return unit to initial configuration:

It may be required to return a SN10100 unit to its initial state, for example:

-  A SN10100 Standard unit was used as a standalone unit, now needs to be used as part of a 1+1 system

-  A SN10100 Spare unit was used as a replacement in a 1+1 system, and must now be removed in order to insert back the repaired unit

To return the unit to its "initial" state (disconnected from other units, waiting to be told if it's standalone, primary or secondary):

-  Connect to the unit's Web Portal (http://[serial_number_of_your_unit]:12358)

-  Click on "Hosts" on the left menu of the Web Portal

-  Click on "Status" tab

-  Click on the status of the SN10100 unit to return to "initial" state

-  Select "Reset Host Role" action from the popup menu

-  Click "Apply"

-  Wait 15-30 seconds, and re-connect to the Web Portal. You should now be in the "Initial configuration" web portal of that SN10100 unit

Web Portal configuration for the SN10100 1+1 system:

The configuration of the SN10100 1+1 system is almost identical to the configuration of a standalone SN10100 unit.

Differences are:

-  A 1+1 Group is defined to bind the two units into a redundant group

-  Two "Hardware" are present

• One for each SN10100 unit of the 1+1 system
• Only the primary unit has a "configuration" that can be modified (TDM Line Interfaces, protocol stacks)
• Each has its own status (status of Line Interfaces and protocol stacks only visible for the unit that's actually active)

-  Two "Hosts" are present

• One for each SN10100 unit of the 1+1 system
• Each has its own status (disk usage, CPU usage, ...)
• Each has its list of applications running on them (identical list of applications on both units)

-  The configuration of the ISUP stack is made redundant on the two units

• The ISUP stack provides "no loss of active call" redundancy by already running as a standby on the secondary unit even when it's not activated. This is not (yet) possible for other protocol stacks.

How redundancy is achieved:

The SN10100 system contains

-  Host server, running call control applications, web portal, and other OAM-related applications

-  Telecommunication unit, running protocol stacks, and having hardware resources to process voice (TDM, or VOIP)

Notes:

-  The SN10100 unit contains both the host server and the Telecommunication unit in the same box.

Redundancy of the applications:

-  The applications running on the host server are redundant by having one copy of each application running on each unit.

-  In case of failure of an application, the corresponding application on the other unit is activated to replace the failed application.

-  In case the whole host server unit fails, all applications on the other unit are activated.

Redundancy of the Telecommunication units:

-  Telecommunications units used in pairs (1+1)

-  Both are connected to the TDM network, and to the IP network

• One is active (driving the signal on the TDM network, assigned an IP address on the VOIP network)
• One is standby (not driving the TDM network, no IP assigned on the VOIP network)

-  When one unit fails

• the other unit is activated with the exact same configuration as the primary units
• the other unit starts driving the TDM network
• the other unit is assigned the IP address (moved from the primary) on the VOIP network)

It was used to configure "accounts" for a very old ring-back-tone piece of code (i.e. configure the prompts per calling number). This function (RBT) is now much more flexible using the routing scripts. Therefore, we do not recommend to use it anymore as it will be removed anyway.

• A SN10k Standard unit was used as a standalone unit, now needs to be used as part of a 1+1 system
• A SN10k Spare unit was used as a replacement in a 1+1 system, and must now be removed in order to insert back the repaired unit

To return the unit to it's "initial" state (disconnected from other units, waiting to be told if it's standalone, primary or secondary):

• Connect to the unit's Web Portal (http://[serial_number_of_your_unit]:12358)
• Click on "Hosts" on the left menu of the Web Portal

• Click on "Status" tab

• Click on the host serial number

• Under the "Host Control" section, select the "Reset Host Role" action from the drop down menu

• Click "Apply action"
• Wait 15-30 seconds, and re-connect to the Web Portal. You should now be in the "Initial configuration" web portal of that SN10k unit

As a new case study, in some cases the remapped nap is depending on the actual time / the calling party number of the called party number. All these data are available already in a MySQL database, so the most logical is to use it.

Link to attachment 

What you need:

- A SmartMedia VoIP Gateway

- A MySQL Server ( version <= 5.1.47 as of now )

- The attached Ruby Script.

Database Scheme:

mysql> describe route\G;

*************************** 1. row ***************************
Field: id
Type: int(11)
Null: NO
Key: PRI
Default: NULL
Extra: auto_increment
*************************** 2. row ***************************
Field: numberA
Type: varchar(255)
Null: NO
Key:
Default: NULL
Extra:
*************************** 3. row ***************************
Field: numberB
Type: varchar(255)
Null: NO
Key:
Default: NULL
Extra:
*************************** 4. row ***************************
Field: napB
Type: varchar(255)
Null: NO
Key:
Default: NULL
Extra:
4 rows in set (0.00 sec)

Create an IP port range

Step 2)

Create a SIP stack
Create a SIP transport server
Create a service access point

Step 3)

Access profile and validate settings

Step 4)

Creating profile

Step 5)

Allocate a SIP Network Access Point

Create Line Interface
Create Line Service

Step 2)

Setup the clock source

To do so:

1- Click Clocking in the navigation panel

2- Click Create New External System Clock Reference

3- Create the new clocking source:

• Select the appropriate hardware adapter
• Select a clock reference type (in this example, Line Service was chosen)
• Select a clock reference source (in this example "Line_Service_00")

Note: In this example, Line Service was chosen as the reference type, and the line service created in step B was chosen as the clocking source.

4- Verify that the SystemClock was successfully created message appears, and that the new clocking source appears in the External System Clock Reference List

Integrated Systems Digital Network (ISDN) is a circuit-switched telephone system that integrated voice and data on the same lines. SmartMedia can be configured to provide an ISDN signaling stack on the trunks of one or more units to meet system configuration requirements.

To create a new ISDN stack:

1- Click ISDN in the navigation menu, under the Signaling header

2- Click Create New ISDN Stack

3- Create the new stack:

• Verify that the box labeled Enabled is checked
• Enter a name for the new ISDN stack
• Select a variant to associate with the stack
• Determine whether the stack will operate on the user side, or the network side
• Select a primary D-channel line service
• Click Create

4- Verify that the "ISDN stack was successfully created" message appears, and that the new stack is listed in the ISDN Stack List

To create a new NAP:

1- Click NAP in the navigation panel

2- Click Create New NAP

3- Create the new NAP:

• Enter a name for the NAP
• Click Create

4- Verify that the NAP was successfully created message appears

5- Associate an ISDN stack with the new NAP:

• Select a stack from the ISDN stack list
• Click the "<<" button to associate it with the NAP

6- Select a value for Channel Usage, to avoid call collision

• Click Save

7- Verify that the "NAP was successfully updated" message appears

Create a new line interface
Create a new line service

Step 2)

Create a new ISDN stack

Step 3)

Create or modify a profile
(Hint: you can ommit this step if you can use the default profile which is allocated automatically) 

Step 4)

Allocate an ISDN NAP

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:

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

Noa values

• unknown_number
• international_number
• national_number
• subscriber_number
• network_specific
• network_routing_national_format
• network_routing_international_format
• abbreviated_number
• subscriber_number_operator_requested
• national_number_operator_requested
• international_number_operator_requested
• no_number_present_operator_requested
• no_number_present_cut_through_call_to_carrier
• test_line_test_code
• non_unique_subscriber_number
• non_unique_national_number
• non_unique_international_number
• call_950_number

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

• call_params[:called_noa] = 0x70

or

• call_params[:called_noa] = 112

Npi values

• unknown_number
• isdn
• telephony
• private
• data
• telex
• national

Calling Display Type values

• unspecified => Type is unspecified.
• calling_party_name => Type is 0xB1.

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

• call_params[:calling_display_type] = 0xB1

or

• call_params[:calling_display_type] = 177

Calling Display value

• call_params[:calling_display] = "Roger Fluffy"

Presentation values

• unspecified
• not_available
• allowed
• restricted
• addr_restricted
• name_restricted

Calling Party Category

values for calling_category

• unspecified (0xa)
• unknown (0x0)
• operator_french (0x1)
• operator_english (0x2)
• operator_german (0x3)
• operator_russian (0x4)
• operator_spanish (0x5)
• subscriber (0xa)
• subscriber_with_priority (0xb)
• data (0xc)
• test (0xd)
• payphone (0xf)

Screening values

• unspecified
• no
• pass
• fail
• network_provided

Redirecting number reason values

ISDN:

• unknown
• busy
• no_reply
• deflection
• dte_out_of_order
• forwarding_by_called_dte
• unconditional

SS7:

• unknown
• busy
• no_reply
• unconditional
• deflection
• deflection_immediate
• mobile_not_reachable

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:

Request-Line: INVITE sip:4175162082@172.22.45.13:5060;user=phone;transport=udp SIP/2.0

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:

    if call_params[:request_uri] && call_params[:request_uri] =~ /sip:(.*)@.*/
       call_params[:called] = $1
    end

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

Any custom sip header can be added to an outgoing call leg:

call[ :sip_header ] = ["P-my-custom-header:any value"]

Many can be added at one time:

call[ :sip_header ] = ["P-my-custom-header:value1", "P-my-custom-header2:value2", "P-my-custom-header3:value3"]

Note: It is not possible to read custom sip headers from inbound call legs.

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.

"file1.wav:repeat:start_off:end_off,file2.wav:repeat:start_off:end_off,file3.wav:repeat:start_off:end_off"

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.

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.

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 before terminating the leg with call duration reason (:call_duration_reason).

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.

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.

 #define NAP_STATS_FIELDS \
   /* Field,                                 szName,                            szDescription,                                        szOptions */ \
   ( SIGNALING_TYPE,                         "signaling_type",                  "Signaling type.",                                    "" ) \
   ( INCOMING_CALL_CNT,                      "inst_incoming_call_cnt",          "Instantaneous Count of incoming calls.",             "" ) \
   ( OUTGOING_CALL_CNT,                      "inst_outgoing_call_cnt",          "Instantaneous Count of outgoing calls.",             "" ) \
   ( AVAILABLE_CNT,                          "available_cnt",                   "Number of available circuits or channels.",          "" ) \
   ( UNAVAILABLE_CNT,                        "unavailable_cnt",                 "Number of unavailable circuits or channels.",        "" ) \
   ( AVAILABILITY_PCT,                       "availability_percent",            "Percentage of available circuits or channels.",      "" ) \
   ( USAGE_PCT,                              "usage_percent",                   "Percentage of used circuits or channels.",           "" ) \
   ( TOTAL_INCOMING_CALL_CNT,                "total_incoming_call_cnt",         "Total Count of incoming calls.",                     "" ) \
   ( ASR_STRUCT,                             "asr_statistics_struct",           "Detailed Answer-Seizure Rate Statistics.",           "" ) \
     ( GLOBAL_ASR_PCT,                       "global_asr_percent",              "Global calculated ASR percentage.",                  "" ) \
     ( TOTAL_OUTGOING_CALL_CNT,              "total_outgoing_call_cnt",         "Total Count of outgoing calls.",                     "" ) \
     ( LAST_24H_ASR_PCT,                     "last_24h_asr_percent",            "Last 24 hours calculated ASR percentage.",           "" ) \
     ( LAST_24H_OUTGOING_CALL_CNT,           "last_24h_outgoing_call_cnt",      "Last 24 hours outgoing calls.",                      "" ) \
     ( HOUR_ASR_PCT,                         "current_hour_asr_percent",        "Current hour calculated ASR percentage.",            "" ) \
     ( HOUR_OUTGOING_CALL_CNT,               "current_hour_outgoing_call_cnt",  "Current hour outgoing calls.",                       "" ) \
     ( LAST_HOUR_ASR_PCT,                    "last_hour_asr_percent",           "Last hour calculated ASR percentage.",               "" ) \
      ( LAST_HOUR_OUTGOING_CALL_CNT,         "last_hour_outgoing_call_cnt",     "Last hour outgoing calls.",                          "" ) \
   ( AVAILABILITY_DETECTION_STRUCT,          "availability_detection_struct",   "Detailed availibility detection Statistics",         "" ) \
     ( POLL_REMOTE_PROXY,                    "poll_remote_proxy",               "Remote proxy polling enabled",                       "" ) \
     ( IS_AVAILABLE,                         "is_available",                    "Remote proxy actually available or not",             "" ) \
     ( TIME_SINCE_POLLING,                   "time_since_polling",              "Time since the last availibility polling",           "" ) \
     ( TIME_AVAILABLE_SECONDS,               "time_available_seconds",          "Number of seconds since the NAP is available",       "x" ) \
     ( TIME_UNAVAILABLE_SECONDS,             "time_unavailable_seconds",        "Number of seconds since the NAP is unavailable",     "x" ) \
   ( REGISTRATION_STRUCT,                    "registration_struct",             "Detailed registration Statistics",                   "" ) \
     ( REGISTER_TO_PROXY,                    "register_to_proxy",               "Register to proxy enabled",                          "" ) \
     ( IS_REGISTERED,                        "registered",                      "Actually registered or not",                         "" ) \
     ( TIME_SINCE_REFRESH,                   "time_since_refresh",              "Time since the last refresh",                        "" ) \
     ( TIME_REGISTERED_SECONDS,              "time_registered_seconds",         "Number of seconds since the NAP is registered",      "x" ) \
     ( TIME_NOT_REGISTERED_SECONDS,          "time_not_registered_seconds",     "Number of seconds since the NAP is not registered",  "x" ) \
   /*!< Nap Status Fields */

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"}}

1- RADIUS client association

2- RADIUS redundancy

3- RADIUS CDR Attributes

RADIUS configuration for SN10k

1- Enabling RADIUS

2- Configuring RADIUS

3- Adding RADIUS Server(s)

RADIUS dictionaries

1- SN10k RADIUS dictionary general

2- SN10k RADIUS dictionary vendor specific

This page contains information about SmartMedia CAS R2 variant scripting.

Refer to the default script (itu.lua) in the Web Portal for a complete working variant script example.

Overview

CAS R2 signaling is done in two parts: line signaling and register signaling. In CAS R2 for E1 trunks, line signaling uses a single timeslot to communicate call states (such as off-hook, answering) for the remaining timeslots. Register signaling is the exchange of MFR2 tones to convey information such as the calling number, called number and calling party category. SmartMedia CAS R2 scripts allow complete customization of the register signaling process, while having some characteristics of the line signaling process customizable. Scripts also contain information relative to the conversion of register signaling data - group B signals and categories - into a format that the application can interpret. The scripting language is Lua.

Mandatory elements

In order for CAS R2 variant scripts to work, some variables, tables and events must be defined from within scripts. All of the following elements are required; if one of these elements is not present, it will not be possible to save the script in the Web Portal or load it on the adapter.

VARIANT_ID

The VARIANT_ID variable must be filled to distinguish variants from another. More precisely, it is used when transporting group B and category information with calls in order to possibly convert information meaning across variants.

Default CAS R2 SmartMedia scripts have variant IDs starting from 1. To avoid future conflicts, user scripts variant IDs should be prefixed with a sufficiently high value. For example, a modified ITU variant could have a ID equal to 0x0001001. Scripts may only share the same variant ID as other scripts if and only if the category and group B meanings are exactly identical.

Group B conversion information

Group B conversion information in scripts is used to convert group B information between CAS R2 variants and between other signaling types. The following elements must be filled so that these conversions can be completed successfully.

GROUPB_DIGIT_TO_MEANING

Each GROUPB_DIGIT_TO_MEANING table element must contain two values: a digit and a meaning. The digit must be a valid digit value (1 to 15) and the meaning must be a valid meaning (see Group B meanings). Each digit must be present in the table.

This table is used to convert group B digits to meaning in the context of an outgoing call. For a given digit, the specified meaning will be propagated to the application.

GROUPB_MEANING_TO_DIGIT

Each GROUPB_MEANING_TO_DIGIT table element must contain two values: a meaning and a digit. Meanings must not appear more than once in the table.

This table is used to convert meanings to digits for an incoming call. This is mostly used for calls where the other leg belongs to another signaling type, although it will be used if the other leg's signaling type is CAS R2 but the variant is different and there was no match in the GROUPB_OTHER_DIGITS table.

If a meaning is not found in this table, the meaning corresponding to GROUPB_DEFAULT_DIGIT will be used.

GROUPB_DEFAULT_DIGIT

This variable must be filled with a valid digit value. It will be used when lookups in the GROUPB_MEANING_TO_DIGIT table fail.

GROUPB_OTHER_DIGITS

Each GROUPB_OTHER_DIGITS table element must contain three values: a variant ID and two valid digit values. This table may be empty but cannot be omitted.

This table is used to convert a variant ID and a digit combination to a digit for the current variant in an outgoing call scenario.

Category conversion information

Category conversion information in scripts is used to convert category information between CAS R2 variants and between other signaling types. The following elements must be filled so that these conversions can be completed successfully.

The pattern used to handle categories is identical to the one used for group B conversions.

CATEGORY_DIGIT_TO_MEANING

Each CATEGORY_DIGIT_TO_MEANING table element must contain two values: a digit and a meaning. The digit must be a valid digit value (1 to 15) and the meaning must be a valid meaning (see Category meanings). Each digit must be present in the table.

This table is used to convert category digits to meaning in the context of an outgoing call. For a given digit, the specified meaning will be propagated to the application.

CATEGORY_MEANING_TO_DIGIT

Each CATEGORY_MEANING_TO_DIGIT table element must contain two values: a meaning and a digit. Meanings must not appear more than once in the table.

This table is used to convert meanings to digits for an incoming call. This is mostly used for calls where the other leg belongs to another signaling type, although it will be used if the other leg's signaling type is CAS R2 but the variant is different and there was no match in the CATEGORY_OTHER_DIGITS table.

If a meaning is not found in this table, the meaning corresponding to CATEGORY_DEFAULT_DIGIT will be used.

CATEGORY_DEFAULT_DIGIT

This variable must be filled with a valid digit value. It will be used when lookups in the CATEGORY_MEANING_TO_DIGIT table fail.

CATEGORY_OTHER_DIGITS

Each CATEGORY_OTHER_DIGITS table element must contain three values: a variant ID and two valid digit values. This table may be empty but cannot be omitted.

This table is used to convert a variant ID and a digit combination to a digit for the current variant in an outgoing call scenario.

Event handlers

Four register signaling event handlers must be defined in the script.

Call context table

Each event handler will have a table passed as a parameter. This table is the call context table, and contains critical information about the state of the call. Once calls are created (through Bwd_HandleNewCall and Fwd_HandleNewCall), the script must initialize the table with its own state information. Also, for incoming calls, as they go on, the script must fill the table with the collected signaling information. For outgoing calls, the table already contains this signaling information. The signaling information fields contained in the table are as follows:

Return values

Each event handlers must return two values. The first value is the action to take immediately or shortly following the call of the event. It must be set to one of the four following values:

The second return value is the digit that accompanies the action, or NO_DIGIT if no digit must be emitted. Its meaning depends on the first return value.

Backward event handlers

The following event functions must be defined so that the CAS R2 stack can proceed with register signaling for incoming calls.

Bwd_HandleNewCall

The Bwd_HandleNewCall event is called whenever an incoming call is discovered on a timeslot. The purpose of this event is for the script to initialize local variables that will be used throughout the tone exchanges.

The event will have the call context table passed as a parameter. This table must be filled with the call state information required by the script for a new incoming call.

The event must return two values as described in the following table:

Bwd_HandleFwdSignal

The Bwd_HandleFwdSignal is called whenever a tone signal has been received, which is most likely the beginning of a compelled sequence.

The event will receive two parameters: the call context table (which was also passed to Bwd_HandleNewCall) and the received tone signal. The event must use the received tone signal to fill the DestinationNumber, OriginNumber and Category fields of the call context table.

The event must return two values as described in the following table:

Forward event handlers

The following event functions must be defined so that the CAS R2 stack can proceed with register signaling for outgoing calls.

Fwd_HandleNewCall

The Fwd_HandleNewCall event is called whenever an outgoing call is initiated on a timeslot. The purpose of this event is for the script to initialize local variables that will be used throughout the tone exchanges.

The event will have the call context table passed as a parameter. This table must be filled with the call state information required by the script for a new incoming call.

The event must return two values as described in the following table:

Fwd_HandleBwdSignal

The Fwd_HandleBwdSignal event is called whenever a tone signal has been received as a response to the current compelled sequence, which is most likely the beginning of a compelled sequence.

The event will receive two parameters: the call context table (which was also passed to Fwd_HandleNewCall) and the received tone signal. The event must use the available DestinationNumber, OriginNumber and Category fields from the call context table to communicate information to the incoming end.

The event must return two values as described in the following table:

Optional elements

The following elements may or may not be defined into a CAS R2 script.

SCRIPT_FILE_NAME

When affecting a value to this variable, the Web Portal will automatically replace the value to the script name followed by the script revision. If the following piece of code is added appended at the end of the script (this is done for default scripts), it will print a trace when loading a CAS R2 stack which can be recovered using an application.

VARIABLES

The VARIABLES table is used to declare variables which can be altered through the Toolpack Web Portal. Typically, variables declared here contain parameters that affect particular trunks. Each row of this table must contain three elements: the variable name, the variable's default value and the variable's description.

Good practices

• Use the local keyword for declaring variables as much as possible. Non-local variables will stay alive outside the scope of event handlers, which in turn will take more CPU time in the form of garbage collection.

Tone generation module selection

By default the VoIP DSP devices are used to generate the MFCR2 tones. If the unit has only IVR DSP devices, or for other reasons, this can be changed by adding these lines to the scripts:

BWD_VP_GROUP = 0
FWD_VP_GROUP = 0

Script keyword reference

Stack variables

Here is the list of stack variables. These variables are declared before the VARIABLES table is parsed in a script. A single script affectation will modify the value one of these variables. It is also possible to edit these variables in the Toolpack Web Portal.

Group B meanings

Here is the list of all defined group B meanings:

ACCEPT_CHARGE
ACCEPT_NO_CHARGE
REJECT_UNSPECIFIED
REJECT_UNALLOCATED_NUMBER
REJECT_NO_ROUTE_TO_NETWORK
REJECT_NO_ROUTE_TO_DESTINATION
REJECT_USER_BUSY
REJECT_SUBSCRIBER_ABSENT
REJECT_CALL_REJECTED
REJECT_NUMBER_CHANGED
REJECT_EXCHANGE_ROUTING_ERROR
REJECT_DESTINATION_OUT_OF_ORDER
REJECT_ADDRESS_INCOMPLETE
REJECT_NO_CIRCUIT_AVAILABLE
REJECT_NETWORK_OUT_OF_ORDER
REJECT_TEMPORARY_FAILURE
REJECT_SWITCHING_EQUIP_CONGESTION
REJECT_REQUESTED_CIRCUIT_NOT_AVAILABLE
REJECT_RESOURCE_UNAVAILABLE
REJECT_SERVICE_NOT_AVAILABLE
REJECT_CALL_IDENTITY_DOES_NOT_EXIST
REJECT_CALL_IDENTITY_IN_USE
REJECT_PROTOCOL_ERROR
REJECT_INTERWORKING_UNSPECIFIED

Category meanings

Here is the list of all defined category meanings:

CATEGORY_UNKNOWN
CATEGORY_OPERATOR_FRENCH
CATEGORY_OPERATOR_ENGLISH
CATEGORY_OPERATOR_GERMAN
CATEGORY_OPERATOR_RUSSIAN
CATEGORY_OPERATOR_SPANISH
CATEGORY_SUBSCRIBER
CATEGORY_SUBSCRIBER_WITH_PRIORITY
CATEGORY_DATA
CATEGORY_TEST
CATEGORY_PAYPHONE

References

• Lua Programming Language official website
• Line signaling Wikipedia article
• Register signaling Wikipedia article

To add one or more additional hardware devices to the Toolpack system configuration, their serial numbers must be registered with the Toolpack application server.

To add a hardware device:

1- Click Hardware in the navigation panel

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

3- 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 the appropriate hardware device from the Type field. (In this case select TMP)
• Select the type of TDM lines that the hardware device will support.
• Indicate if the device will operate as a backup in a 1+1 configuration. If this is the first device being added, leave this field clear.
• Provide the amount of time is seconds, that the system will wait for calls to complete before shutting down for an upgrade.
• Enter the location in which the hardware device is installed.
• Enter a meaningful description as to the usage or purpose of the hardware device.
• Select Enabled from the Target State field.
• Click Create

NOTE The following image shows the 1+1 Backup field set. This is done for the addition a secondary TMP that will operate as the designated 1+1 backup in a 1+1 Group.

4- Verify that the "Adapter was successfully created" message appears, and that the newly added hardware device appears in the Hardware List below

To create a new NAP:

1- Click NAP in the navigation panel

2- Click Create New NAP

3- Create the new NAP:

• Enter a name for the NAP
• Click Create

4- Verify that the NAP was successfully created message appears

5- Associate a SIP service access point with the new NAP:

• Select a SIP SAP from the service access points list
• Click the "<<" button to associate it with the NAP

Follow the procedure listed below to create primary and secondary routes:

1- Click Routes in the navigation panel

2- Click Create New Static Route

3- Create the new route:

• Enter a RoutesetName for the route
• Select a NAP, or leave empty to match calls from any NAP
• Select a Remapped NAP
• Click Create

4- Verify that the "Route was successfully created" message appears, and that the new route is listed in the Routeset list

Note: To activate a configuration, you must be the Root user or have a user access level of 0.

To activate a system configuration:

1. Select Systems from the navigation panel.

2. Click Edit next to the system you wish to activate,in order to access the System Configuration screen.

3. Activate the configuration:

• Enter a name for the system
• Under Activate Configuration:
  • Select a Configuration on which to run the system
  • Click Activate

Note: Make certain that Lock Active Configuration box (located at the top of the page) is 'unchecked. Failure to do so will prevent the configuration from being saved.

Verify that an activation confirmation message is displayed. The system will remind you to back up your database when you are done configuring (at top of screen, in yellow):

• The routing decision
• The outgoing call
• Subsequent outgoing calls, in the case of a route retry
• Parameters selected for a SIP SDP
• The SIP Call-id
• The trunk and timeslot chosen for TDM protocols
• The termination result code, and more.

A call path is shown as separate call legs, distinguishing the incoming portion with other portions of a call. Call trace enables a default of 10,000 call legs to be stored on the system and be viewed using the Web Portal.

Calls may be filtered by called number, calling number, Network Access Point (NAP), time of day range, protocol and direction.

Retrieving calls:

1- Click Call Trace in the navigation panel

2- Set various parameters for the call trace, such as

• Time and date range
• Called or calling number
• Network Access Point (NAP)
• Incoming or outgoing calls
• Call Duration, Reason Code

Once you are satisfied with the filter criteria, click Apply

The filter results are displayed.

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

At the end your SmartNode SN10k will be ready to handle calls from SIP to ISDN and versa.

Step 1) Hardware

Adding New Hardware In SmartMedia

Create the TDM network on SmartMedia

Configuring VoIP Interfaces

Step 2) Protocol Stacks

Configuring ISDN on SmartMedia

Configuring SIP on SmartMedia

Step 3) Routes

Creating a Static Route

Step 4) Troubleshooting

Configuring Call Trace

• T1/E1/J1 interfaces
• DS3 interfaces
• SONET/SDH interfaces

To create a new line interface:

1- Select Tdm Interfaces-->Line Interfaces from the navigation panel

2- Click Create New Line Interface to create a single interface ,or Create Multiple Line Interfaces to create many interfaces at once

3- Create the new line interface:

• Enter a name for the interface
• Set a type for the interface
• Set a local index for the line
• Select a length and an encoding scheme
• Click Create

4- Verify that the "Line interface was successfully created" message is displayed

The E1/J1/T1 line services are also known as trunks or spans.

To create a new line service:

1- Select Tdm Interfaces-->Line Interfaces from the navigation panel

2- Click Edit next to the line service for which you wish to create a line service

3- In the following window, click Create New Child Line Service (also, a number can be created at once by selecting Create Multiple Child Line Service)

4- Create the new Child Line Service:

• Enter a name for the new line
• Select an available local index, from the drop-down box
• Select appropriate framing and loopback modes
• Click Create

5- Navigate back to the line interface page, by following link displayed in the upper-left corner of the screen. The new line service should be displayed in the Line Services list

Upload a SN10K License file

• Log in the web portal and click the 'Status' -> 'Hosts' tab.
• Click on one of the 'Ready host list' link.
• Select 'Upload License' from the drop down box.
• Click the 'Browse...' button and select the License file.
• Once the file selected, click the 'Apply action' button.
• This process will take a while, depending on the speed of the connection to the Web Portal.  
• The license file should load immediately and show you the progress. 

2- Click Create New Route Column on the static routes page

3- Create 2 New Route Column: (Use one of the values listed below.)

• Enter a name for the column
• Type Attributes: text
• Default: What you want to be changed to

4- Valid values for NOA:

• unknown_number
• international_number
• national_number
• subscriber_number
• network_specific
• network_routing_national_format
• network_routing_international_format
• abbreviated_number
• subscriber_number_operator_requested
• national_number_operator_requeste
• international_number_operator_requested
• no_number_present_operator_requested
• no_number_present_cut_through_call_to_carrier
• test_line_test_code
• non_unique_subscriber_number
• non_unique_national_number
• non_unique_international_number
• call_950_number
• national_number_with_transit_network_selection
• international_number_with_transit_network_selection

 Click here for instructions with screen shots.

Step 1: Create different MTP3 Point Code for signaling and for voice Traffic

Click Point Codes in the navigation panel

Click Create New Point Code

Configure the new point code:

   Enter a name for the point code

   Select a point code type (select type-specific parameters)

   Select a point code length (14, 16, 24 bits)

   Enter a point code

   Click Create Repeat above steps for creating a voice traffic PC

Step 2: Create different MTP3 Routes for signaling and voice traffic

Click Create New Mtp3 Route in the MTP3 network configuration window:

Configure the new MTP3 route:

   Enter a name for the route

   Select a point code for the route

   Select a point type

   Check the Route to Adjacent box, if this route is directed to an adjacent network

   Click Create

Repeat above steps for voice traffic MTP3 Route.

Associate the newly created routes with your MTP3 linkset:

   Select a linkset from the list provided at the bottom of the route configuration window

   Click the "<<" button to associate the linkset with the newly created route

address-complete-indication accept set

Once this is set in the interface, the SmartNode will no longer send out the SETUP ACK.

General Usage

Link accounting and authentication together logically

This allows to specify that whenever one of the two associated server is the Current one, then the other one should also be set as the current one.

So both servers have to be the 'current' at the same time.

Sends Acct/Auth requests to the same physical RADIUS server

The association resolves a problem when you would have two physical RADIUS servers, each server hosts an accounting and authorization server, and you have a limitation on the Radius server to run the primary accounting and authentication on the same server (identical IP).

A specific scenario

There are 2 Radius AUTH servers provisioned (RadSRV1 & RatSRV2) and 2 Radius ACCT servers provisioned (the same RadSRV1 & RadSRV2)

So there are 3 different possibilities for switchover:

1. SmartMedia will work with RadSRV1 as master for ACCT and AUTH
2. In case of external failure SmartMedia will switchover both stacks ACCT and AUTH to RadSRV2 
3. In some specific cases of external failures SmartMedia will switchover only one stack, so we will have AUTH to RadSRV1 and ACCT to RadSRV2:

• Either: AUTH to RadSRV1 and ACCT to RadSRV2
• Or: ACCT to RadSRV1 and AUTH to RadSRV2

In this case, associating the accounting and authentication to the same IP will prevent occurrence of scenario 3.

Multiple Radius Servers

SmartMedia Radius AUTH/ACCT can be provisioned with several Radius servers (not only two). Each Radius client processing AUTH and ACCT are flexibly configurable by:

• Use polling (Status-Server)

• Requests timeout and number of retries

Current(Primary) Radius AUTH/ACCT server selection

• If polling is enabled, the selected "Current" server will be the first that responds to the polling requests.

All other servers in the list will be flagged as "online" or "offline" depending whether it responses to the polling.

• If polling is disabled, the server is selected in a round robin order, the first being tested successfully is the "Current".

All other servers in the list will be flagged as "online" or "offline" depending whether it responses to requests within the timeout and retries.

Radius AUTH/ACCT switch-over

Let's take this scenario to explain the Radius AUTH/ACCT switchover feature:

• We have servers A and B, both 'online', and server A is 'Current'.
• Request W is sent to server A.
• Request X,R,Z are in the queue sent to server A.
• Server A doesn't respond to Request W. In consequence, server A is qualified as 'offline' and server B is elected as 'Current'.
• Request W is then sent to server B.
• All new requests M,Y,Q will be sent to server B.
• The Request X which is in queue to A, will be sent to A. If A is still qualified as 'offline'. It will be then sent to B.
• If server A is back qualified as "online". It will process the request X.
• The requests R,Z in queue will be processed same as X.

CDR Redundancy

Radius redundancy

More than one radius server can be configured. When a server starts responding, the RADIUS client will flag this server as 'online'. When a server is flagged as 'online' and there are no other 'online' servers at that time, the server is elected as 'current' (primary). All new CDR records will be sent to the primary, until it no longer responds. This list of Radius servers can be configured here:Configuring Radius

With version 2.7, SmartMedia fully supports redundancy on Radius authentication and accounting. See below link to know how it works:

• Radius Accounting and Authentication Redundancy

Radius and Text CDR

This will send records to the Radius servers list and will also store it in Text CDR.

Text CDR fallback

This functions will only be used if there are no Radius servers 'online', or if the records queue is full. Otherwise, it works the same way as Text CDR.

Text CDR on Redundant servers (CDRs on both servers)

If you are using a SN10300, both Control Hosts can log Text CDRs locally. Text CDRs are not copied between hosts, therefore it is necessary to gather the CDRs from both hosts.

How does it work?

There are two cases where the RADIUS client will consider that a CDR record couldn't be sent:

Request timeout

When a CDR record is received by the RADIUS client and the number of concurrent records is not reached, it is assigned to the server which is considered 'current' (primary) at the time. It might be a server that is currently offline. A request is first sent. If it times out (according to the configured timeout for that server), the request is sent again (up to the number of configured Retransmissions). If all the retries timed out, the server is flagged as 'offline', a new 'current' (primary) server is elected and the record is discarded (that is reflected in the "Acct unanswered record cnt" status item).

Record queue full

When the number of records reach the "maximum accounting queued records" (default 12,000) the records will be discarded. This is shown in the "Acct overflow record cnt" status item.

Text CDR Fallback

In both cases, if text CDR fallback is configured, it will be forwarded to the text CDR module. Otherwise, the record is lost forever. There is no exception to that procedure. Even if all RADIUS servers are considered offline at some point, all CDR records will still be sent to all RADIUS servers, regardless if text CDR fallback is enabled.

SS7 is a signaling protocol which is used to set up and tear down phone calls. It also provides support for such functionality as local number portability, Short Messaging Service (SMS), prepaid billing and number translation.

The configuration of SS7 requires that the physical layer, through to the transport layer, and up to the application layer be configured. SS7 configuration involves configuring values for MTP2 Layer, MTP3 Layer, SCCP, and ISUP.

A conceptual illustration of the SS7 protocol stack is shown below. In the SS7 architecture, every layer has very specific task and responsibilities to provide to upper layers. Looking at the figure below we see that a SS7 stack covers all levels of the OSI model from physical to application layer. Within this model, it is possible to replace one of more layers by another protocol as long as it provides the same functionalities. In a base call control application over a TDM network, the SS7 stack required would include layers MTP1 Layer, MTP2, MTP3 and ISUP or TUP.

It is worth pointing out that, by being layered in different functional groups, SS7 was built so that different nodes in the network don’t need to implement every portion of the protocol stack if they don’t require to.

SmartMedia and SS7

SmartMedia provides SS7 support with all of SN10k mediagateways. SS7 functionality is licensed separately and can be provided at initial purchase or added later on via a software license upgrade.

SS7 signaling is configured once for the entire SmartMedia system. Any SN10k unit is capable of running the entire SS7 signaling stack for all the SN10k units in a system (applicable for SN10300).

Systems developed using SmartMedia hardware can support up to a maximum of 64 OPC, and it's worth mentioning that on SN10300 Cluster together with shared stack capability it's possible to run multiple SN10300 Units with one OPC.

High availability (HA) has been designed into the architecture of the SN10k product such that the failure of an SS7 stack on one SN10k unit will be taken over by the SS7 stack of another SN10k unit.

Maximum Capacity

Supported SS7 Link types

Typically:

• A Link
• F Link

The following types are also supported in some circumstances:

• B/D Link
• C Link
• E Link

Supported standards and variants:

• MTP2
• MTP3
• ISUP

To upgrade the amount of VoIP Channels in your SN10k, you will need to first purchase the license and hardware upgrade.

SNSW-SN10200-16E:
SmartNode SmartMedia (SN10200 and SN10300 models only) 16 T1/E1 with 512 VoIP Channels, Hardware & Software Upgrade

See how to install the license here.

Below are the steps to install the hardware:

Before starting the procedure, please read this entire document before starting and make sure you have all of the required information, tools and setup ready to ensure a quick upgrade procedure. The overall procedure will take approximately 30 minutes to complete.

Required hardware tool:

• Philips #1 screw driver

SN10K VoIP Hardware upgrade kit:

• 1x SoDimm VoIP upgrade mezzanine
• 2x Metal screw

SN10K VoIP Hardware upgrade installation:

• Remove the 2 metal screws retaining the top cover on each side of the SN10K 2U

• Loosen the thumb screw with a Philipp’s screw driver (if you cannot do it with your fingers)

• Slide the cover to remove it from the chassis

• Roll up one end of the wrist wrap to your wrist

• Attach the copper tape to the chassis of the power supply

• Locate the lowest numbered available VoIP SoDimm slot

• Install the VoIP Mezzanine in lowest numbered available SoDimm slot

• Ensure VoIP mezzanine is properly clipped onto the SoDimm connector

• Install the screws (do not over tighten) with the #1 Philips screw driver

Top cover installation:

• Put back the top cover by sliding it into the chassis.

• Screw on the thumb screw

• Put back the 2 top cover metal screws on each side of the SN10K.

End of procedure

A regular expression is a sequence of characters that forms a search and replace pattern. This is useful to modify the called or calling number digit strings. The version used in the SmartMedia SN10K units is based on PERL regular expression.

The Rule:

The remapped called number mask or remapped calling number mask must have 2 regular expressions, and it must be in the form of '/regexWithCapturingGroup/replaceString/'. In the first regular expression, you specify capturing groups using parentheses (...) while in the second regular expression, you specify how to remap the number by referencing the capturing group using \1, \2, etc.

Please refer to the Quick Reference Table below.

Example 1:

If you need to match a called number starts with the digits 450 and then 7 other digits, please put this in the called number mask:

/^450[0-9]{7}$/

^ means the matching is done from the beginning of the number.  $ means the matching is done to the end of then number. 450 is the exact prefix to match. [0-9]{7} means there should be 7 occurrences of the digits 0 to 9. [1-9]{7} would mean 7 digits, excluding 0.

Example 2:

In this example, we have to match a called number starts with optional 1, then digits 450 and then 7 other digits.

/^1?450[0-9]{7}$/

? means the preceding pattern, i.e. the digit '1', is optional.

Example 3:

In this example, we have to match a called number with 4 possible prefixes followed by 7 other digits.

/^(800|888|877|866)[0-9]{7}/

In this example, we have 2 independent regular expressions. The first one match prefix '800' with 7 digits, second match prefix '88' with 8 digits.

/^800[0-9]{7}$|^88[0-9]{8}$/

The | (pipe character) means "or"

Example 4:

In this example, we have to match a called number with a prefix followed by 6 to 11 digits.

/^880([0-9]{6,11})$/

Example 5:

In this example, we want to match any digit string that doesn't start with 080.

/^(?!080)([0-9]*)$/

The ?! is the not operator (everything except this)

Example 6:

In the remapped called number mask, the following is specified:

/^(1?)450([0-9]{7})$/\1514\2/

The first regular expression is '^(1?)450([0-9]{7})$'. There are 2 capturing groups. The first one is '(1?)', the optional digit '1'. The second one is '([0-9]{7})', the 7 digits following '450'.

The second regular expression is '\1514\2' which specifies how the remapped number is composed. In this example, let us suppose that the incoming call has the called number as '15141234567'. The digit '1' in the beginning matches the first capturing group '(1?)' and the digits '1234567' match the second capturing group '([0-9]{7})'. Therefore, the remapped called number would be '1' followed by '514' followed by '1234567', that is '15141234567'.

Example 7:

This is a simpler example in which the remapped called number mask would remove the prefix '852' while keeping the 8 digits following the prefix.

/^852([0-9]{8})$/\1/

First group between parenthesis are the 8 digits after the 852. The output number will be the 8 digits after 852 (represented by the first group "\1" used in the seconds section of the regex)

Quick Reference Table:

Here are some examples:

Add 2720 prefix:

/^(\d+)$/2720\1/

or

/^([0-9]*)$/2720\1/

Strip first 4 digits:

/^([0-9]{4})([0-9]*)$/\2/

Strip # and 7 first digits:

/^([#])([0-9]{7})([0-9]*)$/\3/

VoIP Bonding refers to the SmartNode10k capability to use two available VoIP Ethernet ports as a bonding pair. When the active port becomes unusable (cable disconnected, limited connectivity), other port is used to transport Ethernet traffic.
VOIP interface bonding is available starting with SmartMedia release 2.7.34. Detection of port failure is currently achieved using two methods:

1. Ethernet PHY polling for ethernet cable presence in VoIP interface
2. Sending IPv4 ping requests to a known host to ensure that a logical IP path is available to the unit.

The voip0 (first VoIP port) MAC and IP addresses are used on both VoIP ports of SmartNode10k when VoIP bonding is activated. In bonding mode voip1 port MAC and IP address are not usable (f.e. protocol stacks assigned to voip1 will not work and voip1 will not respond to ICMP requests). Therefore IP services and stacks (such as SIP, SIGTRAN and port ranges) must be assigned to voip0 exclusively.
VoIP Bonding feature also causes the SmartNode10k report the state of the bonding pair only as the voip0 interface. For instance the IPv4 statistics reported by the Web Portal for voip0 are effective for the whole bonding pair. The PHY state is also corresponding to the bonding pair (so it would only be down if both voip ports are down). To know the true state of the physical voip0 and voip1 ports, the SNMP protocol must be used.
The feature has no effect on Virtual IP Interfaces configured in the Web Portal. Virtual IP Interfaces configured on either voip0 or voip1 physical ports still work exactly the same way not minding the VoIP Bonding.

Web Portal presentation

VoIP0 Port Status

Since VoIP0 and VoIP1 are bonded together, VoIP0 represents an aggregated status of the bonded ports. This means VoIP0 will be shown as "RED" only if both VoIP0 and VoIP1 ports are unavailable.

VoIP1 Port Status

VoIP1 port status represents its own physical connectivity.

Web Portal Status menu behaviour

VOIP interface states will be displayed in 'Menu -> Status -> Hardware Units -> IP Interfaces' the following way

Implementation

VOIP bonding feature requires performing reconfigurations on SmartNode10k unit TelcoBoard level, which needs to performed by Patton Electronics Engineer. Please contact Patton Support for assistance.

MTP3 Features

MTP3 SmartMedia implementations delivers the following features:

• Acts as a signaling point (SP) or signaling transfer point (STP)
• Handles either national or international signaling traffic
• Supports national option with and without multiple congestion priorities
• Supports message discrimination function. If the signaling point is the destination point, the message is delivered to the message distribution function. If the signaling point is not the destination point, and the transfer capability is enabled, the message is delivered to the message routing function
• Supports message distribution function. Delivers a message to the appropriate user part or MTP3 function based on the service indicator.
• Supports message routing function. Selects the appropriate signaling link for the transmission of messages. Performs load sharing between links or linksets
• Uses signaling traffic management procedures to divert signaling traffic from signaling links or signaling routes. Also used to temporarily reduce the quantity of traffic in case of congestion. The following signaling traffic management procedures are supported:
  • Changeover
  • Changeback
  • Forced rerouting
  • Controlled rerouting
  • Signaling point restart
  • Management inhibiting
  • Processor outage

NOTE: The signaling point restart is not required for certain country variants, and can be disabled through configuration.

• Uses signaling link management procedures to control the local signaling links. The following basic signaling link management procedures are supported:
  • Signaling link activation
  • Signaling link restoration
  • Signaling link deactivation
  • Linkset activation (normal and emergency restart)
  • Signaling link congestion
  • Signaling link test
  • Signal routing test (only for TTC/NTT, Japan)

• Uses signaling route management procedures to ensure a reliable exchange of information between signaling points concerning the availability of signaling routes. The following signaling route management procedures are supported:
  • Transfer prohibited
  • Transfer cluster prohibited (ANSI/Bellcore)
  • Transfer allowed
  • Transfer cluster allowed (ANSI/Bellcore)
  • Transfer restricted
  • Transfer cluster restricted (ANSI/Bellcore)
  • Transfer controlled (international and national with congestion priorities)
  • Signaling route set test
  • Signaling cluster route set test (ANSI/Bellcore)
  • Signaling route set congestion test
  • Broadcasting of route management messages (such as transfer prohibit and transfer allowed) with multiple point codes (only for TTC/NTT, Japan)

NOTE: Transfer restricted, MTP restart, and route-set-congestion test procedures are national options and can be enabled or disabled through configuration. Supporting multiple congestion priorities is also a national option and can be controlled through configuration. The incoming cluster route management messages (TCP/TCR/TCA/RCP) are handled by MTP3. MTP3 software does not generate cluster management messages and cluster routing.

*SN10300 is a Cluster based system introducing few dedicated HA functionalities, which can be found in this article

1. Single MGW HA design

a) PSU failover
- hot swappable PSUs with realtime failover

b) SS7/MTP3 signaling link failover

c) TDM Clock failover between Line Services

d) Automatic protection mechanism on the TelcoBoard
- On board process monitoring: dead-lock or crashed process are automatically detected and board is rebooted to ensure minimal downtime.
- HW Watchdog: When a SmartMedia system is active, the TelcoBoard is polled continuously by the System Manager. If this polling stops, it means the TelcoBoard lost contact with the SmartMedia applications and it will reboot automatically if communication is not restored in a timely manner.

e) IP Network (SIP Signaling)
For outgoing calls, the system can be configured such that you can use alternate addresses to reach the SIP Proxy, so if one network path is down, it will use the other one. For incoming calls, you can configure SIP stacks on two separate ip interfaces so that if one is not reachable by a peer, the second can be reached. Note however that mechanism such as virtual IP is present only in 1+1 HA model between Units, so the peer SIP agent must be configured with the 2 ip addresses used on the TelcoBoard and it must be able to switch from one to the other if one is down.

f) IP VOIP interfaces bonding
On version 2.7 of SmartMedia bonding of VOIP interfaces was introduced making configuration of 1 IP on two interfaces possible.

g) IP Network (Voice Path)
We support redundant voice path for SIP calls. If one path is down, the other one will be selected for all new calls. If both path are up, they can be used in load sharing.

h) Flexible IP (SmartMedia 2.8 and above)
Version 2.8 allows creating multiple dot1q VLAN based Virtual Interfaces on Physical Interfaces and assigning them different roles. Also bonding is possible on all TelcoBoard interfaces (not only VOIP01 and VOIP1).

i) STM1 - Automatic Protection Switching
STM1 versions of SN10k support a linear topology APS fiber protection for 1+1 configurations only. In some implementations this standard is also called MSP 1+1 (Multiplexing Section Protection).

2. 1+1 Active/Standby HA design

1+1 HA model consists of a Master (regular) SN10k Unit, a special Backup (+1) SN10k Unit and a passive 1+1 patch panel. Below you can find an example SN10200/STM1 1+1 setup

Most outstanding feature in this setup would be the 1+1 patch panel, which allows to connect the Active/Standby pair to one (shared) TDM Line. During normal operations the Active MGW processes all of the calls and holds both Active TDM Signaling stack and Virtual IP. Backup unit is Idle and monitoring the Active MGW with special heartbeat protocol. In case of disaster Backup Unit recovers the Virtual IP and activates TDM Stack.

Virtual IP is based on a proprietary protocol working as a floating IP, announcing the MAC Address switchover with a Gratutious ARP.

Simplified diagram of 1+1 setup during normal operation

Simplified diagram of switched 1+1 setup

HW Architecture
SN10k architecture design is based on division of Application processing (Control Host) and Real Time Traffic (TelcoBoard) on the hardware level:

Such approach unleashes a remarkable call processing power and also allows to fully use the 1+1 potential, mainly because crossover control ability between Control Hosts and TelcoBoards.

Application Level failover in 1+1
All SmartMedia applications support Active-Standby mode so you can have two hosts, each having a running instance of our SmartMedia application. If the active server crashes, the application on the standby server will take the relay. Furthermore, on each host, SmartMedia installs a service that monitors all SmartMedia application and that automatically restart crashed or deadlocked applications.

Configuration Database HA in 1+1
We also support HA at the DB level. SmartMedia can configure 2 DB Server and setup replication between them so that all changes made to the Master DB are replicated on the Slave DB. If the Master DB is lost, SmartMedia will automatically switch to using the Slave DB. After the failure the Database roles are switched, to ensure proper replication.

IP Network (GW Control and Managment) (1+1)
All communications between application<-->application, application<-->TelcoBoard, TelcoBoard<-->TelcoBoard are done using redundant ip interfaces. This is build from the ground up in all our code.

1+1 Redundancy mechanism
a) SmartMedia Heartbeat application will control which unit is active
b) In case of failure:
- Primary unit is restarted (to clear any configuration) by Heartbeat or HW Watchdog
- SS7, SIP, ISDN stacks and resources are allocated on the secondary unit
- Virtual IP is transferred to secondary unit - proprietary low level driver API

1+1 failure scenarios:
a) Switchovers without loss of active calls:
- SmartMedia stopped on one of the units
- An application is shutdown
b) Switchovers causing loss of all calls:
- TelcoBoard unit shutdown
- TelcoBoard reboot requested
- Package installation
- Primary unit is back (and auto-switch-back is used)
c) Host applications switchovers (no loss of active calls)
- Application crash
- Control Host crash
d) TelcoBoard switchovers (loss of active calls)
- Process crash on the telecom board
- Loss of communication with the telecom board

Materials needed

 

You'll need a Cat5 cable end, some Cat 5 cable (just a few inches needed), and a Cat 5 cable crimper & cutter.

 

2 Steps:

1. Cut off about 2 to 4 inches of a Cat 5 cable 
2. Take off the casing 
3. Separate 2 of the 8 wires for use... usually same colors (brown and brown/white, etc.) 
4. Identify the pin order on the Cat 5 end: hold it with the movable/press-side of the clip away from you and the metal contacts facing left. If you are looking at it this way, the bottom slot is pin 1 and the top is pin 8. 
5. Put one end of the first wire (either one will do) into pin 1 and bend it in half and put the other end of it into pin 4. 
6. Put one end of the second wire into pin 2 and bend it in half and put the other end into pin 5. 
7. You should now have 2 wires "looped" in the cat 5 blank end with pin 1 connecting pin 4 and pin 2 connecting pin 5 
8. Put the Cat 5 end into the crimper and verify all of the wires are pushed all the way into the pin slots and then crimp it down. 
9. Test it on a "known good" router with a CSU/DSU (T1 interface). Place the loopback plug into the T1 port and you should see the unit "synch" to itself by indicating either "Link" or having whatever is used for the WAN interface to show the unit now has sync. If it does, you've successfully built the plug. If it doesn't work, you've either built it wrong or the CSU/DSU isn't working properly.

 

3 Steps:

How to use the loop plug

1. Let your ISP know you have a loopback plug. 
2. They will likely want you to plug it into the "smart jack" (the final hand-off point from the local phone company. 
3. The loopback plug will allow the local phone company to test THROUGH THE SMART JACK and verify if the service is working properly through that point. 
4. Once service is verified through the Smart Jack, you should see if you can plug the loopback plug at the end of your Internal (or Inside) wiring. If you have a buscuit jack at the end of an extension from the smart jack, you can plug the loopback plug into it and the ISP can tell you if you are "clean" through the Inside Wiring.

 

4 Steps:

Exception

It IS possible for the test to be good through the loopback plug and there STILL BE AN ISSUE with the local phone company's wiring. In rare cases, the copper pairs may be "rolled." This means that the 4 wires used to provide the T1 service are wired in reverse where Transmit 1/Receive 1 are actually wired to Transmit 2/Receive 2 somewhere along the route. In this case, the loop test will perform properly, but the T1 service will not work. If you suspect this, you should ask the ISP to dispatch the local phone company to "Prove through the demarc/Smart Jack." This will force the local phone company to dispatch to your site and test head-to-head with the local Central Office to prove the service is good. There sometimes may be a charge associated with this dispatch IF IT IS FOUND THAT YOUR EQUIPMENT OR WIRING IS THE CAUSE OF THE OUTAGE.

 

Conclusion

Ultimately, the ISP is "responsible." However, having this simple piece of network test gear can speed up the process of a T1 repair and troubleshooting. In the end, restoring your service as quickly as possible is the ultimate goal and this will help you achieve that goal!

SN10k software SmartMedia supportes basic SNMP implementations in versions 1,2 and 3. Users are allowed to remotely poll (or GET) system variables, known as SNMP Managed Objects, which are defined in files known as MIB modules. In the opposite direction SmartMedia provides messages called SNMP Traps, triggered on some specified system events. Current implementation allows polling based on standard MIBs and proprietary specification (SN-MIB)

SN-MIBs download

SmartMedia 2.7 MIB

SmartMedia 2.8 MIB

Supported SNMP MIB modules

1. RFC 1213 MIB II (RFC1213-MIB)

   • All tables of the RFC1213-MIB are supported, with the exception of:
     • ipRouteTable
     • EGP group
     • atTable

2. RFC 1573 Evolution of Interfaces Group of MIB-II (IF-MIB)

   • The following tables are supported:
     • ifTable
     • ifStackTable

3. RFC 2495 DS1, J1, E1, DS2, and E2 Interfaces (DS1-MIB)

   • The following tables of the DS1-MIB are supported:
     • Dsx1ConfigTable
     • Dsx1CurrentTable
     • Dsx1IntervalTable
     • Dsx1TotalTable

4. RFC 2496 - Definitions of Managed Object for the DS3/E3 Interface Type (DS3-MIB)

   • The following tables of the DS3-MIB are supported:
     • Dsx3ConfigTable
     • Dsx3CurrentTable
     • Dsx3IntervalTable
     • Dsx3TotalTable

5. RFC 1595 - Definitions of Managed Object for the SONET/SDH Interface Type (SONET-MIB)

   • The following tables of the SONET-MIB are supported:
     • sonetMediumTable
     • sonetSectionCurrentTable
     • sonetSectionIntervalTable
     • sonetLineCurrentTable
     • sonetLineIntervalTable
     • sonetFarendLineCurrentTable
     • sonetFarendLineIntervalTable
     • sonetPathCurrentTable
     • sonetPathIntervalTable
     • sonetFarendPathCurrentTable
     • sonetFarendPathIntervalTable
     • sonetVtCurrentTable
     • sonetVtIntervalTable
     • sonetFarendVtCurrentTable
     • sonetFarendVtIntervalTable

6. RFC 2127 - ISDN Management Information Base using SMIv2 (ISDN-MIB)

   • The following tables of the ISDN-MIB are supported:
     • isdnBearerGroup
     • isdnSignalingGroup

7. SmartNode 10k proprietary MIB module (SN-MIB)

   • snHwCommon
     • snHwIdentTable (Hardware Identification)
     • snHwVersionTable (Hardware Version)
     • snHwTempTable (Hardware Temperature)
     • snHwPowerSupplyTable (Hardware Power Supply) - SmartMedia 2.8 only
     • snHwFanTable (Hardware Fan) - SmartMedia 2.8 only
   • snSwCommon
     • snFeatureTable (Software Features Supported)
     • snSwVersionTable (Software Version)
     • snSwPerfTable (CPU Usage)
   • snSignaling
     • snMtp2
     • snM2pa
     • snM2ua
     • snM3ua
     • snIua
     • snIsdn - SmartMedia 2.8 only
     • snCas - SmartMedia 2.8 only
     • snSip
     • snH248 - SmartMedia 2.8 only
   • snCalls - SmartMedia 2.8 only
   • snNAP - SmartMedia 2.8 only
   • snHaNp1 - SmartMedia 2.8 only
   • snHaApp - SmartMedia 2.8 only
   • snClock - SmartMedia 2.8 only
   • snLeafLineServices - SmartMedia 2.8 only

SNMP IF-MIB ifTable interface type

Following table specifies the interface types supported by SN10k with reference to IF-MIB (ifTable) and some human readable description. The ifType are described in Internet Assigned Number Authority (IANA) in IANAifType-MIB

SNMP traps

SNMP Trap module implemented in SmartMedia monitors internally the state on some OIDs and triggers suitable notifications in case of a change. Default polling interval for internal polling is set to 1 minute. This value can be modified in the SnmpAgent configuration.

IF-MIB SNMP Trap/Notification (see RFC1573.txt)

SmartNode 10k SN-MIB SNMP Trap/Notification

SNMP SET

Current implementation of SNMP in SmartMedia doesn't support the SNMP SET configuration directive.

SNMP Configuration Tasks

SmartMedia SNMP configuration tasks are oriented on application called SnmpAgent:

SnmpAgent activation

SnmpAgent configuration

Example SNMP GET and TRAP operations:

SN10k SNMP GET and TRAP example

Before proceeding with the following text please make sure that you are familiar with  SN10k SNMP - supported MIBs KB article. Please also ensure that the SnmpAgent application is running on your system - suitable reference can be found at the end of above article.

SN10k SNMP GET

In this example we will try to read ISDN and SIP NAP availability percentage from a SN10k gateway running 2.8.25 SmartMedia. We will perform the test from a Debian Linux operating system running 'snmp' deb package in version 5.4.3 and 'snmp-mibs-downloader' in version 1.1.
SN10k mgmt0 interface is addressed as '10.9.31.100' and the RO SNMP community is 'public'.

Firstly we need to download the 2.8 MIB file archive and decompress it contents:

root@sandbox:~/2015-04-28_SN10k_snmpTest# wget "http://www.patton.com/support/upgrades/agree.asp?rm=MIBS&path=SmartMedia-MIB.zip" -O SmartMedia-MIB.zip && unzip SmartMedia-MIB.zip && rm SmartMedia-MIB.zip

Then we need to check where the system stores MIB files

root@sandbox:~/2015-04-28_SN10k_snmpTest# net-snmp-config --default-mibdirs
/root/.snmp/mibs:/usr/share/mibs/site:/usr/share/snmp/mibs:/usr/share/mibs/iana:/usr/share/mibs/ietf:/usr/share/mibs/netsnmp

We will copy the downloaded mib to the directory located in current users home: '/root/.snmp/mibs' and create it if necessary

root@sandbox:~/2015-04-28_SN10k_snmpTest# if [ ! -e /root/.snmp ]; then mkdir /root/.snmp && mkdir /root/.snmp/mibs; fi; cp -vf SN10k-MIB.mib /root/.snmp/mibs

Now we will check if the MIB compiles properly and if we can reach the SN10k SnmpAgent process. Name of SNMP SN10k MIB module is 'SN-MIB' so we will use it as both input MIB and STDOUT filter. Following procedure will take some time since it queries all of available OIDs on the system

root@sandbox:~/2015-04-28_SN10k_snmpTest# snmpwalk -v2c -c public -m SN-MIB 10.9.31.100 | grep -iE SN-MIB

Result will contain many lines, most of them similar to following:

SNMPv2-SMI::mib-2.1.2.0 = OID: SN-MIB::snDirectory
SNMPv2-SMI::mib-2.88.1.2.2.1.6.10.115.110.109.112.100.46.99.111.110.102.71.101.110.101.114.97.116.101.32.65.112.112.72.97.83.116.97.116.101.49 = OID: SN-MIB::snHaAppHaCurrentState
SNMPv2-SMI::mib-2.88.1.2.2.1.6.10.115.110.109.112.100.46.99.111.110.102.71.101.110.101.114.97.116.101.32.65.112.112.72.97.83.116.97.116.101.50 = OID: SN-MIB::snHaAppHaCurrentState

In case you receive output similar to following, it means you are missing some standard SNMP MIB modules on your linux machine.

Unlinked OID in SN-MIB: 
Cannot adopt OID in SN-MIB: 

Next step will be to list all SNMP available NAP statistics. In 2.8 MIB file on line 2784 we can find a suitable object for this task:

snNapTable OBJECT-TYPE
    SYNTAX SEQUENCE OF SNNapEntry
    MAX-ACCESS not-accessible
    STATUS current
    DESCRIPTION
        "Lists NAPs statistics information."
    ::= { snNAP 2 }

We can issue a snmpwalk on this table to see what will be the returned values:

root@sandbox:~/2015-04-28_SN10k_snmpTest# snmpwalk -v2c -c public -m SN-MIB 10.9.31.100 SN-MIB::snNapTable

Result will be quite a long list of parameters with two looking mostly interesting:

• SN-MIB::snNapName
• SN-MIB::snNapAvailablePercent

If we will perform a snmpwalk on the first one, we will receive names of NAPs configured on the system with corresponding object identifier

root@sandbox:~/2015-04-28_SN10k_snmpTest# snmpwalk -v2c -c public -m SN-MIB 10.9.31.100 SN-MIB::snNapName
SN-MIB::snNapName.6 = STRING: NAP_SIP_FS5062
SN-MIB::snNapName.7 = STRING: NAP_ISDN_SN4950E1_0

Above results present only two NAPs I have configured on the testing system, which means the questy worked as expected. What's left is to issue a 'snmpget' command and retrieve the availability percentage of both NAPs:

root@sandbox:~/2015-04-28_SN10k_snmpTest# snmpget -v2c -c public -m SN-MIB 10.9.31.100 SN-MIB::snNapAvailablePercent.6
SN-MIB::snNapAvailablePercent.6 = INTEGER: 100
root@sandbox:~/2015-04-28_SN10k_snmpTest# snmpget -v2c -c public -m SN-MIB 10.9.31.100 SN-MIB::snNapAvailablePercent.7
SN-MIB::snNapAvailablePercent.7 = INTEGER: 50
root@sandbox:~/2015-04-28_SN10k_snmpTest#

Queries retured following data:

• NAP_SIP_FS5063 is available in 100% - which is true since the SIP server is UP and responds to SIP OPTIONS
• NAP_ISDN_SN4950E1_0 is available in 50% - which is true as well since this NAP is combined from two ISDN interfaces and one of them is disabled

The only remaining task is to gather numeric OIDs for your NMS system. In order to monitor fe. the availability percentage of NAP_SIP_FS5062 and present it's name

root@sandbox:~/2015-04-28_SN10k_snmpTest# snmptranslate -On SN-MIB::snNapName.6
.1.3.6.1.4.1.1768.400.5.2.1.1.6
root@sandbox:~/2015-04-28_SN10k_snmpTest# snmptranslate -On SN-MIB::snNapAvailablePercent.6
.1.3.6.1.4.1.1768.400.5.2.1.19.6

Of course be sure to implement the SN-MIB into your NMS system!

SN10k SNMP Trap

In order to receive SNMP Trap events I have launched a 'snmptrapd' daemon listening on port UDP/162 of our testing server IP:10.9.23.11.

root@sandbox:~/2015-04-28_SN10k_snmpTest# netstat -tulpaen | grep snmptrapd
udp 0 0 0.0.0.0:162 0.0.0.0:* 0 3912 1409/snmptrapd
root@sandbox:~/2015-04-28_SN10k_snmpTest#

SN10k configuration was done in the following way

After activating the SN10k configuration we enabled a tcpdump on the testing server and disconnected the E1 interface. Tcpdump trace returned the following values:

root@sandbox:~/2015-04-28_SN10k_snmpTest# tcpdump -i eth0 -s0 -n -v udp port 162
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
20:30:05.788731 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto UDP (17), length 248)
10.9.31.100.49135 > 10.9.23.11.162: { SNMPv2c C=SN10kSNMPTrapComTest { V2Trap(189) R=686734327 .1.3.6.1.2.1.1.3.0=354048 .1.3.6.1.6.3.1.1.4.1.0=.1.3.6.1.6.3.1.1.5.3 .1.3.6.1.2.1.2.2.1.1.452976.99=99 .1.3.6.1.2.1.2.2.1.7.452976.99=1 .1.3.6.1.2.1.2.2.1.8.452976.99=2 .1.3.6.1.2.1.2.2.1.2.452976.99="SN00A0BAxxxxxx ISDN Stack 1" .1.3.6.1.6.3.1.1.4.3.0=.1.3.6.1.4.1.8072.3.2.10 } }
20:30:05.791278 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto UDP (17), length 252)
10.9.31.100.49135 > 10.9.23.11.162: { SNMPv2c C=SN10kSNMPTrapComTest { V2Trap(193) R=686734329 .1.3.6.1.2.1.1.3.0=354049 .1.3.6.1.6.3.1.1.4.1.0=.1.3.6.1.6.3.1.1.5.3 .1.3.6.1.2.1.2.2.1.1.452976.100=100 .1.3.6.1.2.1.2.2.1.7.452976.100=1 .1.3.6.1.2.1.2.2.1.8.452976.100=2 .1.3.6.1.2.1.2.2.1.2.452976.100="SN00A0BAxxxxxx ISDN LAPD Link 1" .1.3.6.1.6.3.1.1.4.3.0=.1.3.6.1.4.1.8072.3.2.10 } }
20:30:05.817901 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto UDP (17), length 202)
10.9.31.100.49135 > 10.9.23.11.162: { SNMPv2c C=SN10kSNMPTrapComTest { V2Trap(143) R=686734337 .1.3.6.1.2.1.1.3.0=354051 .1.3.6.1.6.3.1.1.4.1.0=.1.3.6.1.4.1.1768.400.1.2.1.0.1 .1.3.6.1.4.1.1768.400.5.2.1.1.7="NAP_ISDN_SN4950E1_0" .1.3.6.1.4.1.1768.400.5.2.1.2.7=1 .1.3.6.1.4.1.1768.400.5.2.1.19.7=0 } }
20:30:06.061260 IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto UDP (17), length 173)
10.9.31.100.49135 > 10.9.23.11.162: { SNMPv2c C=SN10kSNMPTrapComTest { V2Trap(115) R=686734395 .1.3.6.1.2.1.1.3.0=354076 .1.3.6.1.6.3.1.1.4.1.0=.1.3.6.1.4.1.1768.400.1.2.1.0.8 .1.3.6.1.4.1.1768.400.3.6.2.1.2.1="ISxxxxxx_00" .1.3.6.1.4.1.1768.400.3.6.2.1.3.1=0 } }

Remember that SNMPTrap daemon scans the SN10k Unit state accordingly to the interval configured in: 'Menu -> Applications -> SnmpAgent -> Application Parameters -> Advanced SNMP Parameters -> Polling delay to generate traps', so please provide a value suitable to your application needs, although having in mind that scans performed too oftenly can have a negative impact on your system performance.

Using a tool called 'snmptranslate' and Trap OID description from KB article SN10k SNMP - supported MIBs we can try putting more meaning for example to below line

10.9.31.100.49135 > 10.9.23.11.162: { SNMPv2c C=SN10kSNMPTrapComTest { V2Trap(143) R=686734337 .1.3.6.1.2.1.1.3.0=354051 .1.3.6.1.6.3.1.1.4.1.0=.1.3.6.1.4.1.1768.400.1.2.1.0.1 .1.3.6.1.4.1.1768.400.5.2.1.1.7="NAP_ISDN_SN4950E1_0" .1.3.6.1.4.1.1768.400.5.2.1.2.7=1 .1.3.6.1.4.1.1768.400.5.2.1.19.7=0 } }


Having in ming that SN10k proprietary SNMP module is called 'SN-MIB' and after making sure it's loaded to our system, we can proceed with following command for every OID value in the trace

root@sandbox:~/2015-04-28_SN10k_snmpTest# snmptranslate -m +SN-MIB .1.3.6.1.2.1.1.3.0 .1.3.6.1.6.3.1.1.4.1.0 .1.3.6.1.4.1.1768.400.1.2.1.0.1 .1.3.6.1.4.1.1768.400.5.2.1.1.7 .1.3.6.1.4.1.1768.400.5.2.1.2.7 .1.3.6.1.4.1.1768.400.5.2.1.19.7
DISMAN-EVENT-MIB::sysUpTimeInstance

SNMPv2-MIB::snmpTrapOID.0

SN-MIB::snNapAvailability

SN-MIB::snNapName.7

SN-MIB::snNapSignalingType.7

SN-MIB::snNapAvailablePercent.7

Which in a properly configure snmptrapd log would have the following format:

2015-04-28 20:30:06 host100.testhu [UDP: [10.9.31.100]:49135->[10.9.23.11]]:
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (354051) 0:59:00.51 SNMPv2-MIB::snmpTrapOID.0 = OID: SN-MIB::snNapAvailability SN-MIB::snNapName.7 = STRING: NAP_ISDN_SN4950E1_0 SN-MIB::snNapSignalingType.7 = INTEGER: isdn(1) SN-MIB::snNapAvailablePercent.7 = INTEGER: 0

Informing us that NAP_ISDN_SN4950E1_0 just became unavailable.

1. Single MGW HA design

a) PSU failover
- hot swappable PSUs with realtime failover

b) SS7/MTP3 signaling link failover

c) TDM Clock failover between Line Services

d) Automatic protection mechanism on the TelcoBoard
- On board process monitoring: dead-lock or crashed process are automatically detected and board is rebooted to ensure minimal downtime. 
- HW Watchdog: When a SmartMedia system is active, the TelcoBoard is polled continuously by the System Manager. If this polling stops, it means the TelcoBoard lost contact with the SmartMedia applications and it will reboot automatically if communication is not restored in a timely manner.

e) IP Network (SIP Signaling)
For outgoing calls, the system can be configured such that you can use alternate addresses to reach the SIP Proxy, so if one network path is down, it will use the other one. For incoming calls, you can configure SIP stacks on two separate ip interfaces so that if one is not reachable by a peer, the second can be reached. Note however that mechanism such as virtual IP is present only in 1+1 HA model between Units, so the peer SIP agent must be configured with the 2 ip addresses used on the TelcoBoard and it must be able to switch from one to the other if one is down.

f) IP VOIP interfaces bonding
On version 2.7 of SmartMedia bonding of VOIP interfaces was introduced making configuration of 1 IP on two interfaces possible.

g) IP Network (Voice Path)
We support redundant voice path for SIP calls. If one path is down, the other one will be selected for all new calls. If both path are up, they can be used in load sharing.

h) Flexible IP (SmartMedia 2.8 and above)
Version 2.8 allows creating multiple dot1q VLAN based Virtual Interfaces on Physical Interfaces and assigning them different roles. Also bonding is possible on all TelcoBoard interfaces (not only VOIP01 and VOIP1).

i) STM1 - Automatic Protection Switching
STM1 versions of SN10k support a linear topology APS fiber protection for 1+1 configurations only. In some implementations this standard is also called MSP 1+1 (Multiplexing Section Protection).

2. Cluster HA design

Main advantage of SN10300 series is the cluster architecture, allowing the device to achieve an additional level of High Availability. SN10300 main components are:

• SN10300/STM1/z, SN10300/xE/z, SN10300/xDS3/z - media gateway Units
• SN10300/CTRL/RUI - Control Host for the SN10300 Cluster, running applications and database
• SN10300/SMS/RUI - backplane switch, responsible for low latency, real time media, signaling and clocking transport between MGW. 

Components redundancy
SN10300 design makes possible to duplicate SN10300/CTRL and SN10300/SMS roles in the system. CTRL servers are running as a Primary Secondary pair, allowing sharing the load of running applications. Combined with Event polling from other cluster components, a rapid switchover time and service continuity is achieved in case of detected failure. 

Example SN10300 N+1 fully redundant Cluster setup:

Networking redundancy
All of the internal IP and TDM networks used to build the SN10300 Cluster are based on redundant physical and logical connections (ports and addresses)

SMS

• Prioprietary protocol
• Clocking
• Backplane circuit switching

CTRL (ETH)

• Ethernet / IP based – strict IP Addressing
• Internal network for C based API calls
• Watchdog and Heartbeat

VoIP

• SIP, RTP, SIGTRAN exclusive
• possible to run DNS queries
• VOIP0 and VOIP1 in different broadcast domains – however bonding possible

MGMT

• Web, SSH acces
• IP addressing can be chosen freely
  
  

HW Cluster Architecture
SN10300 architecture design is based on division of Application processing (Control Host - SN10300/CTRL) and Real Time Traffic (MGW Units - SN10300/STM1,xE,xDS3) on the hardware level. Such approach unleashes a remarkable call processing power and also allows to fully use the Cluster potential, mainly because the ability of sharing the load between applications running on separate servers as well as protocol stack running on MGW Units.

Application Level Cluster
SN10300 SmartMedia applications support Active-Standby mode so you can have two hosts, each having a running instance of our SmartMedia application. If the active server crashes, the application on the standby server will take the relay. Furthermore, on each host, SmartMedia installs a service that monitors all SmartMedia application and that automatically restart crashed or deadlocked applications. 

Another feature is the possibility of manually decide which server will run the Active instance of a particular application, which fe. allows isolating routing decisions from monitoring daemon operations.

Signaling Stack Cluster
Protocol stacks are run from SN10300/STM1,xE,xDS3 Units in order to ensure minimal latency in signaling processing and also to offloading for Application Servers. Signaling data after parsing is pushed via a standarized proprietary API from MGW Units to the Application Servers. Thanks to the robust SMS TDM backplane it's possible to perform signaling parsing on any MGW Unit in the Cluster, which means signaling data received on a particular MGW doesn't need to be processed there. 

What is also important the protocol stacks fe. ISUP can be run in a Active/Standby pair on separate MGW Units, causing the state information to be resillent against MGW Unit or protocol stack crashes.

Configuration Database Cluster
Sn10300 supports HA at the DB level. SmartMedia can configure 2 DB Servers and setup replication between them so that all changes made to the Master DB are replicated on the Slave DB. If the Master DB is lost, SmartMedia will automatically switch to using the Slave DB. After the failure the Database roles are switched, to ensure proper direction in replication. In order to ensure data consistency and minimize the rish of cross writing, SmartMedia is running a dedicated database replication director controlling the redundancy mechanism.

IP Network (GW Control and Managment)
All communications between application<-->application, application<-->TelcoBoard, TelcoBoard<-->TelcoBoard are done using redundant ip interfaces. This is build from the ground up in all our code.

3. N+1 Failover design

SN10300 delivers N+1 HA model, which consists of multiple Active (regular) SN10300/STM1 Units, a special Backup (N+1) SN10300/STM1BU Unit and an active N+1 STM1 patch panel. Currently the N+1 redundancy model is available only with optical interfaces (STM1/OC3). SN10300 can run up to 15 Active SN10300/STM1 Units backed up with a single SN10300/STM1BU. System can run up to two N+1 patch panels: one securing the STM1 Working Channel and second the STM1 APS Protection channel.

Simplified diagram of N+1 setup operating in normal circumstances

Most outstanding feature in this setup would be the N+1 patch panel, which allows Backup Unit to take over the STM1 line from a failed Active Unit. N+1 patch panel is controlled by the CTRL servers polling instantly the Event bus of the SN10300 Cluster. During normal operations the Active MGW processes all of the calls, receives the optical path through N+1 patch panel and holds the configured protocol stacks. In case of Active Unit failure, configuration of the failed Unit is copied to the Backup Unit, which instantly is brought online along with N+1 patch panel switching the optical path from Failed Active to Backup MGW. All of the networking configurations including MTP3 and IP are cloned to the Backup Unit. 

Floating IP is based on a proprietary protocol working as a type of FHRP, announcing the IP Address switchover to a new MAC Address with a Gratutious ARP.

Simplified diagram of a switched N+1 system

N+1 failure scenarios:
a) Switchovers without loss of active calls:
- SmartMedia stopped on one of the units
- An application is shutdown
b) Switchovers without loss of active calls running specific protocols (only SS7 call legs running on distributed signaling links are preserved*/**)
- TelcoBoard unit shutdown
- TelcoBoard reboot requested
- Package installation
- Primary unit is back (and auto-switch-back is used)
- Loss of communication with the TelcoBoard
- Process crash on TelcoBoard
c) Host applications switchovers (no loss of active calls)
- Application crash
- Control Host crash
d) TelcoBoard switchovers with loss of active call legs running non-SS7 traffic**
- TelcoBoard unit shutdown
- TelcoBoard reboot requested
- Package installation
- Primary unit is back (and auto-switch-back is used)
- Loss of communication with the TelcoBoard
- Process crash on TelcoBoard

* SIP legs resillency during N+1 switchover is currently on the Roadmap
** due to signaling design ISDN and CAS call legs can't be preserved during N+1 switchover

SmartMedia version 2.8 introduced a new feature called Flexible IP. Compared with 2.7 branch it allows almost unlimited flexibility in configuration of IP interfaces on SN10k TelcoBoards. In order to fully understand the capabilities this enhancement offer we need to get through some definitions:

• Physical Ports - those are the physical Ethernet interfaces available on the TelcoBoard, fe. SN10200 has 4 of them: ETH0, ETH1, VOIP0 and VOIP1. SN10100 on the other hand only two: VOIP0 and VOIP1
• Virtual Port - an virtual entity binding together a Physical Port (or multiple Physical Ports in case bonding is required) and a VLAN Tag (or an Untagged interface)
• IP Interface - instance grouping a Virtual Port, IP configuration and a Service Role
• Service Role - group of services that can be bound to a particular IP interface: Management (WebPortal, SSH, SNMP), H.248/RADIUS, SIP/SIP-I, SIGTRAN, RTP
• Bonding - multiple Physical Ports grouped under one Virtual Port, from which group only one interface is active at time. Mostly deployed for network failover scenarios.

Layer2 

On the Virtual Port level 802.1Q VLAN tags are supported, as well as untagged traffic. Based on the VLAN ID (or untagged traffic) you can create multiple Virtual Ports. You can bind same Physical Ports to different Virtual Ports as long as the VLAN Tags don't conflict. Fe. you can have VPort1 with VLAN ID 100 created on interface VOIP0, and VPport2 with VLAN ID 200 created on the same port.

In case you would place multiple Physical Ports under one Vrtual Port a Bonding will be created. First Physical Port defined in the Virtual Port list will be used as active in this Bonding Group. Bonding is managed as a separate function and allows user to decide how the network failure will be detected:

• by default the bonding group queries Physical Port driver events and check for a Link Down error
• querying an remote IP address
• analyzing ARP replies from a defined remote host

Current limitations are:

• on SN10200 ETH0 and ETH1 untagged  Virtual Ports are reserved for system operations
• on SN10100 VLAN3 on VOIP0 and VOIP1 is reserved for system operations
• 16 Virtual Ports are supported per TelcoBoard

Layer3

Release 2.7 allowed us only to place a single IP address per Physical Port and required a TelcoBoard restart each time a reconfiguration was performed. Now in 2.8 this is a very different story. Using the IP Interface you can bind together a Virtual Port with actual Layer3 configuration (IP address, netmask, default GW).

Each IP Interface is a separate routing entity, which means no traffic is forwarded between different IP Interfaces (there is an axception in case you will configure two IP Interfaces in the sames IP subnet and place both under one Virtual Port - then they are treated as aliases). Number of IP Interfaces is limited to 16 per TelcoBoard.

As you may noticed already, there is a possibility to bind multiple IP Interfaces to one Virtual Port. Those IP Interfaces can be also located in the same IP subnet. Current limitations in this process are:

• there can be only one IP Interface dedicated to SIP, RTP or SIGTRAN role configured on a particular Virtual Port, fe. VirtualPort1 is bound to IPInterface1 carrying SIP and RTP roles; if we would decide to connect VirtualPort1 also with IPInterface2 configured for SIGTRAN (or SIP) role, the configuratio would fail
• there can be more then one IP Interfaces acting as MANAGEMENT or  H.248 bound to a particular Virtual Port, fe. fe. VirtualPort1 is bound to IPInterface1 running MANAGEMENT role; if we would decide to connect VirtualPort1 also with IPInterface2 configured for MANAGEMENT role as well, the configuratio would succeed

Last step during configuration is selecting what roles should be running on a particular IP Interface. We can choose from:

• SIP/SIP-I - SIP/SIP-i signaling stack
• RTP - allocation of media channels for each RTP stream
• SIGTRAN - SIGTRAN signaling stack
• MANAGEMENT - WebPortal, SSH, SNMP interfaces located in the Control Host
• H.248/RADIUS - H.248 MEGACO stack and RADIUS Client

There are also some limitations in the process of binding Service Roles to IP Interfaces:

• a single IP Interface can be acting as: (SIP and/or RTP and/or SIGTRAN) or MANAGEMENT or H.248/RADIUS role
• some examples of valid assignments per one IP Interface:
  • SIP+SIGTRAN+RTP
  • RTP
  • MANAGEMENT
  • H.248/RADIUS
• some examples of invalid assignments per ine IP Interface:
  • RTP + MANAGEMENT
  • MANAGEMENT + H.248/RADIUS
  • SIP + SIGTRAN + H.248/RADIUS

The following call parameters are available in the call object. For example

 called_number = call[:called]