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

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

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 for more informationwww.telcordia.com

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

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

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

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

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

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?

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 Home VoIP Provider A OIS Provider C Inter mediate Provider B

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?

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?

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 Home VoIP Provider A OIS Provider C Inter mediate Provider B Inter mediate Provider X

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

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?

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

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?

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!