ISAM VoIP Architecture With SIP
ISAM VoIP Architecture With SIP
Before we start, please take a quick look at the controls of this web-based
training.
The side panel allows you to see the menu and view the voice-over script.
The control bar along the bottom allows you to play or pause, adjust the
volume, or go to the next or previous page. The Glossary and Resources
such as a PDF or podcast version of this course are options.
When you are ready, select the “Next page” button to continue.
2
After you finish this course, you will be able to:
• Describe the concepts of the ISAM SIP Voice architecture.
• Describe the functions of SIP ISDN PRI.
• Know how to initiate a voice diagnostic test call.
Chapter 1 – ISAM SIP Voice Architecture.
The ISAM Voice provides Voice over IP media gateway functionality to interconnect
legacy POTS (Plain Old Telephone Service) and ISDN (Integrated Services Digital
Network) customer premises terminals to the Next Generation Network (NGN). It is
an ideal solution for Incumbent local exchange carriers (ILECs) where the local loop
will be re-used, thanks to the ISAM voice acting as Media Gateway which converts
TDM to IP and vice versa for the voice over IP service. Alternative service providers,
even the ones leasing the local loop from ILECs, can also benefit from the ISAM
voice service.
The ISAM voice easily converts legacy POTS and ISDN voice traffic to IP traffic using
H.248 or only legacy POTS voice traffic using SIP (Session Initiation Protocol).
IMS (IP Multimedia System) is standardized by the 3GPP (Third Generation
Partnership Project) and ETSI (European Telecommunications Standards Institute)
TISPAN (Telecommunications and Internet converged Services and Protocols for
Advanced Networking) bodies. It is a fully converged and versatile architecture that
goes far beyond the fixed telephony scope.
In the IMS, SIP is the main protocol used for service delivery although H.248 can also
be used for media gateway control.
The IMS Proxy Call Session Control Function (P-CSCF) will handle the SIP protocol
coming from the ISAM.
The ISAM voice architecture is the ISAM with the addition of the voice service, which
translates into the addition of a new voice board, the NPOT (Network Plain Old
Termination).
IMS supports both distributed and centralized deployment models. On the distributed
model we need one IP address per NPOT while on the centralized model, one IP
address associated to the NT is enough. The centralized model is the one used the
most.
Each NPOT acts as SIP UA (User Agent) function and interworks with the SIP server. In
this case the P-CSCF. Each physical POTS line is associated to its SIP UA.
As we see in the diagram, the SIP is over UDP over IP. The end points of signaling are
between the voice LT and the SIP server.
The RTP is also over UDP, over IP. The end points of the RTP are between the voice
LT and the Trunk Gateway (TGW) as shown or an IP terminal.
In SIP, the NPOT not only handles the voice where in one side it will have the analogue
loop connecting the telephones and on the other side the RTP (Real Time Protocol) voice
streams, but it will also take care of the SIP messages. All telephone events such as off-
hook, on-hook, dialing etc. will be converted to SIP messages by the NPOT.
The NPOT needs a CDE (Customer Design Engineering) profile just like in Megaco with
the NVPS card. The CDE is country and operator dependent which defines specific
settings such as dialing tone, Digit map, default codec etc.
The ISAM voice architecture has the NPOT providing POTS service as we’ve seen
before. Since SIP does not support ISDN, there is no ISDN board, the NBAT, like there is
in H.248.
The NPOT interfaces and integrates functions such as ringing, digit detection and tone
generation. This LIM (Line Interface Module) provides a classical POTS interface
towards the subscriber and performs the packetization of the voice over RTP using a
specific codec and sending the voice directly to the network as VoIP over Ethernet. The
voice path is separated from the signaling path and the NPOT in SIP handles both the
signaling and the RTP as we see in the diagram.
As mentioned before, in SIP there can be two models. The distributed one will have one
IP address for SIP per NPOT card and another IP address for RTP per NPOT card.
In the centralized model there will be one IP for all the NPOTs for SIP and another IP for
all the NPOTs for RTP or one IP for SIP and RTP for all the NPOTs. The VRF (Virtual
Routing and Forwarding) in the NT will be the one with these two IPs or one IP and will
discriminate an NPOT by the UDP number. The NPOT will select the corresponding
physical port according to the L3 address in SIP which is usually the DN (directory
number).
Just like in Megaco we can also have a voice path in the ISAM Voice between two LT
(Line Termination) cards within the same system. This would normally only be possible
by using “routed mode” forwarding model and enable user-to-user communication. Voice
calls between two lines on the same LT will be switched internally on the NPOT card.
The ISAM Voice has a Non-blocking voice path which consists of local routing for local
calls and there is non-blocking voice line cards which means that it is possible to have an
RTP stream for each port available in the voice line card.
10
The voice service in the micro-nodes 7353 ISAM MDU, 7353 ISAM CX, 7363 ISAM MX-6
and 7367 ISAM SXs is handled differently compared to the FD and FX ISAMs (7302,
7330, 7356 and 7360), which was seen in previous slides.
This difference is due to two things: first of all, these micro-nodes have a TDM bus which
connects the POTS LTs with the NT and secondly the DSP is not in the POTS LT but in
the NT or NTIO.
The DSP card terminates the TDM bus from the POTS LT and converts the TDM voice to
RTP packets. The NT converts the POTS LT proprietary signaling to SIP and also
handles the call flow management, line status and line test functions.
Here we see the ISAM voice solution in an IMS network using SIP. Recall from the
ISAM VoIP overview module that SIP is the main protocol used for service delivery in
the IMS although H.248 is used for media gateway control via the Access Gateway
Control Function (AGCF) as we see in the diagram. For SIP it is the P-CSCF in the IMS
which will handle the SIP signalling as mentioned before. For more info on the other
IMS elements please refer the ISAM VoIP overview module.
Chapter 2 – ISAMV: NIAT-A: SIP ISDN PRI: Support Basic Function DRCI
The NIAT-A card is used to support the integrated SIP ISDN PRI which mainly deals with
the basic function of DRCI. The SIP ISDN PRI main aim is to develop a SIP ISDN PRI
Gateway which supports basic call. To support the ISDN PRI basic call, all the signaling
messages or parameters received on ISDN-UNI interface shall be converted into
corresponding SIP message or parameters and sent on SIP interface towards P-CSCF
and vice versa.
The PBX (Private Branch Exchange) switches the calls between local lines and to
certain number of external phone lines. E1 is an interconnection cable used to connect
the PBX to the network equipment ISAM V.
ISAM V (ISAM Voice Service Support) acts as a Multi Service Access Node (MSAN)
where the PBX lines terminate and acts as SIP endpoint. The NIAT-A card in the ISAM V
provides SIP ISDN PRI service.
SIP (Session Initiation Protocol) is an application layer protocol used to create, modify,
terminate a multimedia session over the Internet Protocol. It connects the network
equipment to the IMS(IP Multimedia Subsystem) via P-CSCF.
The Proxy-Call Session Control Function (P-CSCF) is the first contact point for the users
of the IP Multimedia Subsystem (IMS). It acts as a proxy server for the user equipment.
It validates and forwards the SIP signaling traffic requests to and from the user
equipment and then processes and forwards the response to the user equipment.
SIP ISDN PRI support is currently provided for ETSI. It provides IMS access to the ISDN
PRI subscribers and supports SIP Redundancy Behavior.
The overall view of the protocol is to implement SIP ISDN PRI for the ISAM V SIP
solution. It terminates the ISDN Q.931 stack from the PBX and develops the
interworking functionality of ISDN-SIP. Thus, it connects ISDN PRI-Layer-3 with SIP
stack. At network side, the SIP stack connected to ISAM V is interfaced with P-CSCF
only.
The CLI commands to configure the SIP ISDN PRI is similar to POT configuration. It
includes the following two commands:
The configure equipment slot command used to plan and configure the new board
type NIAT-A to configure the SIP application.
The configure voice sip isdn-cas-term command create or modify an isdn or cas
termination.
The show voice sip isdn-cas-term command displays the status log of every
termination alarm. DDI and Non-DDI are the two modes to configure the SIP ISDN
PRI. The P-UID parameter in this command checks the mode in which SIP is
configured.
The configure alarm entry command can change the configuration of an alarm.
A new CDE file is defined for NIAT-A board and it supports the following CDE
parameters:
• For SIP
• For ISDN
• For RTP
The new alarm type is added for the SIP ISDN PRI.
The support alarms for ISDN termination are isdn-ais-signal, isdn-los-signal, isdn-rai-
signal, isdn-reg-domainname, isdn-reg-auth, isdn-reg-timeout, isdn-reg-srvfailresp,
isdn-inv-domainname, isdn-inv-auth, isdn-inv-timeout, isdn-inv-srvfailresp, and isdn-
emergency-call.
The show alarm log sip command displays the current and previous status of each
ISDN termination alarm.
The show alarm current sip command displays the current status of each ISDN
termination alarm.
The show alarm snap-shot sip command displays the snap-shot status in a certain
period of each termination alarm.
SIP ISDN PRI provides 120 bulk calls.
The parameters that vary during configuration with respect to hold time are Start-to-Start
Time, Call Length Time, Inter-Call Time and Call-to-Call Time.
The Start-to-Start time is the time by which each channel of a set, staggers its start in a
test.
The Call Length Time is the maximum time that path confirmation is exchanged as part
of an action that is used in a script.
The Inter-call Time is the minimum time between the end of one execution of the script
on a channel and the start of the next execution of the script on the same channel during
a test.
The Call-to-Call time is the minimum time between the start of one execution of the script
on a channel and the start of the next execution of the script on the same channel during
a test.
Chapter 3 – ISAM-V/7363/7367: Capability to initiate a voice call to the
destination DN via CLI
Once a new SIP termination is created in 7302/7330/7363/7367 ISAM V and it is administratively
up, an automated voice diagnostic call to the destination number can be initiated, either via CLI
or through AMS.
The CLI command takes the destination number of the test line as input which is configured
based on the Operator’s dial plan. The destination test line number must be a valid parameter
and the line in test must be connected to a physical phone.
The CLI command checks if the termination under test is well configured E2E and is capable of
establishing a basic voice call over the negotiated bearer path.
This slide shows the hardware that provides support for the voice diagnostic test call.
Prior to the initiation of a voice call test, the line test session should be created.
At one NBLT session, only one line can be tested and cannot be executed
simultaneously with other NBLT tests.
The lttest session parameters can be configured using the “Configure linetest single
ltsession“ command.
Line test session id is the available session id and can have value 0 or 1.
Session-cmd option is used to define the line test session command. Some of the
supported values are: create, starttest, endtest, destroy, repeat etc. For configuring the
session “Create” is selected.
Owner-id defines the owner id of the session and can be a valid Gauge value.
Type-extend option is used to indicate the line test items. In this case the type extend
would be “diagnosis-call”.
The “test-param-num” option is used to define the parameter lines number in the session
for test. The valid range is 0-6.
The “test-mode” can be single, interactive or cable pair. The option “Single“ will run the
test once and exit. The “interactive” option enables the test to run in interactive mode.
The “cablepair” option is used to run cable pair test. In this case “Single“ is selected.
The “timeout-period” allows to set the whole test timer. The valid range is 42-120
seconds.
The line-num is used to input the line number in the session of the test. The maximum
line number depends on the actual LT and physical number of the device.
Once a LT session is created, the parameters of the line under test must be
configured.
The parameters of the line under test can be configured with “Configure linetest
single ltline“ command.
The “ltline” option is to input the available session id which can be either 0 or 1.
“lineid” is the line number of the line in test.
“line-status” is to set the status of the line in test. The status must be “intest“ – to put
the line in test.
Once the line parameters are configured, the single linetest parameters are configured.
The single linetest parameters can be configured with “Configure linetest single ltparm“
command.
“ltparm” option is used to specify the available session id which can be either 0 or 1.
“test-name(unit)” is used to input the test type along with the units. In this case this
parameter can be configured with the value “diagnosis call(1/10s)”
“ltstrvalue1” is the test parameter and can be any valid string value.
Finally the line test session can be started for the ltsession created using the “configure
linetest single ltsession” command by setting the option as “starttest” for the session-cmd
parameter.
The Complete configuration commands in CLI are provided in this slide.
You must ensure that the line in test is connected to a physical phone and a valid
destination test line number is provided as an input.
The ltsession is initially created with type as diagnosis-call and other mandatory
parameters.
Next the line parameters under test are provided as input.
Further single line test parameters are configured with the diagnosis-call units and
the destination line.
Finally the line test session is started.
28
Once the test is completed, the status of the lttest session for Voice Diagnostic test
can be known using the “show linetest single ltsession“ and “show linetest single
ltline” commands.
When the CLI command is received and if the SIP termination under test is in idle
on-hook state, a basic voice call to the given destination test-line is started by the
ISAMV-SIP.
ISAMV-SIP shall reject the request for test-call if the SIP termination under test is not
in idle on-hook state, when the CLI command is received.
29
Wrap-up.
Now that you have completed this course, you should be able to:
• Understand the procedure to initiate a voice diagnostic test call via CLI.
31
This completes the learning. Thank You.