Subject: Re: [Speermint] SPEERMINT SIP Interconnect Guidelines and otherStandards?

From: David Hancock <[email-masked]>
Date: Wed, 3 Mar 2010 21:33:49 -0700

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: [email-masked] [mailto:[email-masked]] On Behalf Of James McEachern
Sent: Tuesday, November 10, 2009 1:39 AM
To: [email-masked]
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

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Thu, 4 Mar 2010 08:46:07 -0600

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: [email-masked] [mailto:[email-masked]] On
> Behalf Of David Hancock
> Sent: Wednesday, March 03, 2010 11:34 PM
> To: James McEachern; [email-masked]
> 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.
> 
> 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:
> 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
> =================
> 
> 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...
> 
> 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.,
> 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.
> 
> 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.
> 
> 
> 
> 
> Describes interworking interface between international carrier networks
> connecting two domestic service provider networks
> 
> Reference Architecture:
> -----------------------
> These i3 Forum documents augment rather than replace/duplicate the
> SPEERMINT interconnect guidelines, since they...
> 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:
> -----------------------
> 
> 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:
> ------
> 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 (2007) Amend. 1 (2008-02) Extensions of NGN NNI
> signalling profile including video and data services
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/speermint

---

From: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Fri, 5 Mar 2010 12:48:28 -0500

David:
In reviewing the latest draft I came up with a couple of questions:

1. I'm not sure I understand what the role of the LNP information is
Section 4.2.1. If the interconnection is SIP, then there should be no
need for such information. I'd assume selection of the target SSP would
be portability corrected and if the INVITE is delivered to them why
should they need/care about the NP info?
Also, in the case of a ported number, what should happen to the rn if
the rn is not a geographic number? In North America LRNs are valid
geographic numbers but in other LNP implementations the rn might be just
a prefix.

2. Section 4.2.2 as written suggests CLI must always be present. While
desirable, there will not always be meaningful CLI, for example when a
call originates from a VoIP outbound-only application where the user is
assigned no TN. Was the intention to just specific how the information
should be presented when it *is* available?
Similarly Section 5.2

3. Likewise in Section 5.6 is the intention to detail how
AutoRecall/Callback should be supported if it is available and agreed to
or to mandate its implementation?

Thanks,

Penn Pfautz
AT&T Access Management
+1-732-420-4962

---

From: David Hancock <[email-masked]>
Date: Mon, 8 Mar 2010 16:50:49 -0700

Hi Penn,

Please see comments inline below.

Thanks
David

> Behalf Of PFAUTZ, PENN L (ATTCORP)
> Sent: Friday, March 05, 2010 10:48 AM
> To: David Hancock; [email-masked]
> Subject: Re: [Speermint] SPEERMINT SIP Interconnect Guidelines
> 
> David:

[dch] The originating network passes the routing number in case the terminating network needs it to route the call internally -- say to route the call to the network node serving that specific routing number. This saves the terminating network from having to perform another LNP dip.

> geographic numbers but in other LNP implementations the rn might be just

[dch] I'm not familiar with the case where an rn parameter does not contain a geographic number (i.e., a number that can be used for routing). Can you clarify this please, or provide an example of how rn is used for the non-geographic case?

> should be presented when it *is* available?

[dch] Yes, this text assumes there is always a calling identity, and it is contained in the P-Asserted-Identity header. For example, an App Server that generates a request is doing so on behalf of a user (say generates an INVITE due to click-to-call), and that user is identified in the PAI header of that request. Can you provide details on the use-case you have in mind, where there is no calling identity? 

> or to mandate its implementation?

[dch] The current wording was intended to reflect "mandatory to implement". Do you think that is too restrictive? If people agree, I can lower it to "optional to implement; if implemented do it this way".

---

From: "PFAUTZ, PENN L (ATTCORP)" <[email-masked]>
Date: Mon, 8 Mar 2010 20:37:16 -0500

David:
I really don't agree with a mandate for populating NP info in SIP
interconnection. I believe we should be trying to move away from
code-based routing.
That's why ENUM is inherently portability-corrected.
If NP info is already available, I have no objection to passing it, but
I would not want to require an originating carrier to obtain NP info if
it's not necessary for them to route the call to the terminating SP. 

I believe some countries use prefixes for NP routing (see RFC 3482
section 6.2)

There are a number of use cases where CLI, at least in the form of an
E.164 may not be available. IXCs sell outbound direct connect services
where the PBX may not have an E.164 number associated with the outgoing
trunk because the IXC doesn't provide local service to the PBX. SkypeOut
is another outbound only service. (I know Skype has some options for
caller ID but they're not mandatory for the user)
So, while I think peering partners should pass CLI when it's available,
guidelines should recognize that sometimes it's not.

I also believe AutoCallback/Recall should be negotiable between partners
not mandatory.

Penn Pfautz
AT&T Access Management
+1-732-420-4962

-----Original Message-----
From: David Hancock [mailto:[email-masked]] 
Sent: Monday, March 08, 2010 6:51 PM
To: PFAUTZ, PENN L (ATTCORP); [email-masked]
Subject: RE: [Speermint] SPEERMINT SIP Interconnect Guidelines

Hi Penn,

Thanks
David

> should they need/care about the NP info?

[dch] The originating network passes the routing number in case the
terminating network needs it to route the call internally -- say to
route the call to the network node serving that specific routing number.
This saves the terminating network from having to perform another LNP
dip.

> geographic numbers but in other LNP implementations the rn might be
just

[dch] I'm not familiar with the case where an rn parameter does not
contain a geographic number (i.e., a number that can be used for
routing). Can you clarify this please, or provide an example of how rn
is used for the non-geographic case?

> should be presented when it *is* available?

[dch] Yes, this text assumes there is always a calling identity, and it
is contained in the P-Asserted-Identity header. For example, an App
Server that generates a request is doing so on behalf of a user (say
generates an INVITE due to click-to-call), and that user is identified
in the PAI header of that request. Can you provide details on the
use-case you have in mind, where there is no calling identity? 

> or to mandate its implementation?

[dch] The current wording was intended to reflect "mandatory to
implement". Do you think that is too restrictive? If people agree, I can
lower it to "optional to implement; if implemented do it this way".