Speermint Use Case for Cable - PowerPoint PPT Presentation

View by Category
About This Presentation
Title:

Speermint Use Case for Cable

Description:

Cable Use Case for Session Peering. MSO has started VoIP trial hosted by CableLabs for two years. ... hosts the contact information of Bob's UE-t. SM-t forwards ... – PowerPoint PPT presentation

Number of Views:16
Avg rating:3.0/5.0
Slides: 11
Provided by: JasonG51
Learn more at: http://www.ietf.org
Category:
Tags: cable | case | hosted | speermint | use

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Speermint Use Case for Cable


1
Speermint Use Case for Cable
  • IETF 66
  • Yiu L. Lee
  • JULY 2006

2
Cable Use Case for Session Peering
  • MSO has started VoIP trial hosted by CableLabs
    for two years.
  • The objective of this trial is to evaluate the
    ENUM technology and the SIP routing capability of
    PacketCable 1.x architecture for peering.
  • From this trial, we evaluated the architecture
    and moved on to design the peering architecture
    for Cable.

3
Peering Reference Architecture
4
Two Layers for Peering (1)
  • We divide the architecture into two layers (1)
    User Location Layer and (2) Session Routing
    Layer.
  • User Location Layer is responsible for locating
    the peering point of the user.
  • Session Routing Layer is responsible for routing
    the SIP messages.

5
Two Layers for Peering (2)
  • User Location Layer consists of the ENUM server
    and DNS server.
  • Session Routing Layer consists of the Peering
    Proxy, Session Manager and the User Endpoint.
  • When Originating User Endpoint wants to call the
    Terminating Endpoint, SIP INVITE request follows
    the following logic

6
Peering Logics for SIP INVITE (1)
  1. Perform an ENUM query on the called party in the
    SIP request URI.
  2. If the ENUM server fails to return the response,
    SM-o forwards the call to PSTN.
  3. ENUM server returns a NAPTR record. SM-o parses
    the regular expression and formulates the sip uri
    of Bob which is ltsipbob_at_mso-t.comgt.
  4. SM-o finds out that it does not own "mso-t.com".
    SM-o has local policies to send the request to
    PP-o.
  5. SM-o sends a DNS query to locate PP-os IP
    address.
  6. DNS returns PP-os IP address to SM-o. SM-o sends
    the SIP INVITE to PP-o. SM-o MAY choose to
    record-route to stay on the signaling path.
  7. PP-o receives the SIP INVITE. It examines the
    request URI and sends a query to DNS server to
    get the IP address of Bobs domain "mos-t.com".

7
Peering Logics for SIP INVITE (2)
  • PP-o performs all the necessary operations such
    as sip header normalization and THIG function and
    sends the INVITE to PP-t. Optionally, PP-o MAY
    act as a B2BUA.
  • PP-t receives the INVITE. It examines the request
    URI to verify the domain is one of its serving
    domains. If it is, PP-t will forward the INVITE
    to some proxy that has access to Bob's user data
    to locate Bobs home proxy.
  • SM-t receives the SIP INVITE. SM-t contains the
    registration information of Bobs UE-t. This is
    the home proxy which hosts the contact
    information of Bobs UE-t. SM-t forwards the SIP
    INVITE request to UE-t.
  • Bob's UE-t receives the SIP INVITE request. Bob
    accepts the call. UE-t sends the 200OK and Alice
    acknowledges it.

8
Network Address Translation
  • Some MSOs use RFC1918 addresses to address their
    User Endpoint.
  • We need to find a way to NAT the IP address to
    a routable public IP address.
  • Two Options
  • Use Endpoint
  • User Endpoint uses ICE, STUN and TURN.
  • Network
  • Network uses Relay Server.

9
IPv4-to-IPv6 Translation
  • Some MSOs are planning to trial IPv6 eMTA in
    2007.
  • eMTA registers its IPv6 address to the Session
    Manager.
  • Our assumption is the IPv6 network is responsible
    for all the necessary NAT-PT translation. The
    outside IPv4 network wont know that IPv6 network
    is running IPv6.

10
Future Works
  • Peering Policy
  • Policies are local. Do we need to exchange
    peering policies between peers?
  • User Location Service
  • Is RFC 3263 enough? Do we need more sophisticated
    user location information?
  • Peering Security
  • TLS? VPN? IPSec? How to enforce asserted user
    identity?
  • Peering QoS
  • How to convey the QoS policy from Layer-5 to
    Layer-3?
  • Peering Accounting and Billing
  • What is the right model for billing? Per minute
    usage or Total Bandwidth usage?
About PowerShow.com