From root@core3.amsl.com Tue Jun 2 11:00:01 2009 Return-Path: X-Original-To: speermint@ietf.org Delivered-To: speermint@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id ECA133A6C33; Tue, 2 Jun 2009 11:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090602180001.ECA133A6C33@core3.amsl.com> Date: Tue, 2 Jun 2009 11:00:01 -0700 (PDT) Cc: speermint@ietf.org Subject: [Speermint] I-D ACTION:draft-ietf-speermint-voip-consolidated-usecases-12.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 18:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF. Title : VoIP SIP Peering Use Cases Author(s) : A. Uzelac, Y. Lee Filename : draft-ietf-speermint-voip-consolidated-usecases-12.txt Pages : 25 Date : 2009-6-2 This document depicts many common Voice over IP (VoIP) use cases for Session Initiation Protocol (SIP) Peering. These use cases are categorized into static and on-demand, and then further sub- categorized into direct and indirect. These use cases are not an exhaustive set, but rather the most common use cases deployed today. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip-consolidated-usecases-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-speermint-voip-consolidated-usecases-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-6-2104614.I-D@ietf.org> --NextPart-- From jason_livingood@cable.comcast.com Wed Jun 3 11:19:48 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF8E23A6C2F for ; Wed, 3 Jun 2009 11:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.766 X-Spam-Level: X-Spam-Status: No, score=-5.766 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id As7M-M3ZgQJt for ; Wed, 3 Jun 2009 11:19:38 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id CE08A3A6EC4 for ; Wed, 3 Jun 2009 11:19:36 -0700 (PDT) Received: from ([10.52.116.30]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.40347846; Wed, 03 Jun 2009 14:19:21 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 14:19:21 -0400 Received: from 10.36.144.29 ([10.36.144.29]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.154]) with Microsoft Exchange Server HTTP-DAV ; Wed, 3 Jun 2009 18:18:31 +0000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Wed, 03 Jun 2009 14:18:32 -0400 From: "Livingood, Jason" To: Adam Uzelac , Message-ID: Thread-Topic: Design Team Comments: draft-ietf-speermint-architecture-08 Thread-Index: Acnkd7N4X0FVs3C/REuB6HMrfsMtnA== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3326883512_3129460" X-OriginalArrivalTime: 03 Jun 2009 18:19:21.0258 (UTC) FILETIME=[D0D438A0:01C9E477] Subject: [Speermint] Design Team Comments: draft-ietf-speermint-architecture-08 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 18:19:49 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3326883512_3129460 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable >From our design session today, which Adam could not attend. Here are our comments for the authors to review and act on. Please perform an update to =AD09 prior to the cutoff for the Stockholm IETF meeting. After these changes, this document is probably ready or nearly ready for WGLC. General: need reference to RFC 5486 (Terminology) Section 1: no comments Section 2:=20 - Eliminate Figure 1 - Eliminate entire section =AD does not serve a useful purpose Section 3, Comments on Figure: - Increase the space between the SSP domains - Move existing DNS block down to be between / on the same level as the LUF - Change existing DNS block, change text inside to: ENUM, TN DB - Add a new box below that block between the LRF, and make that box contain: DNS, IP Addrs., Etc. (and make connecting lines from this to each LRF) - Add connecting lines between the SBEs - Add connecting lines between the DBEs - Within each SSP domain, add a connecting line between the SBE and the SSP=B9s LUF and LRF - Change =B3Orginating SSP=B2 and =B3Terminating SSP=B2 to =B3SSP 1=B2 and =B3SSP 2=B2 - Remove =B3SF=B2 and =B3MF=B2 and just keep SBE and DBE inside the boxes =20 - Remove all text after the figure, and insert a reference to RFC 5486 as follows: =B3For further details on the elements and functions described in this figure, please refer to [RFC 5486].=B2 - Add a new sub-section to section 3, which describes the relationships between various functions/elements, as follows: -- An SBE can contain an SF function -- An SF can perform LUF and LRF functions -- As an additional consideration, a Session Border Controller (cit= e new SBC RFC here), can contain an SF, SBE and DBE, and may perform the LUF and LRF functions. -- The following functions can communicate as follows, depending upon various real-world implementations: - SF can communicate with LUF, LRF, SBE, and SF - LUF can communicate with SF and SBE - LRF can communicate with SF and SBE Section 4: - Hyphenate =B3Inter-Domain=B2 in the section title - Capitalize =B3originating=B2 to =B3Originating=B2 - Change all those steps as follows: 1. Determine the target SSP via the LUF. 2. Determine the address of the SF of the target SSP via the LRF. 3. Establish the session. 4. Exchange the media, which could include voice, video, text, etc. - Fix the following sentences in that section to suit the new numbers above. Section 5:=20 - Make sure each section title has leading caps. For example, 5.1.1.1 should be Target Address Analysis - 5.1.1.1:=20 -- Paragraph 1, delete =B3Note that the SSP may also consult any manner of private data sources to make this determination.=B2 -- Paragraph 2, re-word as follows: If the target address does not represent a resource inside the originating SSP's administrative domain or federation of domains, then the originating SSP performs a Lookup Function (LUF) to determine a target address, and then it resolves the call routing data by using the Location Routing Function (LRF). -- Please remove any detailed discussion beyond above of the LRF =AD and move to the relevant LRF section. -- Please move the SIP redirect section 5.1.2.3 into this section - Remove section 5.1.1.3, Infrastructure ENUM - 5.1.2, at the end, add: =B3The following sections define mechanisms which may be used by the LRF. These are not in any particular order and, importantly, not all of them may be used.=B2 - 5.1.2.1, change title to =B3DNS Resolution=B2 (dropping =8CSIP=B9) - 5.1.2.1, strike the first sentence, as out-of-scope (policy). - 5.1.2.1, strike the sentence =B3Note that these are queries of records in the global DNS.=B2 - Change title of section 5.1.1.2 to =B3ENUM Lookup=B2 and remove reference= s to any specific kind of ENUM (end user, infrastructure, or private) - After 5.1.2.2 (Routing Table), add a new section (5.1.2.3), to describe the new box in the architecture diagram. The box was DNS, IP Addresses, Etc. This section should describe other methods not already defined, such as codec-based routing, method-based routing, time of day routing, least cost routing source-based routing. - 5.1.3, change the title to =B3The Signaling Path Border Element (SBE)=B2 - 5.1.3, reword 2nd paragraph, 2nd sentence as follows: =B3The optional termination and re-initiation of calls may be performed by the signaling path element (SBE), or other signaling elements.=B3 - 5.1.3, end of 3rd paragraph, you have an =B3and=B2 before =B3SIP security=B2 --> so take out that =B3and=B2: =B3... SIP header normalization, SIP security, privacy, and encryption.=B2 (note also comma added after privacy) - 5.1.3.1.2, TLS, delete entire section - 5.2, rename section to =B3Target SSP Procedures=B2 - 5.2.1, delete entire section (out of scope -> DRINKS) - 5.2.2, change title to =B3The Ingress Signaling Path Border Element (SBE)=B2 - 5.2.2.1, delete 2nd paragraph - 5.2.2.1, changes 1st paragraph, delete last two sentences (=B3For these requests, there should be no remaining Route header field values. For in-dialog requests, the receiving SSP can verify that it corresponds to the top-most Route header field value.=B2) - 5.2.2.2, change 2nd paragraph, 2nd sentence, to: =B3For example, when a request is rejected because the originating SSP is not authorized to peer, the receiving SSP should respond with a 403 response with the reason phrase "Unsupported Peer".=B2 - 5.3: This duplicates section 5.2, so delete section. - 5.4, rename section title to =B3Data Path Border Element (DBE)=B2 - 5.4, please also add a reference to RFC 5486 in the first sentence, such as =B3As defined in [RFC 5486], the purpose of the MF...=B2 - 5.5, Policy, delete entire section (we=B9ll come back to policy later i= n another draft) - 6, delete section (may be good content for an implementation-specific draft later on, but not needed here) =20 - GENERAL: The reference numbers in Normative and Informative reference= s ALL need to be checked =8B a number of these are incorrect. Need to change all references to the type [RFCXXXX]. Also, prune any unused references. - Add a new section after Section 9 (IANA considerations), named =B3Contributors=B2, and add: The following people made significant textual contributions to and provided significant in-depth review of this document: Hadriel Kaplan, Acme Packet (hkaplan@acmepacket.com) Jason Livingood, Comcast (jason_livingood@cable.comcast.com) David Schwartz, Kayote Systems (david.schwartz@kayote.com) Rich Shockey, Unaffiliated (richard@shockey.us) //END OF COMMENTS ON THIS DRAFT// --> UNRELATED TO DO ITEM: Create a new draft (anyone?) on Call Control and Media Control Deployment Options using content from Section 6 of http://www.ietf.org/internet-drafts/draft-ietf-speermint-architecture-08.tx= t , if interested: 6. Call Control and Media Control Deployment Options The peering functions can be deployed along the following two dimensions depending upon how the signaling and the media functions along with IP layer=20 are implemented: Composed or Decomposed: Addresses the question whether the media must flow=20 through the same physical and geographic elements as SIP dialogs and sessions. =20 Centralized or Distributed: Addresses the question whether the logical and=20 physical interconnections are in one geographical location or distribute= d to=20 multiple physical locations on the SSP's network. In a composed model, SF and MF functions are implemented in one peering logical=20 element. =20 =20 Provider A Provider B ---------- . . ---------- / \ . . / \ | | . _ . | | | +----+ . / \_ . +----+ | | | SF |<-----/ \------| SF | | | +-+--+ . /Transit\ . | | | | | | . / IP \ . | | | | +-+--+ . | Provider| . | | | | | MF |<~~~| (Option)|~~~~| MF | | | +----+ . \ / . +----+ | | | . \ __ _ / . | | \_________ / . . \________ _/ ---------- ---------- =20 --- Signal (SIP) ~~~ Bearer (RTP/IP) ... Scope of peering =20 Figure 3: Decomposed v. Collapsed Peering =20 The advantage of a collapsed peering architecture is that one-element solves=20 all peering issues. Disadvantage examples of this architecture are singl= e point=20 of failure, bottleneck, and complex scalability. In a decomposed model, SF and MF are implemented in separate peering logical=20 elements. SFs are implemented in a proxy and MFs are implemented in another=20 logical element. The scaling of signaling versus scaling of media may differ=20 between applications. Decomposing allows each to follow a separate migration=20 path. =20 This model allows the implementation of M:N model where one SF is associated=20 with multiple peering MF and one peering MF is associated with multiple SFs.=20 Generally, a vertical protocol associates the relationship between a SF and a=20 MF. This architecture reduces the potential of a single point of failure= . It=20 allows separation of the policy decision point and the policy enforcemen= t point. An example of disadvantages is the scaling complexity because of the M:N=20 relationship and latency due to the vertical control messages between entities.=20 //end// =20 --B_3326883512_3129460 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Design Team Comments: draft-ietf-speermint-architecture-08 From our design session today, which Adam could not attend.  

Here are our comments for the authors to review and act on.  Ple= ase perform an update to –09 prior to the cutoff for the Stockholm IET= F meeting.  After these changes, this document is probably read= y or nearly ready for WGLC.

General: need reference to RFC 5486 (Terminology)

Section 1: no comments

Section 2:
    - Eliminate Figure 1
    - Eliminate entire section – does not serve a= useful purpose

Section 3, Comments on Figure:
    - Increase the space between the SSP domains
    - Move existing DNS block down to be between / on t= he same level as the LUF
    - Change existing DNS block, change text inside to:= ENUM, TN DB
    - Add a new box below that block between the LRF, a= nd make that box contain: DNS, IP Addrs., Etc. (and make connecting lines fr= om this to each LRF)
    - Add connecting lines between the SBEs
    - Add connecting lines between the DBEs
    - Within each SSP domain, add a connecting line bet= ween the SBE and the SSP’s LUF and LRF
    - Change “Orginating SSP” and “Te= rminating SSP” to “SSP 1” and “SSP 2”
    - Remove “SF” and “MF” and = just keep SBE and DBE inside the boxes
   
    - Remove all text after the figure, and insert a re= ference to RFC 5486 as follows:
    “For further details on the elements and func= tions described in this figure, please refer to [RFC 5486].”

    - Add a new sub-section to section 3, which describ= es the relationships between various functions/elements, as follows:
        -- An SBE can contain an SF= function
        -- An SF can perform LUF and LRF functions
        -- As an additional conside= ration, a Session Border Controller (cite new SBC RFC here), can contain an = SF, SBE and DBE, and may perform the LUF and LRF functions.
        -- The following functions = can communicate as follows, depending upon various real-world implementation= s:
            - S= F can communicate with LUF, LRF, SBE, and SF
            - L= UF can communicate with SF and SBE
            - L= RF can communicate with SF and SBE

Section 4:
    - Hyphenate “Inter-Domain” in the secti= on title
    - Capitalize “originating” to “Or= iginating”
    - Change all those steps as follows:
     1. Determine the target SSP via the LUF.
     2. Determine the address of the SF of the tar= get SSP via the LRF.
     3. Establish the session.  
     4. Exchange the media, which could include vo= ice, video, text, etc.  
    - Fix the following sentences in that section to su= it the new numbers above.

Section 5:
    - Make sure each section title has leading caps. &n= bsp;For example, 5.1.1.1 should be Target Address Analysis
    - 5.1.1.1:
        -- Paragraph 1, delete R= 20;Note that the SSP may also consult any manner of private data sources to = make this determination.”
        -- Paragraph 2, re-word as = follows:
    If the target address does not represent a resource= inside the originating SSP's administrative domain or federation of domains= , then the originating SSP performs a Lookup Function (LUF) to determine a t= arget address, and then it resolves the call routing data by using the Locat= ion Routing Function (LRF).  
        -- Please remove any detail= ed discussion beyond above of the LRF – and move to the relevant LRF s= ection.
        -- Please move the SIP redi= rect section 5.1.2.3 into this section
    - Remove section 5.1.1.3, Infrastructure ENUM
    - 5.1.2, at the end, add: “The following sect= ions define mechanisms which may be used by the LRF.  These are not in = any particular order and, importantly, not all of them may be used.”     - 5.1.2.1, change title to “DNS Resolution= 221; (dropping ‘SIP’)
    - 5.1.2.1, strike the first sentence, as out-of-sco= pe (policy).
    - 5.1.2.1, strike the sentence “Note that the= se are queries of records in the global DNS.”
    - Change title of section 5.1.1.2 to “ENUM Lo= okup” and remove references to  any specific kind of ENUM (end us= er, infrastructure, or private)
    - After 5.1.2.2 (Routing Table), add a new section = (5.1.2.3), to describe the new box in the architecture diagram.  The bo= x was DNS, IP Addresses, Etc.  This section should describe other metho= ds not already defined, such as codec-based routing, method-based routing, t= ime of day routing, least cost routing source-based routing.
    - 5.1.3, change the title to “The Signaling P= ath Border Element (SBE)”
    - 5.1.3, reword 2nd paragraph, 2nd sentence as foll= ows: “The optional termination and re-initiation of calls may be perfo= rmed by the signaling path element (SBE), or other signaling elements.“= ;
    - 5.1.3, end of 3rd paragraph, you have an “a= nd” before “SIP security” --> so take out that “a= nd”: “... SIP header normalization, SIP security, privacy, and e= ncryption.”  (note also comma added after privacy)
    - 5.1.3.1.2, TLS, delete entire section
    - 5.2, rename section to “Target SSP Procedur= es”
    - 5.2.1, delete entire section (out of scope -> = DRINKS)
    - 5.2.2, change title to “The Ingress Signali= ng Path Border Element (SBE)”
    - 5.2.2.1, delete 2nd paragraph
    - 5.2.2.1, changes 1st paragraph, delete last two s= entences (“For these requests, there should be no remaining Route head= er field values. For in-dialog requests, the receiving SSP can verify that i= t corresponds to the top-most Route header field value.”)
    - 5.2.2.2, change 2nd paragraph, 2nd sentence, to: = “For example, when a request is rejected because the originating SSP i= s not authorized to peer, the receiving SSP should respond with a 403 respon= se with the reason phrase "Unsupported Peer".”
    - 5.3: This duplicates section 5.2, so delete secti= on.
    - 5.4, rename section title to “Data Path Bor= der Element (DBE)”
    - 5.4, please also add a reference to RFC 5486 in t= he first sentence, such as “As defined in [RFC 5486], the purpose of t= he MF...”
    - 5.5, Policy, delete entire section (we’ll c= ome back to policy later in another draft)
    - 6, delete section (may be good content for an imp= lementation-specific draft later on, but not needed here)
    
    - GENERAL: The reference numbers in Normative and I= nformative references ALL need to be checked — a number of these are i= ncorrect.  Need to change all references to the type [RFCXXXX].  A= lso, prune any unused references.

    - Add a new section after Section 9 (IANA considera= tions), named “Contributors”, and add:
        The following people made s= ignificant textual contributions to and provided significant in-depth review= of this document:
        Hadriel Kaplan, Acme Packet= (hkaplan@acmepacket.co= m)
        Jason Livi= ngood, Comcast (jason_livingood@= cable.comcast.com)
        David Schwartz, Kayote Syst= ems (david.schwartz@= kayote.com)
        Rich Shockey, Unaffiliated (richard@s= hockey.us)


//END OF COMMENTS ON THIS DRAFT//

--> UNRELATED TO DO ITEM:  Create a new draft (anyone?) on Call Con= trol and Media Control Deployment Options using content from Section 6 of http://www.ietf.org/internet-drafts/draft-ietf-speermint-architectu= re-08.txt, if interested:

6. Call Control and Media Control Deployment Options  

   The peering functions can be deployed along the following= two dimensions
   depending upon how the signaling and the media functions = along with IP layer
   are implemented:  

   Composed or Decomposed:  Addresses the question whet= her the media must flow
   through the same physical and geographic elements as SIP = dialogs and sessions.  

   Centralized or Distributed:  Addresses the question = whether the logical and
   physical interconnections are in one geographical locatio= n or distributed to
   multiple physical locations on the SSP's network.  <= BR>
   In a composed model, SF and MF functions are implemented = in one peering logical
   element.  
    
            &nb= sp;Provider A           &n= bsp;            = Provider B
            &nb= sp;----------   .         =       .   ----------
            / &= nbsp;         \ .   &= nbsp;           . &nb= sp;/          \
           |  &= nbsp;         | .   &= nbsp;   _       . |   = ;         |
           |  &= nbsp;    +----+ .     /   = \_    . +----+       |
           |  &= nbsp;    | SF |<-----/     \-----= -| SF |       |
           |  &= nbsp;    +-+--+ .   /Transit\   . | =    |       |
           |  &= nbsp;      | |  .  /   IP =    \  . |    |     &n= bsp; |
           |  &= nbsp;    +-+--+ .  | Provider|  . |  &nbs= p; |       |
           |  &= nbsp;    | MF |<~~~| (Option)|~~~~| MF |   =     |
           |  &= nbsp;    +----+ .   \     =    /  . +----+       |            |  &= nbsp;         | .   &= nbsp;\ __ _ /   . |        &nbs= p;   |
            \__= _______ /  .          &nbs= p;    .  \________ _/
            &nb= sp;----------           &n= bsp;           ------= ----
    
   --- Signal (SIP)
   ~~~ Bearer (RTP/IP)
   ... Scope of peering
            &nb= sp;            &= nbsp;           
            &nb= sp;      Figure 3: Decomposed v. Collapsed Pee= ring
 
   The advantage of a collapsed peering architecture is that= one-element solves
   all peering issues. Disadvantage examples of this archite= cture are single point
   of failure, bottleneck, and complex scalability.  
   In a decomposed model, SF and MF are implemented in separ= ate peering logical
   elements. SFs are implemented in a proxy and MFs are impl= emented in another
   logical element.  The scaling of signaling versus sc= aling of media may differ
   between applications.  Decomposing allows each to fo= llow a separate migration
   path.  

   This model allows the implementation of M:N model where o= ne SF is associated
   with multiple peering MF and one peering MF is associated= with multiple SFs.
   Generally, a vertical protocol associates the relationshi= p between a SF and a
   MF. This architecture reduces the potential of a single p= oint of failure. It
   allows separation of the policy decision point and the po= licy enforcement
   point. An example of disadvantages is the scaling complex= ity because of the M:N
   relationship and latency due to the vertical control mess= ages between entities.

//end//





     --B_3326883512_3129460-- From hmmr@cisco.com Wed Jun 3 11:48:08 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B9143A6DD7 for ; Wed, 3 Jun 2009 11:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWmY4XF+jclT for ; Wed, 3 Jun 2009 11:47:56 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 895DD3A6EA3 for ; Wed, 3 Jun 2009 11:47:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,299,1241395200"; d="scan'208,217";a="78975989" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 03 Jun 2009 18:47:57 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n53IlveM028435; Wed, 3 Jun 2009 11:47:57 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n53Ilpct002808; Wed, 3 Jun 2009 18:47:57 GMT Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Jun 2009 14:47:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9E47B.CE481279" Date: Wed, 3 Jun 2009 14:47:54 -0400 Message-ID: <072C5B76F7CEAB488172C6F64B30B5E3072EE498@xmb-rtp-20b.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Speermint] Design Team Comments:draft-ietf-speermint-architecture-08 Thread-Index: Acnkd7N4X0FVs3C/REuB6HMrfsMtnAAA7T/g References: From: "Mike Hammer (hmmr)" To: "Livingood, Jason" , "Adam Uzelac" , X-OriginalArrivalTime: 03 Jun 2009 18:47:55.0371 (UTC) FILETIME=[CE851BB0:01C9E47B] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=32735; t=1244054877; x=1244918877; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=hmmr@cisco.com; z=From:=20=22Mike=20Hammer=20(hmmr)=22=20 |Subject:=20RE=3A=20[Speermint]=20Design=20Team=20Comments= 3Adraft-ietf-speermint-architecture-08 |Sender:=20; bh=mUJ3V42nwqFsp4PqXQm49hbaer62/L992JQ4dD9TMtQ=; b=nUYVI1bbzIXWPs8BwlMmwx8kB11GVU5QOQE2iwlMfyWgG6HD4JoDAGAU0H /126W7tplekKYvk8UpTpYMHE/JWfSC9nqpncDjhaoVoX93bViMV7gQnbMvUo Cin1NxJn5s; Authentication-Results: sj-dkim-4; header.From=hmmr@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [Speermint] Design Team Comments:draft-ietf-speermint-architecture-08 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jun 2009 18:48:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9E47B.CE481279 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Jason, =20 Seeing as I drew that picture in section 2..... =20 That section could likely be replaced by a reference to the Use Cases document which did not exist at first. =20 The reference could be a sentence at the beginning of what is now Section 3. =20 Mike =20 =20 =20 From: speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On Behalf Of Livingood, Jason Sent: Wednesday, June 03, 2009 2:19 PM To: Adam Uzelac; speermint@ietf.org Subject: [Speermint] Design Team Comments:draft-ietf-speermint-architecture-08 =20 >From our design session today, which Adam could not attend. =20 Here are our comments for the authors to review and act on. Please perform an update to -09 prior to the cutoff for the Stockholm IETF meeting. After these changes, this document is probably ready or nearly ready for WGLC. General: need reference to RFC 5486 (Terminology) Section 1: no comments Section 2:=20 - Eliminate Figure 1 - Eliminate entire section - does not serve a useful purpose Section 3, Comments on Figure: - Increase the space between the SSP domains - Move existing DNS block down to be between / on the same level as the LUF - Change existing DNS block, change text inside to: ENUM, TN DB - Add a new box below that block between the LRF, and make that box contain: DNS, IP Addrs., Etc. (and make connecting lines from this to each LRF) - Add connecting lines between the SBEs - Add connecting lines between the DBEs - Within each SSP domain, add a connecting line between the SBE and the SSP's LUF and LRF - Change "Orginating SSP" and "Terminating SSP" to "SSP 1" and "SSP 2" - Remove "SF" and "MF" and just keep SBE and DBE inside the boxes =20 - Remove all text after the figure, and insert a reference to RFC 5486 as follows: "For further details on the elements and functions described in this figure, please refer to [RFC 5486]." - Add a new sub-section to section 3, which describes the relationships between various functions/elements, as follows: -- An SBE can contain an SF function -- An SF can perform LUF and LRF functions -- As an additional consideration, a Session Border Controller (cite new SBC RFC here), can contain an SF, SBE and DBE, and may perform the LUF and LRF functions. -- The following functions can communicate as follows, depending upon various real-world implementations: - SF can communicate with LUF, LRF, SBE, and SF - LUF can communicate with SF and SBE - LRF can communicate with SF and SBE Section 4: - Hyphenate "Inter-Domain" in the section title - Capitalize "originating" to "Originating" - Change all those steps as follows: 1. Determine the target SSP via the LUF. 2. Determine the address of the SF of the target SSP via the LRF. 3. Establish the session. =20 4. Exchange the media, which could include voice, video, text, etc. - Fix the following sentences in that section to suit the new numbers above. Section 5:=20 - Make sure each section title has leading caps. For example, 5.1.1.1 should be Target Address Analysis - 5.1.1.1:=20 -- Paragraph 1, delete "Note that the SSP may also consult any manner of private data sources to make this determination." -- Paragraph 2, re-word as follows: If the target address does not represent a resource inside the originating SSP's administrative domain or federation of domains, then the originating SSP performs a Lookup Function (LUF) to determine a target address, and then it resolves the call routing data by using the Location Routing Function (LRF). =20 -- Please remove any detailed discussion beyond above of the LRF - and move to the relevant LRF section. -- Please move the SIP redirect section 5.1.2.3 into this section - Remove section 5.1.1.3, Infrastructure ENUM - 5.1.2, at the end, add: "The following sections define mechanisms which may be used by the LRF. These are not in any particular order and, importantly, not all of them may be used." - 5.1.2.1, change title to "DNS Resolution" (dropping 'SIP') - 5.1.2.1, strike the first sentence, as out-of-scope (policy). - 5.1.2.1, strike the sentence "Note that these are queries of records in the global DNS." - Change title of section 5.1.1.2 to "ENUM Lookup" and remove references to any specific kind of ENUM (end user, infrastructure, or private) - After 5.1.2.2 (Routing Table), add a new section (5.1.2.3), to describe the new box in the architecture diagram. The box was DNS, IP Addresses, Etc. This section should describe other methods not already defined, such as codec-based routing, method-based routing, time of day routing, least cost routing source-based routing. - 5.1.3, change the title to "The Signaling Path Border Element (SBE)" - 5.1.3, reword 2nd paragraph, 2nd sentence as follows: "The optional termination and re-initiation of calls may be performed by the signaling path element (SBE), or other signaling elements." - 5.1.3, end of 3rd paragraph, you have an "and" before "SIP security" --> so take out that "and": "... SIP header normalization, SIP security, privacy, and encryption." (note also comma added after privacy) - 5.1.3.1.2, TLS, delete entire section - 5.2, rename section to "Target SSP Procedures" - 5.2.1, delete entire section (out of scope -> DRINKS) - 5.2.2, change title to "The Ingress Signaling Path Border Element (SBE)" - 5.2.2.1, delete 2nd paragraph - 5.2.2.1, changes 1st paragraph, delete last two sentences ("For these requests, there should be no remaining Route header field values. For in-dialog requests, the receiving SSP can verify that it corresponds to the top-most Route header field value.") - 5.2.2.2, change 2nd paragraph, 2nd sentence, to: "For example, when a request is rejected because the originating SSP is not authorized to peer, the receiving SSP should respond with a 403 response with the reason phrase "Unsupported Peer"." - 5.3: This duplicates section 5.2, so delete section. - 5.4, rename section title to "Data Path Border Element (DBE)" - 5.4, please also add a reference to RFC 5486 in the first sentence, such as "As defined in [RFC 5486], the purpose of the MF..." - 5.5, Policy, delete entire section (we'll come back to policy later in another draft) - 6, delete section (may be good content for an implementation-specific draft later on, but not needed here) =20 - GENERAL: The reference numbers in Normative and Informative references ALL need to be checked - a number of these are incorrect. Need to change all references to the type [RFCXXXX]. Also, prune any unused references. - Add a new section after Section 9 (IANA considerations), named "Contributors", and add: The following people made significant textual contributions to and provided significant in-depth review of this document: Hadriel Kaplan, Acme Packet (hkaplan@acmepacket.com) Jason Livingood, Comcast (jason_livingood@cable.comcast.com) David Schwartz, Kayote Systems (david.schwartz@kayote.com) Rich Shockey, Unaffiliated (richard@shockey.us) //END OF COMMENTS ON THIS DRAFT// --> UNRELATED TO DO ITEM: Create a new draft (anyone?) on Call Control and Media Control Deployment Options using content from Section 6 of http://www.ietf.org/internet-drafts/draft-ietf-speermint-architecture-08 .txt, if interested: 6. Call Control and Media Control Deployment Options =20 The peering functions can be deployed along the following two dimensions=20 depending upon how the signaling and the media functions along with IP layer=20 are implemented: =20 Composed or Decomposed: Addresses the question whether the media must flow=20 through the same physical and geographic elements as SIP dialogs and sessions. =20 Centralized or Distributed: Addresses the question whether the logical and=20 physical interconnections are in one geographical location or distributed to=20 multiple physical locations on the SSP's network. =20 In a composed model, SF and MF functions are implemented in one peering logical=20 element. =20 =20 Provider A Provider B=20 ---------- . . ----------=20 / \ . . / \=20 | | . _ . | |=20 | +----+ . / \_ . +----+ |=20 | | SF |<-----/ \------| SF | |=20 | +-+--+ . /Transit\ . | | |=20 | | | . / IP \ . | | |=20 | +-+--+ . | Provider| . | | |=20 | | MF |<~~~| (Option)|~~~~| MF | |=20 | +----+ . \ / . +----+ |=20 | | . \ __ _ / . | |=20 \_________ / . . \________ _/=20 ---------- ----------=20 =20 --- Signal (SIP)=20 ~~~ Bearer (RTP/IP)=20 ... Scope of peering=20 =20 Figure 3: Decomposed v. Collapsed Peering=20 =20 The advantage of a collapsed peering architecture is that one-element solves=20 all peering issues. Disadvantage examples of this architecture are single point=20 of failure, bottleneck, and complex scalability. =20 In a decomposed model, SF and MF are implemented in separate peering logical=20 elements. SFs are implemented in a proxy and MFs are implemented in another=20 logical element. The scaling of signaling versus scaling of media may differ=20 between applications. Decomposing allows each to follow a separate migration=20 path. =20 This model allows the implementation of M:N model where one SF is associated=20 with multiple peering MF and one peering MF is associated with multiple SFs.=20 Generally, a vertical protocol associates the relationship between a SF and a=20 MF. This architecture reduces the potential of a single point of failure. It=20 allows separation of the policy decision point and the policy enforcement=20 point. An example of disadvantages is the scaling complexity because of the M:N=20 relationship and latency due to the vertical control messages between entities.=20 //end// =20 ------_=_NextPart_001_01C9E47B.CE481279 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Design Team Comments: = draft-ietf-speermint-architecture-08

Jason,

 

Seeing as I drew that picture in section 2…..

 

That = section could likely be replaced by a reference to the Use Cases document which = did not exist at first.

 

The = reference could be a sentence at the beginning of what is now Section = 3.

 

Mike

 

 

 

From:= speermint-bounces@ietf.org [mailto:speermint-bounces@ietf.org] On = Behalf Of Livingood, Jason
Sent: Wednesday, June 03, 2009 2:19 PM
To: Adam Uzelac; speermint@ietf.org
Subject: [Speermint] Design Team Comments:draft-ietf-speermint-architecture-08

 

From our design session today, which Adam could not attend.  

Here are our comments for the authors to review and act on. =  Please perform an update to –09 prior to the cutoff for the Stockholm = IETF meeting.  After these changes, this document is probably = ready or nearly ready for WGLC.

General: need reference to RFC 5486 (Terminology)

Section 1: no comments

Section 2:
    - Eliminate Figure 1
    - Eliminate entire section – does not = serve a useful purpose

Section 3, Comments on Figure:
    - Increase the space between the SSP domains
    - Move existing DNS block down to be between / = on the same level as the LUF
    - Change existing DNS block, change text inside = to: ENUM, TN DB
    - Add a new box below that block between the = LRF, and make that box contain: DNS, IP Addrs., Etc. (and make connecting lines = from this to each LRF)
    - Add connecting lines between the SBEs
    - Add connecting lines between the DBEs
    - Within each SSP domain, add a connecting line = between the SBE and the SSP’s LUF and LRF
    - Change “Orginating SSP” and “Terminating SSP” to “SSP 1” and “SSP = 2”
    - Remove “SF” and “MF” = and just keep SBE and DBE inside the boxes
   
    - Remove all text after the figure, and insert a reference to RFC 5486 as follows:
    “For further details on the elements and = functions described in this figure, please refer to [RFC 5486].”

    - Add a new sub-section to section 3, which = describes the relationships between various functions/elements, as follows:
        -- An SBE can contain an = SF function
        -- An SF can perform LUF = and LRF functions
        -- As an additional consideration, a Session Border Controller (cite new SBC RFC here), can = contain an SF, SBE and DBE, and may perform the LUF and LRF functions.
        -- The following = functions can communicate as follows, depending upon various real-world = implementations:
            -= SF can communicate with LUF, LRF, SBE, and SF
            -= LUF can communicate with SF and SBE
            -= LRF can communicate with SF and SBE

Section 4:
    - Hyphenate “Inter-Domain” in the = section title
    - Capitalize “originating” to “Originating”
    - Change all those steps as follows:
     1. Determine the target SSP via the = LUF.
     2. Determine the address of the SF of the = target SSP via the LRF.
     3. Establish the session.  
     4. Exchange the media, which could include = voice, video, text, etc.  
    - Fix the following sentences in that section to = suit the new numbers above.

Section 5:
    - Make sure each section title has leading caps.  For example, 5.1.1.1 should be Target Address Analysis
    - 5.1.1.1:
        -- Paragraph 1, delete “Note that the SSP may also consult any manner of private data = sources to make this determination.”
        -- Paragraph 2, re-word = as follows:
    If the target address does not represent a = resource inside the originating SSP's administrative domain or federation of = domains, then the originating SSP performs a Lookup Function (LUF) to determine a = target address, and then it resolves the call routing data by using the = Location Routing Function (LRF).  
        -- Please remove any = detailed discussion beyond above of the LRF – and move to the relevant LRF section.
        -- Please move the SIP = redirect section 5.1.2.3 into this section
    - Remove section 5.1.1.3, Infrastructure = ENUM
    - 5.1.2, at the end, add: “The following = sections define mechanisms which may be used by the LRF.  These are not in = any particular order and, importantly, not all of them may be = used.”
    - 5.1.2.1, change title to “DNS = Resolution” (dropping ‘SIP’)
    - 5.1.2.1, strike the first sentence, as = out-of-scope (policy).
    - 5.1.2.1, strike the sentence “Note that = these are queries of records in the global DNS.”
    - Change title of section 5.1.1.2 to “ENUM Lookup” and remove references to  any specific kind of ENUM = (end user, infrastructure, or private)
    - After 5.1.2.2 (Routing Table), add a new = section (5.1.2.3), to describe the new box in the architecture diagram. =  The box was DNS, IP Addresses, Etc.  This section should describe other = methods not already defined, such as codec-based routing, method-based routing, time = of day routing, least cost routing source-based routing.
    - 5.1.3, change the title to “The = Signaling Path Border Element (SBE)”
    - 5.1.3, reword 2nd paragraph, 2nd sentence as = follows: “The optional termination and re-initiation of calls may be = performed by the signaling path element (SBE), or other signaling = elements.“
    - 5.1.3, end of 3rd paragraph, you have an “and” before “SIP security” --> so take out = that “and”: “... SIP header normalization, SIP security, = privacy, and encryption.”  (note also comma added after privacy)
    - 5.1.3.1.2, TLS, delete entire section
    - 5.2, rename section to “Target SSP Procedures”
    - 5.2.1, delete entire section (out of scope = -> DRINKS)
    - 5.2.2, change title to “The Ingress = Signaling Path Border Element (SBE)”
    - 5.2.2.1, delete 2nd paragraph
    - 5.2.2.1, changes 1st paragraph, delete last = two sentences (“For these requests, there should be no remaining Route = header field values. For in-dialog requests, the receiving SSP can verify that = it corresponds to the top-most Route header field value.”)
    - 5.2.2.2, change 2nd paragraph, 2nd sentence, = to: “For example, when a request is rejected because the originating = SSP is not authorized to peer, the receiving SSP should respond with a 403 = response with the reason phrase "Unsupported Peer".”
    - 5.3: This duplicates section 5.2, so delete = section.
    - 5.4, rename section title to “Data Path = Border Element (DBE)”
    - 5.4, please also add a reference to RFC 5486 = in the first sentence, such as “As defined in [RFC 5486], the purpose of = the MF...”
    - 5.5, Policy, delete entire section = (we’ll come back to policy later in another draft)
    - 6, delete section (may be good content for an implementation-specific draft later on, but not needed here)
    
    - GENERAL: The reference numbers in Normative = and Informative references ALL need to be checked — a number of these = are incorrect.  Need to change all references to the type [RFCXXXX].  Also, prune any unused references.

    - Add a new section after Section 9 (IANA considerations), named “Contributors”, and add:
        The following people = made significant textual contributions to and provided significant in-depth = review of this document:
        Hadriel Kaplan, Acme = Packet (hkaplan@acmepacket.com)
  = ;     Jason Livingood, Comcast (jason_livingood@cable.comcast.= com)
        David Schwartz, Kayote = Systems (david.schwartz@kayote.com)
  = ;     Rich = Shockey, Unaffiliated (richard@shockey.us)


//END OF COMMENTS ON THIS DRAFT//

--> UNRELATED TO DO ITEM:  Create a new draft (anyone?) on Call = Control and Media Control Deployment Options using content from Section 6 of http://www.ietf.org/internet-drafts/draft-ietf-speermint-arc= hitecture-08.txt, if interested:

6. Call Control and Media Control Deployment Options  

   The peering functions can be deployed along the = following two dimensions
   depending upon how the signaling and the media = functions along with IP layer
   are implemented:  

   Composed or Decomposed:  Addresses the question = whether the media must flow
   through the same physical and geographic elements as = SIP dialogs and sessions.  

   Centralized or Distributed:  Addresses the = question whether the logical and
   physical interconnections are in one geographical = location or distributed to
   multiple physical locations on the SSP's network. =  

   In a composed model, SF and MF functions are = implemented in one peering logical
   element.  
    
            &= nbsp;Provider A             &= nbsp;          Provider= B
            &= nbsp;----------   .             &= nbsp; .   ----------
            /=           \ .             &= nbsp; .  /          \
           |            | .       _ =       . |            |
           |       +----+ .     /   \_    . +----+ =       |
           |       | SF |<-----/     \------| SF | =       |
           |       +-+--+ .   /Transit\   . |    | =       |
           |         | |  .  /   IP    \  . |    |       |
           |       +-+--+ .  | Provider|  . |    |       |
           |       | MF |<~~~| (Option)|~~~~| MF |       |
           |       +----+ .   \        /  . +----+       |
           |            | .    \ __ _ /   . |            |
            \= _________ /  .             &= nbsp; .  \________ _/
            &= nbsp;----------             &= nbsp;         ----------
    
   --- Signal (SIP)
   ~~~ Bearer (RTP/IP)
   ... Scope of peering
            &= nbsp;           &n= bsp;           &nb= sp;
            &= nbsp;      Figure 3: Decomposed v. Collapsed Peering
 
   The advantage of a collapsed peering architecture is = that one-element solves
   all peering issues. Disadvantage examples of this architecture are single point
   of failure, bottleneck, and complex scalability. =  

   In a decomposed model, SF and MF are implemented in = separate peering logical
   elements. SFs are implemented in a proxy and MFs are implemented in another
   logical element.  The scaling of signaling versus scaling of media may differ
   between applications.  Decomposing allows each to = follow a separate migration
   path.  

   This model allows the implementation of M:N model = where one SF is associated
   with multiple peering MF and one peering MF is = associated with multiple SFs.
   Generally, a vertical protocol associates the = relationship between a SF and a
   MF. This architecture reduces the potential of a = single point of failure. It
   allows separation of the policy decision point and the = policy enforcement
   point. An example of disadvantages is the scaling = complexity because of the M:N
   relationship and latency due to the vertical control = messages between entities.

//end//






    

------_=_NextPart_001_01C9E47B.CE481279-- From jason_livingood@cable.comcast.com Thu Jun 4 05:21:46 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A5E13A6927 for ; Thu, 4 Jun 2009 05:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XJKrglzWAZaw for ; Thu, 4 Jun 2009 05:21:42 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id C498E3A68A7 for ; Thu, 4 Jun 2009 05:21:41 -0700 (PDT) Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.40426696; Thu, 04 Jun 2009 08:21:24 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Jun 2009 08:21:24 -0400 Received: from 147.191.227.143 ([147.191.227.143]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.153]) with Microsoft Exchange Server HTTP-DAV ; Thu, 4 Jun 2009 12:20:48 +0000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Thu, 04 Jun 2009 07:59:34 -0400 From: "Livingood, Jason" To: Message-ID: Thread-Topic: Notes from June 3, 2009 speermint Design Team Meeting Thread-Index: AcnlC+z6EEYRmnSFqkmVoI9SXSRA6g== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3326948448_3981756" X-OriginalArrivalTime: 04 Jun 2009 12:21:24.0517 (UTC) FILETIME=[FA1B5D50:01C9E50E] Subject: [Speermint] Notes from June 3, 2009 speermint Design Team Meeting X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 12:21:46 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3326948448_3981756 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Original Agenda: SPEERMINT Design Team Meeting =AD 3 June 2009 Open to any participant, normal IETF guidelines apply =20 Location: Comcast Center 1701 John F. Kennedy Boulevard Philadelphia, PA 19103 =20 Remote: (phone and web available) =20 Agenda: =20 10:00 =AD 10:15 Welcome, Logistics, and Agenda Bashing =20 10:15 =AD 11:45 SPEERMINT Peering Architecture draft-ietf-speermint-architecture-08 Adam Uzelac =20 11:45 =AD 12:45 Lunch =20 12:45 =AD 2:00 SPEERMINT Message Flows draft-ietf-speermint-flows-05 Hadriel Kaplan =20 2:00 =AD 2:15 Break =20 2:15 =AD 3:15 Use of DNS SRV and NAPTR Records for SPEERMINT draft-ietf-speermint-srv-naptr-use-05 Jason Livingood =20 3:15 =AD 3:30 Break =20 3:30 =AD 4:45 SIP Interconnect Guidelines draft-hancock-sip-interconnect-guidelines-00 Daryl Malas =20 4:45 =AD 5:00 Wrap up, review next steps =20 5:30 - Dinner What we actually go through were the first two drafts, and we only spent about 10 minutes on the third draft (DNS SRV and NAPTR). Adam was not present on the first draft, due to personal reasons, so I submitted our notes to him and the list via email. We expect updates on each of these drafts soon. We made excellent progress on the first two and felt the time was very worthwhile. We plan to have another design team meeting between IETF 75 and 76. Attendees: In Person - Shockey, Rich=20 Livingood, Jason=20 Malas, Daryl=20 Khan, Sohel=20 Creighton, Tom Kaplan, Hadriel Schwartz, David=20 Remote -=20 Elwell, John=20 Erkkila, Paul=20 //end// --B_3326948448_3981756 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Notes from June 3, 2009 speermint Design Team Meeting Original Agenda:

SPEERMINT Design Team Meeting – 3 June 2009
Open to any participant, normal IETF guidelines apply
 
Location:
Comcast Center
1701 John F. Kennedy Boulevard
Philadelphia, PA 19103
 
Remote: (phone and web available)
Agenda:
10:00 – 10:15     Welcome, Logistics, and Agenda = Bashing
 
10:15 – 11:45     SPEERMINT Peering Architecture<= BR>             &nb= sp;  draft-ietf-speermint-architecture-08
            &nb= sp;  Adam Uzelac
 
11:45 – 12:45     Lunch
 
12:45 – 2:00     SPEERMINT Message Flows  &n= bsp;  
            &nb= sp;  draft-ietf-speermint-flows-05
            &nb= sp;  Hadriel Kaplan
 
2:00 – 2:15      Break
 
2:15 – 3:15     Use of DNS SRV and NAPTR Records = for SPEERMINT
            &nb= sp;  draft-ietf-speermint-srv-naptr-use-05
            &nb= sp;  Jason Livingood
 
3:15 – 3:30     Break
 
3:30 – 4:45     SIP Interconnect Guidelines  = ;   
            &nb= sp;  draft-hancock-sip-interconnect-guidelines-00
            &nb= sp;  Daryl Malas
 
4:45 – 5:00     Wrap up, review next steps
 
5:30 -           Dinner
What we actually go through were the first two drafts, and we only spent ab= out 10 minutes on the third draft (DNS SRV and NAPTR).  Adam was not pr= esent on the first draft, due to personal reasons, so I submitted our notes = to him and the list via email.  We expect updates on each of these draf= ts soon.  We made excellent progress on the first two and felt the time= was very worthwhile.  We plan to have another design team meeting betw= een IETF 75 and 76.

Attendees:
In Person -
Shockey, Rich=
 Livingood, Jason  Malas, Daryl
 Khan, Sohel
 Creighton, Tom
 Kaplan, Hadriel
 Schwartz, David

Remote -
Elwell, John<= /FONT>
 Erkkila, Paul

//end//
 --B_3326948448_3981756-- From jason_livingood@cable.comcast.com Thu Jun 4 07:12:37 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B495C3A6D4B for ; Thu, 4 Jun 2009 07:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.999 X-Spam-Level: X-Spam-Status: No, score=-4.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CzEIVzpgc7RB for ; Thu, 4 Jun 2009 07:12:34 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id F3FC23A68D9 for ; Thu, 4 Jun 2009 07:12:33 -0700 (PDT) Received: from ([10.195.246.152]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.40443448; Thu, 04 Jun 2009 10:12:15 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Jun 2009 10:12:15 -0400 Received: from 147.191.227.143 ([147.191.227.143]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.153]) with Microsoft Exchange Server HTTP-DAV ; Thu, 4 Jun 2009 14:11:43 +0000 User-Agent: Microsoft-Entourage/12.17.0.090302 Date: Thu, 04 Jun 2009 10:11:44 -0400 From: "Livingood, Jason" To: Message-ID: Thread-Topic: Next Design Team Meeting Thread-Index: AcnlHmOg8BLdakD5TkizlaftkF9B2g== Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3326955104_4347913" X-OriginalArrivalTime: 04 Jun 2009 14:12:15.0836 (UTC) FILETIME=[769A19C0:01C9E51E] Subject: [Speermint] Next Design Team Meeting X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jun 2009 14:12:37 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3326955104_4347913 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable We had a VERY productive meeting yesterday, so thank you to all who were able to participate. We plan to schedule another one between IETF 75 and IETF 76, and we think we=B9ll make excellent progress again in that meeting. For those who did not attend, we go over active drafts line by line, sectio= n by section, generally editing a document live in the meeting. The intent i= s to more rapidly mature documents. While a design team meeting is generally intended for document authors, participation is open (and we typically open a conference bridge for remote participants =8B though in-person attendance is HIGHLY recommended for any document author). Should you be interested in attending, please go to this Doodle Poll now and advise what dates work best. http://www.doodle.com/xfcvz3bh3wtypp59 Thanks! Jason --B_3326955104_4347913 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Next Design Team Meeting We had a VERY productive meeting yesterday, so thank you to all who were a= ble to participate.  We plan to schedule another one between IETF 75 an= d IETF 76, and we think we’ll make excellent progress again in that me= eting.  For those who did not attend, we go over active drafts line by = line, section by section, generally editing a document live in the meeting. =  The intent is to more rapidly mature documents.

While a design team meeting is generally intended for document authors, par= ticipation is open (and we typically open a conference bridge for remote par= ticipants — though in-person attendance is HIGHLY recommended for any = document author).  Should you be interested in attending, please go to = this Doodle Poll now and advise what dates work best.

http://www.doodle.com/xfcv= z3bh3wtypp59

Thanks!

Jason --B_3326955104_4347913-- From jason_livingood@cable.comcast.com Fri Jun 19 11:44:12 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D84E43A6807 for ; Fri, 19 Jun 2009 11:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.001 X-Spam-Level: *** X-Spam-Status: No, score=3.001 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2XZxt1MrD6l for ; Fri, 19 Jun 2009 11:44:08 -0700 (PDT) Received: from paoakoavas10.cable.comcast.com (paoakoavas10.cable.comcast.com [208.17.35.59]) by core3.amsl.com (Postfix) with ESMTP id 9CA8E3A68D7 for ; Fri, 19 Jun 2009 11:43:52 -0700 (PDT) Received: from ([10.195.246.152]) by paoakoavas10.cable.comcast.com with ESMTP id KP-TDCH7.63826160; Fri, 19 Jun 2009 14:43:44 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by NJMDCEXCRLY01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Jun 2009 14:43:43 -0400 Received: from 198.137.252.126 ([198.137.252.126]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([198.137.252.76]) with Microsoft Exchange Server HTTP-DAV ; Fri, 19 Jun 2009 18:43:29 +0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Fri, 19 Jun 2009 14:43:29 -0400 From: "Livingood, Jason" To: Jason Livingood , Message-ID: Thread-Topic: [Speermint] Next Design Team Meeting Thread-Index: AcnlHmOg8BLdakD5TkizlaftkF9B2gL73K/L In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3328267409_4751146" X-OriginalArrivalTime: 19 Jun 2009 18:43:43.0978 (UTC) FILETIME=[DF4994A0:01C9F10D] Subject: Re: [Speermint] Next Design Team Meeting X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 18:44:12 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3328267409_4751146 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable We=B9ve selected October 14, 2009, as the next design team meeting. This one will also be held in Philadelphia and will include a teleconference bridge for remote participants who cannot attend f2f. More details to follow. Anyone who attended the last meeting, and key document authors, have alread= y been sent a calendar item. Regards Jason On 6/4/09 10:11 AM, "Jason Livingood" wrote: > We had a VERY productive meeting yesterday, so thank you to all who were = able > to participate. We plan to schedule another one between IETF 75 and IETF= 76, > and we think we=B9ll make excellent progress again in that meeting. For th= ose > who did not attend, we go over active drafts line by line, section by sec= tion, > generally editing a document live in the meeting. The intent is to more > rapidly mature documents. >=20 > While a design team meeting is generally intended for document authors, > participation is open (and we typically open a conference bridge for remo= te > participants =8B though in-person attendance is HIGHLY recommended for any > document author). Should you be interested in attending, please go to th= is > Doodle Poll now and advise what dates work best. >=20 > http://www.doodle.com/xfcvz3bh3wtypp59 >=20 > Thanks! >=20 > Jason >=20 --B_3328267409_4751146 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Speermint] Next Design Team Meeting We’ve selected October 14, 2009, as the next design team meeting. &n= bsp;This one will also be held in Philadelphia and will include a teleconfer= ence bridge for remote participants who cannot attend f2f.  More detail= s to follow.  Anyone who attended the last meeting, and key document au= thors, have already been sent a calendar item.

Regards
Jason


On 6/4/09 10:11 AM, "Jason Livingood" <jason_livingood@cable.comcast.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>We had a VERY productive meeting yesterday, so t= hank you to all who were able to participate.  We plan to schedule anot= her one between IETF 75 and IETF 76, and we think we’ll make excellent= progress again in that meeting.  For those who did not attend, we go o= ver active drafts line by line, section by section, generally editing a docu= ment live in the meeting.  The intent is to more rapidly mature documen= ts.

While a design team meeting is generally intended for document authors, par= ticipation is open (and we typically open a conference bridge for remote par= ticipants — though in-person attendance is HIGHLY recommended for any = document author).  Should you be interested in attending, please go to = this Doodle Poll now and advise what dates work best.

http://www.doodle.com/xfcv= z3bh3wtypp59

Thanks!

Jason
--B_3328267409_4751146-- From wwwrun@core3.amsl.com Wed Jun 24 15:24:29 2009 Return-Path: X-Original-To: speermint@ietf.org Delivered-To: speermint@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 296AB28C4FA; Wed, 24 Jun 2009 15:24:28 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090624222429.296AB28C4FA@core3.amsl.com> Date: Wed, 24 Jun 2009 15:24:29 -0700 (PDT) Cc: speermint@ietf.org Subject: [Speermint] Last Call: draft-ietf-speermint-voip-consolidated-usecases (VoIP SIP Peering Use Cases) to Informational RFC X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 22:24:29 -0000 The IESG has received a request from the Session PEERing for Multimedia INTerconnect WG (speermint) to consider the following document: - 'VoIP SIP Peering Use Cases ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-07-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip-consolidated-usecases-12.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15867&rfc_flag=0 From wwwrun@core3.amsl.com Wed Jun 24 15:25:27 2009 Return-Path: X-Original-To: speermint@ietf.org Delivered-To: speermint@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id B6AB028C51E; Wed, 24 Jun 2009 15:25:27 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090624222527.B6AB028C51E@core3.amsl.com> Date: Wed, 24 Jun 2009 15:25:27 -0700 (PDT) Cc: speermint@ietf.org Subject: [Speermint] Last Call: draft-ietf-speermint-requirements (SPEERMINT Requirements for SIP-based Session Peering) to Informational RFC X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 22:25:27 -0000 The IESG has received a request from the Session PEERing for Multimedia INTerconnect WG (speermint) to consider the following document: - 'SPEERMINT Requirements for SIP-based Session Peering ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-07-08. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-speermint-requirements-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=14950&rfc_flag=0 From yiu_lee@cable.comcast.com Tue Jun 30 18:13:14 2009 Return-Path: X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A60328C498 for ; Tue, 30 Jun 2009 18:13:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.412 X-Spam-Level: *** X-Spam-Status: No, score=3.412 tagged_above=-999 required=5 tests=[AWL=0.411, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1eH30H4SozQ for ; Tue, 30 Jun 2009 18:13:13 -0700 (PDT) Received: from paoakoavas09.cable.comcast.com (paoakoavas09.cable.comcast.com [208.17.35.58]) by core3.amsl.com (Postfix) with ESMTP id 1D61728C426 for ; Tue, 30 Jun 2009 18:13:13 -0700 (PDT) Received: from ([24.40.15.118]) by paoakoavas09.cable.comcast.com with ESMTP id KP-NTF18.74111954; Tue, 30 Jun 2009 21:13:17 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Jun 2009 21:13:19 -0400 Received: from 72.79.86.41 ([72.79.86.41]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Wed, 1 Jul 2009 01:12:31 +0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Tue, 30 Jun 2009 21:12:28 -0400 From: "Yiu L. Lee" To: Message-ID: Thread-Topic: New Version Notification for draft-ietf-speermint-voip-consolidated-usecases-13 Thread-Index: Acn56I5712ADLUAcSZiJ3FKxIBXaLQAAHGNY In-Reply-To: <20090701010830.B42D93A67ED@core3.amsl.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3329241149_474195" X-OriginalArrivalTime: 01 Jul 2009 01:13:19.0160 (UTC) FILETIME=[1E868B80:01C9F9E9] Subject: [Speermint] FW: New Version Notification for draft-ietf-speermint-voip-consolidated-usecases-13 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 01:13:14 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3329241149_474195 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit We submitted a newer version. This version contains some minor mistakes identified by Simon Perreault. Thanks Simon! ------ Forwarded Message From: IETF I-D Submission Tool Date: Tue, 30 Jun 2009 21:08:30 -0400 To: Yiu Leung Lee Cc: Subject: New Version Notification for draft-ietf-speermint-voip-consolidated-usecases-13 A new version of I-D, draft-ietf-speermint-voip-consolidated-usecases-13.txt has been successfuly submitted by Yiu Lee and posted to the IETF repository. Filename: draft-ietf-speermint-voip-consolidated-usecases Revision: 13 Title: VoIP SIP Peering Use Cases Creation_date: 2009-06-30 WG ID: speermint Number_of_pages: 24 Abstract: This document depicts many common Voice over IP (VoIP) use cases for Session Initiation Protocol (SIP) Peering. These use cases are categorized into static and on-demand, and then further sub- categorized into direct and indirect. These use cases are not an exhaustive set, but rather the most common use cases deployed today. The IETF Secretariat. ------ End of Forwarded Message --B_3329241149_474195 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable FW: New Version Notification for       = ;   draft-ietf-speermint-voip-consolidated-usecases-13 </TITL= E> </HEAD> <BODY> <FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt= '>We submitted a newer version. This version contains some minor mistakes id= entified by Simon Perreault. Thanks Simon!<BR> <BR> ------ Forwarded Message<BR> <B>From: </B>IETF I-D Submission Tool <<a href=3D"idsubmission@ietf.org">i= dsubmission@ietf.org</a>><BR> <B>Date: </B>Tue, 30 Jun 2009 21:08:30 -0400<BR> <B>To: </B>Yiu Leung Lee <<a href=3D"yiu_lee@Cable.Comcast.com">yiu_lee@Ca= ble.Comcast.com</a>><BR> <B>Cc: </B><<a href=3D"adam.uzelac@globalcrossing.com">adam.uzelac@globalc= rossing.com</a>><BR> <B>Subject: </B>New Version Notification for      =     draft-ietf-speermint-voip-consolidated-usecases-13 <= BR> <BR> <BR> <BR> A new version of I-D, draft-ietf-speermint-voip-consolidated-usecases-13.tx= t has been successfuly submitted by Yiu Lee and posted to the IETF repositor= y.<BR> <BR> Filename:        draft-ietf-speermint-vo= ip-consolidated-usecases<BR> Revision:        13<BR> Title:           VoIP SIP= Peering Use Cases<BR> Creation_date:   2009-06-30<BR> WG ID:           speermin= t<BR> Number_of_pages: 24<BR> <BR> Abstract:<BR> This document depicts many common Voice over IP (VoIP) use cases for<BR> Session Initiation Protocol (SIP) Peering.  These use cases are<BR> categorized into static and on-demand, and then further sub-<BR> categorized into direct and indirect.  These use cases are not an<BR> exhaustive set, but rather the most common use cases deployed today.<BR>             &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;     <BR> <BR> <BR> The IETF Secretariat.<BR> <BR> <BR> <BR> <BR> ------ End of Forwarded Message<BR> </SPAN></FONT> </BODY> </HTML> --B_3329241149_474195-- From root@core3.amsl.com Tue Jun 30 18:15:02 2009 Return-Path: <root@core3.amsl.com> X-Original-To: speermint@ietf.org Delivered-To: speermint@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 192D928C336; Tue, 30 Jun 2009 18:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090701011502.192D928C336@core3.amsl.com> Date: Tue, 30 Jun 2009 18:15:02 -0700 (PDT) Cc: speermint@ietf.org Subject: [Speermint] I-D Action:draft-ietf-speermint-voip-consolidated-usecases-13.txt X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group <speermint.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/speermint> List-Post: <mailto:speermint@ietf.org> List-Help: <mailto:speermint-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 01 Jul 2009 01:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session PEERing for Multimedia INTerconnect Working Group of the IETF. Title : VoIP SIP Peering Use Cases Author(s) : A. Uzelac, Y. Lee Filename : draft-ietf-speermint-voip-consolidated-usecases-13.txt Pages : 24 Date : 2009-06-30 This document depicts many common Voice over IP (VoIP) use cases for Session Initiation Protocol (SIP) Peering. These use cases are categorized into static and on-demand, and then further sub- categorized into direct and indirect. These use cases are not an exhaustive set, but rather the most common use cases deployed today. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-speermint-voip-consolidated-usecases-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-speermint-voip-consolidated-usecases-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-06-30180830.I-D@ietf.org> --NextPart-- From yiu_lee@cable.comcast.com Tue Jun 30 20:09:16 2009 Return-Path: <yiu_lee@cable.comcast.com> X-Original-To: speermint@core3.amsl.com Delivered-To: speermint@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E3AB3A6B4F for <speermint@core3.amsl.com>; Tue, 30 Jun 2009 20:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.794 X-Spam-Level: X-Spam-Status: No, score=-0.794 tagged_above=-999 required=5 tests=[AWL=4.205, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QixXfXpGc4SF for <speermint@core3.amsl.com>; Tue, 30 Jun 2009 20:09:12 -0700 (PDT) Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id B2EFF3A6A68 for <speermint@ietf.org>; Tue, 30 Jun 2009 20:08:43 -0700 (PDT) Received: from ([24.40.15.118]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.43888197; Tue, 30 Jun 2009 23:08:51 -0400 Received: from PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) by PACDCEXCSMTP04.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Jun 2009 23:08:52 -0400 Received: from 72.79.86.41 ([72.79.86.41]) by PACDCEXCMB04.cable.comcast.com ([24.40.15.86]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Wed, 1 Jul 2009 03:08:38 +0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Tue, 30 Jun 2009 23:08:32 -0400 From: "Yiu L. Lee" <yiu_lee@cable.comcast.com> To: Yiu Leung Lee <yiu_lee@Cable.Comcast.com>, <speermint@ietf.org> Message-ID: <C6704B70.A04E%yiu_lee@cable.comcast.com> Thread-Topic: [Speermint] FW: New Version Notification for draft-ietf-speermint-voip-consolidated-usecases-13 Thread-Index: Acn56I5712ADLUAcSZiJ3FKxIBXaLQAAHGNYAAQNt3E= In-Reply-To: <C670303C.A048%yiu_lee@cable.comcast.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3329248115_898888" X-OriginalArrivalTime: 01 Jul 2009 03:08:52.0063 (UTC) FILETIME=[42DB96F0:01C9F9F9] Subject: Re: [Speermint] FW: New Version Notification for draft-ietf-speermint-voip-consolidated-usecases-13 X-BeenThere: speermint@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Mailing list for the speermint working group <speermint.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=unsubscribe> List-Archive: <http://www.ietf.org/mail-archive/web/speermint> List-Post: <mailto:speermint@ietf.org> List-Help: <mailto:speermint-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/speermint>, <mailto:speermint-request@ietf.org?subject=subscribe> X-List-Received-Date: Wed, 01 Jul 2009 03:09:16 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3329248115_898888 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable When I said =B3contains=B2, I actually mean =B3corrects=B2, you all know it, right? ;-) On 6/30/09 9:12 PM, "Yiu Leung Lee" <yiu_lee@Cable.Comcast.com> wrote: > We submitted a newer version. This version contains some minor mistakes > identified by Simon Perreault. Thanks Simon! >=20 > ------ Forwarded Message > From: IETF I-D Submission Tool <idsubmission@ietf.org> > Date: Tue, 30 Jun 2009 21:08:30 -0400 > To: Yiu Leung Lee <yiu_lee@Cable.Comcast.com> > Cc: <adam.uzelac@globalcrossing.com> > Subject: New Version Notification for > draft-ietf-speermint-voip-consolidated-usecases-13 >=20 >=20 >=20 > A new version of I-D, draft-ietf-speermint-voip-consolidated-usecases-13.= txt > has been successfuly submitted by Yiu Lee and posted to the IETF reposito= ry. >=20 > Filename: draft-ietf-speermint-voip-consolidated-usecases > Revision: 13 > Title: VoIP SIP Peering Use Cases > Creation_date: 2009-06-30 > WG ID: speermint > Number_of_pages: 24 >=20 > Abstract: > This document depicts many common Voice over IP (VoIP) use cases for > Session Initiation Protocol (SIP) Peering. These use cases are > categorized into static and on-demand, and then further sub- > categorized into direct and indirect. These use cases are not an > exhaustive set, but rather the most common use cases deployed today. > =20 >=20 >=20 > The IETF Secretariat. >=20 >=20 >=20 >=20 > ------ End of Forwarded Message >=20 >=20 > _______________________________________________ > Speermint mailing list > Speermint@ietf.org > https://www.ietf.org/mailman/listinfo/speermint --B_3329248115_898888 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable <HTML> <HEAD> <TITLE>Re: [Speermint] FW: New Version Notification for draft-ietf-speermin= t-voip-consolidated-usecases-13 When I said “contains”, I actually mean “corrects”= , you all know it, right? ;-)


On 6/30/09 9:12 PM, "Yiu Leung Lee" <yiu_lee@Cable.Comcast.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>We submitted a newer version. This version conta= ins some minor mistakes identified by Simon Perreault. Thanks Simon!

------ Forwarded Message
From: IETF I-D Submission Tool <i= dsubmission@ietf.org>
Date: Tue, 30 Jun 2009 21:08:30 -0400
To: Yiu Leung Lee <yiu_lee@Ca= ble.Comcast.com>
Cc: <adam.uzelac@globalc= rossing.com>
Subject: New Version Notification for      =     draft-ietf-speermint-voip-consolidated-usecases-13 <= BR>


A new version of I-D, draft-ietf-speermint-voip-consolidated-usecases-13.tx= t has been successfuly submitted by Yiu Lee and posted to the IETF repositor= y.

Filename:        draft-ietf-speermint-vo= ip-consolidated-usecases
Revision:        13
Title:           VoIP SIP= Peering Use Cases
Creation_date:   2009-06-30
WG ID:           speermin= t
Number_of_pages: 24

Abstract:
This document depicts many common Voice over IP (VoIP) use cases for
Session Initiation Protocol (SIP) Peering.  These use cases are
categorized into static and on-demand, and then further sub-
categorized into direct and indirect.  These use cases are not an
exhaustive set, but rather the most common use cases deployed today.
            &nb= sp;            &= nbsp;            = ;            &nb= sp;            &= nbsp;            = ;     


The IETF Secretariat.




------ End of Forwarded Message

___________= ____________________________________
Speermint mailing list
Speermint@ietf.org
https://www.ietf.= org/mailman/listinfo/speermint
--B_3329248115_898888--