1:59 a.m.
From: Sjur Brændeland <sjur.brandeland(a)stericsson.com>
Features:
- The QoS information is presented as an array of QoS settings with
an associated list IP Packet Filters. Only the QoS data for
connection context of type IMS will be reported.
The assumption is that QoS is only going to be used by IMS applications.
Initially I was planning to put this in the connman-api.txt, but based
on feedback from Denis in the Paris workshop I have moved this to the
IMS API. If this assumption proves wrong QoS should be moved to
ConnectionContext interface.
The UE initiates the Default Bearer. In R8, the Network may then
initiate a number of Dedicated Bearers. Each Dedicated Bearer will
have a defined QoS. In order to route the IP traffic into the
different Dedicated Bearers, a set of Packet Filters can be defined
for each Dedicated Bearer.
- The UE-Mode of operation, is primarily triggered by IMS application
registering to the RadioStack that it has registered on Voice and/or
SMS by setting the properties ImsVoiceRegistered or ImsSmsRegistered.
- SIM identities used for IMS registration such as: PrivateImsIdentity,
PublicImsIdentity, HomeDomainName.
- For SRVCC (IMS to CS handover) the property ImsToCsHandoverStatus
is added for providing handover progress information. This property
is currently a little futuristic, but is presented for completeness.
- ImsVoiceOverPs shows if Network supports IMS voice.
---
This is the initial RFC for the LTE/IMS API. Most of this (except
the QoS parts) has been presented in a worshop in Paris.Based on
input in the workshop I have created this new IMS API.
Feedback and comments are welcome :-)
I'm particularly interested to know if anything should be
removed (or added) from the QoS information. I would like to
see if we could do this any simpler.
Regards,
Sjur
doc/ims-api.txt | 119 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 119 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..865413f
--- /dev/null
+++ b/doc/ims-api.txt
@@ -0,0 +1,119 @@
+IMS hierarchy [experimental]
+=============================
+
+Service org.ofono
+Interface org.ofono.Ims
+Object path [variable]
+
+Methods dict GetProperties()
+
+ Returns all global system properties. See the
+ properties section for available properties.
+
+ Possible Errors: [service].Error.InvalidArguments
+
+ void SetProperty(string property, variant value)
+
+ Sets the property to a desired value
+
+ Possible Errors: [service].Error.InvalidArguments
+ [service].Error.InvalidFormat
+ [service].Error.Failed
+
+Signals PropertyChanged(string property, variant value)
+
+ This signal indicates a changed value of the given
+ property.
+
+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.
+
+ 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.
+
+ 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
+
+ array{string} PcscfAddresses[readonly]
+
+ Domain Name or IP Address of the P-CSCF servers.
+ (SIP Proxy).
+
+ 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
--
1.7.1
6:50 p.m.
Hello,
On Wednesday 26 January 2011 16:59:03 ext Sjur Brændeland, you wrote:
Features:
- The QoS information is presented as an array of QoS settings with
an associated list IP Packet Filters. Only the QoS data for
connection context of type IMS will be reported.
The assumption is that QoS is only going to be used by IMS applications.
Initially I was planning to put this in the connman-api.txt, but based
on feedback from Denis in the Paris workshop I have moved this to the
IMS API. If this assumption proves wrong QoS should be moved to
ConnectionContext interface.
What is this for? In my understanding, the LTE modem will do the classification
on outgoing packets - not the application engine. Indeed, based on the
proposed API, there is no way for the application engine to tag packet for the
benefit of the modem...
And we do not need to know anything about classification of incoming packets,
other than which primary context they belong to.
(...)
+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
I suppose this should be similar to Modem.Lockdown: only one D-Bus client can
set it (at a time), and it gets automatically cleared if said client dies.
+ 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
Ditto.
+ boolean ImsVoiceOverPs [readonly, optional]
+
+ IMS voice is enabled by network
+ Related AT command: AT+CIREP.
I guess the first two should not be settable if this one is false.
+ 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.
+
+ 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
+
+ array{string} PcscfAddresses[readonly]
+
+ Domain Name or IP Address of the P-CSCF servers.
+ (SIP Proxy).
+
+ 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
--
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki
7:29 p.m.
Hi Rémi,
> - The QoS information is presented as an array of QoS settings
with
> an associated list IP Packet Filters. Only the QoS data for
> connection context of type IMS will be reported.
>
> The assumption is that QoS is only going to be used by IMS applications.
> Initially I was planning to put this in the connman-api.txt, but based
> on feedback from Denis in the Paris workshop I have moved this to the
> IMS API. If this assumption proves wrong QoS should be moved to
> ConnectionContext interface.
What is this for? In my understanding, the LTE modem will do the classification
on outgoing packets - not the application engine. Indeed, based on the
proposed API, there is no way for the application engine to tag packet for the
benefit of the modem...
Yes, this is correct. The modem should take care of this.
And we do not need to know anything about classification of incoming
packets,
other than which primary context they belong to.
The point here is that the IMS application needs some information about
the QoS it actually got from the network. Apparently IMS-app needs this for
selecting appropriate codec-parameters to use. That's the only purpose
of presenting this information.
> +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
I suppose this should be similar to Modem.Lockdown: only one D-Bus client can
set it (at a time), and it gets automatically cleared if said client dies.
I assume you are right, but someone knowing more about the IMS application
should answer on this....
Regards,
Sjur
12:14 a.m.
Hi Sjur,
doc/ims-api.txt | 119
+++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 119 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..865413f
--- /dev/null
+++ b/doc/ims-api.txt
@@ -0,0 +1,119 @@
+IMS hierarchy [experimental]
+=============================
+
+Service org.ofono
+Interface org.ofono.Ims
+Object path [variable]
we are trying to not use abbreviations for the interface names. So maybe
something like org.ofono.MultimediaSubsystem would be better.
+Methods dict GetProperties()
+
+ Returns all global system properties. See the
+ properties section for available properties.
+
+ Possible Errors: [service].Error.InvalidArguments
+
+ void SetProperty(string property, variant value)
+
+ Sets the property to a desired value
+
+ Possible Errors: [service].Error.InvalidArguments
+ [service].Error.InvalidFormat
+ [service].Error.Failed
+
+Signals PropertyChanged(string property, variant value)
+
+ This signal indicates a changed value of the given
+ property.
+
+Properties boolean ImsVoiceRegistered [readwrite, optional]
Since the interface name already contains the reference to IMS, we did
avoid to have namespacing as part of the property names. So in this case
using VoiceRegistered would be more correct.
+ 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]
We did try not to use SMS etc. So maybe MessagingRegistered would be
better.
+
+ 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.
+
+ string PrivateImsIdentity [readonly, optional]
+
+ Identity used for IMS registration.
+ Available if present on the ISIM.
Same goes here, PrivateIdentify etc. I think you catch the drift.
+
+ 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.
+
+ 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
+
+ array{string} PcscfAddresses[readonly]
+
+ Domain Name or IP Address of the P-CSCF servers.
+ (SIP Proxy).
+
+ 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.
We really need to understand what the IMS application will need. If this
is about codecs or other things, then maybe oFono should give codec
advise directly. Proposals are welcome. Right now this looks like going
overboard.
Regards
Marcel
12:33 a.m.
Hi,
On 27 Jan 2011, Marcel Holtmann wrote:
> + 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.
We really need to understand what the IMS application will need. If
this is about codecs or other things, then maybe oFono should give codec
advise directly. Proposals are welcome. Right now this looks like going
overboard.
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).
12:48 a.m.
Hi Kai,
>> + 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.
>
> We really need to understand what the IMS application will need. If
> this is about codecs or other things, then maybe oFono should give codec
> advise directly. Proposals are welcome. Right now this looks like going
> overboard.
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).
OK, good to hear.
The 27007 spec specifies the following responses related to TFT/QoS:
+CGTFTRDP: <cid>,<packet filter identifier>,<evaluation precedence
index>,
<source address and subnet mask>,<protocol number (ipv4) / next header
(ipv6)>,
<destination port range>, <source port range>,<ipsec security
parameter index (spi)>,
<type of service (tos) (ipv4) and mask / traffic class (ipv6) and mask>,
<flow label (ipv6)>,<direction>,<NW packet filter Identifier>
+CGEQOSRDP:
<cid>,<QCI>,[<DL_GBR>,<UL_GBR>],[<DL_MBR>,<UL_MBR>]
I tried to pick the minimal set of interesting parameters,
but I would really love some feedback on this from someone who knows
more about the IMS requirements here.
Regards,
Sjur
3:52 a.m.
Hi Sjur,
2011/1/26 Sjur Brændeland <sjurbren(a)gmail.com>:
Features:
- The QoS information is presented as an array of QoS settings with
an associated list IP Packet Filters. Only the QoS data for
connection context of type IMS will be reported.
The assumption is that QoS is only going to be used by IMS applications.
Initially I was planning to put this in the connman-api.txt, but based
on feedback from Denis in the Paris workshop I have moved this to the
IMS API. If this assumption proves wrong QoS should be moved to
ConnectionContext interface.
The UE initiates the Default Bearer. In R8, the Network may then
initiate a number of Dedicated Bearers. Each Dedicated Bearer will
have a defined QoS. In order to route the IP traffic into the
different Dedicated Bearers, a set of Packet Filters can be defined
for each Dedicated Bearer.
I think we need these in ConnectionContext, or perhaps a separate
DedicatedContext interface would be better. The structure of QoS TFT
Also the PcscfAddresses should be part of the Settings or Settings6
in ConnectionContext.
- The UE-Mode of operation, is primarily triggered by IMS
application
registering to the RadioStack that it has registered on Voice and/or
SMS by setting the properties ImsVoiceRegistered or ImsSmsRegistered.
- SIM identities used for IMS registration such as: PrivateImsIdentity,
PublicImsIdentity, HomeDomainName.
These should be available from separate interface/object, one for each ISIM.
Otherwise, this looks fine. Rémi and Marcel had some other concerns...
--
Pekka.Pessi mail at nokia.com
4:37 a.m.
Hi Pekka,
> Features:
> - The QoS information is presented as an array of QoS settings with
> an associated list IP Packet Filters. Only the QoS data for
> connection context of type IMS will be reported.
>
> The assumption is that QoS is only going to be used by IMS applications.
> Initially I was planning to put this in the connman-api.txt, but based
> on feedback from Denis in the Paris workshop I have moved this to the
> IMS API. If this assumption proves wrong QoS should be moved to
> ConnectionContext interface.
> The UE initiates the Default Bearer. In R8, the Network may then
> initiate a number of Dedicated Bearers. Each Dedicated Bearer will
> have a defined QoS. In order to route the IP traffic into the
> different Dedicated Bearers, a set of Packet Filters can be defined
> for each Dedicated Bearer.
I think we need these in ConnectionContext, or perhaps a separate
DedicatedContext interface would be better.
Yes, as I mentioned earlier I considered this as well. But do you see other
scenarios than IMS where the NW will set up Dedicated Bearers?
Also the PcscfAddresses should be part of the Settings or Settings6
in ConnectionContext.
Do you think we will ever have more than one IMS ConnectionContext pr SIM?
If not not we could probably keep the PcscfAddresses in this IMS API (see
object-path proposal below).
> - The UE-Mode of operation, is primarily triggered by IMS
application
> registering to the RadioStack that it has registered on Voice and/or
> SMS by setting the properties ImsVoiceRegistered or ImsSmsRegistered.
>
> - SIM identities used for IMS registration such as: PrivateImsIdentity,
> PublicImsIdentity, HomeDomainName.
These should be available from separate interface/object, one for each ISIM.
I guess if you have more than one SIM, you would in fact have two
modem instances
and two instance of this API. In the next patch I should probably use
[{modem1},{modem2}...] as the
object-path of this IMS object.
Regards,
Sjur
4:55 a.m.
Hi Sjur,
2011/1/27 Sjur Brændeland <sjurbren(a)gmail.com>:
> I think we need these in ConnectionContext, or perhaps a
separate
> DedicatedContext interface would be better.
Yes, as I mentioned earlier I considered this as well. But do you see other
scenarios than IMS where the NW will set up Dedicated Bearers?
I have no idea. On the other hand, there should be a straightforward
way to correlate these and the context that uses them; retrieving them
from the context is such a straightforward way.
> Also the PcscfAddresses should be part of the Settings or
Settings6
> in ConnectionContext.
Do you think we will ever have more than one IMS ConnectionContext pr SIM?
If not not we could probably keep the PcscfAddresses in this IMS API (see
object-path proposal below).
Unfortunately, yes.
>> - The UE-Mode of operation, is primarily triggered by IMS
application
>> registering to the RadioStack that it has registered on Voice and/or
>> SMS by setting the properties ImsVoiceRegistered or ImsSmsRegistered.
>>
>> - SIM identities used for IMS registration such as: PrivateImsIdentity,
>> PublicImsIdentity, HomeDomainName.
>
> These should be available from separate interface/object, one for each ISIM.
I guess if you have more than one SIM, you would in fact have two
modem instances
and two instance of this API. In the next patch I should probably use
[{modem1},{modem2}...] as the
object-path of this IMS object.
ISIM is an application on SIM card (also known as UICC). There can be
multiple ISIMs on a single card but only a single USIM (3G SIM
application) or 2G SIM application.
--
Pekka.Pessi mail at nokia.com
11:25 p.m.
Hi Pekka.
> Do you think we will ever have more than one IMS
ConnectionContext pr SIM?
> If not not we could probably keep the PcscfAddresses in this IMS API (see
> object-path proposal below).
Unfortunately, yes.
Could you please elaborate on this.
Do you really foresee a scenario where an operator will provide more
than one IMS network?
Regards,
Sjur
4:53 a.m.
Hi Pekka, Sjur,
I think we need these in ConnectionContext, or perhaps a separate
DedicatedContext interface would be better. The structure of QoS TFT
Also the PcscfAddresses should be part of the Settings or Settings6
in ConnectionContext.
I prepared a patched in this way sometimes ago for the Dedicated Bearers maybe it can help
:
--
*** ofono-0.36/doc/connman-api.txt 2010-10-31 17:48:50.000000000 +0100
--- ofono-patched/doc/connman-api.txt 2010-12-09 17:44:32.694063480 +0100
***************
*** 132,141 ****
--- 132,163 ----
[service].Error.NotAttached
[service].Error.AttachInProgress
+ array{object,dict} GetSecondarys()
+
+ Get array of secondary context objects and properties.
+
+ The method should only be call once per application.
+ Further changes shall be monitored via SecondaryAdded
+ SecondaryRemoved signals.
+
+
Signals PropertyChanged(string property, variant value)
This signal indicates a changed value of the given
property.
+
+ SecondaryAdded(object path, dict properties)
+
+ Signal that gets emitted when a new secondary context has
+ been created. It contains the secondary context object path
+ and its properties.
+
+ SecondaryRemoved(object path)
+
+ Signal that gets emitted when a secondary context has been
+ removed. The object path of the secondary context is only
+ included for reference. Its properties are no
+ longer accessible at this point.
Properties boolean Active [readwrite]
***************
*** 239,241 ****
--- 261,350 ----
string MessageCenter [readwrite, MMS only]
Holds the MMSC setting.
+
+
+
+
+ Connection Secondary Context hierarchy
+ =================
+ Service org.ofono
+ Interface org.ofono.SecondaryConnectionContext
+ Object path /modemX/contextX/secondaryY
+
+
+ Methods void Close()
+ Deactivate secondary context (dedicated bearer in LTE)
+
+ array{object,dict} GetTFTs()
+
+ Get array of TFT objects and properties.
+
+ The method should only be call once per application.
+ Further changes shall be monitored via TFTAdded
+ TFTRemoved signals.
+
+ Signals TFTAdded(object path, dict properties)
+
+ Signal that gets emitted when a new context has
+ been created. It contains the context object path
+ and its properties.
+
+ TFTRemoved(object path)
+
+ Signal that gets emitted when a context has been
+ removed. The object path of the context is only
+ included for reference. Its properties are no
+ longer accessible at this point.
+
+ TFT hierarchy
+ =================
+ Service org.ofono
+ Interface org.ofono.TFT
+ Object path /modemX/contextX/secondaryY/TFTZ
+
+ Methods dict GetProperties()
+ Returns all properties for the context object.
+
+ Possible Errors: [service].Error.InvalidArguments
+
+ void SetProperty(string property, variant value)
+
+ Sets the property to a desired value
+
+ Possible Errors: [service].Error.InvalidArguments
+ [service].Error.InvalidFormat
+ [service].Error.Failed
+
+ object GetSecondaryContext()
+
+ Returns the related Secondary(dedicated) context
+
+
+ Signals PropertyChanged(string property, variant value)
+
+ This signal indicates a changed value of the given
+ property.
+
+ Properties string DestinationAddress [read]
+
+ Holds the destination Address
+
+ string SubnetMask [read]
+
+ Holds the SbunetMask
+
+ integer DestinationPortRangeStart [read]
+
+ Holds the destination port range start
+
+ integer DestinationPortRangeEnd [read]
+
+ Holds the destination port range end
+
+ integer SourcePortRangeStart [read]
+
+ Holds the source port range start
+
+ integer SourcePortRangeEnd [read]
+
+ Holds the source port range end
Regards,
Redouane.
---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris,
92196 Meudon Cedex, France
Registration Number: 302 456 199 R.C.S. NANTERRE
Capital: 4,572,000 Euros
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
9:22 p.m.
Hi Sjur,
ofono-bounces(a)ofono.org wrote:
- SIM identities used for IMS registration such as:
PrivateImsIdentity, PublicImsIdentity, HomeDomainName.
Correct me if I'm wrong. Private Identity is the one used for registration,
authorisation, administration and billing purposes whereas the Public Identity is the
identity by which the other parties know the subscriber. Basically, Public Identity is not
used for IMS registration.
+ string PrivateImsIdentity [readonly, optional]
+
+ Identity used for IMS registration.
+ Available if present on the ISIM.
+
May I know whats the use of making it available to the user?
EFimpi is a mandatory file on the ISIM, so it is available always if the ISIM is present
in an UICC card.
+ string PublicImsIdentity [readonly, optional]
+
+ Identity used for IMS registration.
+ Available if present on the ISIM.
There can be more than one public identity. And also public identity is not used for IMS
registration. same as EFimpi, EFimpu is a mandatory file on the ISIM.
+
+ string HomeDomainName[readonly, optional]
+
+ Identity used for IMS registration.
+ Available if present on the ISIM.
+
same as EFimpi and EFimpu, EFdomain is a mandatory file.
Correct me if I'm wrong. Domain name just indicates the home network of the
subscriber.
Is it really used for registration?
+ array{string} PcscfAddresses[readonly]
+
+ Domain Name or IP Address of the P-CSCF servers.
+ (SIP Proxy).
If I'm correct, this information also comes from the sim file EFp-cscf and it is
optional.
Regards,
Jeevaka
4248
days inactive
4253
days old
11 comments
7 participants
participants (7)
-
Jeevaka.Badrappan＠elektrobit.com -
Kai.Vehmanen＠nokia.com -
Marcel Holtmann -
Pekka Pessi -
Rémi Denis-Courmont -
Sjur Brændeland -
Soum, RedouaneX