Subject: [dispatch] Basic Telephony SIP Interconnect Guideline Draft

From: "Elwell, John" <[email-masked]>
Date: Wed, 2 Feb 2011 12:13:28 +0100

http://www.ietf.org/mail-archive/web/dispatch/current/msg03112.html

If this is just profiling work, perhaps the SIP Forum would be a better venue.

John

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 2 Feb 2011 12:40:54 +0100

Hi,

In addition, at least ITU-T and 3GPP also have interconnect specifications.

Regarding THIS draft, I am a little confused about that fact that it describes UA procedures, e.g. how a UA shall handle forking. I don't see what that has to do with interconnect.

(I DO agree that it would be good to have common forking procedures in general, but that's another story :)

Having said that, specifying that forking shall be supported over interconnect could be useful.

...unless, of course, you want to deploy SBCs at the interconnect point in order to handle forked sessions :)

Regards,

Christer

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Elwell, John
> Sent: 2. helmikuuta 2011 13:13
> To: [email-masked]
> Subject: [dispatch] Basic Telephony SIP Interconnect Guideline Draft
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Daryl Malas <[email-masked]>
Date: Wed, 2 Feb 2011 13:24:24 -0700

Christer,

David Hancock provided an analysis of how this draft compares to other
industry work in a previous SPEERMINT mailing list discussion.  I have
recopied this below for reference. Note: replace the "work done in
SPEERMINT" as this draft.  Here is a link to the original email:
http://www.ietf.org/mail-archive/web/speermint/current/msg02635.html

Regards,

Daryl

=============== BEGIN Interconnect Standards Compare =============

EXECUTIVE SUMMARY
=================

Here is the list of standards, and my conclusions as to whether each
standard overlaps or duplicates the interconnect work being done in
SPEERMINT.

3GPP IMS: 
 - 3GPP TS 29.165 Inter-IMS Network to Network Interface (Sept 2009)
 - Conclusion: does overlap to a certain extent, but is too
   IMS-centric to be viewed as a interface standard for the
   entire industry

ITU-T Study Group 11:
 - Q.3401 - NGN NNI signalling profile (March 2007)
 - Conclusion: does overlap to a certain extent, but too broad
   and high-level to meet the goals set out by the SPEERMINT
   interconnect guidelines draft (i.e., ITU spec is more a list of
   SIP extensions supported on the interface, rather than
   the SPEERMINT draft which provides more focused and detailed
   procedures to resolve common interworking issues)

i3 Forum:
 - IP international interconnections for voice and other related
   services (June 2009)
 - Conclusion: doesn't duplicate the SPEERMINT draft. This i3 spec
   provides very high-level requirements for the interface between
   two international IP carriers.

GSM Association:
- Inter-Service Provider IP Backbone Guidelines (June 2008)
- Conclusion: doesn't duplicate the SPEERMINT draft. Instead of direct
  peering, the GSM spec defines an indirect peering model where
  each SSP has a single connection to a common "Inter-Service Provider
  IP backbone". This backbone acts a hub that indirectly connects all
  peering SSPs. Very light on SIP interworking.

ETSI
- ETSI SR 00008-NGN-R3 and ETSI DTR/TISPAN-07043-NGN-R3
I didn't include these documents in the comparison, mainly because this
area seems to be still in early stages. The SR 00008-NGN document
references a number of other ETSI documents, including the ETSI version of
3GPP TS 24.229 (the IMS base SIP/SDP spec). DTR/TISPAN-07043 (according to
the title) is about security, which is currently out-of-scope for the
SPEERMINT draft. My assumption at this point is that the SSP SIP
interworking procedures for ETSI are or will-be harmonized with 3GPP/IMS.

ATIS
Unfortunately, I don't have a copy of the ATIS interworking spec, so
didn't include ATIS in the comparison. Would appreciate it if someone who
has access to these documents could provide info on this.

DETAILED ANALYSIS
=================

The following is a more detailed comparison among these different
standards.

3GPP TS 29.165 - Inter-IMS Network to Network Interface
=======================================================
Purpose:
--------
To collect all the II-NNI related requirements spread across multiple IMS
specifications into a single document. 29.165 consists primarily of
NNI-impacting references to other IMS specs, such as...

 Numbering, addressing & identification --> 23.003
 Multi-Media Telephony (MMTEL) Services --> 24.173
 Base (app-agnostic) SIP procedures     --> 24.229
 Media & Codecs                         --> 26.114
 IP Version Interworking                --> 29.162
 Call Charging                          --> 32.260
 Security                               --> 33.210

Reference Architecture:
-----------------------
                             +--29.165 defines this SIP/RTP interface
                             |
                             |
 +---------------------+     |        +-----------------+
 |    IMS Network      |     |        |    IMS Network  |
 |                     |     V        |                 |
 |               IBCF-------SIP---------IBCF            |
 |  x-CSCFs,etc    |   |              |   |             |
 |               TrGW-------RTP---------TrGW            |
 |                     |              |                 |
 +---------------------+              +-----------------+

Scope: 
------
29.165 is similar to the SPEERMINT draft in that it covers signaling (SIP
& SDP) and media (RTP) requirements at NNI. However, 29.165 is much
broader than the SPEERMINT interconnect draft; e.g.,
 - mandates mandatory/optional NNI support for an exhaustive number
   of SIP extensions (~80)
 - mandates procedures for a large number of voice telephony features (~20)

Conclusion:
-----------
29.165 does overlap and duplicate the SPEERMINT guidelines to a certain
extent. However, it is much broader (more extensions, more services) than
the SPEERMINT document, and more IMS-centric, and therefore it would
probably not serve as general industry interface specification.

Some examples of IMS-specific procedures/mechanism include:

 a) Private headers unique to IMS such as
     P-Access-Network
     P-Asserted-Service
     P-Charging-Vector
     P-Charging-Function-Addresses
     P-Profile-Key
     P-Private-Network-Indication
     P-Served-User

 b) Use-cases unique to IMS, such as...
    In IMS roaming scenarios a roaming UE in a visited network
    registers with its home network via the NNI interface. As a
    result, procedures that normally show up only on a UNI
    interface such as registration and visual message waiting
    indication can appear on the NNI interface.

 c) IMS-specific mechanisms
    e.g., MMTEL Service URN urn:urn-7:3gpp-service.ims.icsi.mmtel

ITU-T Q.3401 (03/2007) Signaling requirements and protocols for the NGN -
Service and session control protocols
==========================================================================
Purpose:
--------
To define a common interface profile between peering SSPs.

Reference Architecture:
-----------------------
                  +--Q.3401 defines this SIP/RTP interface
                  |
                  |
 +----------+     |        +---------+
 |          |     V        |         |
 |  SSPa    |----SIP-------|  SSPb   |
 |          |              |         |
 |          |----RTP-------|         |
 +----------+              +---------+

Scope:
------
Similar to the SPEERMING guidelines -- define SIP/RTP guidelines for
support of basic voice services.

Level of Detail:
----------------
Much broader and less detailed than SPEERMINT interconnect guidelines.
 - contains a few high-level guidelines
 - a long list (~40) of mandatory/optional RFCs
 - a high-level profile of RFC3261 that...
    - lists supported methods & headers
    - identifies minor divergences from RFC3261

Conclusion:
===========
Does not contain the level of detail of the SPEERMINT interconnect
guidelines. ITU Q.3401 is more a list of SIP extensions that can appear on
the NNI, in contrast to the SPEERMINT draft which focuses on providing
more detail on a narrower set of topics, sufficient to resolve a bounded
set of common interworking issues.

i3 Forum has two documents...
IP international interconnections for voice and related services (V 1.0)
June 2009
                                and
Technical Interconnection Model for International Voice Services
(Release 2.0) May 2009
=====================================================================

Purpose: 
--------
Describes interworking interface between international carrier networks
connecting two domestic service provider networks

Reference Architecture:
-----------------------
                                 +-- describes this SIP/RTP interface
                                 |
 Country-X                       |                       Country-Y
+------------+                   |                    +------------+
| Domestic   |    +-----------+  V   +-----------+    | Domestic   |
| TDM/VoIP   |----| Carrier-A |------| Carrier-B |----| TDM/VoIP   |
| Provider-A |    +-----------+      +-----------+    | Provider-B |
|            |                                        |            |
+------------+                                        +------------+

Scope:
------
 - Describes SIP & RTP interface between international carriers
 - Describe layers below SIP (e.g., IP, physical)
 - In addition to SIP, describes procedures for signaling
   ISUP & TCAP over IP
 - Defines voice quality metrics measures
 - Defines charging requirements, and accounting data

Level of detail:
----------------
 Detail much lower than SPEERMINT interconnect guidelines
 - Defines high-level profile of RFC 3261
 - Lists mandatory SIP methods and headers with no additional
   detail
 - Aside from application of ring-back tone, does not describe
   any procedures or call flows

Conclusion:
-----------
These i3 Forum documents augment rather than replace/duplicate the
SPEERMINT interconnect guidelines, since they...
 - contain much less detail w.r.t. SIP procedures
 - target a different problem space (international carrier,
   more TDM/SS7 focused)

GSM - Inter-Service Provider IP Backbone Guidelines
===================================================
Purpose: 
--------
To define an architecture built around a common Inter-Service Provider IP
Backbone that enables different SSPs to easily peer with each other.

Reference Architecture:
-----------------------

                        +-- GSM guidelines describe this entity
                        |
                        |
                        V             +------------+
                  +-------------+     |   SSPb     |
+------------+    |             |-----|            |
|   SSPa     |----| Inter-SP    |     +------------+
+------------+    | IP Backbone |
                  |             |     +------------+
                  |             |-----|   SSPc     |
                  +-------------+     |            |
                                      +------------+

This document solves the peering problem by defining an active entity (the
Inter-SP IP backbone) at the peering interface that takes care of the
complexities of establishing multiple peering relationships. Using this
arrangement, a single SSP can reach many peer SSPs via a single connection
to the Inter-SP IP Backbone.

Scope:
------
Describes the architecture, and basic connectivity requirements to make it
work. Very thin on SIP requirements.

Conclusion:
----------
Does not overlap/replace the SPEERMINT interconnect guidelines.

=============== END Interconnect Standards Compare =============

On 2/2/11 4:40 AM, "Christer Holmberg" <[email-masked]>
wrote:

>Regarding THIS draft, I am a little confused about that fact that it
>describes UA procedures, e.g. how a UA shall handle forking. I don't see
>what that has to do with interconnect.
>

---

From: "Richard Shockey" <[email-masked]>
Date: Sat, 5 Feb 2011 13:13:46 -0500

I have privately informed the authors that if they wish this document to
have a home they are more than welcome to bring it to the SIP Forum. 

Richard Shockey
Shockey Consulting
Chairman of the Board of Directors SIP Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>
skype-linkedin-facebook: rshockey101
http//www.sipforum.org

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Elwell, John
Sent: Wednesday, February 02, 2011 6:13 AM
To: [email-masked]
Subject: [dispatch] Basic Telephony SIP Interconnect Guideline Draft

If this is just profiling work, perhaps the SIP Forum would be a better
venue.

John