Options for Conveying Location Information There are three dimensions that can be used to characterize approaches to conveying locations in SIP: insertion point, protocol element and by value vs. by reference. For the insertion point, two options are useful, namely the UAC and proxies along the call path. As protocol elements, location information can appear in SIP header fields and in SIP message bodies. Finally, location information can be 'by value', i.e., contain the location object directly or reference, via a URL, a remote location that contains the object. A number of combinations are possible. The insertion point does not affect the format of the object (by value or by reference) directly: Header Body UAC-inserted yes yes Proxy-inserted yes not allowed Header Body By value yes(*) yes (MIME multipart) By reference yes(*) yes(*) Yes(*) indicates that this is technically possible, but requires additional standardization work. Below, we evaluate the impact of each design decision. According to the SIP guidelines [ref], request header fields are primarily meant to guide request routing. Since location information is indeed used for call routing in applications considered here, this usage is appropriate. ** Efficiency For the location objects considered, the overhead for header fields and message body conveyance is roughly the same. The byte overhead for 'by value' is likely to be larger for the SIP message itself, as a referencing URL is likely to consume about 20-100 bytes, while the size of the location object depends on whether it contains geo and/or civic information and whether it is wrapped in an XML digital signature. (The size could increase by about 1/3 if the header field needs to be base64-encoded for some reason.) A typical location object containing basic geo plus floor information is likely to be around 700 bytes. However, overall efficiency for by-reference modalities is more difficult to compare, as zero or more proxy servers and the UAS may have to dereference the URL and retrieve the location object. This retrieval may also incur the costs of setting up a TCP and possibly TLS connection and the header overhead of the carrying protocol, such as HTTP. If we assume that the location server is close to the UAC and that the network path for the location query traverses roughly the same path as the SIP request, the cost of dereferencing the location pointer by the UAS would be the size of the location object, which is the same for both by-value and by-reference, plus the protocol overhead of the dereferencing protocol. If the first link between the UAC and the network is severely bandwidth constrained, inserting location information later in the call path or using a reference may reduce the cost of transmission or speed call signaling. ** Reliability The reliability of carrying information in SIP header fields or in the message body is roughly the same. It is possible that mis-behaving proxies remove headers. By-value transmission ensures that the call is never separated from location information, ensuring fate sharing. However, a proxy may not be able to decrypt a protected location object. By reference operation means that a proxy that needs location information for call routing may fail if it cannot dereference the information due to network failures between the proxy and the location server, due to NAT issues or authentication failures (if dereferencing the URL requires authentication). A related issue is object accessibility. Sometimes, the location object used for routing or other purposes needs to be accessible long after the call completes, e.g., for debugging routing problems. Systems using by-reference semantics need to capture all location objects used for routing, as there is no inherent lifetime for such external objects. ** Performance UAC-inserted location may increase delay if the access link is slow. For example, a 100 kb/s link would add about 50 ms of delay for conveying a 600-byte location object. By-reference adds the delay of dereferencing, including the round-trip time from the UAS or proxy to the location server and the connection setup delay. ** Security Both by-value and by-reference can provide integrity and confidentiality by protecting the signaling association, e.g., by SIP-over-TLS. The security model for by-value or by-reference differs somewhat. If by-value objects are not encrypted, any proxy that is on the call path may inspect the location object. (For call routing based on location, this may well be necessary for the system to function.) If by-value objects are encrypted, they would need to be encrypted with the public key of the recipient. If there are multiple recipients, these have to share a single private key or the sender has to include multiple objects, each encrypted with its own key. Conversely, by-reference systems can also use equivalent mechanisms. By providing a cryptographically-random identifier, they can provide access to any entity that can read the SIP header field or message body, similar to the unencrypted by-value scenario. By enforcing access authentication and authorization, location servers can restrict access to one or more authorized entities, thus allowing only a subset of proxies and UAS access to the information. Predicting who is authorized to access such information may not be easy, e.g., when call information is passed from a PSAP to a variety of first responders in the case of emergency calling. ** Backward-Compatibility Older UACs cannot create MIME multipart or insert new header fields, but can be assisted by proxies that insert either by-value or by-refereence header fields in the SIP request.