Date: Mon, 31 Dec 2001 17:03:43 EST From: Mpierce1@aol.com To: iptel@lists.bell-labs.com I believe that mention of this RFC in Minneapolis in the March 2001 meeting indicated that there was a general feeling that there were significant problems with the current text and a rewrite was required. Based on this, I will make some rather substantial comments on the current text, with the understanding that they propose some significant changes to the concept and details described. The text of RFC 2806 seems to confuse the controls that might be needed between a controller and the device doing outgoing dialing (e.g., MGC and MG) with what is required in the url to designate the destination (location). For example, it takes the AT modem commands for pauses and waits for dial tone and includes them with the url. While there may be cases in which one specific network element (e.g., a MG) needs to apply these techniques in order to send digits (DTMF or dial pulse) to another element (e.g., a circuit switched PBX), the originator of the call knows nothing about this, so this information should not be a part of the url. In fact, due to alternate routing, two calls with the same url might be treated differently because they are routed differently. This type of dialing in which the originator needed to know the routing in order to formulate the digit string was eliminated from most telephony switching environments long ago. The definition of specific "tel", "fax", and "modem" urls ignores the existence of customer premise devices currently in use which allow the connection of telephones, faxs, and modems on the same telephone line (using the same telephone number). In reality, there is no difference in the urls needed for the 3 cases mentioned. The current telephony network is based on there being no difference within the network for these different uses. If other information needs to be carried (e.g., to specify the type of modem supported) this should be separate from the url and may be ignored by some equipment. This type information should not be a part of the url, since it does not provide an identification of the "resource location". If it did, this would then imply, for example, that the following define different locations, that is, must be routed differently: modem:+1-410-555-1234;type=v32b modem:+1-410-555-1234;type=v21 modem:+1-410-555-1234;type=x75 "Post dial" should not be a part of the url. The example given in Section 2.2 of accessing a voice mailbox shows the mistake. The digits to be dialed by the caller when accessing a voice mailbox depend on the voice prompt from that mailbox system after setup of the initial call. For this reason, the possible post-dialing digits can not be a part of the url. There is a fundamental problem in that the urls being described in this RFC serve both as a user visible address (like on a letterhead or on a web page) and as the inter-network element signaling protocol (e.g., part of SIP). It is noted that E.123, which is referenced, only addresses the representation of numbers, for example, on letterhead. This dual purpose of the url being defined leads to confusion in the description. For example, while some signaling relationships may need to be able to code the extra preliminary prefix digits needed to do special things (like the "0w00" in the 5th example in Section 2.6), this would never be a part of the url as printed or visible on a web page, since it is dependent on the location and equipment of the originator. In the telephony world, the digits 0-9 are represented in signaling only by those numbers, However, the user may see the address with these numbers replaced by letters. Since the url being defined here is intended to be seen by the user (as also defined in E.123), it is essential that it be allowed to include letters (not the A, B, C, D that are used to designate the extra 4 codes possible on a DTMF key pad). As E.123 states, "diallable symbols ... can be digits, letters, or other signs." Of course, this causes a problem if one tries to incorporate the 4 extra DTMF codes into the same address string. However, in the ITU-T E.164 numbering plan, these extra DTMF codes can not be part of the address. The international number is limited to 15 digits, each being a numeral 0-9. So, in the tel: url beginning with +, there is no problem with allowing letters a-z. Of course, this depends on the association between letters and numbers being as recommended in E.161. For this reason, users are advised to avoid using letters to specify telephone numbers in international service, but they may. The 1st, 2nd, and 3rd examples in Section 2.6 show a problem with this scheme of treating tel, fax, and modem separately. The three examples use the same number, which can really occur. As shown, the three identical numbers must all result in exactly the same call setup regardless of the extra parameters. Whether it is treated as a telephone or fax or modem call depends on the kinds of equipment connected and the in-band signals which occur. The 4th example in Section 2.6 show the problem with the post-dial logic. While there may be valid case to support the extra digits needed to directly dial into a PBX at the destination in order to directly reach an extension, that capability needs to be under control of the destination. Only the destination knows whether DTMF or dial-pulse or something else is needed to signal to the final entity. The originating entity does not even need to know that there is an extension number present if it is a part of the complete number (as happens in the US all the time with DID). If the extension number is in addition to the regular international number (which is limited to 15 digits), then the originating entity might know that there are additional digits, but still has no knowledge of how the destination is going to signal them (e.g., to a PBX). The other example of the origination entity needing of enter DTMF to invoke a particular service would require an audible response returned from the destination after call set before these additional DTMF digits are sent. Therefore, they can not be part of the url in this case. The text of the 5th example indicates the problem with this form of the url. It states "this kind of phone umber MUST NOT be used in an environment where all users of this URL might not be able to successfully dial out by using this number directly." Since such a phone number contained on a "company intranet" or printed material would be accessible by many people in various places, this will not work. The method used, and the format of the url, should follow the procedures developed over many decades of such situations in the telephony world. The telephone number needs to be shown in a standard local or international format and the user needs to understand how to dial it from their location (e.g., by dialing "0", waiting for dial tone, and then dialling "00" for international access because the local telephone book says to do this). Clearly, when the originating user has a computerized user agent (SIP phone), it can do this thinking for the person based on dialing rules that it has been provisioned with, so the human doesn't have to worry about it. That means that the url on a web page must be in one of the standard formats (no extra prefix digits). In some environments, there may in fact be multiple ways to dial a specific destination. Today the user may decide which to use and the new user agent (SIP phone) can also do so, so it should not be a part of the url. Since the 6th example shows a telephone number in country code 1, it should be following by a legitimate 10-digit number so as to not confuse. Further, the idea should be represented with a better example. It is unknown of any case in which an E.164 telephone number (in North America) would be specified, but it is only "usable" within that area code. Perhaps the example would be better if it were to specify a number usable only within a specific country. I suggest that this RFC be pared down to simply defining the url for a "telephone" number and that additional parameters that might control call setup, such as modem capabilities, should be a part of SIP or a supplementary draft that specifically describes additions to SIP for fax and modem calls. Mike Pierce Artel ------------- Date: Mon, 31 Dec 2001 05:39:09 -0600 From: "Peterson, Jon" I've never really understood phone-context. FWIW, I think it's an OR match, yes. 6.1.5 says that if multiple phone-contexts are present, the number is valid in all of the contexts named. Only when a private dialing plan or special national number (like '911') outside the scope of E.164 is in use should a tel URL not be in E.164 format. In these cases, unfortunately, the value of an explicit 'context' in signaling isn't really clear. In an enterprise, for example, where '85062' is a valid number for a station, a 'context' parameter really isn't needed - the '8' is already a context. I'm not sure why 'tel:85062' wouldn't be a better way of representing this number than 'tel:5062;phone-context=8'. After all, this context will never be meaningful outside the enterprise anyway. While some people out there may be implementing phone-context, I wouldn't have high hopes for interoperable versions of it. > > - RFC 2806 allows several service providers, identified by a domain > name. Since there is no current data base that maps domain > name to, say, > 1010xxxx prefixes (US example), it is not clear how implementable this > is. It is also not clear what the client should do if it doesn't > recognize any of them. Try anyway, using some other carrier? > Not try? Is > a URL the right mechanism for conveying this information? Even if there were a database that mapped TSP domains onto Carrier Identification Codes (the XXXX part of 101+XXXX) or vice versa, by itself that might not be all that useful for routing calls. Routing on both the CIC and the TSP have their place. Translating between TSPs and CICs would almost always require some policy decisions; many ITADs with domain names will not even have any associated CICs. I think the right way to think about the TSP is as a destination domain. If the tel URL is used as the userinfo portion of a SIP URI, it should never have the TSP parameter - that should be the host portion of the SIP URI. When converting a tel URL into a SIP URI, the 'tsp' parameter should map directly on to the host portion of the SIP URI. A CIC parameter (and one has been proposed as an extension to the tel URL) on the other hand is relevant primarily to SIP-PSTN interworking (find a gateway where you can reach that CIC). Mapping between these two parameters, or determining which should be used in a given instance, is probably a policy decision. > > - RFC 2806 allows private dial-plan identifiers (e.g., X-COMPANY-NET), > with a registration scheme left for future definition. That's > a bit too > vague for my taste. I propose ditching this or, say, making > it a domain > name. My vote would be to ditch it. Juggling multiple private dial-plans in the PSTN is a huge, proprietary hassle, and I don't think providing a standard way to do it would actually grant anyone leverage on any problem I can imagine. I suspect that the only use of a dial-plan identifier is to provide further 'context' in which a telephone number can be understood so that some other entity, elsewhere in the network, can combine the partial number with the context to get a complete, E.164-ish number. Again, wouldn't be clear to me why, if the entity creating the tel URL knows its context, it wouldn't use the context to create a global number to start with - or why any entity receiving the URL would get any advantage from being able to process the dialing plan itself. I'm a little surprised to hear it's being used. --------- From: "Peterson, Jon" To: "'hgs@cs.columbia.edu'" Subject: RE: [IPTEL] New draft RFC 2806bis Date: Mon, 31 Dec 2001 09:31:27 -0600 Okay. As I suggested at the IETF, I have a lot of feedback on rfc2806, which I'm now basing off of your bis draft. This note is already running pretty long, and it doesn't even get around to extensions. More mail to come, I guess. First off, the document already looks a lot better. Kudos. I have one broad comment to start with - one that is addressed intermittently in my notes on specific passages below. I think the tel URL overall is somewhat schizophrenic in so far as it is used both for dial strings that could be entered by a user (like '01144...' or '1010288812125551212' or '9w5551212') and telephone numbers as canonical addresses of record, as they are handled by the signaling network (which generally means E.164 numbers, or numbers that can be trivially converted into them). The problem is that dial-strings are not "telephone numbers" at all. A dial-string is consumed by one or more network entities, and understood in the context of the configuration of these entities, in order to generate a telephone number so that a call can be routed. Dial-strings may require pre-pended DTMF tones (to handle local PBXs), and they may include post-dial DTMF signaling that could control an IVR (theoretically, you could probably use a 2806 tel URL to make bank account transfers). Telephone numbers, however, are addresses-of-record. I publish a phone number as a universal means of reaching me. People who want to reach me from a particular terminal have to know how to convert my telephone number into a dial string appropriate for that terminal. My telephone number itself doesn't tell you what you need to do in your local network (like dialing '9' before placing a call) in order to reach me. Telephone numbers are also the normalized way that addresses are signaled in the PSTN. Clearly, dial-strings and telephone numbers are different sorts of entities entirely. If 2806 were a greenfield, I'd actually recommend separate URLs for these two entities ('tel' and 'dial', maybe) because not all implementers of systems that operate on URLs for telephone numbers need to understand URLs for dial-strings. IXC networks, for example, would probably never operate on a dial-string. I think that all of the protocol work surrounding 'local' and 'global' numbers, phone-contexts, prefixes, dialing plans and so forth is an attempt to accommodate this fundamental division in the purpose of the tel URL. In fact, the usage of dial-strings in a SIP environment (as a Request-URI, say), seems somewhat ambiguous to me; does a dial-string signify "here's all I know about this number, I'd like the network to turn this into a telephone number for me so it can be routed to the appropriate terminal" or does it signify "when this number reaches the PSTN, outpulse this set of tones exactly as I have rendered them and it will reach the right party". I suspect that the author of the original 2806 mostly intended the latter; he seems to frequently assume that the method of access to the PSTN would be a user interface (POTS lines rather than trunks). I believe the application that actually motivated the original author of this draft was probably the use of an HTTP browser/telephone (read: WAP on a mobile phone) to browse tel URLs on a web page that, when selected, would cause the phone to place a call (look especially at the definition of client at the beginning of bis section 5, and section 9, for example) or something very similar to this. This obviously has some bearing on the motivation for 'phone-context'. It also shows why the author frequently assumes that the entity that constructs a tel URL would understand the capabilities of the target of the tel URL - if I set up a web page and list the phone number of a device of mine on it, I'll know what its capabilities are. Obviously in the case in which a tel URL is generated based on digits collected from an end user, or from a PSTN-SIP gateway, or something similar, this sort of capability data wouldn't be available. Another problem with this design is that a web page isn't likely to know your 'context' - that is, what sort of dial-strings will work on your phone. That's why 'phone-context' in 6.1.5 is phrased in terms of restrictions - you can't use the tel URL you found on this web page unless your context matches the context in the URL. Obviously, this makes a number of assumptions about the standardization of these context strings that are shaky at best. If you're in a 'context' that requires you to dial '9w' before you make an outbound call, then you can't use a tel URL that doesn't tell you to do this - I think it's pretty clear where this sort of thinking leads you. I'm not sure what we could do with the tel URL today to clarify this matter of dial-strings vs. telephone numbers that would actually be backwards compatible, but it would be nice, at the very least, to define 'global' and 'local' numbers in a way that makes this distinction obvious. The whole reason why dial-strings are necessary in the first place is because black phones that collect the digits dialed by users have no intelligence, configuration or inherent context. Our understanding of 'phone-context' needs to be tempered by the understanding that endpoints that can act as HTTP or SIP clients have more intelligence and can probably figure out how to parse a dial-string or a telephone number without the assistance of the network. I'm not sure that supplying a pre-configured 'phone-context' along with a tel URL that is constructed based on digits dialed by the user of a SIP phone is actually what the author of the original draft intended, and nor is it probably good practice. It might also be useful to enumerate somewhere in the draft the entities that might be involved with the production and processing of tel URLs - something that collects digits from the user in order to generate a dial-string, something that converts dial-string tel URLs to telephone number tel URLs, even (if this is meaningful) web pages through which tel URLs are delivered to users, or (perhaps more reasonably) SIP location services that provide tel URLs as contact addresses for SIP URIs, that sort of thing. The draft definitely needs to become less steeped in the original WAPish sort of model. Some comments on specific sections follow. Section 2: I'd recommend beefing up the second paragraph and its surrounding a bit. These URI schemes don't, I think, just 'describe terminals that can be contacted using the telephone network'. First off, I think we want tel URLs to work for not just black phones (or ISDN phones), but Internet endpoints as well. So probably these URI schemes should apply to any network devices that can be addressed by a telephone number, including endpoints in the PSTN and the Internet. Second, I don't think a tel URL really 'describes' the terminal itself. It isn't as if the URL contains capability or capacity data (well, maybe that 'modem type' thing is capability, but it's a bad idea IMHO). The service that the tel URL should provide is the same thing TNs provides in the PSTN - information about how to route signaling to an endpoint. Third, I think this section should mention something to the effect that a client can support the tel URL without supporting fax or modem, and all appropriate permutations thereof. Finally, I think this section should discuss at least briefly how the URL will be used. It's probably appropriate to mention SIP as a major customer of the tel URL. The key point I guess is that protocols will use these URL schemes to make query-based (maybe via ENUM) or prefix-based (maybe via TRIP) routing decisions for signaling. Maybe all this sort of information (along with motivation) really belongs in some sort of introductory section. The text in section 5 before 5.1 could also be used in an introduction. 5: The definition of a 'telephone network' in the second paragraph of section 5 (essentially saying landline and/or mobile phone networks) sounds like it rules out VoIP networks. Clearly, some VoIP networks have deployed endpoints that are identified by a telephone number rather than a user@host identity. As well, statements like 'if the client has several different types of telecommunications equipment' sound very primitive. I don't think we want to assume that the client must have a physical fax machine, modem and black phone on hand to use the URIs - these are all logical capabilities of the originator of a call. In reference to the last sentence in 5, I'd hope we can deprecate/remove any kind of capability negotiation from the tel URL - this can't be the right place for describing local or remote capabilities. You might also want to describe the fact that any of these URLs could represent the originator, as well as the target, of a call depending on their usage within the signaling protocol in question. 5.1: Maybe the bnf for local number should allow the hexadecimal character set (A, B, C, D, and E) as they are used in European LNP - and Euro LNP also prepends the LRN to the TN. Note that this A, B, C and D are different than the DTMF A, B, C, and D used by the US military among others. ISDN subaddresses are not used for routing telephone calls in the PSTN. Subaddresses are transparent to the public network - they're basically like NATs that allow multiple ISDN terminals to share the same public address (in this case a public telephone number). I'd be surprised to hear that anyone was using this parameter from 2806 - I'm not even sure how it could be used. Wonder if anyone would chime up if you asked if this feature was being used. I assume we inherit the bnf for 'host' from rfc2396? Might want to specify such. I think I may like 'domain' (from 1034) better than 'host' as an indicator for a TSP- I imagine the suggested form for a 'tsp' parameter should be something like 'sipcarrier.com' that could be the target of a subsequent NAPTR/SRV lookup. Ideally, TSP's should represent the domain portion of a SIP URI - anytime you're using a tel URL as the userinfo portion of a SIP URI, the 'tsp' indicator shouldn't ever be present. Or at least, this is how I've always imagined that 'tsp' should work. I'm not sure why the values of 'phone-context' are named 'prefix'es in the bnf. They aren't literally prefixes for the subscriber number - and calling them this could actually lead to some confusion about their use. Since 2806 defines DTMF special tones like A, B, C and D, I wonder if it should actually define some far more useful tones for MF signaling - namely KP, ST, and the like. I know there are many people out there who are doing SIP-MF interworking - these sorts of trunk-control tones in a tel URL could actually be useful for someone. Probably a case where it's best to wait for someone to ask for it, though. 5.2 Clients that support the fax URI SHOULD support T.33 sub-addresses. Clients that don't support the fax URI shouldn't have to care. 5.3: If it turns out that we do want to keep this modem capability thing (which sounds like a bad idea to me), the list of modem-types should be updated to include V.92 and V.44, and possibly others of which I'm not aware. 6.1: I'm not aware of any good reason to use the local form, unless it cannot be internationalized period (like 911, or private dialing plans). This would be the appropriate place to list 'good reasons', I think, if there are any. 6.1.1: In regards to the last sentence of this section, it isn't clear how the user can be notified if pulse dialing is used by a remote endpoint (a PSTN gw, let's say) to which a tel URL is sent. If you assume a combination phone/browser, I suppose it can just display a message to the end user - if you assume SIP is used to carry these tel URLs, then you need a protocol action. 6.1.3: There is also the exceptional case of hexadecimal characters, since TNs in ISUP/ISDN are encoded with BCD. Hex chars A, B, C, D, and E are used in Euro LNP. 6.1.4: This is something that's bugged me for a while. It would be nice if the grammar for global numbers recommended that the first separator character that appears in an E.164 number should delineate the CC from the NSN, because the CC is a variable length prefix. This would make processing so much easier. Perhaps the separator could even be a particular recommended character (like '/'). Even with this optimization, though, I note that there isn't any text in rfc2806bis that explains how one distinguishes the CC from the NSN in an E.164 number without separator characters - only a mention that E.164 numbers are unambiguous if clients are 'properly configured'. I think this should be explained in bis - it isn't something that non-PSTN-literate people are going to know off the tops of their heads. 6.1.5: I think the view of phone-context in the draft is somewhat confused. Of the two functions described in the first paragraph of 6.1.5, the second, 'qualifying the phone number so it may be used unambiguously', should never be necessary - if the number can be rendered in an international, unambiguous format, it should be - the phone-context parameter isn't necessary for that. The first function, indicating where this number is valid, may have some use, but I'm not sure exactly how to leverage it. In the second paragraph of 6.1.5, I definitely don't think that the phone-context parameter should be REQUIRED for local-numbers. I also don't think the usage of phone-context is sufficiently defined for clients to understand whether or not they are calling from within a given context, so I'm not sure it could really merit the MUST NOT strength. In the example in the last paragraph of 6.1.5, for example, it isn't at all clear to me that '213' wouldn't be valid potential phone-context for multiple networks in the world - the fact that the URL was authored in one such context doesn't mean that it couldn't potentially land somehow in a different context that identifies itself with the same context string. Moreover, if the local prefix form described in the last paragraph is only valid in situations in which 'the unambiguous context for the phone number is given by other means', why do we need phone-context here at all? Why shouldn't this 'unambiguous context' supply all the information we might get out of the use of the phone-context parameter? Again, the problem here is that phone-context is only useful when you already have some assured context information. I'm also concerned that these sorts of local phone-contexts might turn out to be very complex. For example, I'm aware of some national numbers in the USA (freephone numbers, actually) that are only reachable from within the network of a certain iLEC. Unfortunately, the number of NPAs owned by any given iLEC is very high - we'll just say it's over 100. Would we really want to supply a tel URL with 100 distinct phone-context parameters, each containing an NPA? If I had to make any suggestion, I guess it would be this: the only really valid values for phone-context should be global-prefixes - and these should be restricted to country codes. Phone-context should be used ONLY for telephone numbers that are strictly national in scope (like freephone numbers, emergency/directory services numbers, etc). You may give rise to some failed calls by not admitting of a level of granularity below the country code, but it isn't as if there was a way these calls might have succeeded if that granularity had been allowed. A telephone number written on a flier will not have a phone-context parameter; users will generally not input a phone-context as part of their normal dialing behavior. Finally, I also think the string 'phone-context' is big. Maybe there should be a short version of it - like 'cxt' - that could be used as well. 6.1.6 The talk of 'dialing' here seems to exclude conventional PSTN signaling (SS7, Q.931, etc) in favor of the end-user approach - a common thread through the document, actually, and the root of the pre-dial DTMF tones and other similar mechanisms. If an SS7 gateway is the recipient of a call to a tel URL, it can of course use global numbers in ISUP without converting them to local numbers. In some instances, local numbers might have to be converted to national or international numbers for transmission in ISUP. 6.4 I definitely like the idea of having mandatory and optional parameters for the tel URL (sort of like the 'handling=' Content-Disposition for MIME bodies in SIP). One question, though - generally, the 'x-' prefix for a parameter/header means that it isn't registered with IANA, rather than that it's optional, right? From section 10 I gather than all parameters (even 'x-' ones) must be registered with IANA. I only bring it up since it may be confusing to people familiar with the slightly different meaning of 'x-'. Maybe some other prefix could be used to suggest that a parameter is optional? 8.1: All of the ISDNish language in this document strikes me as extremely dated. SIP is of course the antidote to having to juggle a million URI schemes in order to figure out the best way to communicate with a remote user. The assumptions of 8.1, I think, are very anti-SIP. Personally, I think this section provides slim motivation for having separate schemes for 'fax' and 'modem'. I'd be interested in hearing how many people are using modem URLs; the idea that you'd use a (necessarily IP-network-derived) URL to contact a modem, presumably so you can get network access, seems downright nonsensical. A Google search on "modem URL" doesn't turn up much other than rfc2806. >From an organizational perspective, I would move motivation like this and some of the subsequent sections to the front of the document, probably into section 2. 8.3: The third paragraph is good advice when users dial telephone numbers off of web pages, business cards or billboards. But when a gateway constructs a tel URL from a national number, it has to know what the CC (possibly derived from local configuration) and NSN components are since the two are concatenated to make the finished product. 8.4: Not really sure where this section fits in to the big picture. This would be a good section to talk about digit collection and similar issues. I wonder if 'en bloc' and 'overlap' signaling need to be mentioned in this context. 8.5: The rules in 8.5 are sensible - if only phone-context actually created this kind of assurance for clients. It isn't clear from the example why a local phone number that could be trivially internationalized would be sent in a tel URL. I'd hesitate to include the example because it might inadvertently encourage that sort of behavior. - J From: Tom Gray@MITEL on 01/02/2002 08:00 AM With respect to the suggestion that the issue of 'wait for dial tone' belongs in the media gateway and should not be specified in the tel URL, comes the issue of how the media gateway can know how to do this? Contrary to what was said below, it seems to me that the originator would know that the 'wait for dial tone' is needed in typical cases and that this fact would not be known to media gateways.. With the example given below of the use of 'wait for dial tone' on a PBX with DISA or some similar functionality, a user would enter a public PSTN number followed by a number of digits. How would the MG know that the routing plan for the number should have a 'wait for dial tone' in it? The public PSTN number is likely one that the owners of the media gateway are unaware of. It would be very unlikely that they would have programmed their routes to behave in the proper manner. --- "Unfortunately, determining the country code in an E.164 number follows complex rules. The only one digit country codes are '1' and '7'; all other country codes are either two or three digits long. Among codes beginning with: - 2: only '20' and '27' are two digits long, the remainder are three digits long. - 3: all codes are two digits long except those of the form '35x', '37x' and '38x'. - 4: all codes are two digits long except those of the form '42x'. - 5: all codes are two digits long except those of the form '50x' and '59x'. - 6: all codes are two digits long except those of the form '67x', '68x', '69x'. - 8: '81', '82', '84' and '86' are two digits long; all others are three digits long. - 9:, all codes are two digits except those of the form '96x', '97x', and '99x'." And also to point to the canonical document (a little more useful than the tpc.int doc above) which is here: http://www.itu.int/itudoc/itu-t/ob-lists/icc/e164_717.pdf I'd note that the tpc.int doc lists a 5399 country code that doesn't exist, AFAIK. 53 is Cuba, and four-digit CCs are illegal. Then again, the US military essentially has their own private dialing plan, so who knows what principles hold for military bases on foreign soil. Still, it isn't part of the E.164 country code plan. Brett Tate: - uses phone-context - tsp I presume from your comments that you support a significant rewrite of RFC 2806 and deletion of the things that were there to support PC/modem communication (like the AT command set I referred to) which would not be appropriate for specifying the destination telephone address. Following are additional comments/thoughts on this subject: Since the purpose is to define a telephony resource (a destination for a call), it would seem that there are three somewhat related uses for this url: 1. to represent the destination resource at the user interface for the human to enter/read 2. to represent the destination resource as seen by a user agent, for example in an A HREF html tag or the equivalent SIP user agent. 3. to represent the destination resource for inclusion in messages (e.g., in SIP) In other signaling systems, the above would be distinct formats. In SIP, there is an assumption that these 3 uses must be the same format, as in HTTP, which has led to the difficulty with defining/understanding how to treat spaces and other things. It seems that, independent of whatever is done in SIP or in other protocols, the representation to the user should use exactly what is currently standardized in E.123. That is, the international number, which could include spaces, hyphens, or dots as visual separators or letters in place of numbers. When the tel: url is used internally (in an A HREF tag or in a signaling message), all visual separators would be removed and letters would be converted to the appropriate numbers. There would need to be a specific decision on which of the procedure symbols defined in E.123 need to be included. My suggestions: 1. International prefix symbol - + used to indicate an international number (Note that this symbol is really defined in E.123 as indicating the need to dial an international prefix which is not included in the number since it depends on where one is dialing from. Here it is being used to indicate that an international number follows. This is pretty much the same in the end, but a slightly different definition.) 2. Parentheses - never used in an international number, but might be allowed in other numbers 3. Slash "/" to indicate multiple numbers - probably not allowed 4. ... to indicate in-dialing - actual uses of this are unknown 5. Tilde to indicate where another dial tone will occur - uses of this in real life as a part of the destination national or international number are unknown. It is defined in E.123 only as an indication to the human of where to expect another dial tone. It does not control signaling. Representation of international numbers should be easy, since this is already defined in E.123. This results in a truely "uniform" resource locator. If there is also a need to represent national numbers and private numbers, this causes difficulty in keeping them "uniform". Of course, E.123 defines the representation on printed material and includes the words "international" or "national" before the numbers, which the tel: url won't do. The absence of the "+" could mean national, however, the result is not "uniform" in the sense of being unique. Numbers from private number plans are much more of a problem since they are never unique. Considering the three uses of the tel: url listed above: The representation at the user interface has a meaning only to that user. That is, the person understands the context of the number they enter or see. The representation within an A HREF html tag or equivalent has no knowledge of the context. Either it is unique (e.g., an international number) or the user agent must assume a context or determine it by other means. Within the signaling message, the context must be explicit. Here there is no reason to support national numbers, since they are just a subset of the international number. The user agent could always fill in the complete number. Private number plans must be supported, and some way to identify the context ("domain"?) is desired. I do not believe it should be a part of the tel: url, since the identification of the "domain" applies to other things besides the telephone number. Since the purpose of the tel: url is to designate the destination resource, it should never include procedures for getting out of the originator's local environment. That is why dial tone detection and pauses, as used to control modems to get through the user's PBX, are not required. Mike Pierce Artel ----- Brett Tate: > No, unless somebody makes a case that this > is actually useful and used > in practice. Are you using the modem parameters? No. I was just checking. I guess the first vendor that wants it, can define it in an extension. > > > - No post-dial strings or > > > 'waiting-for-dial-tone' characters (p, w). > > > > I hate to see this one go since it allows for > > easier user interaction with auto-attendants, > > messaging-servers, etcetera. > > I sympathize; are you using this feature? It isn't in our product. And it probably won't be added anytime soon. > > > - No carrier identification. > > > > We have commercial deployments using the cic. > > This includes interaction with other vendors. > > The CIC parameter somebody else proposed or > the TSP parameter? The CIC as defined within draft-yu-tel-url-02. > Can you name the other vendors? Cisco and Sonus. I was informed that other softswitch vendors intend to implement it. > How are the carriers identified? Carrier identification codes (CICs) are used to route and bill calls in the public switched telephone network. CICs are four-digit codes in the format XXXX. To obtain a CIC, an applicant must purchase access from an access provider, who will in turn apply to NANPA (North American Numbering Plan Administration) for the assignment on behalf of the access purchaser. Reflecting their origin, CICs may be classified as Feature Group (FG) B or (FG) D, depending on the type of access purchased. CICs are assigned according to the guidelines developed by the ATIS-sponsored Industry Numbering Committee. Effective August 6, 2001, Interim Feature Group D CIC Assignment Procedures will be in effect until further notice from the FCC. The TRA, or Telcordia? Routing Administration, is administered by Telcordia Technologies and has its own web site, www.trainfo.com. The TRA maintains extensive databases and publishes detailed numbering information, including the Telcordia? LERG? Routing Guide. This information is needed by carriers, PBX owners, payphone operators, and others to successfully route and bill calls, as well as to meet other needs. This information applies to all active and planned area codes, Central Office Codes, and prefixes (NXXs) within Service Access Codes (SACs) 500 and 900. The information includes supporting details for area code splits, as well as lists of Carrier Identification Codes (CICs), SS7 Network Codes and other codes assigned by the NANPA. > > We have deployments using the private-prefix > > which was defined in rfc2806. > > > > The private-prefix phone-context allows for > > easy communication of a private > > service/dial-plan for a given local-phone-number. > > I'm still a bit worried about the name space > ambiguity problem, but I suppose a domain name > could be used to solve this. Yes, the domain ensures no ambiguity. Currently the domain could be provided by usage of tsp or sip-url's host/maddr. It is the domains responsibility to ensure uniqueness. For private-prefixes that are made public, a solution could be to start the prefix with the FQDN that guarantees uniqueness: ';phone-context=/iana.org/...'.