Draft-newton-speermint-itsp- problem-statement Andrew Newton 8 - November - 2006 SPEERMINT WG, IETF...

10
draft-newton- speermint-itsp- problem-statement Andrew Newton 8 - November - 2006 SPEERMINT WG, IETF 67 San Diego, CA, US

Transcript of Draft-newton-speermint-itsp- problem-statement Andrew Newton 8 - November - 2006 SPEERMINT WG, IETF...

Page 1: Draft-newton-speermint-itsp- problem-statement Andrew Newton 8 - November - 2006 SPEERMINT WG, IETF 67 San Diego, CA, US.

draft-newton-speermint-itsp-problem-statement

Andrew Newton

8 - November - 2006

SPEERMINT WG, IETF 67

San Diego, CA, US

Page 2: Draft-newton-speermint-itsp- problem-statement Andrew Newton 8 - November - 2006 SPEERMINT WG, IETF 67 San Diego, CA, US.

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.

Page 3: Draft-newton-speermint-itsp- problem-statement Andrew Newton 8 - November - 2006 SPEERMINT WG, IETF 67 San Diego, CA, US.

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.

Page 4: Draft-newton-speermint-itsp- problem-statement Andrew Newton 8 - November - 2006 SPEERMINT WG, IETF 67 San Diego, CA, US.

Types of Relationships

• Bilateral– One-to-one.– Always contractual.

• Multi-lateral– Many-to-many.– The HOT thing these days.

• Free-for-all– Tools don’t exist yet.

Page 5: Draft-newton-speermint-itsp- problem-statement Andrew Newton 8 - November - 2006 SPEERMINT WG, IETF 67 San Diego, CA, US.

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.

Page 6: Draft-newton-speermint-itsp- problem-statement Andrew Newton 8 - November - 2006 SPEERMINT WG, IETF 67 San Diego, CA, US.

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!

Page 7: Draft-newton-speermint-itsp- problem-statement Andrew Newton 8 - November - 2006 SPEERMINT WG, IETF 67 San Diego, CA, US.

Troubleshooting

• The more hops the call makes, the harder it is to diagnose.

• Best practices on:– Points of contact.– Organization Header

Page 8: Draft-newton-speermint-itsp- problem-statement Andrew Newton 8 - November - 2006 SPEERMINT WG, IETF 67 San Diego, CA, US.

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.

Page 9: Draft-newton-speermint-itsp- problem-statement Andrew Newton 8 - November - 2006 SPEERMINT WG, IETF 67 San Diego, CA, US.

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.

Page 10: Draft-newton-speermint-itsp- problem-statement Andrew Newton 8 - November - 2006 SPEERMINT WG, IETF 67 San Diego, CA, US.

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.