draft-newton-speermint-itsp-problem-statement

1
draft-newton-speermint-itsp-problem-statement

• Andrew Newton
• 8 - November - 2006
• SPEERMINT WG, IETF 67
• San Diego, CA, US

2
Purpose

• Provide a problem statement from the point of
  view of an ITSP (or VSP).
• Specifically, a broadband VoIP network operator
  with a direct relationship with customers.
• The intent by the author is to drive SPEERMINT
  discussion and direction, not publish an RFC.

3
New Terminology

• Routed Peering
• refers to the use of directories or SIP redirect
  proxies to act as a routing function which
  facilitates direct peering, indirect peering, or
  assisted peering.
• Limited Indirect Peering
• refers to the inability to offer indirect
  peering, or transit, for all calls.

4
Types of Relationships

• Bilateral
• One-to-one.
• Always contractual.
• Multi-lateral
• Many-to-many.
• The HOT thing these days.
• Free-for-all
• Tools dont exist yet.

5
Call Termination

• Traditionally
• Any indirect peer to whom we could route a call
  could terminate that call.
• Going forward
• No longer true.
• Need to know, at call time, very fast, where to
  route the call.

6
The E.164 Namespace

• Provisioning
• It sure would be nice if everybody used the same
  protocol.
• RFC 4114.
• Number Lookup
• Public trees look more like deserts.
• And are sometimes broken.
• Many useful private trees.
• Which requires multiple, parallel queries. Not
  ideal!

7
Troubleshooting

• The more hops the call makes, the harder it is to
  diagnose.
• Best practices on
• Points of contact.
• Organization Header

8
Security

• Security between contractual peering arrangements
  is fine and unlikely to change regardless of how
  many RFCs MUST it.
• Completely open peering will require good
  security of both signaling and media.
• Thanks to popular TV shows like Law Order, most
  Americans believe (incorrectly) that signaling
  is easily obtained by 3rd party but media is
  not.

9
CODECs

• A standardized list would go along way.
• And because CODECs run at the edge, it must not
  be a list that changes from federation to
  federation.
• VSPs may join federations.
• End users run CODECs.

10
RFC Compliance

• The number of SIP related RFCs and the
  intricacies involved with them are many.
• Vendors have a hard time keeping up and
  developing what is already on the books.
• Therefore, new RFCs MUST be meaningful.