On Tuesday 08 February 2011 16:29:17 ext Sjur Brændeland, you wrote: > From: Sjur Brændeland > > Thanks for lots of useful feedback from last RFC, > here is my next revision on the LTE/IMS API. > Comments are still very much welcome! > > Changes from RFC-V1: > - Renamed IMS to IpMultimediaSubsystem (some places) > - Changed registration of IMS application. > - Moved IMS Identities to a separate interface > - Dropped the entire TFT/QoS info. > Instead oFono checks the QoS SIP Preconditions. > IMS application is notified about changes in QoS, > and asks oFono if the QoS SIP preconditions are > satisfied. > --- > doc/ims-api.txt | 162 > +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, > 162 insertions(+), 0 deletions(-) > create mode 100644 doc/ims-api.txt > > diff --git a/doc/ims-api.txt b/doc/ims-api.txt > new file mode 100644 > index 0000000..5404e61 > --- /dev/null > +++ b/doc/ims-api.txt > @@ -0,0 +1,162 @@ > +Ip Multimedia Subsystem hierarchy [experimental] > +================================= > + > +Service org.ofono > +Interface org.ofono.IpMultimediaSubsystem > +Object path [variable prefix] I guess this is meant to be a modem object path, but it seems the oFono documentation is already a bit sloppy on this point. > +Methods dict GetProperties() > + > + Returns all IMS properties. See the > + properties section for available properties. > + > + void Register(string type) > + > + Register a IMS Application. It must register > + with one of the types: > + "voice", "messaging", "voice_messaging". I am not very familiar with the underlying protocol... If it really makes sense to register both services simultaneously, then I think we should have an array of strings. Or if there are no benefits, then why bother with 'voice_messaging' anyway. > + This registration will inform modem's radio > + stack that the IMS application has registered > + for Voice and/or Messaging over IMS. > + This registration may impact "UE Mode of operation" > + and the ISR feature in the radio stack. > + > + The registered application is tracked, if the > + application exits the registration will be > + automatically released. > + > + Related AT command: AT+EISR. Is this a standard command? As it is not in the 3GPP namespace (AT+C...), it might be nice to provide a reference pointer. > + Possible Errors: [service].Error.InvalidArguments > + > + void UnRegister(object path) > + > + Un-register a IpMultimediaSubsystemAgent. > + > + Possible Errors: [service].Error.InvalidArguments > + > + boolean PreConditionCheck(string Type, string PeerAddress, > + uint16 PeerPort, uint16 LocalPort) > + > + This method is used by the IMS application to check > + if the QoS SIP precondition is fulfilled. > + > + The IMS application should call this method when > + receiving a PreConditionChanged() signal. > + The IMS Application is not allowed to start alerting > + before it has confirmed that it has a voice-ready > + Dedicated Bearer and QoS set up in the network. > + > + The legal parameter for Type currently is currently > + "voice" only. In future "video" (Conversational Video, > + Live Streaming) will be added. > + > + PeerAddress can be IPv4 or IPv6 address. PeerPort and > + LocalPort is the RTP port used for the media stream. > + > + This method returns true if the Traffic Flow Template > + read from the modem matches the address information > + provided, and the QCI and Bit Rates fulfills the > + requirements for the specified type. > + > + Related AT commands: AT+CGEQOSRDP, AT+CGTFTRDP > + > + NOTE: Should the "Type" parameter be removed? > + Maybe IMS-video still is a bit futuristic. That stuff is per context. Should it not be in the context object rather than in the IMS manager? > + > +Signals PropertyChanged(string property, variant value) > + > + This signal indicates a changed value of the given > + property. > + > + void PreConditionChanged() > + > + This signal is sent when the network has changed > + the QoS or Packet Filters for a Bearer. > + The IMS application can then check the QoS SIP > + preconditions by calling PreConditionCheck(). > + > + Only QoS information relevant for IMS will be > + signaled, i.e. QCI=1 for voice and QCI=2 for video. > + > + Related AT commands: AT+CGEREP, > + +CGEV: NW ACT, +CGEV: NW MODIFY > + > +Properties > + array{object} Identities [readonly] > + > + Array of IP Multimedia Identities objects and > + properties. > + NOTE: It is assumed that Identities will not change. > + > + boolean VoiceOverPs [readonly] > + > + IMS voice is enabled by network > + Related AT command: AT+CIREP. > + > + string CsHandoverProgress [readonly, optional] > + > + Indicates the handover progress status during a CS > + fallback procedure. The possible values are: > + "started" - CS Fallback procedure has started > + "complete" - CS Fallback procedure has completed > + "failure" - CS Fallback has failed > + "idle" - No CS call or fallback is ongoing > + > + Related AT URC: +CIREP > + > + array{string} PcscfAddresses [readonly] > + > + Domain Name or IP Address of the SIP Proxy. > + The P-CSCF address returned in EPS signaling as > + as part of the Default Bearer setup will be used. > + The addresses may be of type IPv4 and/or IPv6. > + If no P-CSCF data is available the information from > + EFp-cscf will be used. > + > + Related AT command: AT+CGCONTRDP > + > + NOTE: If an operator can have more than one > + IMS-APN with different set of pcscf servers, > + this property must be moved to the > + ConnectionContext object. Should this be in the context object? The AT command is per CID. Would it make any sense for a network to have different P-CSCF based on the bearer? > +IP Multimedia Identities hierarchy [experimental] > +================================== > + > +Service org.ofono > +Interface org.ofono.IpMultimediaIdentities > +Object path [variable prefix] > + > + > +Methods dict GetProperties() > + > + Returns all IMS identitiy properties. > + > + Possible Errors: [service].Error.InvalidArguments > + > + NOTE: No PropertyChanged signal is supported. > + Technically it is possible for provisioning > + to update these identities, but 3gpp TS31.103 > + discourages this. > + > +Properties string PrivateIdentity [readonly] > + > + The Private Identity is used to allow the UE access > + to the IMS network (registration, authorization, > + administration and billing). > + > + array{string} PublicIdentity [readonly] > + > + The Public Identity is used to identify a specific > + IMS user (there may be more than one associated > + with one Private Identity). This information is conveyed > + to the IMS Network during registration so that the > + network can know what IMS users that are registered and > + available for service (e.g. a reception of a voice > + session). > + > + string HomeDomainName[readonly] > + > + Identity used for IMS registration. -- Rémi Denis-Courmont Nokia Devices R&D, Maemo Software, Helsinki