SIP PUBLISH Method

1
SIP PUBLISH Method

• Jonathan Rosenberg
• dynamicsoft

2
Versioning

• Current draft using information in the body to
  provide versioning
• Need relative orders across publishers of the
  same tuple
• This requires global clock synchronization bad
• Proposal
• Cseq orders publications from a particular client
• Server assigns a timestamp for each tuple,
  returned in 200 OK to PUBLISH
• PUBLISH has If-Unmodified-Since when updating a
  tuple will fail with a 412 if someone else has
  modified that tuple since I last did
• If doc contains multiple tuples,
  If-Modified-Since applies to all
• An automata will not override (by omitting the
  If-Unmodified-Since) without human interaction

3
Number of Tuples

• Can you have a PUBLISH with a PIDF doc with
  multiple tuples?
• Alternative each is a separate PUBLISH
• Nice to have the atomicity of the publications
  (tuple) match what you send in each PUBLISH (a
  tuple)
• Otherwise, to which one does a header apply?
  I.e., Expires, If-Unmodified-Since, etc.

4
Label vs. id

• What uniquely identifies a tuple ?
• Current draft says the id attribute
• However, this requires a lot of semantics for id
  not defined in PIDF
• Chosen uniquely by publishers
• Persistent for long periods of time
• May be overriden by another publisher
• Could also use RPIDS label
• Proposal have the spec describe these additional
  semantics to id, and also eliminate label from
  RPIDS
• Plays a similar role

5
Number of documents

• The scope of PUBLISH is for any event package
• Document specifies things that need to be done to
  use PUBLISH for any package
• Should we therefore have one doc for PUBLISH, and
  then another for the details for presence?
• Proposal no just have a separate section in
  the same doc

6
Deletion with Expires 0

• Right now, the tuple ID is part of the presence
  document
• To delete a tuple, you send PUBLISH with Expires
  0
• How to identify the tuple you are deleting??
• Only solution now is to include a body that has
  the tuple with its id
• Value of the tuple is irrelevant
• Other solution is that identification of the
  tuple is done with a header, and the body only
  contains the value of the tuple (when needed)
  not a full PIDF doc

7
Cseq and Call-ID

• Spec says client should reuse the same Call-ID
  and increment Cseq by one
• However, server never looks at these
• Unlike REGISTER
• With versioning proposal, only tuple ID and
  server timestamp matter
• Do we keep current Cseq/CallID rules?
• No will confuse people

8
Call Forwarding

• Scenario
• user enables call forwarding from AOR X to AOR Y
• PUBLISH to X therefore gets forwarded to Y
• ESC looks at To field to determine AOR that is
  being published-to
• But this no longer matches the domain of the ESC
• ESC rejects PUBLISH!

9
Call Forwarding

• Solution
• ESC should only use request-URI to determine
  identity of AOR to which publish applies
• In the case of a UA that registered, this is the
  AOR against which the register was made
• This doesnt always work in the call forwarding
  case
• Dont want to delegate SUBSCRIBE and PUBLISH for
  short-lived call forwarding
• Solution call forwarding apps probably only
  should look at INVITE not clear where, if
  anywhere, that would get handled

10
Migration

• When migrating subscriptions to a UA, the UA
  needs to have the state of the presentity
• If other users are publishing for that
  presentity, you want the PUBLISH to migrate too
• However, there will be an interval between when a
  SUBSCRIBE gets migrated, and the UA has received
  all PUBLISHes
• During this interval, its state will be wrong
• Proposal ignore this problem

11
Caller Prefs

• Presence spec recommends clients REGISTER with
  caller-prefs params to indicate that they support
  SUBSCRIBE
• Should the PUBLISH spec recommend the same for
  PUBLISH?
• Yes should be aligned

12
Requirement 19

• Requirement 19 says
• There must be a way for a publisher to tell a
  presence agent that a piece of published presence
  should be passed on to watchers wtihout
  modification
• We dont have such a mechanism
• Idea 1 S/MIME signature in PUBLISH implies that
• Also implies that the presence doc is not
  composed with anythng else?
• But what if the S/MIME is to sign it for
  consumption by the PA?
• Idea 2 remove requirement
• Idea 3 Require header

13
Requirement 14

• Requirement 14 reads
• PUAs MUST have a capability that allows them to
  query for the identifiers of all of the segments
  of presence information that have currently been
  published for a presentity (provided that the PUA
  is authorized to receive this information)
• We dont have this
• Proposal 1 abandon requirement
• Proposal 2 200 OK to PUBLISH contains raw
  aggregated presence document with all published
  tuples
• Proposal 3 SUBSCRIBE to that event package gives
  you that data almost

14
Hard State

• How is hard state default presence documents
  specified?
• I believe we concluded at San Francisco that this
  is done with data manipulation
• Making sure
• PUBLISH spec should probably mention collecting
  tuples from non-PUBLISH sources, like xcap