SIP PUBLISH Method Jonathan Rosenberg dynamicsoft.

Slides:



Advertisements
Similar presentations
Re-INVITE Handling draft-camarillo-sipping-reinvite-00.txt
Advertisements

1 © 2001, Cisco Systems, Inc. All rights reserved. © 2004, Cisco Systems, Inc. All rights reserved. Location Conveyance in SIP draft-ietf-sipping-location-requirements-02.
SIP, Presence and Instant Messaging
Presence, Security and Privacy. VON The Current Environment Many Faces of Security Authentication Verify someone is who they.
An Application Component Architecture for SIP Jonathan Rosenberg Chief Scientist.
SIP and Instant Messaging. SIP Summit SIP and Instant Messaging What Does Presence Have to Do With SIP? How to Deliver.
Fall IM 2000 Introduction to SIP Jonathan Rosenberg Chief Scientist.
SIMPLE Open Issues Jonathan Rosenberg dynamicsoft IETF 52.
Fall VoN 2000 SIP for IP Communications Jonathan Rosenberg Chief Scientist.
XCAP Tutorial Jonathan Rosenberg.
IPP Notification and Notification Services White Paper Hugo Parra; Novell, Inc. October 6, 1999 The intent of this paper is to supplement the discussions.
Yunling Wang VoIP Security COMS 4995 Nov 24, 2008 XCAP The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)
Cookies, Sessions. Server Side Includes You can insert the content of one file into another file before the server executes it, with the require() function.
SIP Working Group Jonathan Rosenberg dynamicsoft.
SIMPLE Presence Traffic Optimization and Server Scalability Vishal Kumar Singh Henning Schulzrinne Markus Isomaki Piotr Boni IETF 67, San Diego.
Session-Independent Policies draft-ietf-sipping-session-indep-policy-01 Volker Hilt Gonzalo Camarillo
SIP Working Group Stuff Jonathan Rosenberg dynamicsoft.
XML Configuration Access Protocol (XCAP) Jonathan Rosenberg dynamicsoft.
3GPP Presence Requirements Requirements for Presence Service based on 3GPP specifications and wireless environment characteristics draft-kiss-simple-presence-wireless-
SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) Reporter : Allen.
GRUU Jonathan Rosenberg Cisco Systems. sip and sips General problem –What should gruu say about relationship of sips to gruu? Specific questions –If the.
GRUU Mechanism Jonathan Rosenberg. Status Draft-rosenberg-sipping-gruu-reqs-01 defines the problem Draft-rosenberg-sip-gruu submitted with proposed solution.
Draft-campbell-dime-load- considerations-01 IETF 92 DIME Working Group Meeting Dallas, Texas.
RPIDS - Rich Presence Information Data Format for Presence Based on the Session Initiation Protocol (SIP) Henning Schulzrinne (ed.) Vijay Gurbani Krisztian.
WebDAV Issues Munich IETF August 11, Property URL encoding At present, spec. allows encoding of the name of a property so it can be appended to.
Presence Data Model Jonathan Rosenberg. Changes in -02 Split out data and processing models Allow multiple devices, services, person with same URI/device.
XCAP Needed Diffs Jonathan Rosenberg Cisco Systems.
Name of Presentation Red Hat Presenter Mobicents SIP Presence Service: XDM Server Creating XCAP Application Usages Eduardo Martins.
SIPREC draft-ietf-siprec-req-02 Requirements for Media Recording using SIP Draft authors: K. Rehor, A. Hutton, L. Portman, R. Jain, H. Lum IETF 78.5 Interim.
Recommended name changes for buttons in Schedule Sept 27, 2013.
S/MIME and Certs Cullen Jennings
Example: object diagram for Scheduler, v What is wrong with this diagram? Seems like a lot of similarity between Task and UnplannedTask Can use.
Data Manipulation Jonathan Rosenberg dynamicsoft.
XCAP Jonathan Rosenberg dynamicsoft. Changes in Main Spec Removed POST usage Clarified the meaning of PUT for inserts vs. modifies Added AUID grammar.
App Interaction Framework Jonathan Rosenberg dynamicsoft.
SIMPLE Drafts Jonathan Rosenberg dynamicsoft. Presence List Changes Terminology change Presence List Information Data Format –Provides version, full/partial.
XCAP Jonathan Rosenberg dynamicsoft. Agenda XCAP Main spec changes XCAP Main spec open issues XCAP Package changes XCAP Package Open Issues Authorization.
Andrew Allen Communication Service Identifier.
SIP PUBLISH draft-ietf-simple-publish-01 Aki Niemi
Christian Groves Describing Captures in CLUE and relation to multipoint conferencing draft-groves-clue-multi-content-00 CLUE Interim meeting (09/13)
Caller Prefs and Friends Jonathan Rosenberg dynamicsoft.
Making SIP NAT Friendly Jonathan Rosenberg dynamicsoft.
SIP WG Open Issues IETF 50 Jonathan Rosenberg dynamicsoft.
OMA Presence 1.0 Presence attribute, composition issues Krisztián Kiss
Name that User John Elwell Cullen Jennings Venkatesh Venkataramanan
GRUU Jonathan Rosenberg Cisco Systems. Changes in -06 Editorial as a result of RFC-ED early copy experiment.
SIP file directory draft-garcia-sipping-file-sharing-framework-00.txt draft-garcia-sipping-file-event-package-00.txt draft-garcia-sipping-file-desc-pidf-00.txt.
1 A mechanism for file directory with SIP draft-garcia-sipping-resource-sharing-framework-01.txt draft-garcia-sipping-resource-event-package-01.txt draft-garcia-sipping-resource-desc-pidf-00.txt.
July 28, 2009BLISS WG IETF-751 Shared Appearance of a SIP AOR draft-ietf-bliss-shared-appearances-03 Alan Johnston Mohsen Soroushnejad Venkatesh Venkataramanan.
SIP Events: Changes and Open Issues IETF 50 / SIP Working Group Adam Roach
Caller Preferences Jonathan Rosenberg dynamicsoft.
1 © NOKIA Presentation_Name.PPT / DD-MM-YYYY / Initials Company Confidential XCAP Usage for Publishing Presence Information draft-isomaki-simple-xcap-publish-usage-00.
SIPPING Drafts Jonathan Rosenberg dynamicsoft. Conferencing Package Issues Only one – scope Depends on broader work in conferencing May include –Participant.
SIP PUBLISH draft-ietf-simple-publish-01 Aki Niemi
SIP Extension Changes Jonathan Rosenberg dynamicsoft IETF 52.
SIP wg Items Jonathan Rosenberg dynamicsoft Caller Preferences: Changes Discussion of Redirects –Previous draft only proxy –Nothing different for redirect.
Jonathan Rosenberg dynamicsoft
Session-Independent Policies draft-ietf-sipping-session-indep-policy-02 Volker Hilt Jonathan Rosenberg Gonzalo.
Jonathan Rosenberg dynamicsoft
ECRIT Interim: SIP Location Conveyance
SIP Configuration Issues: IETF 57, SIPPING
Markus Isomäki Eva Leppänen
App Interaction Framework
Jonathan Rosenberg dynamicsoft
draft-ietf-geopriv-lbyr-requirements-02 status update
Jonathan Rosenberg dynamicsoft
SIMPLE Presence Traffic Optimization and Server Scalability
RPIDS - Rich Presence Information Data Format for Presence Based on the Session Initiation Protocol (SIP) Henning Schulzrinne (ed.) Vijay Gurbani Krisztian.
Henning Schulzrinne Columbia University
BINDing URIs to SIP AORs
Presentation transcript:

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: –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

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.

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

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

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

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

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!

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

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

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

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

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

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