Skip to content Skip to site navigation

Phones

Starting in March 2022, you can no longer dial 9 + 7-digit local phone numbers when using the Stanford phone system. For details, see Change for Dialing Local Calls from Stanford Phone Numbers Coming Soon.

Types of phones

A telephone number in the Registries should be a fully articulated number containing all connecting information -- country and area codes plus number.

The Person Registry supports the following types of phone:

Phone type Occ Source Description
min:max reg ext user
permanent 0:1 no yes yes Permanent residence phone
local 0:1 no yes yes Local phone, if different than permanent
mobile 0:1 no yes yes Cell phone number
pager 0:1 no yes yes Pager number
residence 0:1 no yes no Communication Services dorm (or other campus residence) phone.
home 0:1 yes no no Single "best" home phone number
office 0:1 per aff no yes yes Per-affiliation office/work phone
office2 0:1 per aff no yes yes Second per-affiliation office/work phone
officefax 0:1 per aff no yes yes Per-affiliation office/work fax
officemobile 0:1 per aff no yes yes Affiliation-specific mobile phone
officepager 0:1 per aff no yes yes Affiliation-specific pager phone
work 0:2 yes no no Single "best" work phone
workfax 0:1 yes no no Single "best" fax phone
  • Occ: min:max occurrences, where max="n" is no specified limit.
  • Source: reg(istry) = internally generated by Registry/Person rules; ext(ernal) = contributed by external source systems such as Campus PeopleSoft; user = person themselves during self registration or via Stanford.You

Permanent Phone

Registry Database: table=phone, type_cd=general, no aff_source data
XML Document: <phone type="permanent">
LDAP Directory: suPermanentPhone

Generally speaking, the telephone number corresponding to the person's permanent address.

Local Phone

Registry Database: table=phone, type_cd=local
XML Document: <phone type="local">
LDAP Directory: suLocalPhone

An optional phone where a person can record a more local (to Stanford) phone if it differs from the their permanent phone. Usually but not necessarily, associated with a local address. Labeled "Temporary phone" in StanfordYou.

Mobile Phone

Registry Database: table=phone, type_cd=mobile
XML Document: <phone type="mobile">
LDAP Directory: mobile

An optional personal mobile/cell phone number. Not supported for students.

Pager Phone

Registry Database: table=phone, type_cd=pager
XML Document: <phone type="pager">
LDAP Directory: pager

An optional personal pager phone number. Not supported for students.

Residence Phone

Registry Database: table=phone, type_cd=residence
XML Document: <phone type="residence">
LDAP Directory: suResidencePhone

A Communications Services assigned student subscription phone for campus residential service.

Home Phone

Registry Database: n/a
XML Document: <phone type="home">
LDAP Directory: homePhone

A derived phone, not stored separately in the database, computed as local, else permanent phone. This provides a "best" single value for home residence phone as a convenience for downstream systems, such as the directory.

Office Phones

Registry Database: table=phone, type_cd=office|office2, with aff_source data
XML Document: <phone type="office"> in <affiliation><place type="office">
LDAP Directory: suGwAffilPhone[n], embedded type code of office

A per-affiliation work phone (the term "office" is used because it can occur for both staff and students, and to semantically distinguish it from the "work" phone below). A phone of type office2 should not occur unless there is also a first phone of type office.

Office Fax

Registry Database: table=phone, type_cd=officefax, with aff_source data
XML Document: <phone type="officefax"> in <affiliation><place type="office">
LDAP Directory: suGwAffilPhone[n], embedded type code of officefax

A per-affiliation work fax.

Office Mobile

Registry Database: table=phone, type_cd=mobile, with aff_source data
XML Document: <phone type="officemobile"> in <affiliation><place type="office">
LDAP Directory: n/a

A per-affiliation (i.e. job/position related) mobile phone.

Office Pager

Registry Database: table=phone, type_cd=officepager, with aff_source data
XML Document: <phone type="officepager"> in <affiliation><place type="office">
LDAP Directory: n/a

A per-affiliation (i.e. job/position related) pager phone.

Work Phone

Registry Database: n/a
XML Document: <phone type="work">
LDAP Directory: telephoneNumber

A single derived phone, not stored separately in the database, taken from the highest ranking professional (non-student) and non-private affiliation for which there is either an office phone or office fax value. This provides a "best" single value for work phone as a convenience for downstream systems, such as the directory.

Work Fax

Registry Database: n/a
XML Document: <phone type="workfax">
LDAP Directory: facsimileTelephoneNumber

A derived fax number, not stored separately in the database, taken from the highest ranking professional (non-student) and non-private affiliation for which there is either an office phone or office fax value. This provides a "best" single value for work fax as a convenience for downstream systems, such as the directory.

Parts of a Phone Number

Each phone in the registry is stored as a single row in the phone table of the Person Registry database. A phone consists of these parts:

What Required? Schema xml
Type of phone yes type_cd <telephone type="..."> attribute
Country Code no country_cd <telephone>...<icc> element
Area Code no areacode <telephone>...<area> element
Number no number <telephone>...<number> element
Extension no extension <telephone>...<ext> element

Type of phone

Type of data per above.

Country Code

One to three digit international calling code country designation as specified by ITU (International Telecommunication Union) E.164. See http://www.itu.int/itudoc/itu-t/ob-lists/icc/e164_763.html. Phones entered online without a country code are assumed to be "1" (US).

Area Code

For US numbers, this is the 3-digit NANP (North American Numbering Plan) initial portion of a domestic telephone number, corresponding to a region, city or part of a city. For a foreign address this can be a numeric city code. Numbers entered as 7 digits (or 5 digits and completed as a Stanford number) are assumed to be in area code 650.

Number

The remainder of a foreign or domestic number. It will be 7 digits for US numbers, variable for foreign. Online input allows 5-character input if they can be expanded to these Stanford prefixes:

  • 3-nnnn -- 723-nnnn
  • 4-nnnn -- 724-nnnn
  • 5-nnnn -- 725-nnnn
  • 6-nnnn -- 736-nnnn
  • 7-nnnn -- 497-nnnn
  • 8-nnnn -- 498-nnnn

Extension

An optional, numeric extension number. In calling, this is technically not a part of the number itself, but an access code used to further route a call once a connection has been made.

Data integration rules

Phones from the source to the Registry

  • A source may contribute one each of a permanent and local phone.
  • A source may not contribute a home phone. This is derived on output.
  • A source may contribute zero to two office phones for each affiliation.
  • A source may contribute an office fax for each affiliation.
  • A source may not contribute a work phone. This is derived on output.
  • A source may not contribute a work fax. This is derived on output.

Phones in the registry outbound Person XML document

  • Phones of type permanent and local are in the <telephone> at the root level of the document.
  • A single home phone is generated from the other personal phones and represented in the <place> element of type=home.
  • Each office phone is represented as part of its corresponding affiliation inside a <telephone> element in a <place> element of type=office inside an affiliation.
  • A single work phone is generated from the office phone in the highest ranked office phone and represented in the <place> element of type=work.

Events

Registry/Directory synchronization events

The Person Registry posts an registry_person:reconcile for any change in phone data.

Infrastructure person events

The person Slog process that maintains Person data in the Directory posts the following events when directory attributes change. The parms designating the specific data type allow consumers to filter the events to select only changes needed by their system.

Directory attribute event (domain:topic) parm1
suPermanentPhone person:phone permanent
suLocalPhone person:phone local
homePhone person:phone home
suResidencePhone person:phone residence
telephoneNumber person:phone work
Last modified December 14, 2021