1 / 14

SIP PUBLISH Method

SIP PUBLISH Method. Jonathan Rosenberg dynamicsoft. 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:

scottjose
Download Presentation

SIP PUBLISH Method

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 doesn’t always work in the call forwarding case • Don’t 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 don’t 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 don’t 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

More Related