1. ECRIT Interim: SIP Location Conveyance
James Polk

2. SIP Location Conveyance Review
-02 is currently being edited, aim to cut ~30 pages
Plan to move all well-formed message examples to separate ID
Define “Conveyance” as “pushing”, not pulling also
Review Requirements
Grouped into UAC, UAS and Proxy
Introduce Location Header
For by-reference URI, cid (?), Option-tag, what else (need help with syntax!)
Introduce Location Option-tag
To be placed in Supported, Unsupported, Requires, and Proxy-Requires headers
Discuss Methods Location is used in
Introduce 424 (Bad Location) error
Will delete all mention of 425 (Retry Location)

3. Review Requirements
UAC-1 The SIP INVITE Method [RFC3261] MUST support Location Conveyance.
UAC-2 The SIP MESSAGE method [RFC3428] MUST support Location Conveyance.
UAC-3 SIP messages within a dialog SHOULD support Location Conveyance.
UAC-4 Other SIP Requests MAY support Location Conveyance.
Comments about
UAC1 –
UAC2 –
UAC3 –
UAC4 -

4. Review Requirements (cont’d)
UAC-5 Transmitted Location information SHOULD remain confidential e2e to the destination UAS (i.e. using S/MIME).
UAC-6 It MUST be possible for a UAC to update its location information prior to dialog establishment, and within a dialog.
Comments about
UAC5 –
UAC6 -

5. Review Requirements (cont’d)
UAC-7 The privacy and security rules established within [RFC3693] that would categorize SIP as a 'using protocol' MUST be met.
UAC-8 Location conveyance from endpoint UAC to endpoint UAS SHOULD be conveyed using a PIDF-LO [RFC4119] as the common, well understood location format
Comments about
UAC7 –
UAC8 -

6. Review Requirements (cont’d)
UAC-9 Location conveyance from endpoint UAC to endpoint UAS MAY be conveyed using a Location-by-Reference URI, pointing at a PIDF-LO (for the UAC).
UAC-10 Location conveyance using a Location-by-Reference URI, pointing at a PIDF-LO (for the UAC), MAY be in either a header or a message body (part)
Comments about
UAC9 –
UAC10 -

7. Review Requirements (cont’d)
UAC-11 There MUST be a means for publishing location state information for a particular presentity to a Presence Compositor Server.
UAC-12 If the initial SIP message containing Location had security properties (encryption, authentication, etc), and fails as the result of a non-response timeout or error response, the subsequent message to the same destination SHOULD be sent without those security properties.
Comments about
UAC11 –
UAC12 -

8. Review Requirements (cont’d)
UAC-13 A UAC MAY choose to send an initial message containing a PIDF-LO in cleartext if it is configured to understand this message is emergency services related (knowing a SIP proxy will need to route the message based on the viewable location information). This requirement is orthogonal to using TLS or IPSec between the UAC and Proxy.
UAC-14 It MUST be possible to provide a privacy mechanism (that does not violate the other requirements within this document) to a user within a jurisdiction that gives that user the right to choose not to reveal their location even when contacting an PSAP during an emergency.
Comments about
UAC13 –
UAC14 -

9. Review Requirements (cont’d)
UAC-15 For a PSAP UAS that received an emergency call. A call transfer between response centers MUST NOT be considered a violation of the distribution privacy attribute contained within this location object of the call taken.
UAC-16 The UA must provide the actual location of the endpoint, and not location which might have been erroneously given to it by, e.g. a VPN tunnel DHCP server.
Comments about
UAC15 –
UAC16 -

10. Review Requirements (cont’d)
UAS-1 SIP responses to requests containing location MUST support Location Conveyance (i.e. a 200 OK to an INVITE containing location).
UAS-2 Transmitted Location information SHOULD remain confidential e2e to the destination UAC (i.e. using S/MIME).
UAS-3 Transmitted Location information MAY not be confidential e2e to the destination UAC if the UAS received location in the request message in cleartext (i.e. meaning S/MIME was not used).
Comments about
UAS1 –
UAS2 –
UAS3 -

11. Review Requirements (cont’d)
UAS-4 Location conveyance from endpoint UAS to endpoint UAC SHOULD be conveyed using a PIDF-LO [RFC4119].
UAS-5 Location conveyance from endpoint UAC to endpoint UAS MAY be conveyed using a Location-by-Reference URI, pointing at a PIDF-LO (for the UAC). This requirement expects the UAS to be able to go fetch the location of the UAC at the reference.
UAS-6 Location conveyance using a Location-by-Reference URI, pointing at a PIDF-LO (for the UAS), MAY be in either a header or a message body (part).
Comments about
UAS4 –
UAS5 –
UAS6 -

12. Review Requirements (cont’d)
UAS-7 There MUST be a unique 4XX error response code informing the UAC it did not provide applicable location information.
UAS-8 Privacy mechanisms MUST NOT be mandatory for successful conveyance of location during an (sos-type) emergency call.
UAS-9 A PSAP UAS MUST be able to override the retention and retransmission policy indicated within the PIDF-LO of a message, even if fetched in a subsequent transaction, when local regulation governs such retention and retransmission procedures.
Comments about
UAS7 –
UAS8 –
UAS9 -

13. Review Requirements (cont’d)
Proxy-1 Proxy servers MUST NOT modify or remove a location message body part ([RFC3261] currently forbids this), or a location header value.
Proxy-2 B2BUA instances of a SIP intermediary SHOULD NOT modify a PIDF-LO message body part, or a location header value, during its processing if received on the UAS side of the server, and MUST transmit location body or header unchanged out the UAC side of server.
Comments about
Proxy1 – MN or SN?
Proxy2 -

14. Review Requirements (cont’d)
Proxy-3 B2BUA instances of a SIP intermediary MAY add a PIDF-LO message body part if it is qualified as an [RFC3693] "Sighter" for the originating endpoint UAC. If the B2BUA is not a qualified Sighter, it SHOULD NOT add a PIDF-LO message body part.
Proxy-4 Proxy servers and B2BUA instances of a SIP intermediary MAY add a location header to a SIP message during processing, but the server SHOULD be qualified as an [RFC3693] "Sighter" for the originating endpoint UAC in order to do this.
Open question about #4 here: what to do about a proxy that learns the UAC’s location with a lag in time, meaning an UPDATE probably cannot be originated by the Proxy in that dialog.
Comments about
Proxy3 – is this necessary?
Proxy4 -

15. Review Requirements (cont’d)
Proxy-5 If a Proxy server is qualified as an [RFC3693] "Sighter" for the originating endpoint UAC, and a received SIP message SHOULD or MUST have location within the message to be processed correctly, that Proxy transmits a unique 4XX error response code informing the UAC it did not provide applicable (or any) location information, and to include the location information contained in the message body of this error message in the UAC's next request attempt.
Proxy-6 If a Proxy Server adhered to Requirement Proxy-5, it MUST retain state for the subsequent request message for a reasonable amount of time. If the subsequent request does not include the UAC's location, the message is processed as if requirement Proxy-5 didn't exist, and forward the message as it normally would have.
This failure to include location on a second request attempt MAY be a sign the UAC doesn't support location conveyance as defined in this document. Because requirement Proxy-5 is envisioned for 911/112-type emergency calling, the subsequent attempts shouldn't fail the emergency call, as a downstream SIP entity may have a solution, such as being the Sighter for the UAC.
Proxy-5 and Proxy-6 are to be deleted from document
Comments about
Proxy5 –
Proxy6 -

16. Review Requirements (cont’d)
Proxy-7 If a Proxy server or B2BUA instance of a SIP intermediary detects "location" already exists within a SIP message, it MUST NOT add another location header or location body to the message.
Proxy-8 There MUST be a unique 4XX error response code informing the UAC it did not provide applicable location information.
Proxy-9 A SIP message initiated by one SIP server destined for another SIP server SHOULD convey location-by-reference, and not by-value.
Comments about
Proxy7 – does this apply to a header and body, or just the header?
Proxy8 –
Proxy9 -

17. A New Requirement? Should I add a Proxy Requirement stating:
a Proxy MAY engage a B2BUA function through an API when processing an emergency call transaction. This would allow this server to add a PIDF-LO to the message.
Comment: -

18. Location Header Is there a purpose for the cid?
Location = "Location" HCOLON Location- value
*(COMMA Location-value)
location-value = (addr-spec / option-tag / token)
addr-spec = cid-url / absoluteURI
option-tag = string
token = token / quoted-string
cid-url =
absoluteURI = SIP or SIPS-URI
Is there a purpose for the cid?
Other comments: -
Is there a purpose for the cid?
I’d like help with the above syntax!

19. Location Header
Header field where proxy INV ACK CAN BYE REG OPT PRA
Location Rr amdr o o o o -
Header field where proxy SUB NOT UPD MSG REF INF PUB
Location Rr amdr o o o o o o o
Do say that if a Proxy/B2BUA receives this header, it shouldn’t be changed
Comments: -

20. “Location” Option-tag
Used in Supported, Unsupported, Requires and Proxy-Requires headers
SHOULD be used when any location is included in message
Comments:
- SHOULD be used when any location is included in message?

21. Methods Location makes sense in
INVITE
UPDATE
MESSAGE
PUBLISH
But don’t prohibit using it in any other method
State: if a Request has location, a Response MAY include location (200 OK is the only one that makes sense here)
Note:
SUB/NOT are considered Pulling location, and out of scope of this doc
Comments: -

22. New 424 (Bad Location) Response
If a UAC transmitted a bad location, this is a specific error to tell the UAC this was what was in error
And perhaps re-query however it got location to get new location
Comments: -

23. Removing 425 (Retry Location)
Cannot get around how this can be used to spoof to find a UAC’s location
Comments: -

24. Example flows
These are just enough to get the point across, they do not have well-formed SIP messages or PIDF-LO