10:28 p.m.
Hi Sjur,
doc/ims-api.txt | 119
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 119 insertions(+), 0 deletions(-)
create mode 100644 doc/ims-api.txt
+Properties boolean ImsVoiceRegistered [readwrite, optional]
+
+ Inform modem's radio stack that the IMS application
+ has registered for Voice over IMS. This impacts
+ "UE Mode of operation" and the ISR feature in the
+ radio stack. Related AT command: AT+EISR
+
+ boolean ImsSmsRegistered [readwrite, optional]
+
+ Inform modem's radio stack that the IMS application
+ has registered for SMS over IMS. This impacts
+ "UE Mode of operation" and the ISR feature in the
+ radio stack. Related AT command: AT+EISR
+
+ boolean ImsVoiceOverPs [readonly, optional]
+
+ IMS voice is enabled by network
+ Related AT command: AT+CIREP.
+
Which specification details this AT command, searched in 27.007 rel 10, but it is
not available there.
Isn't ISR a property by default a UE should have when it is registered to LTE?. 23.401
says ISR support is mandatory for E-UTRAN UEs that support GERAN and/or UTRAN and optional
for the network.
i don't think this setting should affect ISR behavior.
+ 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?
+ 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?
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.
+ array{string} PcscfAddresses[readonly]
+
+ Domain Name or IP Address of the P-CSCF servers.
+ (SIP Proxy).
+
This should be optional property based on the service table information.
+ 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?
regards
Arun
2:11 a.m.
New subject: [RFC] doc: Proposal for LTE/IMS API.
Hi Arun,
2011/1/28 Arun Ravindran <ext-arun.1.ravindran(a)nokia.com>:
> + boolean ImsVoiceOverPs [readonly, optional]
> +
> + IMS voice is enabled by network
> + Related AT command: AT+CIREP.
> +
Which specification details this AT command, searched in 27.007 rel 10, but
it is not available there.
According to the 27.007 CRs, it should be in 10.0.0:
http://www.3gpp.org/ftp/specs/html-info/27007-CRs.htm
My copy is 10.2., and it has CIREP along with +CIREPI,+ CIRPEH and +CISRVCC,
Isn't ISR a property by default a UE should have when it is
registered to
LTE?. 23.401 says ISR support is mandatory for E-UTRAN UEs that support
GERAN and/or UTRAN and optional for the network.
i don't think this setting should affect ISR behavior.
The ISR means that device is registered to both 2G/3G and LTE. It
might receive pagings from both of these radio networks. However, the
network needs to know if the currently available radio network
supports PS voice or not, so the device has to update its state when
changing between LTE radio supporting PS voice and other radio not
supporting it.
--
Pekka.Pessi mail at nokia.com
11:15 p.m.
New subject: [RFC] doc: Proposal for LTE/IMS API.
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
12:12 a.m.
New subject: [RFC] doc: Proposal for LTE/IMS API.
Hi,
On 31 Jan 2011, Sjur Brændeland wrote:
> Sjur Brændeland wrote:
>> + array{dict,array{dict}} QosFilters [readonly, optional]
>> +
>> + Information about the QoSes and associated Packet
>> + Filters for the Default PDN and it's dedicated
Arun Ravindran wrote:
> 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.
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
just to add to this: some information about the traffic filters
is most definitely needed (RFC3312 is needed to set up calls
according to TS24.229 and e.g. GSMA IR.92 ([1] a profile using 24.229)).
So in short the idea is that phone should not start alerting
before it has got a confirmation it has a voice-ready data connection
set up (including QoS).
But as the modem is just a IP transport in this case and does not know
which ports (nor even which protocols) are used for voice (and which media
streams are used by the application), it is really hard to prune down
the list of information provided via oFono with 'QosFilters'. In the
end it's the application that needs to check all the IP flows needed
for the call are covered by sufficient QoS, before continuing the call
establishment.
So I'm not sure what the strategy should be.. expose the full
27.007 set, expose list based on what the first modems implementing
the interface support, or prune the list based on some known application
(e.g. IR.92 profile of TS24.229), or something in between.
The oFono design principle of '4.2 Minimal & Complete' is not so easy
to apply when doing something new... ;)
[1] http://gsmworld.com/documents/IR9230.pdf
4248
days inactive
4251
days old
3 comments
4 participants
participants (4)
-
Arun Ravindran -
Kai.Vehmanen＠nokia.com -
Pekka Pessi -
Sjur Brændeland