1 / 10

IETF 67 – San Diego

IETF 67 – San Diego. SIP Peering Use Case for VSPs Adam Uzelac adam.uzelac@globalcrossing.com Skype: voiploser draft-uzelac-speermint-use-cases-00.txt. Use Cases. Typical internet protocol interconnection scenarios for SIP signaled VOIP Peering in varied inter-domain and trust contexts

hafwen
Download Presentation

IETF 67 – San Diego

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IETF 67 – San Diego SIP Peering Use Case for VSPs Adam Uzelac adam.uzelac@globalcrossing.com Skype: voiploser draft-uzelac-speermint-use-cases-00.txt IETF 67 – San Diego – Nov. 2006

  2. Use Cases • Typical internet protocol interconnection scenarios for SIP signaled VOIP • Peering in varied inter-domain and trust contexts • Pre-established contract between administrative domains • Signaling and media designed to enable and enforce call admission, policy, quality and security for traversing the network boundary. IETF 67 – San Diego – Nov. 2006

  3. The context for these Use Cases • Signaling and media collapsed & symmetrical across the administrative boundary. • Transcoding, if required, is accomplished at the first point of recognized media incompatibility. • There is assumed IP reachability • There is no specific requirement or presumption of private (RFC1918) or public address space use. IETF 67 – San Diego – Nov. 2006

  4. ENUM ENUM DNS DNS Proxy(o) to SBC(o) to Proxy(t) Legend: <anything>(o) = originating <anything>(t) = terminating <anything>(T) = transit Signaling Next-hop lookups VSP (o) VSP (t) IETF 67 – San Diego – Nov. 2006

  5. ENUM ENUM DNS DNS Proxy(o) to SBC(o) to SBC(t) to Proxy(t) Legend: <anything>(o) = originating <anything>(t) = terminating <anything>(T) = transit Signaling Next-hop lookups VSP (o) VSP (t) IETF 67 – San Diego – Nov. 2006

  6. ENUM ENUM ENUM DNS DNS DNS Proxy(o) to SBC(T) to SBC(T) to Proxy(t) Legend: <anything>(o) = originating <anything>(t) = terminating <anything>(T) = transit Signaling Next-hop lookups VSP (o) VSP (T) VSP (t) IETF 67 – San Diego – Nov. 2006

  7. ENUM ENUM ENUM DNS DNS DNS Proxy(o) to SBC(o) to SBC(T) to SBC(T) to SBC(t) Proxy(t) Legend: <anything>(o) = originating <anything>(t) = terminating <anything>(T) = transit Signaling Next-hop lookups VSP (o) VSP (T) VSP (t) IETF 67 – San Diego – Nov. 2006

  8. Something to noodle on… • BASIC REQUIREMENT (from: Stastny_voipeer_BOF_IETF_63.ppt) • “Any connection that originates on IP and terminates on IP should stay on IP end-to-end • No additional cost for PSTN by-pass • Improved QoS for native IP connections • improved functionality (BB codecs, IM, video, conferencing, presence, …)” Each use case was end to end IP, but was basic requirement met?!?! IETF 67 – San Diego – Nov. 2006

  9. Finally… • Proposal - There are 4 IDs of Use Case – We should consolidate into a single ID. • Need to investigate and document why these use cases exist in the way they do today, add to WG requirements (if applicable) once hashed out on mailing list. IETF 67 – San Diego – Nov. 2006

  10. !? Questions/Comments/Concerns ?! IETF 67 – San Diego – Nov. 2006

More Related