Re: SPEERMINT SIP Interconnect Guidelines and otherStandards?
Mike Hammer (hmmr <
hmmr@...>
2010-03-04 14:46:07 GMT
David,
I would suspect that Q.3401 and ATIS-1000009.2006 are aligned and thus the ITU-T document could be used as
proxy for the latter. There is also a phase 2 document in progress in ATIS that can go further, but I am not
sure how much detail one can include without trying to define all possible service and features might
traverse such an interface. Being more prescriptive could also become more restrictive. In the end, I
would trust that SPs know how to deliver services. Such exercises are more proof points that an NNI is
sufficiently defined.
Thanks,
Mike Hammer
> -----Original Message-----
> From: speermint-bounces@...
[mailto:speermint-bounces@...] On
> Behalf Of David Hancock
> Sent: Wednesday, March 03, 2010 11:34 PM
> To: James McEachern; speermint@...
> Subject: Re: [Speermint] SPEERMINT SIP Interconnect Guidelines and
> otherStandards?
>
>
> James,
>
> I reviewed a number of the interconnect standards documents and compared
> them in terms of scope level of detail, etc, to see if & how they overlap
> or duplicate the SPEERMINT Interconnect Guidelines draft.
>
> Based on this analysis (see details below), I think the SPEERMNIT
> interconnect guidelines draft plays a unique role in resolving a targeted
> set of common inter-SSP interworking issues, and should be advanced.
>
> Please let me know if you don't agree with this conclusion.
>
> Thanks
> David
>
> =============== 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 =============
>
>
>
> ________________________________________
> From: speermint-bounces@...
[mailto:speermint-bounces@...] On
> Behalf Of James McEachern
> Sent: Tuesday, November 10, 2009 1:39 AM
> To: speermint@...
> Subject: [Speermint] SPEERMINT SIP Interconnect Guidelines and
> otherStandards?
>
> I was wondering if our SIP Interconnect Guidelines is factoring in related
> activities in other organizations. Specifically I was wondering about:
> - ITU-T Q.3401 NGN NNI signalling profile (protocol set 1)
> - ITU-T Q.3401 (2007) Amend. 1 (2008-02) Extensions of NGN NNI
> signalling profile including video and data services
> - i3Forum Technical Interconnection Model for International Voice
> Services
> - i3Forum IP international interconnections for voice and other
> related services
> - GSMA IR.34 Inter-Service Provider IP Backbone Guidelines
> In addition, ATIS Next Generation Carrier Interconnect is tackling a
> similar space.
> Jim McEachern
> T:+1 613 763-3419
> M:+1 613 853-0176
> _______________________________________________
> Speermint mailing list
> Speermint@...
> https://www.ietf.org/mailman/listinfo/speermint
RSS Feed