Internet Draft A.Uzelac SPEERMINT Global Crossing Intended status: Standards Track Y.Lee Expires: August 2007 Comcast D.Schwartz Kayote Networks E. Katz Xconnect O.Lendl enum.at R.Mahy Plantronics May 15, 2007 VoIP SIP Peering Use Cases draft-ietf-speermint-voip-consolidated-usecases-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on Dec 15, 2007. Copyright Notice Copyright (C) The IETF Trust (2007) Uzelac (et al) Expires Dec 15, 2007 [Page 1] Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2007 Abstract This document will capture the VoIP use case for SIP Peering. It is a consolidation of other Speermint use cases and will focus exclusively on VoIP. Table of Contents 1. Introduction...................................................3 2. Terminology....................................................3 3. Use Cases......................................................4 3.1. Direct Use Cases..........................................5 3.1.1. Minimalist Direct.......................................5 3.1.1.1. Administrative characteristics........................6 3.1.2. Direct with one SBE.....................................6 3.1.2.1. Administrative characteristics........................7 3.1.3. Direct with two SBEs....................................7 3.1.3.1. Administrative characteristics........................8 3.2. Indirect..................................................8 3.2.1. Transit PSP.............................................8 3.2.1.1. Administrative Characteristics........................9 3.3. Assisted..................................................9 3.3.1. Assisted PSP............................................9 4. Federations....................................................9 4.1. Federation Categorization.................................9 4.2. Federation Examples.......................................9 4.2.1. Trivial Federations.....................................9 4.2.2. Access List based.......................................9 4.2.3. TLS based Federations...................................9 4.2.4. Central SIP Proxy.......................................9 4.2.5. Private Layer 3 Network.................................9 4.2.6. Peer to Peer SIP........................................9 4.2.7. DUNDi...................................................9 5. Security Considerations........................................9 6. IANA Considerations............................................9 References........................................................9 Normative References...........................................9 Informative References.........................................9 Author's Addresses.............................................9 Full Copyright Statement.......................................9 Intellectual Property..........................................9 Acknowledgment.................................................9 Uzelac (et al.) Expires Dec 15, 2007 [Page 2] Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2007 1. Introduction This document attempts to capture VoIP use cases for Session Initiation Protocol (SIP)[1] based peering. Identifying use cases will help to understand and clarify requirements. These use cases will assist in identifying requirements for VoIP Peering using SIP and provide a perspective on future specifications. Only use cases related to VoIP such as VoIP are considered in this document. Other real-time SIP communications use cases, like Instant Messaging (IM) and presence are out of scope for this document. Thus, use cases described herein are use cases of VoIP using SIP. In describing use cases, the intent is descriptive, not prescriptive. There are existing documents [2][3][4][5][6] that have captured use case scenarios. This draft draws from those documents. The document contains three categories of use cases; Direct, Indirect and Assisted. The use cases contained in this document attempts to be as comprehensive as possible, but should not be considered complete. 2. Terminology The terminology for this draft will be draw from the Speermint terminology draft. [15] Uzelac (et al.) Expires Dec 15, 2007 [Page 3] Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2007 +-------------+-------------------------------------+------------+ | \ Assisted Domain / | | \ / | | \ +------+ +---+--+ / | | \ + A-LS + + A-SM | / | | \ +------+ +-----++ / | | \ +------+ +------+ / | | +------+ \ | A-SBE| | A-DBE| /+------+ | | +-----+ O-LS + \ +------+ +------+ / + T-LS +-----+ | | | +------+ \ / +------+ | | | | \ / | | | | \ / | | | | +------+ \ / +------+ | | | | | O-SBE+ \ / + T-SBE| | | | | +---+--+ \ / +------+ | | | | | \ / | | | | | \ / | | | | +---+--+ \ / +------+ | | | +-----+ O-SM | \ / | T-SM +-----+ | | +-----++ + ++-----+ | | +----+ | | | +----+ | | |O-UE+---------+ | +---------+T-UE| | | +----+ +------+ | +------+ +----+ | | | O-DBE|==============| T-DBE| | | +------+ | +------+ | | Originating Domain | Terminating Domain | +----------------------------------------------------------------+ Figure 1 Generalized Overview PLEASE NOTE: In figure one – the elements defined are option in many use cases. 3. Use Cases Use cases are sorted into 3 groupings: Direct, Indirect and Assisted. Though there may be some overlap among the use cases in these categories, there are different requirements between the scenarios and this document serves to help identify the requirements for SIP Peering for VoIP. Per information in the Speermint terminology draft, the direct use cases involve those cases in which two service providers interconnect without using an intervening layer 5 network. This approach is also considered a bi-lateral peering agreement. Uzelac (et al.) Expires Dec 15, 2007 [Page 4] Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2007 Indirect use cases involve the use of a third party that both the O- VSP and T-VSP have in common. This has been referred to as Transit peering as well. Assisted use cases involve the use of a third party, but this third party may or may not have a pre-existing relationship with the T-VSP. The A-VSP may only provide next-hop discovery for the O-VSP, or may be more intimately involved my maintaining session state in both the signaling and bearer planes. 3.1. Direct Use Cases There are intra-domain message flows within the use cases to serve a supporting background. The inter-domain communications is germane to Speermint. 3.1.1. Minimalist Direct 1. O-UE initiates a call = SIP INVITE 2. O-SM queries for next-hop information from routing database. 3. Routing database entity replies with route to called party 4. Call sent to terminating domains session manager. 5. Session manager sends call to called party. +------------------+-------------------+ | Orig Domain | Term Domain | | +--------+ | +--------+ | | | LS-o | | | LS-t | | | +--------+ | +--------+ | | (2) / | | | /(3) | | | +-----+ | +-----+ | | |O-SM |--------(4)---------|T-SM | | | +-----+ | +-----+ | | | | | | | (1) | (5) | | | | | | | +----+ | +----+ | | |O-UE+=======(RTP)=========+T-UE+ | | +----+ | +----+ | +------------------+-------------------+ Figure 2 Minimalist Direct Uzelac (et al.) Expires Dec 15, 2007 [Page 5] Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Feb 2007 3.1.1.1. Administrative characteristics The minimalist direct use case is typically implemented in a scenario where exists a strong degree of trust between the 2 administrative domains. Neither the Originating nor Terminating domains have a dedicated network element (i.e. Session Border Element - SBE) that serves any domain demarcation purpose. This can and should be considered an “Open” peering model. 3.1.2. Direct with one SBE In this type of interconnection scenario, the SBE is owned and operated within the originating administrative domain. 1. O-UE initiates a call. 2. The O-SM performs next-hop determination for the called party via the LS. This can be done via ENUM/DNS/Redirect 3XX multiple choices and/or static routing. 3. The result of the query will be O-SBE that is interconnected to the terminating domain, but administered in the originating domain. 4. Proxy will signal O-SBE. 5. O-SBE routes call to T-SM within terminating domain. 6. T-SM signals the called party, T-UE. Uzelac (et al.) Expires Dec 15, 2007 [Page 6] Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2007 +------------------+-------------------+ | Orig Domain | Term Domain | | +--------+ | +--------+ | | | LS-o | | | LS-t | | | +--------+ | +--------+ | | (2) / | | | /(3) | | |+-----+ +-----+ +-----+ | ||O-SM |-(4)-|O-SBE+----(5)---|T-SM | | |+-----+ +--+--+ +-----+ | | | | | | | (1) | (6) | | | | | | | +----+ | +----+ | | |O-UE+=========(RTP)=========+T-UE+ | | +----+ | +----+ | +------------------+-------------------+ Figure 3 Direct with one SBEs 3.1.2.1. Administrative characteristics The direct peering with a single SBE is typically implemented in the scenario where the Originating domain is a VoIP Service Provider (VSP) and the Terminating domain is an Enterprise IP telephony deployment. The SBEs provides the VSP with the ability to support overlapping RFC1918 address space via NAT, Session limiting, Session “scrubbing” to permit only certain SDP options, etc. 3.1.3. Direct with two SBEs Multiple SBCs are implemented in this interconnection scenario. The SBEs are operated within different administrative domains. 1. O-UE initiates a call. 2. The O-SM performs next-hop determination for the called party via the LS. This can be done via ENUM/DNS/Redirect 3XX multiple choices and/or static routing. 3. The result of the query will be O-SBE that is interconnected to the terminating domain, but administered in the originating domain. 4. Proxy will signal O-SBE. 5. O-SBE routes call to T-SBE within terminating domain. Uzelac (et al.) Expires Dec 15, 2007 [Page 7] Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2007 6. T-SBE signals T-SM. 7. T-SM signals the called party, T-UE. +---------------------+ +-----------------------+ | Orig Domain | | Term Domain | | +--------+ | | +--------+ | | | LS-o | | | | LS-t | | | +--------+ | | +--------+ | | (2) / | | | | /(3) | | | |+-----+ +-----+ +-----+ +-----+ | ||O-SM |---(4)--|O-SBE|--(5)--|T-SBE+---(6)---|T-SM | | |+-----+ +-----+ +-----+ +-----+ | | | | | | | | (1) | | (7) | | | | | | | | +----+ +-----+ +-----+ +----+ | | |O-UE+========+O-DBE+=======+T-DBE+==========+O-UE| | | +----+ +-----+ +-----+ +----+ | +---------------------+ +-----------------------+ Figure 4 Direct with two SBEs 3.1.3.1. Administrative characteristics The direct peering use case with 2 SBEs is typically seen in where both the originating and terminating domain are SPs. Both maintain that there is perceived value in “protecting” their VoIP network core via SBEs. 3.2. Indirect 3.2.1. Transit PSP This is a direct call flow, as in the minimalist approach, but with a Peering Service Provider (PSP) aiding the originating domain. 1. O-UE initiates a call. 2. The O-SM performs next-hop determination for the called party via the LS within the Assisted domain. This can be done via ENUM/DNS/Redirect 3XX multiple choices and/or static routing. 3. The result of the query will be A-SBE that is interconnected to the Transit domain, but administered in the originating domain. Uzelac (et al.) Expires Dec 15, 2007 [Page 8] Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2007 4. O-SM will signal A-SBE. 5. O-SBE routes call to T-SBE within terminating domain. 6. T-SBE signals T-SM. T-SM signals the called party, T-UE. +------------------+ | Transit Domain | | | | +--------+ | | +--+ LS-a | | | / +-+--------+ | | / / | +---------------+ / / +----------------------+ | Orig Domain |/ / | Term Domain | | +--------+ / | +--------+ | | / |/ | | LS-t | | | / +----(3)+ | +--------+ | | (2) / | | | | / / | | | |+-----+ +-----+ +-----+ +-----+| ||O-SM |---(4)--|A-SBE+------------+T-SBE+---(6)---|T-SM || |+-----+ +-----+ +-----+ +-----+| | | | | | | | | | (1) | | | | (7) | | | | | | | | | | +----+ +-----+ +-----+ +----+| | |O-UE+========+A-DBE+============+T-DBE+==========+O-UE|| | +----+ +-----+ +-----+ +----+| +---------------------------------------------------------+ Figure 5 Indirect with Assisted PSP 3.2.1.1. Administrative Characteristics The Transit peering use case is normally implemented due to a business or trust relationship between the either the originating domain and transit, and/or the terminating domain and the transit domain. Orig Domain .--. Transit = Relationship O-T Uzelac (et al.) Expires Dec 15, 2007 [Page 9] Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2007 In the O-T relationship, typical policies, features or functions that deem this relationship necessary are NP, Ubiquity of termination options, and masquerading of originating VoIP network gear. Term Domain .--. Transit = Relationship T-T In the T-T relationship, typical policies, features or functions observed consist of codec “scrubbing”, anonimizing, and transcoding. 3.3. Assisted Assisted use cases involve the facilitation of direct session establishment between the O-VSP and T-VSP. There may exist elements that provide SIP proxy functionality, and are often implemented in practice by SBE’s which may "filter" "normalize" and provide network- hiding for incoming messages en route to their final destination. Fear and distrust coupled with continued interoperability and security concerns have revived the need for the neutral central element role enabled by this peering model. Popularity of this model can be attributed to the concentration of functions provided by A-PSP. As an external element, A-PSP can provide the full set of services for VSPs, and through its own relationships with the VSP, eliminate the need of all VSPs for pair- wise service relationships. A-PSP can potentially encompass a large namespace of users that is accessible in one query to external VSP members (or not -depending on policy). In addition there is an interoperability function usually performed by an SBE, almost guaranteeing interoperability and protocol interchangeability between member VSPs. As part of the interoperability there is also is media sub-function enabling the federation to enforce a standard set of codecs or alternatively provide transcoding functionality to make sure there is media interoperability as well. Finally, A-PSP can implement the routing function enabling traffic shaping and throttling across the federation. 3.3.1. Assisted PSP This is a direct call flow, as in the minimalist approach, but with a PSP aiding the originating domain. 1. O-UE initiates a call. Uzelac (et al.) Expires Dec 15, 2007 [Page 10] Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2007 2. The O-SM performs next-hop determination for the called party via the LS within the Assisted domain. This can be done via ENUM/DNS/Redirect 3XX multiple choices and/or static routing. 3. The result of the query will be O-SBE that is interconnected to the terminating domain, but administered in the originating domain. 4. Proxy will signal O-SBE. 5. O-SBE routes call to T-SBE within terminating domain. 6. T-SBE signals T-SM. 7. T-SM signals the called party, T-UE. +------------------------+ | Assist Domain | | | | +--------+ | | | LS-a | | | ++---+---+ | | | | | +---------------+ | | +-----------------+ | Orig Domain \ | | / Term Domain | | +----------+------+ | / +--------+ | | / \ | / | LS-t | | | / +----(3)----+--------+ / +--------+ | | (2) / \ / | | / / +------------+ | |+-----+ +-----+ +-----+ +-----+ +-----+ | ||O-SM |---(4)--|O-SBE+--|A-SBE+---+T-SBE+---(6)---|T-SM | | |+-----+ +-----+ +-----+ +-----+ +-----+ | | | | | | | | (1) | | (7) | | | | | | | | +----+ +-----+ +-----+ +-----+ +----+ | | |O-UE+========+O-DBE+==+A-DBE+===+T-DBE+==========+O-UE| | | +----+ +-----+ +-----+ +-----+ +----+ | +----------------------------------------------------------+ Figure 6 Direct with Assisted PSP PLEASE NOTE – elements depicted are optional. Uzelac (et al.) Expires Dec 15, 2007 [Page 11] Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2007 4. Federations This section discusses the federation concept, explains which technical parameters make up the foundation of a federation and provides examples. Contrary to the previous section, this section does not focus on specific implementation details like the presence of SBCs or other border elements. The aim here is to provide a broader view on what kinds of arrangements are possible. The concrete implementation details (e.g. "direct with one SBC" versus "direct with two SBCs") is often orthogonal to this list. To recapitulate: A federation is a group of VSPs which agree to receive calls from each other using pre-agreed technical and administrative procedures. 4.1. Federation Categorization The technical procedures which federations need to define can be used to categorize them. Each federation has to specify how a few core operations which are to be performed by its members. These include: 1. Peer Discovery This specifies how a VSPs discovers that he can place a specify call to a peering partner in this federation. Possible solution are e.g.: a manually configured list of TN- prefixes and domain names, automatically obtained list of reachable prefixes/domains by some sort if intra-federation route announcements, trial queries to the federation's LS, trial lookups in federation-internal databases (e.g. private DNS),public database lookups (e.g. I-ENUM). 2. Location Server What methods are used for TN to URI mapping? Examples: Public User-ENUM, public Infrastructure ENUM, private ENUM tree, SIP Redirect, DUNDi. 3. Next Hop Domain Resolution Uzelac (et al.) Expires Dec 15, 2007 [Page 12] Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2007 If the LS did not return an URI of the form sip:user@IP-address, then the originating VSP has to translate the domain part of the URI to an IP-address (plus perhaps fall-backs) in order to contact the next hop. Examples: RFC3263 in the public DNS. RFC3263 in a federation private DNS. RFC3263 in the public DNS with split-DNS, P2P SIP, modified RFC3263 in the public DNS (e.g. a federation-specific prefix to the domain name). 4. Call Setup The federation may also define specifics on what SIP features need to be used when contacting the next hop in order to a) reach the next hop at all and b) to prove that the sender is a legitimate peering partner. Examples: hard-code transport (TCP/UDP/TLS), non-standard port number, specific source IP address (e.g. in a private L3 network), which TLS client certificate to use, other authentication scheme. 5. Filtering Incoming Calls On the receiving side, the border element needs to determine whether the INVITE it just received really came from a member of the federation. This is the flip side of 4. Example: verify TLS cert, check incoming interface/VLAN,check source IP address against a configured list of valid ones. 4.2. Federation Examples This section lists some examples of how federations can operate. 4.2.1. Trivial Federations A private peering arrangement between two VSPs is a special case of a federation. These two VSP have agreed to exchange calls amongst themselves and they have set up whatever SBC/LS/SBE plus Layer 3infrastructure they need to route and complete the calls. It is thus not needed to treat bi-lateral peerings as conceptually different to federation-based peering. On the other extreme, the set of all VSPs implementing an open SIP service according to RFCs 3261/3263/3761 also fulfills the definition of a federation. In that case, the technical rules are Uzelac (et al.) Expires Dec 15, 2007 [Page 13] Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2007 contained in these three RFCs, the LS is the public DNS. Whether some of these VSPs use SBCs as border elements is not relevant. The administrative model of this federation is the "email model": There is no "member list", any SIP server operating on the Internet which implements call routing according to these RFCs is implicitly a member of that federation. No business relationship is needed between "members", thus no money is likely to change hands for terminating calls. There is no contractual protection against nuisance calls, SPIT, or denial of service attacks. 4.2.2. Access List based If running an open SIP proxy is not desired, then a group of VSPs which want to allow calls from each other can collect the list of IP addresses of all their border elements. This list is redistributed to all members which use it to configure firewalls in front of their ingress elements. Thus calls from other members of this federation are accepted while calls from other hosts on the Internet are blocked. Whether VSPs deploy SBCs as border elements is not relevant. Call routing can still be done via standard RFC rules. Whenever a new member joins this club every other VSP needs to adapt its filter rules. 4.2.3. TLS based Federations Another option to restrict incoming calls to federation members is to use Transport Layer Security (TLS) certificates as access control. This works best if the federation runs a certificate authority (CA) which signs the TLS keys of each member VSP. Thus the ingress element of a VSP needs to check only whether the client certificate presented by the calling SIP proxy contains a proper signature from that CA. Adding support for Certificate Revocation Lists solves the issue of blocking calls from former members of that federation. The main benefit of this model is that no changes need to be made at the ingress element of all old members whenever a VSP joins that federation. Uzelac (et al.) Expires Dec 15, 2007 [Page 14] Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2007 4.2.4. Central SIP Proxy One way to simplify the management of these firewall rules is to route all SIP messages via a central proxy. In that case, all federation members just need to open up their ingress elements to requests from that central server. A new VSP just triggers a change in the configuration of this box and not at all other VSPs. Although such a setup reduces the configuration complexity of larger federations, the central SIP proxy might lead to other scaling issues. This is an example of Assisted Peering. 4.2.5. Private Layer 3 Network Federations can also establish a separate layer 3 network for their peering traffic. This could be implemented e.g. by creating a new VLAN at an Internet exchange point to which all members of that federation connect their SBEs. Alternatively, a federation can establish a smaller version of the Internet to which only members are allowed to connect. The GRX network of the mobile operators is an example of a dedicated layer 3 infrastructure. Such a private layer 3 network can also be implemented using virtual private network (VPN) technologies like IPsec. In all these cases the SBE can assume that any SIP requests it receives via an interfaces located in this L3 network comes from legitimate peering partner. The separation of the peering network from the Internet makes it easier to protect the peering arrangement from attacks and to ensure QoS. 4.2.6. Peer to Peer SIP P2PSIP replaces the RFC3263 rules by a lookup in a distributed hash table (DHT). A federation could use this technology to implement call routing between the peers: the border elements of all members participate in the DHT algorithm and distribute routing information this way. Uzelac (et al.) Expires Dec 15, 2007 [Page 15] Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2007 Only members of the federation thus can use information stored in the DHT which could be the basis of both call routing within the federation as well as access control between members. 4.2.7. DUNDi Distributed Universal Number Discovery (DUNDi) [http://www.dundi.com/dundi.txt] can also be used to build federations: DUNDi itself acts as a distributed LS which can add dynamically generated passwords to the URIs it returns. This way, the T-SBE can verify that an incoming calls comes from a member of this DUNDi cloud. 5. Security Considerations This document introduces no new security considerations. However, it is important to note that session interconnect, as described in this document, has a wide variety of security issues that should be considered in documents addressing both protocol and use case analyzes. 6. IANA Considerations This document creates no new requirements on IANA namespaces [RFC2434]. Uzelac (et al.) Expires Dec 15, 2007 [Page 16] Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2007 References Normative References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [2] Schwartz, David, draft-schwartz-speermint-use-cases-federations [3] Mahy, Rohan, draft-mahy-speermint-direct-peering [4] Lendl, Otmar, draft-lendl-speermint-federations [5] Lee, Yiu, draft-lee-speermint-use-case-cable [6] Uzelac, Adam, draft-uzelac-speermint-use-cases [7] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [8] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003. [9] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [10] Peterson, J., Liu, H., Yu, J., and B. Campbell, "Using E.164 numbers with the Session Initiation Protocol (SIP)", RFC 3824, June 2004. [11] Peterson, J., “Address Resolution for Instant Messaging and Presence”,RFC 3861, August 2004. [12] Peterson, J., "Telephone Number Mapping (ENUM) Service Registration for Presence Services", RFC 3953, January 2005. [13] ETSI TS 102 333: " Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Gate control protocol". [14] Peterson, J., "enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004. Uzelac (et al.) Expires Dec 15, 2007 [Page 17] Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2007 Informative References [15] Meyer, D., "SPEERMINT Terminology", draft-ietf-speermint- terminology-06 (work in progress), 2006. [16] Mule, J-F., “SPEERMINT Requirements for SIP-based VoIP Interconnection”, draft-ietf-speermint-requirements-00.txt, June 2006. [17] Camarillo, G. “Requirements from SIP (Session Initiation Protocol) Session Border Control Deployments“, draft-camarillo- sipping-sbc-funcs-04.txt, June, 2006. [18] Habler, M., et al., “A Federation based VOIP Peering Architecture”, draft-lendl-speermint-federations-03.txt, September 2006. Author's Addresses Adam Uzelac Global Crossing Email: adam.uzelac@globalcrossing.com Rohan Mahy Plantronics Email: rohan@ekabal.com Yiu L. Lee Comcast Cable Communications Email: yiu_lee@cable.comcast.com David Schwartz Kayote Networks Email: david.schwartz@kayote.com Eli Katz Xconnect Global Networks Email: ekatz@xconnect.net Otmar Lendl enum.at GmbH Email: otmar.lendl@enum.at Uzelac (et al.) Expires Dec 15, 2007 [Page 18] Internet-Draft draft-ietf-speermint-voip-consolidated-usecases May 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Uzelac (et al.) Expires Dec 15, 2007 [Page 19] Internet-Draft draft-ietf-speermint-voip-consolidated-usecases Uzelac (et al.) Expires Dec 15, 2007 [Page 20]