Peering Considerations for Directory Assistance and Operator Services - John Haluska Telcordia

1. Peering Considerations for Directory Assistance and Operator Services-John HaluskaTelcordia SPEERMINT, IETF 68 Prague, Czech Republic 20 March 2007

2. Goals of this presentation • Introduce ID – what it is trying to accomplish • Discuss how services are different than simple call termination • Special needs of services such as DA, etc. versus simple call termination scenarios • Questions for SPEERMINT WG • Solicit feedback on draft – proposed mechanisms, etc. • Is any of this more generally applicable, perhaps helpful to SPEERMINT

3. The Draft • Considerations for Information Services and Operator Services Using SIP • draft-haluska-sipping-directory-assistance-02.txt • From the VoIP Directory Services Signaling (IPDS) Telcordia Industry Issues Forum • The objective of the IPDS is to drive IP standards for Information Services (e.g., DA) • IPDS comprises service providers and vendors from the directory assistance and operator services industry • See www.telcordia.com for more information

4. Goal of Draft • To identify how Operator and Information Services (OIS) can be implemented using existing SIP mechanisms • Provide a set of Best Current Practices • Solicit IETF comment • Aim is to facilitate migration to SIP, and to facilitate interoperability • Believe adoption of SIP will facilitate development of more advanced services

5. Background • Services such as DA require specialized infrastructure and resources • Thus, they are often contracted out to specialized providers • Call needs to be routed to the proper service provider • Versus routing to a phone number • Service logic potentially based on multiple criteria which might include service agreement, identity of the originating provider, etc. • Service might be provided on • Per individual basis (need caller identity) • Per business basis (need charge number) • Per originating provider basis (need originating provider identity) • Per trunk group basis for PSTN originated calls (need trunk group) • Per other provider basis (need identity of upstream provider with business relationship to OIS provider) • Combination of these • Thus need a way to signal/identify these, in order to provide agreed service • E.g. language, custom variations of service, etc. • Charge number is a deficiency • “Other provider” may be a deficiency

6. Multiple inter provider scenarios • Services Provided by the Caller’s Home Provider • Services Provided by a Direct Third Party Provider • Services Provided by an Indirect Third Party Provider

7. Services Provided by the Caller’s Home Provider (retail) • No peering involved, not an interesting case Home Provider ( and OISP)

8. Services Provided by a Direct Third Party Provider (wholesale) – 1/2 • Home provider has direct L5 connectivity with OISP • This corresponds to Direct Peering Scenario • Home provider is Originating VSP • OISP is Terminating VSP Home VoIP Provider A OIS Provider B

9. Services Provided by a Direct Third Party Provider (wholesale) – 2/2 • This is a straightforward example of direct peering • Provider A routes such calls to provider B, which provides the service • OISP needs to know identity of the home provider in order to provide the proper service (e.g. branded announcements, etc), and possibly to query elements in home provider’s network • Easy because there is direct L5 connectivity • Could use PAI (RHS yields domain, maps to provider) • Could use SubjectAltName if TLS is used • Could use lookup on top Via header • Does this sound reasonable?

10. Services Provided by an Indirect Third Party Provider (wholesale) – 1/3 • Home provider has relationship with an intermediate provider • Intermediate provider has relationship with OISP • This corresponds to Indirect Peering Scenario • Home provider is Originating VSP • OISP is Terminating VSP • Intermediate provider is a Transit Provider Intermediate Provider B OIS Provider C Home VoIP Provider A

11. Services Provided by an Indirect Third Party Provider (wholesale) – 2/3 • This is a straightforward example of indirect peering • Provider A routes such calls to provider B • Service logic/routing decision yields B • B is the DA provider for this call • Request URI indicates ingress point of B • A has relationship with B which allows this • Provider B routes to provider C • Service logic/routing decision yields C • C is the DA provider for this call • Request URI retargeted to ingress point of C • C is the DA provider for this call • B has relationship with C which allows this • Does this sound reasonable?

12. Services Provided by an Indirect Third Party Provider (wholesale) – 3/3 • OISP needs to know identity of the provider sending him the call • This is the OISP’s customer • How to identify? • Certs if TLS used • Via header • SIP History-Info • OISP also needs to know identity of the home provider • He still needs to take into account the home provider for branding, etc., and possibly to query elements in home provider’s network • PAI • SIP History-Info • SIP History-Info can be used because of retargeting • Does this sound reasonable?

13. A Questionable Case – 1/3 • Similar to previous case • A has relationship with B for DA calls • B has relationship with C for DA calls • But in this case, B must route through X to C • X relationship to C is transit only, no concept of DA • C cares about identity of A, B but not X Intermediate Provider X Intermediate Provider B OIS Provider C Home VoIP Provider A

14. A Questionable Case – 2/3 • This case is motivated in part by recent ML discussions regarding multi hop routing as well as statements in the federations draft • Were considering this case independently of the above as well • Provider A routes such calls to provider B • Service logic/routing decision yields B • B is the DA provider for this call • Request URI indicates ingress point of B • A has relationship with B which allows this • Provider B routes to provider C • Service logic/routing decision yields C • C is the DA provider for this call • But it cannot send directly to C, must send via X • Perhaps static provisioning • Perhaps short term – e.g. too many incoming calls at this moment directly from C

15. A Questionable Case – 3/3 • Does SPEERMINT cover this case? • Is there a basis for this in today’s peering environments? • Does SPEERMINT intend hop by hop routing be done on SIP URIs, or on TNs? • Seems to make more sense with TNs • Is it intended that B forwards to X with Request-URI indicating C?

16. Questions • Do our proposed mechanisms seem reasonable? • PAI for home provider • TLS/Via for last hop • History-Info for intermediate providers • Use of SIP URIs versus tel URIs

17. Questions • Applicability of federation policy to identify required signaling for DA/OIS • Such as PAI, etc. • Does any of this seem more generally applicable than just DA/OIS? • For accounting, is there currently a need to know the home provider and also the last-hop? • Or when peering for simple termination, is only the last hop of interest?

18. Next Steps • Have we raised anything of interest to the SPEERMINT WG, especially with respect to peering for services as opposed to call termination? • Appreciate any comments on the draft or on the topic of these slides • Thank you for your time!