ECRIT Interim: SIP Location Conveyance

1
ECRIT Interim SIP Location Conveyance

• James Polk
• 20060202

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.

4
Review Requirements (contd)

• 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.

5
Review Requirements (contd)

• 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

6
Review Requirements (contd)

• 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)

7
Review Requirements (contd)

• 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.

8
Review Requirements (contd)

• 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.

9
Review Requirements (contd)

• 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.

10
Review Requirements (contd)

• 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).

11
Review Requirements (contd)

• 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).

12
Review Requirements (contd)

• 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.

13
Review Requirements (contd)

• 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.

14
Review Requirements (contd)

• 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 UACs location with a lag
  in time, meaning an UPDATE probably cannot be
  originated by the Proxy in that dialog.

15
Review Requirements (contd)

• 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

16
Review Requirements (contd)

• 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.

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.

18
Location Header

• 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? Id 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 shouldnt be changed

20
Location Option-tag

• Used in Supported, Unsupported, Requires and
  Proxy-Requires headers
• SHOULD be used when any location is included in
  message

21
Methods Location makes sense in

• INVITE
• UPDATE
• MESSAGE
• PUBLISH
• But dont 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

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

23
Removing 425 (Retry Location)

• Cannot get around how this can be used to spoof
  to find a UACs location

24
Example flows

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