SIP PSTN Number Association Sep 2002 Internet Engineering Task Force SIPPING WG INTERNET-DRAFT Mick O'Doherty, draft-odoherty-sipping-pstn-number-association-00.txt Mark Ashworth, Sep 2002 Nortel Networks SIP PSTN Number Association Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This document describes a specific requirement for associating SIP endpoints with PSTN (Public switched telephony Network) endpoints, not for the SIP endpoint to replace the PSTN endpoint, but to allow them to be used together. It outlines some potential ways of addressing this requirement and proposes one of the options as the best case approach. Additionally, it describes a general requirement that fell out from this scenario and that might be a good candidate for further study. 2. Introduction When a PSTN call is set up between two endpoints, one or both of the endpoints typically knows the called and calling party numbers (cdpn and cli/cgpn). If the users would like to have an end to end SIP connection at the same time as the PSTN call, it would be useful to be able to set up a SIP call using the cdpn and cli/cgpn to address the two endpoints (or for the called party to be able to use the cli to address the SIP entity that the calling party would use to associate with the call). This would allow two users, in the examples below Jack and Jill, to have a voice conversation (for example) over the PSTN connection and another media call (eg low quality video or file sharing) via the SIP connection. The tricky part is that we want to allow Jack and Jill to specify (if they choose) that the addressing is used only for this other media and not for voice calls. M&M Internet Draft 1 SIP PSTN Number Association Sep 2002 So, if another user with a SIP voice phone were to call Jack, lets assume Jack wants to take voice calls like this on his PSTN phone, not on his SIP client. In other words the other user would use JackĘs PSTN phone number to address his PSTN phone and the call would break out of the SIP network into the PSTN network via an appropriate gateway. Therefore JackĘs PSTN number is being used in the SIP networks in two ways depending on the context ū if it is a voice call from another SIP ęphoneĘ then the call is to routed to his PSTN phone and if it is a multimedia session associated with a PSTN phone call it is to be routed to whatever SIP client he chooses to associate with this SIP address. 2.1. System Overview The diagram below gives a high level system overview. Jack is calling Jill using the PSTN. When Jill receives the call she sets up a SIP call to Jack, using the delivered cli (JackĘs PSTN number) to address the SIP entity Jack wants to use for calls of this nature. Note that this ęcli based addressĘ does not need to be the primary address for this SIP endpoint ū i.e. the SIP endpoint may have a more normal SIP address (e.g. SIP:JackPC@acmeisp.com) ū the cli based address simply directs the call to the normal address. Note that we are making no assumption about the nature or format of this ęcli based addressĘ at this point. ( ) ( ) ( SIP ) ( Network ) ( )--------------\ / ( ) \ / ( ) \ -------/ \ / \ / +----+ -------\ V |PSTN| V +------+ +----+ +------+ |JackĘs| / \ |JillĘs| | SIP | /---/ \--------\ | SIP | |Client| O----O / \ O----O |Client| | | /\ / \ /\ | | +------+ / \ / \ +------+ ---- ---- JackĘs JillĘs PSTN Phone PSTN Phone Figure 1 ū 2.1. Key requirement for further discussion Distilling the problem domain described above the key requirement that dropped out was: - the ability to route a SIP request differently depending on the service that the request is requesting. O'Doherty Internet Draft 2 SIP PSTN Number Association Sep 2002 This will not be addressed in this document but will be brought up for further discussion to determine if it is a valid requirement in the context of SIP and if so how it might be addressed. 2.2. Options for the format of cli/cdpn based address This section outlines 4 options for building a SIP address from the cli or the cdpn to route to the SIP client the user wants to use for Multimedia calls associated with a PSTN call. The following section then selects the option that is judged to be the best solution and explains the rational for that selection. Option 1 ū using ENUM --------------------- ENUM is used to resolve the E.164 number to a SIP address. Although this is not included in the 'ENUM usage scenarios' draft, or in the working group charter, it seems the ENUM protocol could be used for this. There are a number of existing drafts discussing service-specific enum lookups, or service tagging of returned URIs, but none of these capture the required semantics that the E.164 number should be used as a telephony number for voice calls, and a returned SIP URI used for media components which are supplemental to the PSTN call. Therefore, whilst this approach will work for the use-case where the originator is already aware of these semantics (e.g. the scenario of 2.1), it will not deliver the correct behaviour for a call from a standard SIP client. Advantages: - well understood methodology Disadvantages: - Does not obviously allow the user to have certain calls routed to their PSTN phone and others to their SIP client depending on the type of call as discussed above Option 2 ū Use of a specific Sip service URI ----------------------------------------------------------------- In this case the ęcli/cdpn based addressĘ is a service URI (cf RFC3087) which addresses a redirect service specifically for this application. Part of the username of the SIP URI is used to request that a CLI be translated to a SIP address, and the rest of the username contains the CLIū e.g. xxcli2sip- 441628434238@acmetelco.com where the ęcli2sipĘ is some token recognized by acmetelco.com that indicates that this is a cli or cdpn lookup that is being requested. Advantages: - requires no development or changes to the majority of the entities in the SIP network Disadvantages: - very specific solution - requires solution-specific SIP server logic to perform the lookup. Option 3 ū a new URI schema specially for this case ----------------------------------------------------------------- A new URI scheme is defined specifically to identify the SIP clients associated with a PSTN number. O'Doherty Internet Draft 3 SIP PSTN Number Association Sep 2002 Advantages: - it is clear from the URI schema itself that the 'thing' being identified by this URI is a multimedia endpoint associated with a PSTN endpoint ū not clear that this is a particularly strong advantage. Disadvantages: - new URI schema would need to be defined and supported. Option 4 ū using a well known (perhaps only locally) hostname ----------------------------------------------------------------- Here the domain of the SIP URI built is a well known domain. This domain expects to receive SIP messages with an enum like username part and will redirect the request or proxy the request to whatever SIP endpoint the user has registered against it. Advantages: - no changes to the majority of the SIP network Disadvantages: - if this is used beyond one cli resolution domain of control some form of co-operation is required, perhaps a centrally managed domain for resolution or simply a list of each cli resolution domainĘs well know domain which is then traversed until a match is found. 3. The selected option Option 4, using a well known host name was considered by the authors to be the best option for addressing the specific requirement highlighted by this document. It needs no changes to the vast majority of the network, requiring only the end user or something acting on their behalf to know the well know host name. Additionally, it can scale from a single cli resolution domain deployment where a particular well known name is used, to multi cli resolution domain deployments where either a single centrally managed hostname is agreed or each cli resolution domain simply searches in turn through the otherĘs well known hostnames until a match is found if the address is not resolved in their own domain. For completeness, a full call walkthrough would follow these steps: 1 ū Jack makes a regular PSTN call to JillĘs PSTN phone. 2 ū Jill receives the call and either she or some entity such as her PC acting on her behalf, builds a SIP invite, for some non voice media such as low quality video or a whiteboard sharing application, using the well know domain for cli resolution she is familiar with. If the CLI delivered (JackĘs PSTN phone number) is +441628434238 for example and the well know domain name for CLI resolution in JillĘs network is clilookup.acmeisp.com, then the invite would be sent to SIP:4.4.1.6.2.8.4.3.4.2.3.8@clilookup.acmeisp.com 3 ū The invite is received at the cli lookup domain, where the domain checks it database to see who is registered against this username (JackĘs multimedia client in this case)and then redirects O'Doherty Internet Draft 4 SIP PSTN Number Association Sep 2002 the SIP invite to the appropriate place. If the domain canĘt find the username registered it may redirect the invite to another well known domain (of another cli resolution domain for exmaple or some central one shared between cli resolution domains) for the cli lookup to be resolved. 4 ū JackĘs multimedia client receives the SIP call and Jack and Jill now have end to end voice and multimedia. 8. Acknowledgements The authors would like to thank all the people in Nortel Networks who provided input and feedback. 9. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Handley, et al., "RFC 2543 SIP: Session Initiation Protocol March 1999ö AuthorĘs Address Mick OĘDoherty Mark Ashworth Nortel Networks Concorde Road Maidenhead Berkshire SL6 4AG England mdoherty@nortelnetworks.com O'Doherty Internet Draft 5