1. SPEERMINT Architecture - Reinaldo Penno Juniper Networks SPEERMINT, IETF 70 Vancouver, Canada 2 December 2007

2. What the draft is about? The objective of this document is to define a reference peering architecture in the context of Session PEERing for Multimedia INTerconnect (SPEERMINT). In this process, we define the peering reference architecture (reference, for short), it's functional components, and peering interface functions from the perspective of a real-time communications (Voice and Multimedia) IP Service provider network.

3. Status of the draft Some discussion on the list Review and suggestions done by Daryl, Otmar and few others Stopped updating it as terminology and requirements changed because a lot of churn was happening A new version is in the pipeline

4. Changes in the Pipeline Major changes –Now that the terminology is settling down, we can change the architecture draft accordingly: SSP, SBE, DBE, etc –Same goes for requirements draft. Some alignment is needed. –Mapping of terminology introduced by use-cases-03 to architecture draft. For example, LS and SM –Remove MUST wording…It is a information draft. “MUST implement TLS” “request MUST contain a valid Identify” “….”

5. Changes in the Pipeline Section 4 (Reference SPEERMINT Architecture) –Change “The signaling function is located within the Signaling Path Border Element (SBE) “ to “The signaling function is represented by a Signaling Path Border Element (SBE) “ –Other similar changes –Change “The media function is located within the Data Path Border Element (DBE).” to “The media function is represented by a Data Path Border Element (DBE).

6. Changes in the Pipeline Section 5.1.3 (Carrier ENUM lookup) –Change title from Carrier ENUM to infrastructure ENUM Section 5.1.4 (Routing Table) –Include text to highlight the indirecte peering option Section 5.1.5 (SIP DNS Resolution) –Include text to highlight the fact that the terminating domain might no accept a call

7. Changes in the Pipeline Section 5.2.1 (Publish ENUM records) –Introduce text to highlight the fact that peers might not want to peer by default –Introduce text that suggests how to reject calls (IP Layer and/or SIP Layer)

8. Changes in the Pipeline Section 5.2.2 (Publish SIP DNS records) –This section needs to be reconciled with Requirement #3 which says “the mechanisms recommended for the declaration and advertisement of SBE and SDE entities must allow for peer and media variability.” –Change to allow indirect peering

9. Changes in the Pipeline Section 5.4.4 (Send the SIP request) –Change “Once a TLS connection between the peers is established, the initiating peer sends the request.” to “Once a trust relationship is established..”.. “In the case of TLS”

10. Changes in the Pipeline Section 6 (Call Control and Media Control Deployment Options) –Protocol between MF and SF is not in scope of SPEERMINT. Today H.248v3 is used in the IMS architecture