Minutes, OMA Ad-Hoc at IETF 62

Reported by Dan Wing
Edited by Dean Willis

chair: Dean Willis, IETF Liaison to OMA

purpose of meeting: improve collaboration between IETF and OMA

Relationship defined in RFC3975; similar to 3GPP's relationship

OMA tracks their dependencies on IETF's work; URL is available from
Dean or from OMA home page (http://www.openmobilealliance.org)

presenters:

OMA Presence -- Krisztian Kiss
OMA Messaging -- Markus Isomaki
OMA push to talk -- Tom Hiller, includes Allen P-Headers draft
Event Draft -- Miguel Angel Garcia-Martin
Location - James Winterbottom
SMS - <no name>

Presentations:

OMA Presence, Krisztian Kiss, Nokia
-----------------------------------

Defined data model for a presence server - a tuple
   <contact> <service-description> <device-id>

Watcher defines presence composition policy, which deals with resolving
ambiguities

In subsequent releases, the presence server will improve its algorithm
so that better presence information is published. This will simplify
the Watcher.

Presence attributes: Person/Device/Tuple

application-specific willingness (is user available or is user
interested in receiving information from the application)

application-specific availability

overriding willingness - Do Not Disturb button, takes precedence over
application-specific settings

Reusing some IETF elements - communication address, activity, and
others ...

OMA-specific PIDF extensions: service-desc, willingness,
overriding-willingness, network-availability, session-participation.

Device-ID: OMA using a 128-bit random number, urn:omai:xxxxx..., which
requires IANA registration

Authorization issues: <external-list>, <other-identify>, extensions for
<transformation>.

AI: other-identity is used as a match for a default policy; the "any"
attribute might provide a similar function. Need to followup with
IETF.

In next release, OMA may adopt prescaps, cipid, future, XCAP
hard-state; will IETF define authorization rules for these I-Ds?

Q: The <other-identity> is similar to discussions in the SIMPLE WG -
how are they related?
A: They're different - the <other-identity> doesn't combine with other
rules; this might well be a problem with the common policy model.
"Any" will require further study to see if it would fit needs as well
as other-identity.

OMA Messaging - Markus Isomaki, Nokia
-------------------------------------

OMA Instant Messaging

The OMA Instant Messaging is less mature than the OMA presence; OMA
Instant Messaging has more open issues and is still in the early
definition stage, and could use more of IETF's work. OMA is driving
requirements for instant messaging into the IETF, rather than 3GPP.

OMA SIMPLE IM's purpose is to define an entire IM system: 1:1 and 1:M
messaging (one shot), and 1:1 and 1:M messaging (session). Very much
like IETF's SIMPLE. Strong inclination to keep system components
interoperable with IETF's specifications - SIP MESSAGE, MESSAGE URI,
MSRP, XCAP, etc.

OMA's requirements work is finished, and architecture work is ongoing

requirements:

   - store/forward support for SIP Message (similar to
draft-burger-simple-imdn)
   - mimic pager-mode messaging paradigm over session-based transport
     Necessary to exceeed content size limits of SIP Message
     (discussion with audience ensued about desirability of this and the
     interaction of switching between pager-mode and session-based
messaging)

SIMPLE needs to resolve how to switch between these two modes

   - Message delivery lists (based on draft-sipping-uri-list-message),
which
     is primarily for page-mode. What remains undefined, but is
required, is
     for recipient to see who else received the same message.

Paul K.: What about consent?
Markus: if you sign up for the service, you'll get messages from anyone
who sends you a message.

Q: What's relationship between MMS store-and-forward and SIP
store-and-forward?
A: No relationship because there is a lack of an overall messaging
framework.

   - private messaging w/in a multiparty chat conference, similar to
draft-niemi-simple-chat
   - nickname usage within a multiparty chat conference, similar to
draft-niemi-simple-chat

Data manipulation requirements

   - OMA is also working with XML Document Management (XMM), which is
based on IETF XCAP
   - copying and moving of XML resources
   - authorization for XML resources (resource lists) - allow other
users to get/put/delete an XML resource
   - resource list extensions (vCard - network-stored phonebook)
   - search a PoC or a chat conference via subject, owner, start time,
etc. Protocol current undefined.

OMA push to talk -- Andrew Allen, Research in Motion, Tom Hiller, Lucent
------------------------------------------------------------------------

OMA PoC Overview and draft-allen-sipping-poc-p-headers

presentation given by Tom Hiller

OMA publishes its approved documents on its website. URLs available in
the presentation.

PoC (Push to Talk over Cellular) Concepts
- make classic PTT over Cellular work over SIP
- manual and auto-answer modes
- manual answer override, for emergency dispatch purposes
- confirmed and unconfirmed speak indicators

PoC servers includes PF (participating PoC server function). Knows
which mode user is in, knows confirmed/unconfirmed speak preference,
and other per-user settings. Other PoC server is CF (controlling
function), which performs floor control and does media mixing, and can
buffer media while cellular network is paging the user

on-demand call model. conventional e2e Invite initiated PoC session
establishment. Includes implicit floor grant.

pre-established session model. Uses fewer bytes, and can be done w/o
SIP signaling on terminating side; rather, state sits in the SIP proxy.
Functions like a conference server, where conference server is set up
early. Makes significant use of OMA-specified floor control.

Latency challenge: dorman activation and low bandwidth challenges.
PoC indication-to-speak must be below 2 seconds. Unconfirmed floor
control causes network to buffer voice if recipient isn't available.

on-demand call model: call flow slide showing P-Answer-State in 183
and 200 OK's going back to initiator. Several questions from audience
about buffering, and if some users in a user group aren't available or
aren't answering, and how buffering works in those situations. Media
packets are sent to the IP address of the Media Buffer device, which is
an RTP conference mixer.

OMA's floor control borrowed the first 12 bytes from RTCP, but uses a
different port and isn't an RTCP packet.

draft-allen-sipping-poc-p-headers:
   - P-Alerting-Mode
     - Manual, Auto, Manual-Alert-Override. Only MAO is used today.
     - appears as separate header in Invite and Refer. Rosenberg
pointed out it should be in refer-to
   - P-Answer-State

Paul K: OMA should consider auto-answer with MSRP

P-Alerting-Mode has security around it to reduce abuse of MAO
(whitelists of users allows to use MAO?)

P-Answer-State: PoC servers buffer media

Jonathan R: general SIP case has a similar problem. Someone calls a
line, and you hear it ringing but can't answer before it goes to
voicemail. I'd like to pick up the phone and talk to the user while
they're leaving the message with voicemail. In SIP, you'd proxy Invite
to get the user talking to you again, and you'd have a 3-way conference
in progress (voicemail server, answerer, caller). This is another way
to do an unconfirmed indication. This is similar to PoC, except you
don't get the 4 rings at your house -- instead, the calling party goes
directly to "voicemail" (the media buffering PoC server), and then the
called party 'joins' that conference and listens to the buffered media.

Floor discussion (Dean, Jonathan R, Tom): p-answer-state
confirmed/unconfirmed is used to indicate if user has really answered
('confirmed') or if the network 'thinks' the user will be able to
answer ('unconfirmed', and thus the PoC buffers).

Stig: if the called user is incorrectly 'thought' to be answering by
the destination PoC server, but the user doesn't answer, the caller
gets a call failure tone after they spoke and their voice was buffered.

AI: Proposal from Jonathan to take autoanswer as a standards-track
document in IETF SIP WG.

Dean shows a slide and asks: OMA interfaces around location roaming
(LR) and the privacy profile register (PPT). Do we need to coordinate
what the OMA is doing here with the IETF is doing on location?

-d