RFC 6011
Session Initiation Protocol (SIP) User Agent Configuration
Session Initiation Protocol (SIP) User Agent Configuration 🦋
Okay bestie, this is RFC 6011, and it's a super cute little spec about how a SIP User Agent finds, grabs, and keeps up to date its configuration from a Configuration Service 💖 It came out in October 2010 from the IETF (Internet Engineering Task Force). The header lists S. Lawrence, Ed. from Linden Research, Inc. and J. Elwell from Siemens Enterprise Communications as the authors, and the ISSN is 2070-1721. The category is Informational 🌸 which means it's published for information and isn't a Standards Track spec. The header doesn't list anything it obsoletes or updates, so there's nothing to look up there 🙈
Abstract
This document defines procedures for how a SIP User Agent should locate, retrieve, and maintain current configuration information from a Configuration Service. ✨
Status of This Memo
This document is not an Internet Standards Track specification; it is published for informational purposes. 🎀
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. 💅
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6011. 🧚
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. ⭐
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 📜
Table of Contents
1. Introduction ....................................................3
1.1. Scope ......................................................3
1.2. Terminology ................................................3
1.3. User Agent Installation Examples ...........................4
1.3.1. Hosted IP Service Provider Example ..................5
1.3.2. IP-PBX Example ......................................5
1.3.3. Special Considerations for High Security
Deployments .........................................6
2. Obtaining User Agent Configuration ..............................6
2.1. Network Discovery ..........................................6
2.1.1. Link Layer Provisioning .............................7
2.1.2. Network Layer Provisioning ..........................7
2.2. Obtaining the Configuration Service Domain .................8
2.2.1. The Local Network Domain ............................8
2.2.2. Manual Domain Name Entry ............................8
2.3. Constructing the Configuration Request URL .................8
2.3.1. Obtaining a Configuration Service Base URL ..........9
2.3.2. Adding Configuration Request Parameters ............10
2.3.3. Configuration Request URI Example ..................12
2.4. Obtaining Configuration from the Configuration Service ....13
2.4.1. Configuration Data Request Authentication ..........13
2.4.2. Configuration Data Request Failure .................14
2.5. Configuration Changes .....................................15
2.5.1. Configuration Change Subscriptions .................16
2.5.2. Configuration Change Polling .......................18
2.6. Validity of Stored Configuration Data .....................19
2.6.1. Re-Validating Configuration Data ...................19
2.7. Retry Backoff Procedure ...................................20
3. Configuration Data .............................................20
3.1. Configuration Data Items ..................................20
3.1.1. Address-of-Record ..................................21
3.1.2. Realm ..............................................21
3.1.3. Username ...........................................21
3.1.4. Digest .............................................21
3.1.5. OutboundProxy ......................................21
3.2. Reset User Agent to Default Configuration .................21
4. IANA Considerations ............................................21
4.1. DHCP SIP User Agent Configuration Service Domains Option ..21
4.2. DHCPv6 SIP User Agent Configuration Service
Domains Option ............................................22
4.3. U-NAPTR Registration ......................................23
4.4. SIP Forum User Agent Configuration Parameter Registry .....23
5. Security Considerations ........................................24
6. Acknowledgements ...............................................26
7. Normative References ...........................................271. Introduction ✨
A user gets a new SIP User Agent (UA); it may be a hardware device or software. Some User Agents have a user interface that can accept a username, password, and domain name. Other devices, like Analog Telephony Adapters (ATAs), have no user interface other than that provided by an attached analog phone. How does a non-technical user minimally configure it so that when it is started, something useful happens? 🤔
1.1. Scope
This document specifies a procedure for how a SIP User Agent locates, retrieves, and maintains current configuration information for a given SIP Service Provider. As such, it specifies requirements to be met by both the User Agent, the Configuration Service at the SIP Service Provider, and the network infrastructure services that allow them to communicate. 🦋
Nothing in this specification prohibits a User Agent from obtaining configuration information by any means in addition to the mechanisms specified herein. 🌈
The intent of this specification is to provide mechanisms sufficient for User Agents to discover an appropriate source of configuration and maintain the currency of that configuration. A User Agent implementation compliant with this specification MAY also implement additional mechanisms necessary in particular environments or when the services specified here are not available. 💜
The form and content of configuration data to be downloaded are outside the scope of this specification, although Section 3.1, "Configuration Data Items" suggests a minimum set of data items likely to be required by all types of UAs. 🍓
1.2. Terminology
The following terms are used in this document: 🎀
User Agent, UA
As defined in RFC 3261 [RFC3261]. Note that this includes any implementation of a User Agent. A SIP phone is a User Agent, but the term also encompasses any other entity that uses SIP (for example, for a text chat, for sharing a whiteboard, or for a fax). 📞
Soft User Agent, Soft UA
A User Agent that runs as an application within some larger system that has responsibility for some of the steps described in this specification. In those cases, the Soft UA must be able to obtain the information from the platform. In all cases, the term User Agent also encompasses a Soft User Agent. 💻
SIP Service Provider, Service Provider
An entity that provides services to User Agents using the SIP protocol. This specification requires that a Service Provider make configuration data and certain other information available in order to configure User Agents. 🫶
Configuration
The set of information that establishes operational parameters for a particular User Agent. ⚙️
Configuration Service, CS
The source of Configuration for User Agents. 🌸
Configuration Service Domain
The DNS name for the service from which a Configuration is requested. 🌐
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 🔑
1.3. User Agent Installation Examples
This section is non-normative; it is a set of "user stories" -- narrative descriptions of the user experience in different environments. These are "black box" descriptions meant to include the actions to be taken by the human participants (including administrators and system operators as well as the "user" of the UA), but not how the network elements communicate or operate internally. The intent is that these narratives provide context for the subsequent technical specifications. 📖
1.3.1. Hosted IP Service Provider Example
Configuring a new UA to use a hosted IP telephony service will typically proceed as follows: the customer makes a request to their Service Provider to add one or more new users to their service. The customer may supply further details such as a preferred username, type of endpoint and any requests for specific functionality, depending on what information the Service Provider considers useful, but no additional information is required from the customer. 🛍️
The Service Provider performs any necessary provisioning actions on their equipment, and returns to the customer provisioning information, which may include a domain name or a numeric domain identifier for the provider, a user identifier, and a password. Typically, a Service Provider will supply provisioning information for each device to be provisioned, but may choose to supply information that can be used with multiple devices, or for a limited duration or with other benefits and restrictions. 🎁
The customer enters the provisioning information into the UA to be configured, whereupon the UA uses this information to locate the configuration service, securely fetch the configuration information, and configure itself for operation. 🎉
1.3.2. IP-PBX Example
Configuring a new UA in a typical business begins by provisioning a user identity in the Private Branch Exchange (PBX) (add user "John Smith"), and assigning a phone number to the user. That number must then be assigned to a line on a specific UA; this is usually done by selecting a UA and provisioning it in the PBX by its serial number (usually a Media Access Control (MAC) address), and then assigning the identity or phone number to a 'line' on that UA in the PBX configuration system. 🏢
Once provisioning in the PBX is complete, the new user goes to his or her workplace and connects the UA to the network. When connected and powered up, the UA is provided with the user identity, phone number, and any other configuration data with no local user interaction -- just connecting it to the network loads the configuration from the PBX and the UA is operational. 🌟
Part 1 of 6 is done, bestie! 🧚 Part 2 is coming up next, so stay tuned 💜
1.3.3. Special Considerations for High Security Deployments ✨
okay so, deploying a new UA in a high security scenario is a whole vibe 🔐 It takes some extra care, bestie. A security-conscious deployment will most likely need the SIP and other management interfaces, including the interface to the configuration service, to be secured before the device goes live 💅
To get any level of security, the device needs to be pre-configured with some security-related information in the form of certificates 📜 There are a few ways to make that happen. Some examples include:
- An administrator who configures the device in a secure environment before making the device available to the user.
- Some certificates may be built into the device during the manufacturing process, enabling the configuration service to certify information such as the manufacturer, UA type, and MAC address. The configuration service may then be used to provision the device with other certificates as required 🏭
- The device may have a facility for the user to provide the security information in the form of a security card or dongle 🔑
ngl, all of these mechanisms are likely to restrict the user to a limited set of devices approved for use in a particular deployment. Very exclusive, very secure 🫶
2. Obtaining User Agent Configuration 🎀
okay this section is the main event! 🦋 It explains how a User Agent connects to the network, figures out which domain to ask for configuration, gets that configuration from the domain, and gets notified by that domain when the configuration changes. Iconic behaviour, honestly 👑
The User Agent MAY obtain configuration information by any means in addition to those specified here, and MAY use such information in preference to any of the steps specified below. BUT it MUST be capable of using these procedures alone in order to be compliant with this specification. So the standard steps have to work on their own, no matter what else is going on 💜
2.1. Network Discovery 🌐
A UA needs a minimum set of parameters to communicate on the network. Some networks let the UA discover these parameters automatically, while other networks need some or all of them to be manually provisioned on the UA. Different vibes depending on the network! ✨
2.1.1. Link Layer Provisioning
The UA SHOULD attempt to use Link Layer Discovery Protocol - Media Endpoint Discovery (LLDP-MED; see [ANSI.TIA-1057-2006]) for automatic provisioning of link layer parameters 🔌
In some deployments, failing to properly provision the link layer may result in the UA having the wrong Layer 2 priority, which degrades the quality of service. It could also leave the UA on the wrong virtual LAN (VLAN), possibly resulting in complete loss of service. Not a good look 💀
2.1.2. Network Layer Provisioning
In order to communicate using IP, the UA needs the following minimal IP configuration parameters:
IP Network Parameters
- UA IP Address
- Subnet Mask
- Gateway IP address
- DNS Server IP address(es)
With the exception of a Soft UA that relies on its platform to obtain the IP Network Parameters:
- If the User Agent is using IP version 4 on a network technology for which the Dynamic Host Configuration Protocol (DHCP) [RFC2131] is defined, the UA MUST attempt to obtain the IP Network Parameters using DHCP and MUST request DHCP options 141 (see Section 4.1) and 15 [RFC2132]. If the DHCP service provides a value for option 141, the domain name(s) it provides MUST be saved as candidates for use as the Local Network Domain (see Section 2.2, "Obtaining the Configuration Service Domain"). If and only if no values are returned for option 141, the UA MUST save any values returned for option 15 for use as the Local Network Domain 📡
- If the User Agent is using IP version 6 on a network technology for which the Dynamic Host Configuration Protocol version 6 (DHCPv6) [RFC3315] is defined, the UA MAY use any standard IPv6 mechanism to determine the IP Network Parameters, but MUST request DHCPv6 options 58 (see Section 4.2) and 21 [RFC3319]. If the DHCPv6 service provides a value for option 58, those domain names MUST be saved as candidates for use as the Local Network Domain (see Section 2.2, "Obtaining the Configuration Service Domain"). If and only if no values are returned for option 58, the UA MUST save any values returned for option 21 for use as the Local Network Domain 🌸
2.2. Obtaining the Configuration Service Domain 🗺️
To get a configuration, the UA needs to know which domain to request it from. This domain is the Configuration Service Domain, and its value is a DNS name (see [RFC1034]) 🧚
User control or prior configuration MAY establish a value for the Configuration Service Domain that takes precedence over the discovery procedure defined below. Otherwise, in the absence of user control or prior configuration, candidate values for the Configuration Service Domain are obtained as specified in Section 2.2.1, "The Local Network Domain". If that doesn't work out, the UA falls back to the manual mechanism specified in Section 2.2.2, "Manual Domain Name Entry" 🍓
2.2.1. The Local Network Domain
The UA MUST attempt to use each value obtained for the Local Network Domain name (see Section 2.1.2, "Network Layer Provisioning") as the Configuration Service Domain. If multiple names are provided by DHCP and/or DHCPv6, the UA MUST attempt to use each of the names provided until a configuration is successfully obtained. (Multiple names may come back from these services if both are in use, if the UA has multiple network interfaces, or if the option responses have multiple values. Lots of possibilities, bestie 🙈)
The order in which values obtained in different responses are used is not defined by this specification -- the UA MAY use any order. However, multiple values returned within a single response MUST be tried in the order they were provided in that response 🔁
If the DHCP service does not provide any local domain name values, the UA SHOULD use the manual mechanism defined in Section 2.2.2, "Manual Domain Name Entry" 🙏
2.2.2. Manual Domain Name Entry
A UA MAY provide an interface by which a DNS name is supplied directly by the user for the Configuration Service Name ⌨️
2.3. Constructing the Configuration Request URL 🔗
Using the Configuration Service Domain name obtained in Section 2.2, "Obtaining the Configuration Service Domain", the UA MUST construct an HTTPS URL [RFC2818] to request configuration with. Building this URL happens in two parts:
- Section 2.3.1, "Obtaining a Configuration Service Base URL"
- Section 2.3.2, "Adding Configuration Request Parameters"
2.3.1. Obtaining a Configuration Service Base URL
The Configuration Service Domain gets resolved to one or more URLs using the URI-enabled Naming Authority Pointer (U-NAPTR) DDDS application defined in "Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)" [RFC4848] 🧭
The lookup key for the U-NAPTR request is the Configuration Service Domain name determined in Section 2.2, "Obtaining the Configuration Service Domain". The UA MUST make a DNS request for NAPTR records for that domain name. From the returned records, the UA MUST select those whose Service field value is "SFUA.CFG". From those records, the UA MUST extract the HTTPS URL of the Configuration Service from the Regular Expression field (see the next paragraph for how that field value is constructed) 🎯
The NAPTR records for the Configuration Service Domain name whose Service field value is "SFUA.CFG" MUST be configured with the Flag field set to "U", an empty Substitution field, and a Regular Expression field value of the following syntax (i.e., a regular expression to replace the domain name with an https URI):
u-naptr-regexp = "!.*!" <URI> "!"where <URI> is as defined in STD 66 [RFC3986], the URI syntax specification, and where the scheme of the URI is "https" 🔒
Note that the UA does not need to implement a general regular expression evaluator in order to process the record above correctly. 🎉 The URI value can be extracted by stripping the fixed value !^.*! from the beginning of the value, and ! from the end of the value, to obtain the base URL. See Section 2.3.3, "Configuration Request URI Example" 💖
2.3.1.1. Configuration Service Redundancy
Multiple Configuration Servers can be used to provide redundancy and additional capacity for provisioning User Agents. If the DNS NAPTR request for the Configuration Service Domain name returns multiple records with the 'SFUA.CFG' service tag, then the UA should treat the resulting URLs as alternatives, ordered according to the rules for the priority and weight as specified for NAPTR records. Backup plans, periodt 🛟
In addition to redundancy provided by multiple NAPTR records, resolving the host part of the HTTPS URL can produce multiple results too ✨
2.3.1.2. Configuration Service Name to Base URL Resolution Failure
If the DNS request to resolve the Configuration Service Domain name to a request URL does not receive any response, the UA should follow standard DNS retry procedures 🔄
If the DNS request to resolve the Configuration Service Domain name to a host name returns a response that indicates no matching result is available (NXDOMAIN), the UA SHOULD attempt to obtain another Configuration Service Domain name using the procedures in Section 2.2, "Obtaining the Configuration Service Domain". No match? Try a different domain, no cap 🥲
2.3.2. Adding Configuration Request Parameters
To construct the full configuration request URL, the UA adds one or more parameters to the base URLs to specify what configuration it's asking for 📝
- The UA MUST add all parameters from those defined in the Configuration Request Parameters list below for which the UA has a value. Any parameter from that set for which the UA does not have a value MUST be omitted.
- The query parameter names defined by this specification all begin with the prefix
sfua-. All names beginning with the prefixsfua-are reserved for this specification and future revisions. The UA MUST NOT include any request parameter whose name begins with the prefixsfua-that is not defined by this specification (including any future revisions). Hands off the reserved prefix, bestie 🚫 - Any parameter not defined by the specification is allowed, but MUST be ignored by any Configuration Service that does not recognize it. Unknown params just get ignored, lowkey iconic 🫧
2.3.2.1. Configuration Request Parameters 💅
Okay bestie, here are the parameters the configuration request can carry. Section 4.4 sets up an IANA registry for these, plus any parameters defined in the future 🗂️
sfua-id
This is the URN that identifies the User Agent. It's built the way Section 4.1 of [RFC5626] "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)" describes 🆔
Since the [RFC5626] procedure lets any UA make up a value for this, the sfua-id parameter MUST always be included. No skipping it, periodt ✨
If the UA implements [RFC5626] and includes the '+sip.instance' Contact header field parameter in any request, then when it requests configuration it MUST use the same value for sfua-id. Consistency is everything 🫶
sfua-user
This is an identifier for a user tied to the configuration. Here's the tea: it might be different from any SIP 'user' in the UA configuration. It could be, for example, the login name of an account on the service provider's website 👀 The syntax is that of the 'userid' [RFC2617].
For how this parameter connects to authentication of the configuration data request, see Section 2.4.1, "Configuration Data Request Authentication" 🔐
sfua-vendor
This identifies the vendor of the User Agent. The syntax of the value is that of a DNS domain. The domain value MUST be a domain owned by the vendor. No borrowing other companies' domains, iykyk 🏢
sfua-model
This further narrows down the User Agent from among the ones the vendor makes. The syntax is the same as the 'token' [RFC3261]. The vendor picks the values for this one 🧚
sfua-revision
This is also an identifier that further narrows down the User Agent from among the ones the vendor makes. The syntax is the same as the 'token' [RFC3261], and the vendor selects the values 🍓
2.3.3. Configuration Request URI Example 🦋
Using the rules in Section 2.2, "Obtaining the Configuration Service Domain", the UA worked out that the Configuration Service Domain is "example.net". To get the base URL, the UA builds a DNS NAPTR request for "example.net.", which gives back these records:
NAPTR 10 10 "u" "SFUA.CFG" "!^.*$!https://p1.example.net/cfg!" ""
NAPTR 100 10 "u" "SFUA.CFG" "!^.*$!https://p2.example.net/cfg!" ""
NAPTR 90 50 "s" "SIP+D2T" "" _sip._tcp.example.net.
NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.example.net.Figure 1: Example Configuration Service NAPTR Query Results
The records with the service-field "SFUA.CFG" each give you a base URL value for SIP UA configuration requests. Main character records 📜
Our hypothetical example communications device is a 'HypoComm' version 2.1, made by ExampleCorp, and it has the link layer MAC address 00:11:22:33:44:55. It doesn't know any user identity to request configuration for, so it builds its query parameters from the values it does have. Then it combines each one with the base URL to make these request URLs (lines wrapped for readability) 🌸
https://p1.example.net/cfg
?sfua-id=urn:uuid:00000000-0000-1000-8000-001122334455
&sfua-vendor=examplecorp.com
&sfua-model=HypoComm
&sfua-revision=2.1
https://p2.example.net/cfg
?sfua-id=urn:uuid:00000000-0000-1000-8000-001122334455
&sfua-vendor=examplecorp.com
&sfua-model=HypoComm
&sfua-revision=2.1Figure 2: Example Configuration Request URLs
2.4. Obtaining Configuration from the Configuration Service 🎀
To request configuration with a URL built the way Section 2.3, "Constructing the Configuration Request URL" describes, the User Agent MUST do an HTTPS GET request to each of the URLs. It keeps going until one of the requests gets back a configuration the UA can actually use 🔁
A successful final response from the Configuration Service to a GET request for configuration data MUST contain the configuration data for the UA in the HTTP response body. Also, the CS has the full HTTP toolkit from [RFC2616] at its disposal, so it can use things like redirection as part of how it delivers configuration data. Smart 🧠
Configuration data in a successful response can change whenever the CS wants. The HTTP cache control metadata, meaning the max-age value from any Cache-Control header plus the Etag and Last-Modified header values from the response that provides the data, is what tells the UA when a change has happened (Section 2.5.1.3, "Configuration Change Notices") and how to check stored configuration data (Section 2.6, "Validity of Stored Configuration Data") ⏰
- An HTTP response from the CS that provides configuration data MUST include cache control metadata that's good enough to make sure that when a new configuration is available, its cache control information is different. No sneaky identical metadata 🙅♀️
- The UA MUST keep all of the HTTP cache control metadata from any response that provides configuration data. Hold onto it 💾
2.4.1. Configuration Data Request Authentication 🔐
Since the Configuration Request URL scheme is HTTPS, the UA MUST always use Transport Layer Security (TLS) [RFC5246] to set up a connection with the Configuration Service. Always. Non-negotiable 🔒
The UA MUST provide a server_name extension in the TLS Client Hello message, as defined in [RFC4366] "Transport Layer Security (TLS) Extensions". Its value is the Configuration Service Domain name. (This might not be the same as the host part of the CS base URL, so don't mix them up 🙃) This lets the CS figure out who you're asking for and hand over a server certificate with the right identity, so one server can serve lots of domain names 🏠
A UA MUST attempt to validate the server certificate the CS provides, following the rules in Section 3.1 of [RFC2818]. Unfortunately, validation can fail. For example, the UA might not have a trusted root CA cert in its firmware that the CS certificate chain can connect to, or the root CA cert might have expired since the UA firmware was last updated 😩 If the UA can't validate the server certificate, it SHOULD store that certificate and alert the user if that CS host ever gives a different certificate later. Yes, 'trust on first use' isn't as secure as real validation, but it still gives some protection against man-in-the-middle (MITM) attacks down the road 🕵️♀️
If it has one, the UA MUST provide a client certificate. The CS MUST validate the UA's client certificate if one is provided. If the CS can't authenticate the certificate from the UA (say the UA is using a self-signed certificate), the CS MAY choose to cache that certificate, as long as the UA successfully authenticates with HTTP authentication (see the next paragraph). This lets a CS treat the digest authentication credentials as a single-use password for authenticating the client certificate. It's the same 'trust on first use' idea, and it protects against future MITM attacks as long as the first conversation wasn't compromised 🔑
If the CS requires HTTP authentication for the configuration data request, the HTTP 'username' parameter MUST be the same value as the sfua-user value provided in the configuration data request parameters. The UA MUST implement both Basic and Digest authentication as specified by [RFC2617]. Both, no exceptions 💜
2.4.2. Configuration Data Request Failure 🙈
The HTTP configuration data request can fail in a bunch of ways, so here's how each one gets handled:
- If a DNS request to resolve the host name in the request URL comes back with NXDOMAIN, meaning no matching result is available, the UA MUST remove that request URL from the list of alternatives for the Configuration Service Domain. Gone 🗑️
- If the attempt to open a TCP connection to the host in the request URL fails, the UA MAY try requests to any alternative URLs for the same configuration service without waiting between alternatives. But any requests to the same host MUST wait between requests, following the procedure in Section 2.7, "Retry Backoff Procedure" ⏳
- If the TCP connection succeeds but the TLS handshake fails, including when the UA can't validate the certificate from the Configuration Service host (if the UA is able to validate at all), the UA MUST remove the failed URL from the list of alternative URLs for this Configuration Service Domain. Bye bye 👋
- If the request gets a permanent HTTP failure response (response code
>= 400, with noRetry-Afterheader field), the UA MUST remove the failed URL from the list of alternatives for this Configuration Service Domain. Not coming back 💀 - If the list of alternatives for this Configuration Service Domain ends up empty, the UA MUST try to get another Configuration Service Domain name using the procedures in Section 2.2, "Obtaining the Configuration Service Domain" 🔄
- If the UA has hit its chosen maximum number of retries (this specification doesn't set a maximum number of retries, but any retries to the same host MUST follow the procedure in Section 2.7, "Retry Backoff Procedure"), the UA MAY try to get another Configuration Domain name using the procedures in Section 2.2, "Obtaining the Configuration Service Domain" 🫠
2.5. Configuration Changes 💜
The configuration data the CS provides can change, and this specification gives the UA two ways to find out a change is available:
- SIP subscription by the UA to the CS, so the UA gets notified about changes to the configuration data. 📣
- HTTP polling by the UA of the configuration data URL at the CS. 🔍
The Configuration Service picks the mechanism and signals it to the UA in each HTTP response that provides configuration data. In such a response, the CS MUST either:
- Tell the UA to subscribe for change notifications by including a Link header in the response with the link relation
'monitor'and a SIP URI. This choice is specified in Section 2.5.1, "Configuration Change Subscriptions" 🔔 - Tell the UA to poll for updates using HTTP by not including a Link header with the link relation
'monitor'. This choice is specified in Section 2.5.2, "Configuration Change Polling" 🔁
A User Agent MUST support both mechanisms, and it uses whichever one the Configuration Service indicates. Flexible queen 👑
2.5.1. Configuration Change Subscriptions 💌
okay so if the CS wants to use the SIP subscription mechanism, it MUST include a Link header in the HTTP configuration data response, as specified by [RFC5989] 🦋. The URI in that Link header MUST be a SIP URI, and the link relation (rel) value MUST be monitor. The monitor-group relation MUST NOT be used. Multi-resource monitoring has its own rules, which we'll get to below 👀. The SIP URI in the Link header is the "configuration change subscription URI" 📬.
A UA that gets a successful configuration data response with a Link header that specifies a monitor relation MUST attempt to maintain a subscription to the SIP URI from that header, for the http-monitor event package. This subscription is called a "configuration change subscription" 💜.
The CS MUST accept properly authenticated SUBSCRIBE requests from the UA for the http-monitor event package at the URI it gave in the Link header of a configuration data response. The authentication of the SUBSCRIBE request uses any standard SIP authentication mechanism, with credentials the UA was given in the configuration data 🔐.
Configuration data MAY include references in the form of additional URLs at the CS, and the UA MUST use those to get additional data 🌸. Any response to requests for these additional URLs that provides configuration data MUST provide cache control data and a configuration change subscription URI. The CS MAY return a unique configuration change subscription URI for each configuration data request, or MAY return the same SIP URI for different requests. Either way works, as long as a change to the configuration data returned in any of these requests results in a notification on all subscriptions to the associated subscription URI ✨.
If the CS returns a unique configuration change subscription URI in the Link header of different configuration data requests:
- The UA MUST maintain multiple subscriptions, one to each URI associated with configuration data the UA is using.
If the CS returns the same configuration change subscription URI in the Link header of different configuration data requests:
- The UA is not required to create multiple subscriptions to the same URI.
- The UA MUST associate the URI with each of the configuration data requests for which it was returned. Any
NOTIFYor other change in the status of that subscription affects the validity of all of the associated configuration data. - The CS MUST send a
NOTIFYmessage on the configuration change subscription when there is a change to any of the different configuration data resources for which the subscription URI was returned 🧚.
2.5.1.1. Change Subscription Failure
If a configuration change SUBSCRIBE request (either the initial request or any attempt to refresh the subscription) is permanently rejected by the Configuration Service, the UA MUST consider the associated configuration data to be not valid 💀. "Permanently rejected" means the CS returns a failure response that is not an authentication challenge or a redirection, and that does not specify a Retry-After header. The UA then MUST attempt to revalidate the data as specified in Section 2.6.1, "Re-Validating Configuration Data". The CS isn't allowed to reject a properly authenticated request, so this points to a problem with either the configuration data or the CS 🙈.
If a configuration change SUBSCRIBE request (either the initial request or any attempt to refresh the subscription) fails in any way other than being permanently rejected, the UA MUST consider the associated configuration data to be of unknown validity. It MUST retry the SUBSCRIBE request as specified in Section 2.7, "Retry Backoff Procedure". The maximum time between retries MUST NOT be more than 30 minutes, and the retries MUST continue as long as the configuration is used ⏰. The UA MAY at any time return to any earlier step in the process of obtaining configuration data 🔁.
2.5.1.2. Change Subscription Termination
If the CS explicitly terminates the configuration change (http-monitor) subscription by sending a NOTIFY message with a Subscription-State header value of terminated, the UA MUST consider the configuration data to be of unknown validity 😭. If the rules for interpreting and acting on the reason code parameter, as specified in Section 3.2.4 of [RFC3265], allow it, the UA MUST attempt to re-establish the subscription. If those rules do not allow the UA to re-subscribe, then the UA MUST consider the data to be not valid and attempt to revalidate it as specified in Section 2.6.1, "Re-Validating Configuration Data". The UA MAY at any time return to any earlier step in the process of obtaining configuration data 🌈.
2.5.1.3. Configuration Change Notices
To tell the UA about a configuration data change, the CS MUST send a NOTIFY message to the UA in the configuration change subscription the UA set up, as detailed in Section 2.5.1, "Configuration Change Subscriptions" 📣.
The CS MUST NOT send unsolicited (out-of-dialog) NOTIFY messages. Not allowed, bestie 🙅♀️.
As specified in [RFC5989], the body of a NOTIFY message in the http-monitor event package is the HTTP headers that would have been returned in response to an HTTP HEAD request. A HEAD request returns the headers that would have come back for a GET request to the same URI, just with no body 🎀.
When the UA receives a NOTIFY message in the configuration change subscription, the UA MUST compare the cache control data it kept when it received the configuration data with the HTTP header values in the body of the NOTIFY message. If any of the cache control data in the HTTP header values differs from the data in the original configuration data response, the UA MUST consider the stored configuration data to be no longer valid. As soon as reasonably possible after the UA finds out the data is no longer valid, the UA MUST attempt a GET request to the HTTPS configuration request URL that provided the configuration data, to get the changed configuration data 🛠️.
If this HTTPS request to the URL that previously provided the configuration data fails, the UA MUST attempt to obtain a new URL as specified in Section 2.3, "Constructing the Configuration Request URL" 🗺️.
2.5.2. Configuration Change Polling 🔄
If the CS chooses to use the HTTP polling mechanism, it MUST NOT include a Link header with the relation monitor in the HTTP configuration data response. It MUST include a Cache-Control header that specifies the max-age directive ⏳. The max-age cache control directive in HTTP gives the maximum number of seconds the returned data may be cached. This specification defines that time as the maximum time the configuration data is considered valid.
A short time before the validity time has passed, the UA SHOULD poll to revalidate the configuration data, as described in Section 2.6.1, "Re-Validating Configuration Data" 🥰.
2.6. Validity of Stored Configuration Data 🧾
Configuration data stored by a UA is considered valid in these cases:
- If the CS chose to use the subscription mechanism to deliver change notices, and the UA has a subscription to the CS as described in Section 2.5.1, "Configuration Change Subscriptions", on which no
NOTIFYmessage from the CS indicating that the configuration data has changed has been received. - If the CS chose to use the HTTP polling method, and the number of seconds since the configuration data response was received is less than the time specified by the
Cache-Controlmax-agedirective in that response.
When a UA initializes itself at any time other than immediately after receiving new configuration data, it MUST consider any stored configuration data to be of unknown validity 🌙.
The UA MAY use configuration data that is of unknown validity, or configuration data that is known to be no longer valid, while it tries to revalidate that data or get new data. There is no assurance that such configuration data is still useful, but the UA MAY choose to keep the data and keep using it 🫶.
2.6.1. Re-Validating Configuration Data
To revalidate stored configuration data of unknown validity, the UA MUST repeat the HTTPS GET request it used to obtain the stored configuration data. It has to include the appropriate HTTP headers to make the request a conditional request, using the cache control data returned in the response that provided the configuration data 🔍. This lets the CS respond either with a new configuration data response, or with a 304 (Not Modified) response to say the configuration data has not changed.
If the CS responds with a 304 response, and the original response included a Link header with the monitor relation, the SIP UA MUST assume that the value of that Link header is still correct. In effect, the HTTP cache control values and the subscription URL are part of the configuration data 💅. So the UA MUST attempt to create and maintain a subscription to that URL, just like when the configuration data was first obtained (Section 2.5.1, "Configuration Change Subscriptions").
If the CS chooses to use the HTTP polling method, then any 304 response MUST include a Cache-Control header containing a max-age directive. The UA MUST use this new value as the maximum validity time for the associated configuration data ⭐.
If the HTTP request to revalidate the configuration fails, the UA MUST follow the procedures defined for a failure of the initial HTTP configuration data request, as specified in Section 2.4.2, "Configuration Data Request Failure" 💀.
2.7. Retry Backoff Procedure ⏳
In the case of certain possible failures described above, the right move is to retry the failed operation. In all of these retry cases, the following rules apply:
- The UA SHOULD retry at least 5 times before abandoning the failed step, except as allowed for in the specific error handling rules above.
- After the first instance of a given failure, the UA MUST select an initial backoff timer value randomly between 2 and 8, inclusive. It waits this number of seconds before retrying the failed request 🎲.
- After any subsequent instance of a given failure, the UA MUST increase the backoff timer value by 2 raised to the power of the number of preceding failures (
2^N, whereNis the number of previous failures). It then waits this increased number of seconds, or the maximum interval specified by the specific error handling procedures, whichever is less, before retrying the failed request 📈.
For example, after an initial failure, the UA randomly picks an initial backoff timer value of 4 seconds. Then it retries at these times: 6 seconds (4 + 2^1), 10 seconds (6 + 2^2), 18 seconds (10 + 2^3), 34 seconds (18 + 2^4), and 66 seconds (34 + 2^5) 🍓.
3. Configuration Data 🎀
This document does not specify the form or content of configuration data. As such, the contents of this section are non-normative 🌸.
3.1. Configuration Data Items 📋
The configuration data for a SIP UA should, at minimum, include items with the following semantics.
3.1.1. Address-of-Record
The Address-of-Record (AOR) is a SIP or SIPS URI that identifies the user of the device, as specified in [RFC3261] 🪪.
3.1.2. Realm
The realm is used to populate the realm parameter in the SIP Proxy-Authorization header, as specified in [RFC3261], when the UA receives an authentication challenge 🛡️.
3.1.3. Username 🎀
okay so the username is what fills in the username parameter in the SIP Proxy-Authorization header, as laid out in [RFC3261], whenever the UA gets hit with an authentication challenge 🔐 it's giving security guard checking your ID at the door 💅
3.1.4. Digest 💖
the digest is a string holding the digest of the username, realm, and password, as specified in [RFC2617] 🧁 the UA uses it to generate a response to an authentication challenge, as specified in [RFC3261]. literally the secret sauce 🤫✨
3.1.5. OutboundProxy 🦋
the OutboundProxy, if one is defined, holds the default outbound proxy. SIP requests that aren't explicitly routed get sent through it, as specified in [RFC3261] 🚀 it's the default door everything walks out of, bestie 🌈
3.2. Reset User Agent to Default Configuration 🧹
okay so the earlier sections of this doc explain how a UA can get auto-provisioned 🤖 but some User Agents let a user set their own stuff, like a Contact Directory, custom ringtones, and so on, and that stuff might get saved locally on the UA 🎶 here's the tea: since a UA might need to be re-assigned later, people designing configuration data formats may want explicit controls for those local settings. that includes being able to explicitly delete them so the UA goes back to a completely unconfigured state 🧼 main character reset energy, iykyk 💅
4. IANA Considerations 🌸
4.1. DHCP SIP User Agent Configuration Service Domains Option 🍓
this spec defines DHCP option code 141, the "SIP UA Configuration Service Domains", for the IANA registry "BOOTP Vendor Extensions and DHCP Options" defined by [RFC2939] 📋
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 141 | Len | Searchstring... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Searchstring... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+in that diagram, Searchstring is a string that specifies the searchlist 🔍 if the searchlist is longer than what one option can hold (255 octets), then multiple options MAY be used, as described in [RFC3396] "Encoding Long DHCP Options in the Dynamic Host Configuration Protocol (DHCPv4)" 📦
so to make the searchlist super compact, the searchstrings in it MUST be concatenated and encoded using the technique in Section 4.1.4 of [RFC1035], "Domain Names - Implementation and Specification" ✨ the trick is that an entire domain name, or a list of labels at the end of one, gets swapped out for a pointer to an earlier copy of the same name 🧠 it's a bit extra, ngl, but it's worth it, because DHCP option space is tight and a domain searchstring is super likely to repeat the same domain name over and over 🙈 so DNS name compression is both useful and likely to actually work well 💜
for this spec, the pointer refers to the offset inside the data portion of the DHCP option. the option code byte and the option length byte don't count 🧮
if there are multiple SIP UA Configuration Service Domains options, the data portions of all of them get concatenated together as specified in RFC 3396, and the pointer is an offset into that whole combined block of data 🧩
for examples of how to encode this option, check out Section 3 of [RFC3397], "Dynamic Host Configuration Protocol (DHCP) Domain Search Option", which uses the same encoding for option 119 🎀
4.2. DHCPv6 SIP User Agent Configuration Service Domains Option 🧚
this spec defines DHCPv6 option code 58, OPTION_SIP_UA_CS_LIST, for the IANA registry "Dynamic Host Configuration Protocol for IPv6 (DHCPv6), DHCP Option Codes" defined by RFC 3315 🌐
the format of the SIP User Agent Configuration Service Domains option looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_SIP_UA_CS_LIST | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| searchlist |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+here's the breakdown:
option-code:OPTION_SIP_UA_CS_LIST(58) 🔢option-len: the length of thesearchlistfield, in octets 📏searchlist: the list of domain names in the SIP User Agent Configuration Service Domains 🗂️
the domain names in the searchlist MUST be encoded as specified in Section 8, "Representation and Use of Domain Names" of RFC 3315 🫶
4.3. U-NAPTR Registration 🦋
this doc registers the following U-NAPTR application service tag in the registry defined by [RFC3958], "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)" 📝
+-------------------------+----------+
| Application Service Tag | SFUA.CFG |
+-------------------------+----------+this tag is used to get the base URL of the Configuration Service from the DNS name of a SIP domain, as specified in Section 2.3.1, "Obtaining a Configuration Service Base URL" 🔗✨
4.4. SIP Forum User Agent Configuration Parameter Registry 💅
IANA has set up a registry for "SIP Forum User Agent Configuration Parameters" 🗃️ it records the HTTPS request parameters for the initial configuration data request that a User Agent sends to a Configuration Service, as described in Section 2.3.2, "Adding Configuration Request Parameters" 🌸
each entry in the registry must include a Parameter Name and a Description that specifies the value syntax and usage of the parameter:
- Parameter Name: the name of the parameter. it MUST match the ABNF production for 'token' from [RFC3261] 🏷️
- Value Syntax: the syntax of the value, if there is one (a parameter can just be a name with no value attached) 🔤
- Usage: the purpose the parameter serves, including any default method the UA should use to construct it, if that applies 🛠️
the initial values for the registry are the parameters described in Section 2.3.2.1, "Configuration Request Parameters" 🌟 and the policy for adding future entries depends on the parameter name:
- if the name of the parameter begins with the characters 'sfua-' in any case, the policy for adding it to the registry is "RFC Required", as described by [RFC5226] 🔒
- any other parameter entry may be added using a "First Come First Served" policy, as described by [RFC5226] 🙌
5. Security Considerations 💀
okay this section is serious, bestie, so pay attention 🚨 initial discovery of the Configuration Service Domain name relies on a bunch of operations that are normally unsecured. a DHCP response could be supplied by an attacker to replace the values of any of the IP Network Parameters (Section 2.1.2, "Network Layer Provisioning"), including the Local Network Domain, which is the default choice for the Configuration Service Domain name 😱 a human user confirming the Configuration Service Domain name could help mitigate this (perhaps unintentional) potential reconfiguration, especially when it's different from a value used before 🧐 and note that previously loaded configuration MAY constrain which parts of the discovery and location procedures get used. for example, the Configuration Service Domain name might be fixed so that discovery can't change it 🔐
the connection to the Configuration Service is made over TLS. as the TLS server, the CS always provides a server certificate during the TLS handshake 🤝 if possible, the UA should validate that certificate and confirm it contains, as a subject, either the Configuration Service Domain name or at least the host name from the Configuration Service Base URL (see [RFC2818]) ✅ it may not be possible to have the info needed for a full validation of the CS server certificate before the first configuration. for example, the UA might not have a current CA certificate for the CA that signs the CS server certificate 🥲 so implementors are advised to put that info in configuration data, so it can be used for later reconfigurations. this narrows the window of vulnerability to the first configuration attempt 🪟
to secure initial configuration attempts, the CS can deny requests from unknown devices, and/or it could implement other measures, like restricting the time window during which it will accept an initial configuration request from a given device ⏰ a more secure approach would be giving the user a password, maybe a one-time password that's only valid for the initial access 🔑 in high security environments, the Configuration Service could require the User Agent to provide a client certificate for authentication in the TLS connection for configuration data requests 🛡️ this would need some prior manual configuration of the User Agent, and possibly the Configuration Service, and that configuration should also include enough info for the UA to fully validate the CS certificate 📋
the values of some or all of the request parameters the UA sends on the initial request for configuration data (see Section 2.3.2, "Adding Configuration Request Parameters") may be sensitive information 👀 since that request is made over a TLS connection, the confidentiality of that info is protected on the network. Configuration Service implementations should take all necessary measures to make sure the request parameter data is properly protected within the CS itself 🔒
the Configuration Change Request Subscription (Section 2.5.1, "Configuration Change Subscriptions") is only set up after the UA has loaded the configuration data, so all the security mechanisms available in SIP (including request digest authentication and the use of TLS) can be configured and required by either the CS or the UA 💪 also, a configuration change notice doesn't actually provide any new configuration data, and it can't change where the UA sends a request for new configuration data either. this means an attacker can't reconfigure a UA by messing with only the change notice subscription. the most they can do is trigger checks for new data 🙃 to actually modify the configuration data itself, the attacker would have to subvert the CS or the steps that lead to CS discovery (subject to the checks described above) 🕵️♀️
implementations of TLS typically support multiple versions of the Transport Layer Security protocol, as well as the older Secure Sockets Layer (SSL) protocol. because of known security vulnerabilities, SIP UAs, SIP Service Provider, and the Configuration Service Host MUST NOT request, offer, or use SSL 2.0 🚫💀 see Appendix E.2 of [RFC5246] for further details 📚
6. Acknowledgements ✨
okay so bestie, this is the shoutout section and everyone on it earned it 🫶 These are the Contributing Members of the SIP Forum User Agent Configuration Working Group:
- Francois Audet, Nortel Networks, Inc.
- Eric Burger, SIP Forum
- Sumanth Channabasappa, Cable Television Laboratories, Inc. (CableLabs)
- Martin Dolly, AT&T Labs
- John Elwell, Siemens Enterprise Communications
- Marek Dutkiewicz, Polycom, Inc.
- Andy Hutton, Siemens Enterprise Communications
- Lincoln Lavoie, University of New Hampshire
- Scott Lawrence, Avaya, Inc.
- Paul Mossman, Avaya, Inc.
- Michael Procter, VoIP.co.uk
- Marc Robins, SIP Forum
- Henning Schulzrinne, Columbia University
- Rifaat Shekh-Yusef, Avaya, Inc.
- Robert Sparks, Tekelec
- Simo Veikkolainen, Nokia
The Editor would also like to acknowledge valuable contributions by Leslie Daigle and Margaret Wasserman 💜
7. Normative References 📚
these are the docs this spec leans on, so here's the full reading list, copied exactly as written 🎀
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition
of New DHCP Options and Message Types", BCP 43, RFC 2939,
September 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration
Protocol (DHCPv6) Options for Session Initiation Protocol
(SIP) Servers", RFC 3319, July 2003.
[RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the
Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396,
November 2002.
[RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration
Protocol (DHCP) Domain Search Option", RFC 3397,
November 2002.
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application
Service Location Using SRV RRs and the Dynamic Delegation
Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006.
[RFC4848] Daigle, L., "Domain-Based Application Service Location
Using URIs and the Dynamic Delegation Discovery Service
(DDDS)", RFC 4848, April 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5989] Roach, A., "A SIP Event Package for Subscribing to Changes
to an HTTP Resource", October 2010.
[ANSI.TIA-1057-2006]
American National Standards Institute, "Telecommunications
IP Telephony Infrastructure Link Layer Discovery Protocol
for Media Endpoint Devices", April 1993.Authors' Addresses 🦋
and last but not least, here's how to reach the people who wrote this thing 💅
Scott Lawrence (editor)
Linden Research, Inc.
EMail: scott-ietf@skrb.org
John Elwell
Siemens Enterprise Communications
Phone: +44 1908 817801
EMail: john.elwell@siemens-enterprise.com📦 where this page comes from
- ietf: rfc6011 2010-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms