David Hancock | 1 Mar 18:40 2010

Re: Should SIP Interconnect Guidelines recommendTransmission Loss?

John and Penn,

Thanks for the feedback. I'm OK with leaving this out-of-scope. I think it is important that peering voice
networks adhere to industry standards related to insertion loss, but perhaps this isn't the appropriate
place to address that.

Unless someone else has a strong opinion otherwise, I'll leave this out-of-scope.

Thanks
David

> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@...]
> Sent: Thursday, February 25, 2010 2:15 AM
> To: PFAUTZ, PENN L (ATTCORP); David Hancock; speermint@...
> Subject: RE: [Speermint] Should SIP Interconnect Guidelines
> recommendTransmission Loss?
> 
> David,
> 
> I too am concerned about this. Implementations of the NNI (SIP proxies,
> B2BUAs, SBCs, etc.) will not in general be the media endpoints, so if we
> specify anything of this nature it will need to be made explicitly clear
> that it applies to the media endpoints (e.g., user devices, gateways,
> media servers) and not to the signalling entities. In general a SIP
> service provider (carrier or enterprise) is not in control of the media
> endpoints that use its services and has no way of enforcing those media
> endpoints to comply with any NNI specification (and indeed has no way of
> telling those media endpoints whether a given medium for a given session
> is routed via an NNI). Therefore whatever we specify for media endpoints,
(Continue reading)

Daryl Malas | 2 Mar 00:59 2010

Call for agenda items

All,
 
As we near IETF 77 in Anaheim, please let us know if you would like to submit an item for the agenda.  Please send an email to Jason or myself and include a brief overview, pointer to a draft if applicable and requested time.
 
We look forward to seeing you in Anaheim.
 
Regards,
 
Daryl
 
---------------------------
Daryl Malas
Project Director, IP Interconnects
w - +1 303 661 3302
 
_______________________________________________
Speermint mailing list
Speermint@...
https://www.ietf.org/mailman/listinfo/speermint
David Hancock | 4 Mar 05:33 2010

Re: 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
Mike Hammer (hmmr | 4 Mar 15:46 2010
Picon

Re: SPEERMINT SIP Interconnect Guidelines and otherStandards?

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
Daryl Malas | 4 Mar 20:07 2010

Re: **Last Call** on the Speermint Peering Architecturedraft

Mike,

I have updated the diagram.  Thanks.

Regards,

Daryl 

-----Original Message-----
From: Mike Hammer (hmmr) [mailto:hmmr@...] 
Sent: Friday, January 22, 2010 1:48 PM
To: Daryl Malas; speermint@...
Subject: RE: [Speermint] RE:**Last Call** on the Speermint Peering Architecturedraft

Daryl,

Two problems:

1)  The SBE to SF, LUF, and LRF relationship is convoluted and circular (can iterate endlessly).
2)  You reference the SF throughout, but do not show it in the diagram.

My proposal is to change the figure 1 as follows.
Note, you can collapse the inner boundary of SBE, DBE, and SSP to be a single edge if you want.

             +----------------+
+---------------+
            /                  \                       /
\
           |   +-----SBE---+   |                      |    +---SBE-----+
|
           |  /             \  |                      |   /
\ |
           | |     +--LUF-+ |  |       +------+       |   | +--LUF-+
| |
           | |  |->|      | |  |       | ENUM |       |   | |      |<-|
| |
           | |  |  |      +----------->| TN DB|<------------+      |  |
| |
           | |  |  |      | |  |       +------+       |   | |      |  |
| |
           | |  |  +------+ |  |                      |   | +------+  |
| |
           | |  |           |  |                      |   |           |
| |
           | |  |  +--LRF-+ |  |      +--------+      |   | +--LRF-+  |
| |
           | |  |->|      | |  |      | DNS    |      |   | |      |<-|
| |
           | |  |  |      +---------->|IP Addrs|<-----------+      |  |
| |
           | |  |  |      | |  |      +--------+      |   | |      |  |
| |
           | |  |  +------+ |  |                      |   | +------+  |
| |
           | |  |           |  |                      |   |           |
| |
           | |  |  +------+ |  |                      |   | +------+  |
| |
           | |  |->|      | |  |                      |   | |      |<-|
| |
           | |     |  SF  |<------------------------------->|  SF  |
| |
           | |     |      | |  |                      |   | |      |
| |
           | |     +------+ |  |                      |   | +------+
| |
           |  \       |     /  |                      |    \    |      /
|
           |   +------|----+   |                      |     +---|-----+
|
           |      +-------+    |                      |     +-------+
|
           |      |       |    |                      |     |       |
|
           | SSP1 |  DBE  |<------------------------------->|  DBE  |
SSP2|
           |      |       |    |                      |     |       |
|
           |      +-------+    |                      |     +-------+
|
            \                 /                        \
/
             +---------------+
+---------------+
                  Figure 1: Reference SPEERMINT Architecture

Thanks,
Mike

> -----Original Message-----
> From: speermint-bounces@... [mailto:speermint-bounces@...]
On
> Behalf Of Daryl Malas
> Sent: Friday, January 22, 2010 1:11 PM
> To: speermint@...
> Subject: [Speermint] RE:**Last Call** on the Speermint Peering 
> Architecturedraft
> 
> All,
> 
> As a final reminder, the "Last Call" on the Speermint Peering
Architecture
> draft ends today.  Thank you to those who have already submitted
feedback
> on the draft, as this greatly helps the authors in improving it.  Once
we
> receive any additional comments today, we will begin working to update
the
> draft.
> 
> Best Regards,
> 
> Daryl
> 
> -----Original Message-----
> From: speermint-bounces@... [mailto:speermint-bounces@...]
On
> Behalf Of Daryl Malas
> Sent: Tuesday, January 19, 2010 8:54 AM
> To: speermint@...
> Subject: [Speermint] RE:**Last Call** on the Speermint Peering 
> Architecturedraft
> 
> All,
> 
> This is just a reminder the "Last Call" on the Speermint Peering 
> Architecture draft ends this Friday, January 22nd.  Please review and
post
> comments to the mailing list soon.
> 
> Regards,
> 
> Daryl
> Speermint Chairs
> 
> -----Original Message-----
> From: speermint-bounces@... [mailto:speermint-bounces@...]
On
> Behalf Of Daryl Malas
> Sent: Friday, January 08, 2010 9:47 AM
> To: speermint@...
> Subject: [Speermint] RE:**Last Call** on the Speermint Peering 
> Architecturedraft
> 
> All,
> 
> With the understanding it may be challenging for some to schedule the
time
> to review and provide comments in 1 week, the "Last Call" is extended
to
> January 22nd.
> 
> Regards,
> 
> Daryl
> 
> -----Original Message-----
> From: speermint-bounces@... [mailto:speermint-bounces@...]
On
> Behalf Of Daryl Malas
> Sent: Thursday, January 07, 2010 9:55 AM
> To: speermint@...
> Subject: [Speermint] **Last Call** on the Speermint Peering 
> Architecturedraft
> 
> All,
> 
> We discussed this during our last meeting, but I wanted to officially
note
> it on the mailing list.  Please provide any final comments on the 
> Speermint Peering Architecture draft.  This last call will last 
> approximately 1 week and end on January 15th.
> 
> Here is a link to the draft:
> http://tools.ietf.org/html/draft-ietf-speermint-architecture-09
> 
> Adam,
> 
> Please review and begin correction of the nits here:
>
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-spe
> ermint-architecture-09.txt.
> 
> We would like to wrap up this draft quickly, so everyone's effort to 
> review and provide and final feedback is greatly appreciated.
> 
> Regards,
> 
> Daryl
> _______________________________________________
> Speermint mailing list
> Speermint@...
> https://www.ietf.org/mailman/listinfo/speermint
> _______________________________________________
> Speermint mailing list
> Speermint@...
> https://www.ietf.org/mailman/listinfo/speermint
> _______________________________________________
> Speermint mailing list
> Speermint@...
> https://www.ietf.org/mailman/listinfo/speermint
> _______________________________________________
> Speermint mailing list
> Speermint@...
> https://www.ietf.org/mailman/listinfo/speermint
Daryl Malas | 4 Mar 20:11 2010

Re: **Last Call** on the Speermint PeeringArchitecturedraft

The new diagram looks like this:

+=============++                          ++==============+
              ||                          ||
        +-----------+                +-----------+        
        |    SBE    |                |    SBE    |
        |  +-----+  | SIP   +-----+  |  +-----+  |
        |  | LUF |<-|------>|ENUM |  |  | LUF |  |
        |  +-----+  | ENUM  |TN DB|  |  +-----+  |
   SIP  |           |       +-----+  |           |
 ------>|  +-----+  | DNS   +-----+  |  +-----+  |
        |  | LRF |<-|------>|FQDN |  |  | LRF |  |
        |  +-----+  |       |IP   |  |  +-----+  |
        |  +-----+  | SIP   +-----+  |  +-----+  |
        |  | SF  |<-|----------------|->|  SF |  |
        |  +-----+  |                |  +-----+  |
        +-----------+                +-----------+
              ||                           ||
        +-----------+                +-----------+
   RTP  |    DBE    | RTP            |    DBE    |
 ------>|           |--------------->|           |  
        +-----------+                +-----------+
              ||                           ||
SSP1 Network  ||                           ||  SSP2 Network
+=============++                           ++=============+

Any concerns?

--Daryl 

-----Original Message-----
From: Mike Hammer (hmmr) [mailto:hmmr@...] 
Sent: Friday, January 22, 2010 1:52 PM
To: Mike Hammer (hmmr); Daryl Malas; speermint@...
Subject: RE: [Speermint] **Last Call** on the Speermint PeeringArchitecturedraft

All,

This txt art is messed up.  Seems like a lot of extra CR were injected.
But, hopefully you can see that the essence is:

SSP is composed of SBE and DBE.

SBE is composed of LUF, LRF, and SF.

Mike

> -----Original Message-----
> From: speermint-bounces@... [mailto:speermint-bounces@...]
On
> Behalf Of Mike Hammer (hmmr)
> Sent: Friday, January 22, 2010 3:48 PM
> To: Daryl Malas; speermint@...
> Subject: Re: [Speermint] **Last Call** on the Speermint 
> PeeringArchitecturedraft
> 
> Daryl,
> 
> Two problems:
> 
> 1)  The SBE to SF, LUF, and LRF relationship is convoluted and
circular
> (can iterate endlessly).
> 2)  You reference the SF throughout, but do not show it in the
diagram.
> 
> My proposal is to change the figure 1 as follows.
> Note, you can collapse the inner boundary of SBE, DBE, and SSP to be a 
> single edge if you want.
> 
>              +----------------+
> +---------------+
>             /                  \                       /
> \
>            |   +-----SBE---+   |                      |
+---SBE-----+
> |
>            |  /             \  |                      |   /
> \ |
>            | |     +--LUF-+ |  |       +------+       |   | +--LUF-+
> | |
>            | |  |->|      | |  |       | ENUM |       |   | |
|<-|
> | |
>            | |  |  |      +----------->| TN DB|<------------+      |
|
> | |
>            | |  |  |      | |  |       +------+       |   | |      |
|
> | |
>            | |  |  +------+ |  |                      |   | +------+
|
> | |
>            | |  |           |  |                      |   |
|
> | |
>            | |  |  +--LRF-+ |  |      +--------+      |   | +--LRF-+
|
> | |
>            | |  |->|      | |  |      | DNS    |      |   | |
|<-|
> | |
>            | |  |  |      +---------->|IP Addrs|<-----------+      |
|
> | |
>            | |  |  |      | |  |      +--------+      |   | |      |
|
> | |
>            | |  |  +------+ |  |                      |   | +------+
|
> | |
>            | |  |           |  |                      |   |
|
> | |
>            | |  |  +------+ |  |                      |   | +------+
|
> | |
>            | |  |->|      | |  |                      |   | |
|<-|
> | |
>            | |     |  SF  |<------------------------------->|  SF  |
> | |
>            | |     |      | |  |                      |   | |      |
> | |
>            | |     +------+ |  |                      |   | +------+
> | |
>            |  \       |     /  |                      |    \    |
/
> |
>            |   +------|----+   |                      |
+---|-----+
> |
>            |      +-------+    |                      |     +-------+
> |
>            |      |       |    |                      |     |       |
> |
>            | SSP1 |  DBE  |<------------------------------->|  DBE  |
> SSP2|
>            |      |       |    |                      |     |       |
> |
>            |      +-------+    |                      |     +-------+
> |
>             \                 /                        \
> /
>              +---------------+
> +---------------+
>                   Figure 1: Reference SPEERMINT Architecture
> 
> Thanks,
> Mike
> 
> 
> 
> 
> > -----Original Message-----
> > From: speermint-bounces@... [mailto:speermint-bounces@...]
> On
> > Behalf Of Daryl Malas
> > Sent: Friday, January 22, 2010 1:11 PM
> > To: speermint@...
> > Subject: [Speermint] RE:**Last Call** on the Speermint Peering 
> > Architecturedraft
> >
> > All,
> >
> > As a final reminder, the "Last Call" on the Speermint Peering
> Architecture
> > draft ends today.  Thank you to those who have already submitted
> feedback
> > on the draft, as this greatly helps the authors in improving it.
Once
> we
> > receive any additional comments today, we will begin working to
update
> the
> > draft.
> >
> > Best Regards,
> >
> > Daryl
> >
> > -----Original Message-----
> > From: speermint-bounces@... [mailto:speermint-bounces@...]
> On
> > Behalf Of Daryl Malas
> > Sent: Tuesday, January 19, 2010 8:54 AM
> > To: speermint@...
> > Subject: [Speermint] RE:**Last Call** on the Speermint Peering 
> > Architecturedraft
> >
> > All,
> >
> > This is just a reminder the "Last Call" on the Speermint Peering 
> > Architecture draft ends this Friday, January 22nd.  Please review
and
> post
> > comments to the mailing list soon.
> >
> > Regards,
> >
> > Daryl
> > Speermint Chairs
> >
> > -----Original Message-----
> > From: speermint-bounces@... [mailto:speermint-bounces@...]
> On
> > Behalf Of Daryl Malas
> > Sent: Friday, January 08, 2010 9:47 AM
> > To: speermint@...
> > Subject: [Speermint] RE:**Last Call** on the Speermint Peering 
> > Architecturedraft
> >
> > All,
> >
> > With the understanding it may be challenging for some to schedule
the
> time
> > to review and provide comments in 1 week, the "Last Call" is
extended
> to
> > January 22nd.
> >
> > Regards,
> >
> > Daryl
> >
> > -----Original Message-----
> > From: speermint-bounces@... [mailto:speermint-bounces@...]
> On
> > Behalf Of Daryl Malas
> > Sent: Thursday, January 07, 2010 9:55 AM
> > To: speermint@...
> > Subject: [Speermint] **Last Call** on the Speermint Peering 
> > Architecturedraft
> >
> > All,
> >
> > We discussed this during our last meeting, but I wanted to
officially
> note
> > it on the mailing list.  Please provide any final comments on the 
> > Speermint Peering Architecture draft.  This last call will last 
> > approximately 1 week and end on January 15th.
> >
> > Here is a link to the draft:
> > http://tools.ietf.org/html/draft-ietf-speermint-architecture-09
> >
> > Adam,
> >
> > Please review and begin correction of the nits here:
> >
>
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-spe
> > ermint-architecture-09.txt.
> >
> > We would like to wrap up this draft quickly, so everyone's effort to 
> > review and provide and final feedback is greatly appreciated.
> >
> > Regards,
> >
> > Daryl
> > _______________________________________________
> > Speermint mailing list
> > Speermint@...
> > https://www.ietf.org/mailman/listinfo/speermint
> > _______________________________________________
> > Speermint mailing list
> > Speermint@...
> > https://www.ietf.org/mailman/listinfo/speermint
> > _______________________________________________
> > Speermint mailing list
> > Speermint@...
> > https://www.ietf.org/mailman/listinfo/speermint
> > _______________________________________________
> > Speermint mailing list
> > Speermint@...
> > https://www.ietf.org/mailman/listinfo/speermint
> _______________________________________________
> Speermint mailing list
> Speermint@...
> https://www.ietf.org/mailman/listinfo/speermint
David Hancock | 5 Mar 06:13 2010

Extension negotiation in SIP Interconnect Guidelines


During EITF#76 review of the SIP Interconnect Guidelines, the Extension Negotiation section was
discussed, and specifically the sentence ...

    "The SBE MAY support configuration controls to disable
     certain extensions based on bilateral agreement between 
     peer networks. "

Here's a high-level summary of the discussion...

On the one hand, the above requirement is only a MAY, and therefore seems pretty benign. However,
restricting the set of extensions supported on the interface has a downside -- it disables extension
negotiation between endpoints, making it difficult to roll out new services. It would be preferable if
the SSP network was transparent to extension negotiation, so if both endpoints in a call support a new
extension they can use it. Conclusion of the discussion was that it's OK to leave the requirement in as long
as text is added to identify the disadvantages of blocking transparent end-to-end extension negotiation.

Here's a proposed resolution of this issue...

The "MAY" requirement under discussion was included as a general requirement to cover a specific case
where an operator wanted to disable the use of PRACK in their network because they deemed its value in terms
of increased reliability wasn't warranted by the cost of the extra signaling traffic load. The majority
of endpoints in the network supported PRACK, and would therefore include '100rel' in the Supported
header of originating INVITEs. On receiving such an INVITE, most endpoints would in fact use PRACK. So the
only way to turn it off was to remove '100rel' from the Supported header.  

Regarding the general requirement, a Service Provider can always choose to enforce a policy which limits
extensions supported/used in their network. Whether and how they do it is really out-of-scope of the
draft, and in that spirit maybe we should remove the requirement. However, since applying this kind of
policy is fairly common practice, it would probably be a good idea to add a note pointing out the negative
aspects of doing so (impedes deployment of new services, etc). Proposed text is shown below...

========= OLD TEXT BEGIN ==========================================

4.1.  Extension Negotiation

   It is RECOMMENDED that originating SBEs facing other peer networks be
   configured in such a way that they do not require any SIP extensions
   to be supported by the other end.  The SBE MUST identify all
   supported SIP extensions in the Supported header.  The SBE MAY
   support configuration controls to disable certain extensions based on
   bilateral agreement between peer networks.  For example, the SBE
   could be configured to remove '100rel' from the Supported header in
   order to disable the use of reliable provisional response (PRACK).

========= OLD TEXT END ==========================================

========= NEW TEXT BEGIN =======================================

4.1.  Extension Negotiation

   It is RECOMMENDED that originating SBEs facing other peer networks be
   configured in such a way that they do not require any SIP extensions
   to be supported by the other end. The SBE MUST identify all
   supported SIP extensions in the Supported header.  The SBE MAY
   support configuration controls to disable certain extensions based on
   bilateral agreement between peer networks.  For example, the SBE
   could be configured to remove '100rel' from the Supported header in
   order to disable the use of reliable provisional response (PRACK).

      Note: Policies that limit or block the use of SIP extensions 
      should be applied with care, since their application tends to
      disable SIP's native extension negotiation mechanism, and 
      therefore inhibit the deployment of new services. 

========= NEW TEXT END ==========================================

Comments welcome.

Thanks
David
Elwell, John | 5 Mar 18:12 2010

Re: Extension negotiation in SIP Interconnect Guidelines


> -----Original Message-----
> From: speermint-bounces@... 
> [mailto:speermint-bounces@...] On Behalf Of David Hancock
> Sent: 05 March 2010 05:13
> To: speermint@...
> Subject: [Speermint] Extension negotiation in SIP 
> Interconnect Guidelines
> 
> 
> During EITF#76 review of the SIP Interconnect Guidelines, the 
> Extension Negotiation section was discussed, and specifically 
> the sentence ...
> 
>     "The SBE MAY support configuration controls to disable
>      certain extensions based on bilateral agreement between 
>      peer networks. "
> 
> Here's a high-level summary of the discussion...
> 
> On the one hand, the above requirement is only a MAY, and 
> therefore seems pretty benign. However, restricting the set 
> of extensions supported on the interface has a downside -- it 
> disables extension negotiation between endpoints, making it 
> difficult to roll out new services. It would be preferable if 
> the SSP network was transparent to extension negotiation, so 
> if both endpoints in a call support a new extension they can 
> use it. Conclusion of the discussion was that it's OK to 
> leave the requirement in as long as text is added to identify 
> the disadvantages of blocking transparent end-to-end 
> extension negotiation.
> 
> Here's a proposed resolution of this issue...
> 
> The "MAY" requirement under discussion was included as a 
> general requirement to cover a specific case where an 
> operator wanted to disable the use of PRACK in their network 
> because they deemed its value in terms of increased 
> reliability wasn't warranted by the cost of the extra 
> signaling traffic load. The majority of endpoints in the 
> network supported PRACK, and would therefore include '100rel' 
> in the Supported header of originating INVITEs. On receiving 
> such an INVITE, most endpoints would in fact use PRACK. So 
> the only way to turn it off was to remove '100rel' from the 
> Supported header.  
> 
> Regarding the general requirement, a Service Provider can 
> always choose to enforce a policy which limits extensions 
> supported/used in their network. Whether and how they do it 
> is really out-of-scope of the draft, and in that spirit maybe 
> we should remove the requirement. However, since applying 
> this kind of policy is fairly common practice, it would 
> probably be a good idea to add a note pointing out the 
> negative aspects of doing so (impedes deployment of new 
> services, etc). Proposed text is shown below...
> 
> ========= OLD TEXT BEGIN ==========================================
> 
> 4.1.  Extension Negotiation
> 
>    It is RECOMMENDED that originating SBEs facing other peer 
> networks be
>    configured in such a way that they do not require any SIP 
> extensions
>    to be supported by the other end.  The SBE MUST identify all
>    supported SIP extensions in the Supported header.  The SBE MAY
>    support configuration controls to disable certain 
> extensions based on
>    bilateral agreement between peer networks.  For example, the SBE
>    could be configured to remove '100rel' from the Supported header in
>    order to disable the use of reliable provisional response (PRACK).
> 
> ========= OLD TEXT END ==========================================
> 
> ========= NEW TEXT BEGIN =======================================
> 
> 4.1.  Extension Negotiation
> 
>    It is RECOMMENDED that originating SBEs facing other peer 
> networks be
>    configured in such a way that they do not require any SIP 
> extensions
>    to be supported by the other end. The SBE MUST identify all
>    supported SIP extensions in the Supported header.  
[JRE] I find this text problematic. Does it mean all SIP extensions supported by the SBE or all SIP
extensions supported by the UA? The former is problematic because advertising support for something
that the UA might not support is wrong. The latter is problematic because the SBE cannot know that a UA
supports something if the UA doesn't include it in the Supported header field.

John

> The SBE MAY
>    support configuration controls to disable certain 
> extensions based on
>    bilateral agreement between peer networks.  For example, the SBE
>    could be configured to remove '100rel' from the Supported header in
>    order to disable the use of reliable provisional response (PRACK).
> 
>       Note: Policies that limit or block the use of SIP extensions 
>       should be applied with care, since their application tends to
>       disable SIP's native extension negotiation mechanism, and 
>       therefore inhibit the deployment of new services. 
> 
> ========= NEW TEXT END ==========================================
> 
> Comments welcome.
> 
> Thanks
> David
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Speermint mailing list
> Speermint@...
> https://www.ietf.org/mailman/listinfo/speermint
> 
David Hancock | 5 Mar 18:43 2010

Re: Extension negotiation in SIP Interconnect Guidelines

John,

Comments below...

David

> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@...]
> Sent: Friday, March 05, 2010 10:12 AM
> To: David Hancock; speermint@...
> Subject: RE: Extension negotiation in SIP Interconnect Guidelines
> 
> 
> 
> > -----Original Message-----
> > From: speermint-bounces@...
> > [mailto:speermint-bounces@...] On Behalf Of David Hancock
> > Sent: 05 March 2010 05:13
> > To: speermint@...
> > Subject: [Speermint] Extension negotiation in SIP
> > Interconnect Guidelines
> >
> >
> > During EITF#76 review of the SIP Interconnect Guidelines, the
> > Extension Negotiation section was discussed, and specifically
> > the sentence ...
> >
> >     "The SBE MAY support configuration controls to disable
> >      certain extensions based on bilateral agreement between
> >      peer networks. "
> >
> > Here's a high-level summary of the discussion...
> >
> > On the one hand, the above requirement is only a MAY, and
> > therefore seems pretty benign. However, restricting the set
> > of extensions supported on the interface has a downside -- it
> > disables extension negotiation between endpoints, making it
> > difficult to roll out new services. It would be preferable if
> > the SSP network was transparent to extension negotiation, so
> > if both endpoints in a call support a new extension they can
> > use it. Conclusion of the discussion was that it's OK to
> > leave the requirement in as long as text is added to identify
> > the disadvantages of blocking transparent end-to-end
> > extension negotiation.
> >
> > Here's a proposed resolution of this issue...
> >
> > The "MAY" requirement under discussion was included as a
> > general requirement to cover a specific case where an
> > operator wanted to disable the use of PRACK in their network
> > because they deemed its value in terms of increased
> > reliability wasn't warranted by the cost of the extra
> > signaling traffic load. The majority of endpoints in the
> > network supported PRACK, and would therefore include '100rel'
> > in the Supported header of originating INVITEs. On receiving
> > such an INVITE, most endpoints would in fact use PRACK. So
> > the only way to turn it off was to remove '100rel' from the
> > Supported header.
> >
> > Regarding the general requirement, a Service Provider can
> > always choose to enforce a policy which limits extensions
> > supported/used in their network. Whether and how they do it
> > is really out-of-scope of the draft, and in that spirit maybe
> > we should remove the requirement. However, since applying
> > this kind of policy is fairly common practice, it would
> > probably be a good idea to add a note pointing out the
> > negative aspects of doing so (impedes deployment of new
> > services, etc). Proposed text is shown below...
> >
> > ========= OLD TEXT BEGIN ==========================================
> >
> > 4.1.  Extension Negotiation
> >
> >    It is RECOMMENDED that originating SBEs facing other peer
> > networks be
> >    configured in such a way that they do not require any SIP
> > extensions
> >    to be supported by the other end.  The SBE MUST identify all
> >    supported SIP extensions in the Supported header.  The SBE MAY
> >    support configuration controls to disable certain
> > extensions based on
> >    bilateral agreement between peer networks.  For example, the SBE
> >    could be configured to remove '100rel' from the Supported header in
> >    order to disable the use of reliable provisional response (PRACK).
> >
> > ========= OLD TEXT END ==========================================
> >
> > ========= NEW TEXT BEGIN =======================================
> >
> > 4.1.  Extension Negotiation
> >
> >    It is RECOMMENDED that originating SBEs facing other peer
> > networks be
> >    configured in such a way that they do not require any SIP
> > extensions
> >    to be supported by the other end. The SBE MUST identify all
> >    supported SIP extensions in the Supported header.
> [JRE] I find this text problematic. Does it mean all SIP extensions
> supported by the SBE or all SIP extensions supported by the UA? The former
> is problematic because advertising support for something that the UA might
> not support is wrong. The latter is problematic because the SBE cannot
> know that a UA supports something if the UA doesn't include it in the
> Supported header field.

[dch] This goes back to the discussion on what is the target entity of normative statements in this draft. It
was a long time ago, but there was a discussion on the SPEERMINT list where we agreed to redefine the term
"SBE" within the context of this draft to mean all the SIP entities in the SIP signaling chain that can
affect the SIP/SDP peering interface. Here's the thread...

http://www.ietf.org/mail-archive/web/speermint/current/msg02606.html

In other words, within the scope of this draft, the SBE isn't the entity that sits at the egress/ingress
point; rather it's the whole SSP network (similar to the model used in SIPconnect1.1).

Does this resolve your concern?

By the way, at IETF#76 discussion on this draft you pointed out that even with this new definition of SBE,
there is a problem when the SIP signaling chain extends beyond the SSP network into some other network (in
other words, the UA is not part of this redefined SBE, so how can the SBE ensure it meets the guidelines?). I
think I need to address this concern, and will propose some text in a separate email. 

> 
> John
> 
> 
> 
> > The SBE MAY
> >    support configuration controls to disable certain
> > extensions based on
> >    bilateral agreement between peer networks.  For example, the SBE
> >    could be configured to remove '100rel' from the Supported header in
> >    order to disable the use of reliable provisional response (PRACK).
> >
> >       Note: Policies that limit or block the use of SIP extensions
> >       should be applied with care, since their application tends to
> >       disable SIP's native extension negotiation mechanism, and
> >       therefore inhibit the deployment of new services.
> >
> > ========= NEW TEXT END ==========================================
> >
> > Comments welcome.
> >
> > Thanks
> > David
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Speermint mailing list
> > Speermint@...
> > https://www.ietf.org/mailman/listinfo/speermint
> >
PFAUTZ, PENN L (ATTCORP | 5 Mar 18:48 2010
Picon

Re: SPEERMINT SIP Interconnect Guidelines

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

Gmane