SIP in higher education

[John Todd <>]

At 5:04 PM -0400 8/4/05, Ed Guy wrote:
> Sip.edu'ers
>
> I really like John Todd's proposal of using the ITAD to indicate the "domain"
> portion when mapping numbers to sip uri's however, everyone I talk to outside
> of this group about using the '*' as a delimiter cringes.  While no 
> one I've discussed
> it with can say with full certainty that an asterisk in the middle 
> of a dial string will
> absolutely break some system,  they're willing to bet it will. 
> There's got to be a
> better way to encode this info.   This email introduces another approach-
> after a bit of analysis.
>
> For the sake of this discussion,  I'll work from the following requirements:
> * The sip:user@domain  uri Shall be translated into two sets of 
> digits that are combined
>    into  a string composed of  common DTMF characters {0..9*#} 
> suitable for dialing
>    on a traditional phone.
> * The "user" portion of the string Shall be determined by a policy 
> local to the domain.
> * The "domain" portion string Shall be common for all members of a 
> given "domain"
> * the non-numeric DTMF characters SHOULD be used in a manner consistent with
>   known dialing limitations.
> * The total length of the string SHALL NOT exceed 15 characters
> * E.164 numbers in the NANP SHALL NOT be used as an identifier.
>
> I'll further make these assumptions:
> * ITAD numbers are the choice for domain numbering.
> * collisions with other dialing patterns are not a concern because 
> some local dialing
>   prefix (e.g. 012, or 0110) will be used.
> * partial dialing and dial patterns are not a major concern; there 
> is no need to collect
>   subsequent digits.
>
> Therefore,  I'll go back to my short list of simple methods to 
> accomplish this two
> part encoding.
> * the two fields can be delimited by a known character:
> * one of the fields can be fixed length
> * or the length of the field can be determined from the number.
>
> Using a known character as a delimiter is difficult because any 
> numeric choice limits the
> valid user and domain choices and '*' and '#' just might make 
> dialing difficult.
>
> The US Phone company made the 'carrier' field fixed length and kept 
> having to extend
> it.  10XX, 10XXX?, 101XXXX.  Any choice we make is likely to be 
> wrong and wasteful
> My number might be 33489-000258 or 000258-33489
> Country codes are of known length based on the first digit. 
> Assigning them this way would
> be difficult and it changes the IANA assignment procedure.  BUT, we 
> can use the IANA
> assigned ITADs and run length encode them by prefixing  (or 
> appending) the length of the
> ITAD.  So, my number might be 3258-33489 for ITAD 258 or 
> 41234-33489 for ITAD 1234.
> So the proposed algorithm to encode sip.edu numbers  is
>    sip.edu number = strlen(ITAD)+ITAD+USER
> where '+' is the concatenation operator.
>
> This technique is no longer than the delimited case, it is surely 
> more compatible with
> traditional phone systems, and it maps nicely into private ENUM and 
> SRV records,
> with out any changes. It can also use a table lookup if needed.
>
> (By the way, another possibility is to put the ITAD and length at 
> the end: making it
> 33489-2583.    sip.edu number =? USER+ITAD+LEN(ITAD)
> while the Internet does least-to-most significant encoding,  the 
> phone system does
> most-to-least encoding and other than being in the same order as the 
> email address, I
> cant come up with any advantages of this over the prior method)
>
>
> Comments??  Fire way!
>
> /ed
>
>
> --
> ======================================================================
> Edward T. Guy, III, Ph.D. Chief Scientist, Pulver.com Enterprises 
> Melville, NY 11747
> sip:
> mailto:
> tel:+1.973.437-4519



Ed, All -
  That's actually a decent idea, and I really like it at first 
glance.  However, there are some problems with the concept, some of 
which are more critical than others and which I believe in total 
would make me shy away from this method and remain with the "*" as 
the subscriber/ITAD delimiter as originally described.  I've listed 
them in rough order of importance:


1) Moving away from a known delimiter makes the number less 
identifiable as an ISN number.  The presence of a "*" in the number 
makes it clear by looking at the number that it is an ISN number, and 
therefore must be dialed using the local prefix sequence unique to 
ISN dialing.  Without the "*", it is possible that your example 
number 41234-33489 could be written or interpreted as "4123433489" 
and from there to "412-343-3489" which would be clearly confusing as 
to it's difference from E.164 numbering.

2) While I understand that there is fear about using the non-numeric 
"*" separator, I would like to see concrete examples of some 
widely-used modern system with a significant customer base that will 
not function with that dialing syntax.  Until I can see some 
real-world issues, I remain unconvinced that it will be 
insurmountable.  I certainly understand that there will be some 
infrequently used systems which cannot handle the "*" digit in a 
pattern, but I think that will be largely ignorable.  Why?  Because 
if the system is so old that it chokes on "*", then chances are good 
that it will not have a VoIP trunk option, anyway.  If that is the 
case, then to pass calls out to ISN numbers, a trunk system will be 
required to send the subsequent digits from the local system to a 
VoIP-capable platform which will be able to handle the digit string.
 Example: let's say that I have a very old and "stupid" system which 
can't correctly parse "*" in an initial dial.  However, I configure 
the system so that when I dial "012" it will pick up an external 
trunk line, and then send all subsequent digits to that trunk.  Since 
ISN calls in my enterprise all start with "012" as the prefix, then 
as soon as I finish the "012" part of the call, the "stupid" switch 
hands the call to the TDM-(PRI or channelized T1 or whatever)-to-VoIP 
trunk which then parses the subsequent digits.  The problem is 
offloaded from the "stupid" system to a "smart" system which knows 
how to handle that dialing pattern.
  Any system which can't handle the "*" character after that point 
I'd think would also be unable to pass the "*" digit to external IVR 
platforms, which would be causing a large number of headaches for the 
user community already.
  Until a factual case can be made for a meaningful number of users 
would would be unable to use this method, I remain convinced that it 
is the most clear and useful syntax.  ("meaningful"=platforms with 
widespread usage which would cause >5% of the possible user base to 
be unable to use the ISN method of dialing in any form.)

3) The mapping is somewhat confusing.  The ISN would then comprise of 
three different variables, and will be difficult to explain.  While 
it may seem obvious to you and I how to look up an ITAD, count the 
number of digits in the ITAD, and then suffix (or prefix) that number 
to the ITAD to get the dialing method... I think that is hard to 
describe to people.  Imagine describing this to a typical phone 
system user.  I think it's going to be a challenge (though possible) 
to describe ISNs, but adding this additional dimension of complexity 
that separates ITAD from dialing sequence will be a point of derision 
for people who like their comfortable habits.  "Oh, and now I have to 
remember to count the number of digits and add that on the end... of 
which? where?  what?"   I also expect that people will double-add 
suffix digits.  An ITAD of 1234 and subscriber of 999 would be 
99912344 but that might easily become 999123445, or worse: 99912347.
  The problem is most pronounced during the most fragile part of the 
cycle, when people are getting used to the system.  The transition 
between 3, 4, and 5 digit numbers will be rather rapid during 
ramp-up, so there will be the densest use of different run-length 
suffixes/prefixes during the introduction of the method, which could 
be counterproductive.  What is required is a methodology to convert 
between ITAD numbers and dialed numbers in a way that is consistent 
and understood by the most technology-averse or even overtly hostile 
users with a minimum of possible intentional or unintentional 
confusion.

4) Using a number suffixed or prefixed to the ITAD as a length 
identifier is obviously limited 10 digits, which means using 0-9 as 
the number of digits.  So you have another single digit to add to 
every number dialed. So, that means that an ITAD of 12345678 would be 
123456788 in this scheme.  Moving out a bit more, if/when the number 
of ITADs grows to >999,999,999 then the numbers would be something 
like this: 12223334440.  A five-digit ITAD becomes six, six to seven, 
and so on.  This method penalizes the entire user community into 
remembering and dialing another digit, versus using a consistent 
symbol ("*") that does not have to be memorized or synthesized 
independently for each dialing sequence.

5) Removing the "*" character makes the number less like a SIP URI. 
One of the minor sub-goals of the adoption of ISNs is to make people 
familiar with a syntax for telecommunication endpoint identification 
that is "<subscriber><delimiter><organization>", so that the 
transition to SIP URIs is more easily understood in the future as 
keyboard-capable telephony devices come onto the scene.  Without the 
delimiter, it is not apparent that there is a difference between the 
entity identifier and the subscriber number.  It is less obvious what 
the entity identifier even is, so it is possible to accidentally list 
the last digit of the subscriber as the first digit of the ITAD 
without knowing the method to use the run-length digit as a parsing 
hint.



Discussion not related to the run-length vs "*" delineator:

6) There had been discussion earlier about putting the ITAD number at 
the end of the dialing sequence, so it would be <subscriber>*<ITAD> 
and I think there was general agreement that the construct was better 
in this format, so that it resembled a SIP URI more closely.  I think 
that's a "closed" issue unless there is real desire to stay in 
lock-step with the Telephone System model...  I think that subscriber 
numbers will be more unique than ITADs, so this even fits very well 
with directory-based or dialhistory-based auto-completion systems, so 
that fewer results will be more quickly presented with fewer digits 
entered.  Users rarely will be guessing numeric extensions, so having 
a least-to-most specific "worldwide" directory will be almost 
useless, though it sounds good at first look.  (This is perhaps not 
the case for phonetic or alpha searches, though - what is good for 
one syntax is not necessarily good for the other.)

7) I am unconvinced that e.164 numbers should be forbidden as part of 
the identifier, regardless of if the "*" or run-length value is used 
as an ITAD delimitation method.  It may be good practice to actually 
go out of one's way to _include_ the e.164 numbers as an alias 
identifier for a domain.
  Let's say I have Penny's business card with -only- her e.164 number 
on it (16095551212), and I know that Penny is a professor at Banzai 
University (BU).  Because I often communicate with other staff at BU, 
I happen to know that the ITAD for the BU is 1984.  Or perhaps I 
looked up BU's ITAD in the on-line ITAD directory.  If the 
administrator at BU has been clever and followed the hypothetical 
best practices document, then for every e.164 number that BU is 
allocated from various PSTN providers is _also_ mapped in an internal 
system on BU's SIP proxies.  So, I could guess and dial 
16095551212*1984 and it would map to a device which would reach 
Penny.  Recall that these directory listings do NOT pollute the true 
ENUM root nor should they cause any confusion, because they are 
essentially local requests within the entity.  Of course, every 
entity needs to maintain that list however they see fit - there can 
be as many or as diverse a set of aliases as would be deemed 
appropriate for that enterprise.  Perhaps 5551212@1984 maps to Penny, 
as does 1212@1984.  Other numbers which are not part of previous 
e.164 mappings may also map to Penny - this is totally up to the 
local administrator, and it may make sense for some entities to 
install full e.164 mappings in their tables to make "guess-able" 
transitions possible even if only the e.164 number and organization 
is known by a caller.  Some sites might use it, some might not, but 
why limit the obvious mappings?

8) Limiting to 15 digits becomes more restrictive as digit length of 
the ITAD grows, and also artificially limits later participants from 
longer subscriber numbers in order to stay under the limit.  Granted, 
the interval between ITAD digit growth becomes logarithmically 
larger, but those intervals may not have corresponding chronological 
interval durations as adoption increases.  I would hope that it would 
be some time before there are >1,000,000 ITADs, but resource 
exhaustion has plagued IP services in this way before and I'm 
hesitant to artificially limit the number space to match some 
arbitrary older technological limits.   I'd have no problem if this 
were a "suggested" or "best practice" method, but not a "MUST".  I 
also think that the aliasing of full e.164 numbers within the 
enterprise is a good idea even though the canonical subscriber 
numbers may be much shorter.  Using e.164 numbers as subscriber 
aliases will very obviously create rapid (almost instant) conflict 
with the 15 digit limit.
  I understand the request, so perhaps changing the wording to 
something like "there SHOULD BE for each subscriber a sequence of 
digits (subscriber+*+ITAD) that is less than or equal to 15 total 
digits", but saying "MUST" means that any administrator of an ITAD 
that is 9 digits is limited to a 4 digit extension pool.  I know this 
is long-term thinking, but who would have thought we could POSSIBLY 
run out of IPv4 space?  Or ASN space?  :-)


JT