Re: [RFC] doc: Proposal for LTE/IMS API.

[Sjur =?unknown-8bit?q?Br=C3=A6ndeland?= <sjurbren@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5311 bytes --]

Hi Arun,

>>  +        string  PrivateImsIdentity [readonly, optional]
>>  +
>>  +            Identity used for IMS registration.
>>  +            Available if present on the ISIM.
>>  +
>>  +        string  PublicImsIdentity [readonly, optional]
>>  +
>>  +            Identity used for IMS registration.
>>  +            Available if present on the ISIM.
>>  +
>>  +        string  HomeDomainName[readonly, optional]
>>  +
>>  +            Identity used for IMS registration.
>>  +            Available if present on the ISIM.
>>  +
>
> Will these not be known to the user?
> When does this interface becomes alive (org.ofono.ims)? post_sim or
> post_online?

These are read from the ISIM, so I believe this should be available post_sim.

>>  +        string  ImsToCsHandoverStatus [readonly, optional]
>>  +
>>  +            Indicate the handover progress status during a CS
>>  +            fallback procedure. This property will only be present
>>  +            when in LTE coverage. The possible values are:
>>  +            "none", "started","complete", "failure".
>>  +            Related AT URC: +CIREP
>>  +
>
> Again which specification details these AT commands?. Do we need a property
> like this to show the CSFB?

ImsToCsHandoverStatus is the progress notification of the actual
handover from LTE to CS,
I believe this information will be needed for setting up the CMT
device (CS Audio) and
knowing when to switch from IMS Audio to CS Audio streams.

> why can't we...
>
> while in LTE:
>    oFono has network registration, connection manager, SIM and LTE
>    specific interfaces
>
> while in CSFB :
>    oFono has all other interfaces too.

Yes, agree.
CSFB will look similar to the case where you loose your LTE coverage
and move to WCDMA/GSM. You will have the same oFono APIs available
in both cases, regardless of how the change was initiated.


>>  +        array{dict,array{dict}} QosFilters [readonly, optional]
>>  +
>>  +            Information about the QoSes and associated Packet
>>  +            Filters for the Default PDN and it's dedicated bearers.
>>  +            It is organized as a list of QoS definitions with
>>  +            a list of corresponding packet filters.
>>  +
>>  +                uint8 QoSClassIdentifier [readonly]
>>  +                    The numeric parameter that specifying
>>  +                    the class of QoS. (3GPP TS 23.203 [85])
>>  +                    0    QCI is selected by network
>>  +                    [1 – 4] guaranteed bit rate
>>  +                    [5 – 9] non-guaranteed bit rate
>>  +
>>  +                uint16 UplinkRate [readonly, optional]
>>  +                    Guaranteed Uplink Bit-rate in kb/sec.
>>  +
>>  +                uint16 DownlinkRate [readonly, optional]
>>  +                    Guaranteed Downlink Bit-rate in kb/sec.
>>  +
>>  +            For each QoS defined there may be a list of Packet
>>  +            Filters. Each Packet Filter is a dictionary defining
>>  +            the filter. An empty Packet Filter represents the
>>  +            "default" filter (Default PDN connection).
>>  +
>>  +                string Direction [readonly]
>>  +                    "uplink", "downlink", "bidirectional"
>>  +
>>  +                uint8 ProtocolNumber [readonly]
>>  +                    IP protocol number (0-256)
>>  +
>>  +                string PeerAddress [readonly]
>>  +                    The remote peer's IP address.
>>  +
>>  +                uint16 PeerPortMin [readonly]
>>  +                    Remote peer's port number min. value
>>  +
>>  +                uint16 PeerPortMax [readonly]
>>  +                    Remote peer's port number max. value
>>  +
>>  +                uint16 LocalePortMin [readonly]
>>  +                    The local port number min. value
>>  +
>>  +                uint16 LocalPortMax [readonly]
>>  +                    The local port number max. value
>>
>
> Do we really need this?. What is the real usage of this information?.
> In 27.007 there are few AT commands for TFT, and are not used, may be
> because no body (operator) supports this.
>
> In LTE will this be going to be different?

In LTE the network will be responsible for setting up Dedicated
Bearers (Secondary PDPs).
And I believe the IMS application needs information about the
TFT/QoSes when setting up a call.

BTW, did you see the response from Kai earlier in this mail thread?
[kai.vehmanen(a)nokia.com wrote:]
>this is used e.g. for SDP preconditions mechanism used in IMS:
>http://www.faqs.org/rfcs/rfc3312.html
>The QoS is signalled on a per port/media basis, so relaying
>the packet-filters seems like a sane approach to me (cannot really
>say the same about 3312, but that's a different thing ;P).


Regards,
Sjur