e164 vs. partyNumber aliases

Chris Purvis Chris.Purvis at MADGE.COM
Thu Apr 15 04:18:47 EDT 1999


My feeling would be that as an endpoint making calls, you will probably only
be dealing with dialled numbers, and will therefore use the e164 field.

When you're registering with a gatekeeper, however, you may need to do
different.  For example, I have here an internal phone number within Madge
(31359), and a DDI number (+44 1753 661 359).  I could see a sensible way of
modelling that situation as being for my endpoint to register a
PrivatePartyNumber of the former and a PublicPartyNumber of that latter.
The gatekeeper then needs to cope with the difference between the two, and
who dials what to get hold of you.  If you use only the e164 number field,
you either register one or the other (and expect the gatekeeper to
translate), or register both.  The advantage of differentiating them in some
way (either using typed numbers or letting the gatekeeper "invent" another
number for you) is that (particularly in the world of H.225.0 Annex G) the
gatekeeper will probably only publicise public numbers to third parties
(after all, a four or five digit number can't be expected to identify
individuals uniquely if the scope is larger than a single organisation).
If, then, you accept that such differentiation is useful, that means you're
asking extra intelligence within your gatekeeper.  It may make it "easier"
for gatekeepers to have that extra intelligence if you register typed,
rather than dialled, numbers.

Dr Chris Purvis - Senior Development Engineer, WAVE CC Software
Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks.  ENGLAND
Phone: +44 1753 661 359  email: cpurvis at madge.com

> -----Original Message-----
> From: Paul Long [mailto:Plong at SMITHMICRO.COM]
> Sent: 14 April 1999 6:57
> Subject: Re: e164 vs. partyNumber aliases
> Okay, but what is the status of the e164 alias? For example,
> if a user enters
> a "telephone number" at a v1 EP, it must be provided as an
> e164 alias. Will
> all other entities continue to recognize this as a telephone
> number? Now if a
> user does the same thing at a v2 EP, can the number be
> provided as an e164
> alias _or_ a partyNumber? Will all entities continue to
> support both types of
> aliases, or is e164 deprecated as of v2? As an EP vendor, I'd
> really hate to
> require the user to indicate whether the number they just
> entered is an "e164
> alias" or a "party number." Yucko... Maybe, just to be safe,
> the number should
> be provided in both forms, but I think some entities get confused when
> confronted with multiple aliases, or at least the semantics
> of such a thing is
> ambiguous.
> Paul Long
> Smith Micro Software, Inc.
>         -----Original Message-----
>         From:   Callaghan, Robert
> [SMTP:Robert.Callaghan at ICN.SIEMENS.COM]
>         Sent:   Wednesday, April 14, 1999 12:14 PM
>         To:     ITU-SG16 at MAILBAG.INTEL.COM
>         Subject:        Re: e164 vs. partyNumber aliases
>         Paul,
>         The E164 alias, in use, is the user dialed number not
> a structured
> E.164
>         address.  The partyNumber is the structured E.164 or
> Private Number.
>         Bob
> ------------------------------------------------------------------
>         Robert Callaghan
>         Siemens Information & Communication Networks
>         Tel: +1.561.997.3756    Fax: +1.561.997.3403
>         Email:  Robert.Callaghan at ICN.Siemens.com
> ------------------------------------------------------------------
>         -----Original Message-----
>         From: Paul Long [mailto:Plong at SMITHMICRO.COM]
>         Sent: Wednesday, April 14, 1999 12:38 PM
>         To: ITU-SG16 at mailbag.cps.intel.com
>         Subject: e164 vs. partyNumber aliases
>         What is the difference between an e164 alias and a
> partyNumber alias?
> Was
>         e164
>         found lacking, and does partyNumber now supercede it?
> Are we supposed
> to
>         stop
>         using e164? If not, how do we decide which form to use?
>         Paul Long
>         Smith Micro Software, Inc.

More information about the sg16-avd mailing list