Draft-newton-speermint-itsp- problem-statement Andrew Newton 8 - November - 2006 SPEERMINT WG, IETF...
-
Upload
alexander-turner -
Category
Documents
-
view
213 -
download
0
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.](https://reader036.fdocuments.net/reader036/viewer/2022083008/56649f455503460f94c66dec/html5/thumbnails/1.jpg)
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.](https://reader036.fdocuments.net/reader036/viewer/2022083008/56649f455503460f94c66dec/html5/thumbnails/2.jpg)
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.](https://reader036.fdocuments.net/reader036/viewer/2022083008/56649f455503460f94c66dec/html5/thumbnails/3.jpg)
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.](https://reader036.fdocuments.net/reader036/viewer/2022083008/56649f455503460f94c66dec/html5/thumbnails/4.jpg)
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.](https://reader036.fdocuments.net/reader036/viewer/2022083008/56649f455503460f94c66dec/html5/thumbnails/5.jpg)
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.](https://reader036.fdocuments.net/reader036/viewer/2022083008/56649f455503460f94c66dec/html5/thumbnails/6.jpg)
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.](https://reader036.fdocuments.net/reader036/viewer/2022083008/56649f455503460f94c66dec/html5/thumbnails/7.jpg)
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.](https://reader036.fdocuments.net/reader036/viewer/2022083008/56649f455503460f94c66dec/html5/thumbnails/8.jpg)
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.](https://reader036.fdocuments.net/reader036/viewer/2022083008/56649f455503460f94c66dec/html5/thumbnails/9.jpg)
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.](https://reader036.fdocuments.net/reader036/viewer/2022083008/56649f455503460f94c66dec/html5/thumbnails/10.jpg)
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.