SIP TRUNKING THE ROUTE TO THE NEW VOIP SERVICES
Ivan Gaboli Virgilio Puglia
Italtel
ABSTRACT
This work gives an overview of SIP-Trunking solution and
explains the existing difficulties in implementing VoIP
services, when this architecture is deployed in multivendor
environment. The causes of these problems are explained
with two existing approaches used by carrier to solve
interoperability: they are Full Jacket SIP-Trunk and
Customized SIP-Trunk. A solution to cover the lackings of
SIP standards is the introduction of a SIP adaptation device
called “Inter-Domain Adaptation Device” which will
increase the potentiality of SIP-Trunking based solutions.
It is also proposed a method for assessing the complexity of
different approaches to SIP-Trunking applications.
Keywords — SIP-Trunking, T.38, MTP, SBC, PBX.
1. INTRODUCTION
There is an evident evolution of technology used by
Telecom Providers tending to migrate voice services from
traditional TDM networks to new VoIP networks,
especially involving SIP-Trunking solutions. The number
of this type of migrations is expected to grow dramatically
at 106% Compound Annual Growth Rate (CAGR) in the
next few years, to reach nearly 170000 in 2012 in West
Europe [1]. The main driver of this migration is reduction
in capital expenditures (CAPEX) and decrease of the
operational expenditures (OPEX). But this migration
determines also a slight quality of voice service reduction;
depending on speech coder of VoIP the Mean Opinion
Score (MOS) [2] may vary and usually is near to 4 [3] a bit
less than the traditional TDM fixed networks but similar to
mobile users experience.
The technology change determines also migration problems
for already deployed services. If it’s problematic to
implement consolidated services like analogical fax and
modem (see e.g. Sip-Forum that realizes a FoIP Task Group
[4],[5]), it’s also easy to understand how it’s difficult to
deploy new services like IP Automated Trading Desk or
complex mandatory services like support for handicapped
(bars brail, hearing, etc.).
The introduction of new VoIP solutions at Enterprise level
is a great opportunity to redesign and standardize services.
SIP-Trunking makes possible to implement new services
(like Presence, videoconference, telepresence, virtual-fax)
accessible as “advanced communications as a service” and
that can change customer perception and improve
productivity, collaboration and travels costs reduction.
Service Providers (SPs) can obtain savings in terms of
CAPEX and OPEX, but this new solution introduces
Paper accepted for presentation at the ITU-T " Beyond the Internet ? – Innovations for future networks and services"
Kaleidoscope 2010 Conference, Pune, India, http://itu-kaleidoscope.org/2010
Italtel
interoperability problems between different technologies
and vendors.
This situation is similar to the ISUP solution in the
beginning of 90’ [6]; but today there are a wide range of
players that develop VoIP products for business market like
IP-PBXs and Corporate Switching Nodes (CSN). There are
big vendors (like Alcatel-Lucent, Ericsson,…) as well as
small software houses that develops applications [7] on
commercial hardware. This implementation simplicity
determines solutions based on different interpretation of
SIP protocol, permitted by laxity of SIP standards, which
leaves room for proprietary adjustments in features such as
advanced calling features, security or QoS. Hence
compliance with SIP standards doesn’t guarantee seamless
communication between end-users that leverage on
different IP-PBX systems. The SIP-Forum [8] tries to solve
this problem with an architecture framework proposal
(SIPconnect) that define a minimal set of IETF and ITU-T
standards that must be supported and provides precise
guidance in the areas where the standards leave multiple
implementation options and specifies a minimal set of
capabilities that should be supported by the SPs and
enterprise’s networks [9].
Some vendors try to promote the sharing of knowledge and
experience through on-line community [10]. All this
approaches demonstrate the existing difficulty in SIP-
Trunking Architecture deployment, specifically in very
large and multi country scenarios; but new services and
voice traffic cost reduction push Large Enterprises to issue
Request For Quotation for SIP-Trunking solutions in order
to put in competition SPs and gain the best ROI (Return Of
Investment). So customers ask for quick deployment and
SPs must be able to respect customers requirements.
This paper addresses some topics encountered during the
implementation of complex systems integration projects
implemented by Italtel for Large Enterprises and Service
Providers.
2. SIP STANDARDIZATION MODEL
The SIP protocol is standardized by IETF Requests For
Comments (RFCs) developed in an open and communal
environment. To have the greatest possible consensus in
committees and satisfy the largest number of participants,
usually the RFC bloated in both size and flexibility. The
specifications are full of weak terms like "May" and
"Should" that allows the developers of SIP-based systems
to make plenty of “free decisions”. So two VoIP systems
may be incompatible with each other while being both
compliant with specs; e.g. there are many standard ways to
transport DTMF (Dual-tone multi-frequency) tones:
 defined combining a set of RFCs with appropriate policy
- RFC2833 [11]: specialized payload packets in the defined by the carrier.
RTP; Between the SSW-C5 and Private Domains there is a layer
- RFC4730 [12]: SIP-NOTIFY with XML docs; of Border-Elements (BE) that provide the following main
- SIP-INFO [13]: a SIP message with specific features:
payload.
 network topology hiding;
This approach is entirely different from ITU-T  application layer firewalling;
specifications that the Telecommunications Industry was  NAT-SIP aware.
regulated or standardized for the last four decades.
Hence the problem does not start with the technology, but These devices provides termination and reorigination of
with the approach in creating standards. both signaling and media between Public and Private
domain.
3. SIP BUSINESS TRUNKING ARCHITECTURAL
The CSN can be inserted in the architecture when the
MODEL
private VoIP network is very large and there are benefits
having a local session routing capabilities.
The SIP Business-Trunking reference architecture is a five
level hierarchical architecture divided into two domains:
The CSN provides the following main functionalities:
Public and Private.
The Public Domain has two levels represented by:  Corporate’s IP-PBX interconnection point;
 Centralized session routing;
- Class 5 softswitches (SSW-C5), that are the first  On-Net/Forced On-Net calls management;
level of the network model;  Corporate’s private numbering plan management;
- Network Border-Elements (second level) that is  signaling mediation between Corporate VoIP
the frontier of the public domain towards network and SP’s Business Trunking UNI;
customers.  private/public phone identity translation.

The Private Domain has three hierarchical levels: The CSN represents also the Network Element (NE) that
interconnects Application Server like: Fax-Server,
- Corporate Border-Element, the frontier towards Microsoft Office Communicator , Presence-Server, etc..
the public network; Lower the CSN there are multiple IP-PBX with attested IP-
- Corporate Switching Node (CSN); Phones.
- IP-PBXs. The described architecture can be declined in two different
ways depending on the treatment modality of the user-plane
NGN
SIP-I (RTP flow) that can be:

Class 5
ISUP  Fixed-Media modality;
Softswitch
PSTN/PLMN  Variable-Media modality.
Media

SIP
3.2 Fixed vs Variable media
Border Elements

Public Domain In the VoIP world the RTP stream (user-plane) typically is
Private Domain
BE BE peer-to-peer, this means that end-points negotiate end-to-
AS
end media informations and they are always involved in
CSN IP-PBX each media stream variation (e.g.: when an hold with music
IP-PBX IP-PBX
is invoked). The signaling passes end-to-end through al
network elements involved in the path. This type of user-
plane treatment is called Variable-Media. In the traditional
ISDN-PBX the media is anchored by the PBX itself that
Very Large Enterprise Medium/Large Enterprise
terminates BRA/PRA links and, when needed, perform
signaling and media loop splitting the call in two different
Figure 1: Network Architectural Model legs.
The SSW-C5 are generally connected northbound to the IP-PBX’s vendors have realized some dedicated elements
SP’s transit network (Class-4 Exchange) via ISUP or via that perform media anchoring and emulates traditional PBX
SIP-I/SIP-T whereas southbound SSW-C5 provides a SIP behavior called Fixed-Media; for example Cisco has MTP
User to Network Interface (UNI) that allows the end user (Media Termination Point) function [14] and Avaya has
access to the PSTN/PLMN; the Business-Trunking UNI is Prowler Cards [15].
The Fixed-Media architecture in IP-PBX dramatically Private Domain Public Domain

simplifies the interconnection with carriers via SIP- Custom ICT CSN SIP SIP SIP H.248 ISUP

IP Phone IPPBX CSN BE BE SSW-C5 MGW PSTN

Trunking because all the calling scenarios are reduced to a Skinny
ICT

“basic-call”; so the Fixed-Media Architecture is

1. INVITE (no SDP)

2. 100 Trying 3. INVITE (no SDP)

4. 100 Trying 5. INVITE (no SDP)
characterize by the presence of anchoring equipments. 6. 100 Trying
7. IAM
8. ACM
Unfortunately elements like MTP etc., increase costs 9. CRCX
(g711, g729, T.38)

without added value to the customer and in some cases 12. 180 ringing
11. 180 ringing
(g729, sendrcv)
10. OK (g729)

13. 180 ringing (g729, sendrcv)

creating limitations to the evolution of the services (for Skinny

ICT
(g729, sendrcv)

example they are not able to treat video); hence 14. PRACK
(g729) 15. PRACK
(g729) 16. PRACK

recommended choice is to adopt Variable-Media model. 18. 200 OK

(g729)
17. 200 OK

ICT 19. 200 OK

RTP RTP
RTP (Ring Back Tone)
15. ANM
3.4 SIP Business Trunking Benefits 21. 200 OK (g729)
20. 200 OK (g729)

22. 200 OK (g729)

ICT
Skinny
23. ACK (g729)
24. ACK (g729)

The SIP Business-Trunking allows to realize a centralized RTP RTP

25. ACK (g729)
RTP

dedicated telephony infrastructure at the enterprise’s

premises that permits to conform services delivered to all
offices with the added value of customizing them to the
needs of the end users.
A centralized platform management permits the control of
the delivered service’s quality (think of companies with so
many small/medium sites all around the world, where
telecommunication is a commodity).
SIP also revolutionizes the way through which Enterprises
can realize interconnection with SPs; so it is possible to
concentrate the interconnection with the public network in a
centralized point with a substantial saving of cost of
interconnection.
Moreover the Large Enterprises can choose more than one
SPs and can choose the trunk to be used depending on type
of traffic (towards PLMN, PSTN, international…) and rate
applied by the SP’s.
Figure 2: Call Setup in the reference architecture
The signalling model varies depending on whether you
choose the Fixed-Media or the Variable-Media modality;
depending on the choice made for media we will speak
respectively about:
 ISDN-like SIP-trunk signalling model;
 Pure SIP-trunk signalling model.
ISDN-like SIP-trunk model is not detailed in this paper
because it does not give any added advantage as described
in 3.2; so we will focus our attention on Pure SIP-trunk
model and we will introduce a newly proposed
Hierarchical SIP-model that maintains the flexibility of
pure model and simplifies the interworking between
different technologies.

4.1 Pure SIP trunk signaling model

4. SIP BUSINESS TRUNKING SIGNALING MODEL
In a pure SIP signaling model with variable media, it is
The setup of a voice call with SIP protocol is based on expected that messages originated in a corporate premise
signaling flow that allows the network to perform the will be propagated to other corporate premises involved in
session routing and the bearer capabilities are negotiated by the scenario. The following figure is an example of the
the endpoints through the offer/answer procedure as simplified signaling flow after a successful call setup, the
specified in the RFC3264 [16]. called user performs a blind call transfer towards a PSTN
number:
Referring to the SIP business trunking architectural model,
in the following figure an example of a VoIP signaling call
flow is depicted. The call is initiated by an IP-Phone IP Phone IP-PBX SBC SSW SBC IP PBX IP Phone Trunking
Gateway

directing towards PSTN, through a SIP-Trunk Setup

INVITE INVITE INVITE INVITE Setup
Answer
interconnection. The call is terminated by a SSW-C5 with 200 OK
ACK
200 OK
200 OK 200 OK

ACK

trunking gateway functionalities and redirected toward RTP

ACK ACK

PSTN. In the example is supposed that CSN use an Inter- INVITE (Hold) INVITE (Hold) INVITE (Hold)
INVITE (Hold)
Transfer

Cluster-Trunk protocol to dialog with corporate’s IP-PBXs

200 OK 200 OK
200 OK 200 OK
ACK ACK
ACK REFER
ACK
and the IP-PBXs use custom protocols versus controlled IP REFER
NFY (Trying)
REFER
NFY (Trying)
REFER

NFY (Trying) NFY (Trying)

Phones (e.g. Cisco Skinny Protocol). 200 OK
200 OK
200 OK 200 OK

INVITE
INVITE (*) IAM
ANM
200 OK
200 OK
ACK ACK
RTP

NFY (200 OK) NFY (200 OK) NFY (200 OK) NFY (200 OK)
200 OK 200 OK
200 OK
200 OK
BYE BYE BYE BYE
200 OK 200 OK
200 OK
200 OK

Figure 3: Call flow example (simplified without CSN)

The initial INVITE-200OK-ACK [23] exchange determines
the establishment of the call; after that the end-user
performs a call transfer. The call transfer invoked by the
user of Enterprise-B, triggers a sequence of signaling that
cross all the network elements and impacts also the IP-PBX
of Enterprise-A (see REFER [17] in figure 3 that crosses all
the network).
The IP-PBX of Enterprise-A must be able to understand
signaling and perform requested service; in this example it
must manage the REFER method and implement the call
transfer service. In the pure SIP signaling model the service
logic is distributed only between the two IP-PBX, whereas
the SSW-C5 performs the routing functions.
This is a simplified approach but implies that all the IP-
PBX are able to perform requested service logics and, when
a new behavior is introduced in the network by a new
element, all the interoperability tests must be performed to
be sure that no regression happened. In the figure’s
example there is also another point of attention (marked
with *): in the signaling flow proposed by RFC5589 [18] a
new INVITE is issued by transferee. The INVITE could not
be correctly associated to the call transfer service, so the
transferee can be in the condition to be charged for the
entire leg of the call (from transferee to target). The
transferor will not be charged for the second leg of the call
(and this can be not compliant with country charging
requirements). By the way “plain” SIP networks are simpler
than hierarchical one but the latter better fulfill SP’s
requirements like Call Detail Records generation (CDR),
(crucial for billing purposes) and SP’s UNI technical
specifications.
4.2 Hierarchical SIP signaling model
To establish successfully sessions between two users and to
manage the various scenarios that can happen during the
call, it is important to consider and manage different
aspects such as:
 Identity management & certification;
 Voice-codec compatibility;
 DTMF interoperability;
 Encryption;
 Fax support;
 CDR generation.
The call-flow in figure 3 highlights how each new NE or
new service introduced in the network may have impacts
towards all other NEs present in the Public or Private
domains. The pure SIP signaling model has a big constraint
so in this period of standardization laxity it is better to
implement a hierarchical architecture where it is foreseen
some harmonization functions that split various domains
and simplify the interworking procedures.
The harmonization function can be performed either in a
dedicated network element or embedded in the SSW-C5 or
BE. The right choice depends on the specific characteristics
of the network; a hierarchical architecture allows adopting
some specific rules on the SSW-C5 that force a well
defined behavior on the UNI and guarantee SPs to maintain
the control on user’s operations.
5. GO TO MARKET APPROACH
Waiting for an efficient standardization of SIP, the SPs
have two possibilities:
 Full Jacket (FJ)
If the volume (number of enterprise customers) is
high, the SP can define some pre-packaged
solutions. This approach is usually utilized by the
incumbent Carrier
 Customer Tailored (CT)
The SP tries to satisfy all the customer’s requests
without imposing technical limitations or pre-
packaged service bundles
5.1 Full Jacket
The Full Jacket approach defines all the various equipments
and services that can be supported by the solution and
combine them into bundles; each bundle is pre-certified and
can be sold as an out-of-the-shelf product. The SP sells to
the Enterprise all the necessary platform and terminals to
provide services. It’s more easy to propose a FJ bundle
when the customer is a green field.
Each time it is required to introduce a new service and/or a
new device, it is necessary to update the bundle with
dedicated study and test sessions.
The expected effort for this kind of activity can be
evaluated as a proportion of the possible combinations
between all the devices as show in the following formula:
[1]
Where TF is the total number of functionalities that must be
supported, NS is the number of Enterprises, is the
number of typology devices that are involved for the f
function on the enterprise i. The is the number of
typology devices that are involved for the f function on the
enterprise j.
The effort to validate the solution is made at the first
implementation, with this approach we operate every time
in a Homogeneous Domain (HoDo).
5.2 Customer Tailored
The Customer Tailored approach complies with all the
requests of the customer case-by-case. This means that all
the devices, terminals and services are selected by the
Enterprise based on its commercial/technological
requirements.
All the devices and terminals are customer ownership and
usually are managed by the SP with a specific contract of
maintenance. The delivery effort depends on the typology
and the number of devices involved, not only in current
implementation, but also in the previous one. So from the
SP’s point of view the complexity increases with the
increase of acquired customers.
The expected effort can be evaluated as indicate in the
formula [1].
Each time a new Enterprise with different devices is added
to SP’s network, the effort put in solving the problems can
be evaluate as show in the following formula:
[2]
Where is the number of typology devices involved in the
f function by the new enterprise. NS is the number of
already existing Enterprise. The and TF are the same of
formula [1]. With this approach we operate every time in a
Inhomogeneous Domain (InDo).
Usually an Enterprise which selects InDo has the trend to
realize multi vendor domains in their premise, so the
interoperability problems start already at customer’s home.
6. RECONCILATION BETWEEN THE
APPROACHES
Both approaches (FJ and CT) can have serious
compatibility problems with the volumes expected in the
next three years in the SIP business trunk market.
Each SP will have a complex InDo, composed by islands of
HoDo; there is a concrete risk to have an unmanageable
network with exponential growth of OPEX. We propose to
adopt the SIP Business Trunking and signaling architectural
model (cfr. 3, 4.2) with a new network function (or
element) denominated Inter-Domain Adaptation Device
(IDAD) which understands simultaneously all the
“standard” SIP-messages and call flows and can harmonize
them.
The IDAD perform the following main functionalities:
 Media Anchoring;
 Dynamic Audio/Video transcoding;
 Signaling decoupling & normalization;
 Interdomain features harmonization;
 Session Admission Control;
 Fax adaptation;
 DTMF interworking;
 Encryption termination.
Italtel has developed a feature called Media Termination
Function (MTF) on board of its own Softswitch (i-SSW
[19]) that performs some of IDAD’s functionalities.
6.1 Media Anchoring
In a standard SIP session the RTP flow goes peer-to-peer;
Media Anchoring feature allows IDAD to anchor the media
stream splitting the RTP flow in two segments and to
monitor both session’s user and control plane and perform
transcoding if necessary. The usage of this feature makes
also possible to perform signaling normalization as
described in 6.3. The anchoring point represents a unique
interworking point for all other domains towards which the
originating domain will be connected with.
No Media Anchoring
Media Anchoring
Class 5
Class 5 Softswitch
Softswitch
IDAD
BE BE
BE BE BE BE
IP-PBX IP-PBX IP-PBX IP-PBX
Enterprise A Enterprise B Enterprise A Enterprise B
Figure 4: Media path with/without media anchoring
The singularities of the originating domain will be managed
by IDAD preserving other domains thus simplifying
interoperability. The Media Anchoring is also an
opportunity to be able to complete successfully a session
between two domains with no common shared codec
(IDAD intercepts the RTP and performs the required media
transformation).
6.2 Dynamic Audio/Video transcoding
During the SIP session setup it is performed the
offer/answer procedure [16] that is used by user agents
(UA) to agree codecs that must be used for communication.
If the two parties don’t have a common audio/video codec,
the negotiation will fail unless IDAD intercept the codec
mismatch and engage transcoding resources. Depending on
the session setup scenario the IDAD can decide to book
transcoding resources based on one of the following events:
 The originating domain presents a set of codecs
insufficient for the destination domain (based on
provisioning information);
 Catching an error response received by destination
UA.
In the first case the IDAD enriches the codec bouquet with
all codecs defined by provisioning information and, if the
answer will select a codec that the origin domain doesn’t
support, IDAD will perform requested transcoding.
In the second case when IDAD reveals an error message for
codec mismatch, it will issue a new INVITE with an SDP
with all codecs supported by IDAD and performs requested
transcoding.
An alternative to perform a provisioning of codecs
supported by various domains can be represented by the
auto-learning feature of IDAD that will learn dynamically
(based on error messages revealed during session
instauration) the set of supported codecs by various
domains and it applies resource reservation and transcoding
following self-learned rules.
6.3 Signaling decoupling & normalization But a well designed access can also go in defect for some
rare events when the profile of traffic heavily violates the
The IDAD, in combination with SSW-C5, performs a traffic model considered in design phase.
decoupling of the signaling among domains terminating and The Session Admission Control performed by IDAD allows
re-originating SIP session in a Back-to-Back logic. This to monitor the saturation of available bandwidth; IDAD per
behavior allows IDAD to perform a normalization of each access considers the used codec and the bandwidth
headers used/expected from/by various domains. A typical occupation. When the amount of occupied bandwidth
example: SIP Diversion Header [20] and History Info surpasses a specific percentage threshold new sessions
Header [21], both permitted by standards to indicate in request will no more be authorized for the specific access.
which point a session has suffered a transfer. IDAD The IDAD can also differentiate the admission policy
performs requested adaptation to make different “SIP- depending on the codec used, so for example video can be
dialects” compatible by different IP-PBX vendors. allowed only when e specific percentage of bandwidth is
available or for a limited number of sessions.

6.4 Interdomain features harmonization

6.6 Fax Adaptation
Some features or methods not declared mandatory by
standards, can create interworking problems between IP- In the IP world there are two common ways to transmit fax:
PBX of different vendors; for example some domains are
using UPDATE method [22] while others do not support it  Fax Passthrough (G.711 clear channel);
or direct fax session setup with Fax Relay (T.38). The  Fax Relay (T.38).
IDAD performs the interdomain harmonization by
interpreting and filtering the particular features used by a This two methods are incompatible with each other; the
specific domain and spreading only basic and more best practice is to use T.38 which is more reliable, but
common procedures towards others domains. sometimes T.38 cannot be used. So in the real world a SP
For example a fax call that starts directly in T.38 (without a can have domains that use T.38 (with no fallback to G.711
previous establishment of a session that uses a voice codec) capability) and others that support only Fax Passthrough.
the IDAD can emulate towards called domain a more In this case IDAD is able to detect the incompatibility of
widespread behavior that consists in setting up as first step fax codecs during the session setup phase and perform the
a G.711 session and try later to negotiate a T.38 fax relay necessary transcoding operations and signaling adaptation
codec; in this way the percentage of a successful session to have a successful fax transmission.
setup is higher and the fallback to fax pass-through mode is
guaranteed.
6.7 DTMF in-band/out-of-band transformation
IDAD
IP Phone A
Setup
IP-PBX SBC
SSW
SBC IP PBX IP Phone B Trunking
Gateway Once the session is established it’s possible for user agents
INVITE INVITE
INVITE INVITE
200 OK
Setup
Answer
to exchange DTMF end-to-end. DTMF can be transmitted
200 OK
200 OK
ACK
200 OK

ACK
ACK
in two different modalities:
ACK
RTP IP Phone B RTP
Transfer
INVITE (Hold)
INVITE (Hold)


RTP Hold Tone
INVITE (Hold)
200 OK 200 OK 200 OK
ACK
In Band
ACK
ACK REFER
REFER
NFY (Trying) NFY (Trying)
The digit is transmitted in the media flow marking
200 OK 200 OK

(New CDR) IAM in a particular way an RTP packet following

ANM
INVITE (MG)
200 OK RFC2833[11] ;
ACK


RTP Trunking Gateway RTP
Out-of-band
NFY (200 OK) NFY (200 OK)
200 OK 200 OK
The digit is transmitted following the signaling
BYE

200 OK
BYE
200 OK path using:
o SIP-INFO Method
o KPML (RFC4730 [12])
SIP-INFO is more widely supported although less
Figure 5: Signalling harmonization well standardized.

6.5 Session Admission Control

In this heterogeneous DTMF transmission modes present
today, the IDAD presence in the network resolves DTMF
The access bandwidth (data link between enterprise and SP) exchanging problems performing transformation among
is a parameter subject to the contract’s Service Level various methods.
Agreement negotiated between SP and Enterprise; so the
amount of access bandwidth should be determined as the
trade-off between traffic expected and bandwidth’s cost.
 Class 5
Softswitch
IDAD
INFO (DTMF2) RTP Packet DTMF 2
RFC 2833
BE/C-BE BE/C-BE
DTMF
Out-of-Band INFO (DTMF2)
UII DTMF 2
Figure 6: DTMF transformation
Based on the domains’ characteristics IDAD decides when
it is necessary anchor the media flow and to perform DTMF
transformation ensuring interoperability.
6.8 Encryption termination
There are some enterprises which request to have the voice
encryption. Typically this kind of requirement can be
satisfied inside the customer premises but sometimes this
requirement exists also between different enterprises that
belongs to the same group.
It is difficult for SP’s to provide encryption in this enlarged
scenario with different methods of encryption used in
different domains, non sharing of key/certificate between
different organizations, obligation to be able to apply lawful
interception.
The IDAD allows SPs to offer encryption of voice flow
between different enterprises maintaining the capability to
intercept the voice stream if requested by the authorities;
indeed IDAD can anchor the user-plane and perform the
required decryption/encryption process.
6.9 Simplification of the complexity
The deployment of a new technology domain implies a
campaign of certification tests that covers all possible
combinations between different technologies for their
interworking because of weak standardization of SIP-
Trunk interface.
With the introduction of IDAD platform, the expected
effort to insert a new HoDo, will be proportional to the
possible combinations between all the devices and the
IDAD. See the following formula:
[3]
Where NHoDo is the number of Enterprise in the new
HoDo. The TF and are the same of formula [1].
For example when a new island HoDo, realized by a single
enterprise, is inserted, the effort can be evaluate as show in
the following formula:
[4]
Where is the number of typology devices that are
involved for the f function on the added enterprise.
The effort without IDAD is significantly major than with
DTMF
IDAD as showed by the following formula:
In-Band
[5]
7. DISCUSSIONS AND CONCLUSIONS
The objective of this paper was to provide an overview of
SIP-Trunking solution, their state of art and show the
tendencies of their development. Some problems that
impact on the services were analyzed. We strongly believe
the most likely evolution of VoIP will be SIP-Trunking,
that will permit the creation of new services for end users.
But both models used today by Carrier (FJ and CT) may
have serious compatibility problems with the market
volumes expected in the next years.
The strengthening of the standards is the main way to go
forward for multi-vendor interoperable solutions, but we
must also consider the market presence of many small-
medium players coming onto the world of
telecommunications with the advent of VoIP.
These players prefer the development of products/services
that are partially compliant with product of other vendors,
but meet the needs and timing of the market. It is difficult
that these players will waiting for standard’s maturity.
For these reasons in this study we have proposed a solution
(IDAD) to cover the lapses/lackings of SIP standard,
without limiting the network flexibility. We hope this study
will serve as a stimulus for improve the SIP standardization
and for further research in above-mentioned subject area.
REFERENCES
[1] Salmeron, “Western European SIP-Trunking Market,
2007-2012”, Decembre 2008, IDC #WS06Q, volume:1;
[2] ITU-T Recommendation P.800 Methods for subjective
determination of transmission quality;
[3] D.Collins, “Carrier Grade Voice Over IP”,McGraw-Hill;
[4] SIP Forum – Fax_Over_IP_Task_Group – Problem
Statement – V1.0;
[5] SIP Forum – Fax_Over_IP_Task_Group – Addressing
the Identified Problems;
[6] Cazzaniga,Garavelli, ”Implementation of SS7: Italtel's
experience”,ieee, jul.1990,vol.28;
[7] http://www.asterisk.org/;
[8] http://www.sipforum.org/;
[9] SIPconnect Whitepaper, ”The SIPconnect Technical
Recommendation ”,rev1;
[10] http://www.siptrunk.org/;
[11] H.Schulzrinne,S.Petrack, RFC2833, “RTP Payload for
DTMF Digits, Telephony Tones and Telephony
Signals”;
[12] E.Burger,M.Dolly, RFC4730, “A Session Initiation
Protocol (SIP) Event Package for Key Press Stimulus
(KPML)”;
[13] S.Donovan, RFC2976, “The SIP INFO method”;
[14] http://www.cisco.com/en/US/docs/voice_ip_comm/cuc
m/admin/3_1_1/ccmsys/a05mtp.html#wp1030050;
[15] http://www.avaya.com/rt/master-usa/en-
us/resource/assets/applicationnotes/gateway.pdf;
[16] J.Rosenberg,H.Schulzrinne, RFC3264 “An
Offer/Answer Model with the Session Description
Protocol (SDP)”;
[17] R.Sparks, RFC3515, “The Session Initiation Protocol
(SIP) Refer Method”;
[18] R.Sparks,A.Johnston,D.Petrie, RFC5589 ” Session
Initiation Protocol (SIP) Call Control–Transfer”;
[19] http://www.italtel.com/allegati/2Solutions-
products/products/
[20] S.Levy, Internet Draft, “Diversion Indication in SIP
draft-levy-SIP-diversion-11”;
[21] M.Barnes, RFC4244, “An extension to SIP for request
history information”;
[22] J.Rosenberg, RFC3311, “The Session Initiation Protocol
(SIP) UPDATE Method”;
[23] J.Rosenberg,H.Schulzrinne,G.Camarillo, RFC3261
“SIP: Session Initiation Protocol”;