Notes On OMA Ad-Hoc at IETF 62

Produced by Spencer Dawkins

 Starting out with a pretty packed Rochester Room (and food delivered to the previous meeting), after Dean found the projector...

Dean is current IETF liaison for the OMA

Cisco providing dinner...

Improving collaboration, informing IETF, discussing specific OMA activities with related drafts

RFC 3975 defines our relationship with OMA

- OMA SIP/SIMPLE Presence composition and attribute issues/requirements
compared to IETF (SIMPLE data model, RPID etc.), future requirements -

    •     Krisztian Kiss presented OMA Presence 1.0 release
    •     OMA has done work on presence composition policy
    •     Unique identifier for an OMA-defined service (POC service), with service descriptions
    •     Presence server resolves ambiguity in OMA-defined attributes
    •     Default composition policy is "choose latest timestamp", but other policies are possible
    •     OMA view - presence server should not leave ambiguities for the watcher - determine actions based on source of presence information?
    •     Makes watcher simpler, but presence server is less extensible and needs knowledge of semantics and sources
    •     Presence attributes - Person/device/tuple model
    •     Have added willingness, application-specific availability, overriding willingness, along with a lot of reused attributes from IETF
    •     Network-availability, Session-participation are also new from OMA
    •     PIDF dependencies - using RPID parts, may use rest of RPID, PRESCAPS, CIPID, FUTURE, etc. in later releases
    •     Using service description instead of PRESCAPS? Yes, for POC, but leaving the door open for other services
    •     Device-ID will be 128-bits and random - OMAI needs to be registered with IANA
    •     Authorization issues - extensions for <transformations> - may have requirements for prescaps, cipid, future, XCAP hard-state publication - will IETF define authorization rules for these I-Ds?
    •     Added <other-identity> as default policy - overlap with <any> attribute? only works if there is no other rule matching - this may be going against current policy model
- OMA SIP/SIMPLE IM requirements (for the release targeted for 09/2005)
-  Markus Osomaki

    •     OMA Instant Messageing 1.0 - not as advanced as presence work at OMA, target date is toward yearend, can still use stuff IETF is defining now
    •     Requirements to IETF coming more from OMA and less from 3GPP?
    •     OMA IM based on SIMPLE work, with strong inclination to keep system components compatible with IETF protocol specifications
    •     At the same time, there is strong industry demand for finalized system standard in timely fashion
    •     SIP MESSAGE must be "store-and-forwardable" when recipient is offline, with notification of later, final delivery
    •     MSRP for a single message to overcome size limits in SIP MESSAGE (need to say "one message" when you set up MSRP session) - got plans? Sendonly? We have plans, we just need conventions - are you sure you want this? It's not what Jonathan's cell phone does today - could be done at receiver UA? This is moving the pager-mode/session mode problem into MSRP - do we want to go here? List discussion would be good
    •     Aki - problem here is that we have two paradigms and no indication when you use which paradigm - don't want to pop up "incoming session" for one message - SIMPLE needs to solve the transition problem that has been identified (here and previously)
    •     Is this for page mode or both modes? Mostly page modes. Doing anything with consent? That's a good question - if you sign up for OMA service, you're signing up for this, too.
    •     Relationship between store-and-foreward and MMS? Why two mechanisms? No overall messaging framework - this isn't a new question. MMS isn't available everywhere, may have SIP-only devices.
    •     Need message delivery lists (based on SIPPING URI LIST draft)
    •     Need private messages within multiparty (as in SIMPLE discussion)
    •     Need nickname identity within chat room (as in SIMPLE discussion)
    •     Data manipulation requirements - OMA is working on XCAP-based mechanism - augment with WebDAV?
    •     Authorization for resource lists
    •     vCARD network-stored phonebooks as extension to resource lists
    •     Search PoC and chat conferences within a scope based on certain attributes - owner, start time, etc. Also search for people - interdomain? Not clear, requirements focused on one domain now
- OMA PoC issues
   - draft-allen

    •     Tom Hiller presenting
    •     POC documents are available outside OMA
    •     POCv1 is focused on audio
    •     Uses SIP, and builds on IMS, but doesn't preclude non-IMS SIP networks
    •     Two kinds of SIP servers, the focus and the application server
    •     Participating PoC function and controlling PoC function (acts as focus, media mixer, etc.)
    •     Two call models - on-demand calls (INVITE-initiated) and pre-established sessions (fewer bytes and maybe no SIP signalling on terminating endpoints - uses REFER instead of INVITE - more state in PoC servers, and maybe proxies, too)
    •     CDMA has 8000 bps in reverse direction - that's the pain level we're dealing with
    •     Latency challenge - slow links with dormant/activation delays ("under two seconds" requirement)
    •     Does PoC server maintain ordering? When two people PoC to me (glare)? PoC may pick one, may buffer, etc.
    •     183 Session Progress with P-Answer-State: Unconfirmed - allows talker to talk while network is setting up channels, etc.
    •     Does PoC server transcode, since you haven't negotiated media? Yes
    •     There is clipping (PoC server sends to all receivers when first receiver answers) - goal is to put buffering in one place in the network - users can be trained to ask "are you guys out there?"
    •     What IP address are you sending to? the buffer inserts itself into the path. Modified SDP? No, INVITEs go to focus, anyway - is this a legal RTP transmitter? do we get problems with RTCP, etc? What does the spec say?
    •     How are you doing floor control? There's an OMA-specified floor control protocol - haven't ruled out BFCP, but need to publish now, so...
    •     P-Alerting-Mode - only current value is Manual Answer Override, but manual and auto are added for future use
    •     P-Answer-State - allows a PoC server to tell a talker how far the speech path has been established
    •     Why not preconditions? Was considered, design discussion is in the specifications - there are technical concerns, but a lot of phobia around IPR on preconditions
    •     P-Alerting-Mode sits in REFER, and should be Refer-To - this is just wrong. Can it be fixed? Don't know what resistence is within OMA, people are building in parallel
    •     Is auto-answer also used for MSRP? Don't think this has been discussed in OMA - MSRP was set up in INVITE/200 OK, maybe OMA should think about this? How does this interact with early media? Is a lost early-media message the same as lost speech? ("Have you ever talked to your children?")
    •     What is authentication policy for Manual Answer Override (so not everyone can just start talking out your phone)?
    •     P-Answer-State is Confirmed/Unconfirmed
    •     Jonathan - we haven't solved unconfirmed problem in general SIP space - how to break in on a caller talking to my voice mail? Almost like shared-line-appearance, voice mail server is also a focus - this is exactly the same problem in OMA - mechanism is the same except voice mail is immediate - can't rely on anything by the phone (in a high-latency mobile environment) - terminating PoC server becomes a conference bridge - problem at OMA is that all the buffering is happening at another PoC server, so no buffering happens at the terminating PoC server
    •     Is this the simulcast problem? We need to solve this anyway (so we can synchronize playout)
    •     Why is NOTIFY used? Jonathan is modeling this as a shared line appearance (Dean's answer: "because you don't want to do an SDP media exchange on every call setup") - latency to PoC client is so high that we can't use JOIN
    •     Aki - agree with Jonathan that his approach would work, but OMA also cares about minimizing the number of messages - three more messages = "bad"
    •     Jonathan - probably nothing wrong, why isn't this an isfocus parameter in 200 OK?
    •     Steve Norris - if PoC server anticpates what is happening, what happens if it doesn't happen? You just get a "bong" later on - call failed
    •     Jonathan - another way to model this is as a conference out-dial?
    •     Steve Norris - why is media buffering before the final PoC server? Just to keep all the buffering in one place - there can be an arbitrary number of PoC servers inline, so trying to minimize buffering all over the network
    •     P-Alerting-Mode used to be in Callerprefs and disappeared for a good reason, but it's come back as part of MMUSIC loopback diagnostic testing and simulcast application - hard problem is always authorization, and whitelist authorization isn't bad - this really has more general application, it's not a P-header any more and should be generally defined
    •     People are going to use this P-header for autoanswer everywhere anyway when it becomes available - we should do it as a standards-track specification - to the SIP working group? But we need this already - can the draft be in on Monday?
   - Future issues - ?

    •     What are OMA interfaces arouund location roaming and Privacy Profile Register? Do we need to coordinate with OMA and IETF? It's going into PoC 2 now