[RFCv2] doc: Proposal for LTE/IMS API

[RFCv2] doc: Proposal for LTE/IMS API

[Sjur =?unknown-8bit?q?Br=C3=A6ndeland?=]

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

From: Sjur Brændeland <sjur.brandeland@stericsson.com>

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]
+
+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".
+
+			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.
+
+			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.
+
+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.
+
+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.
-- 
1.6.3.3

Re: [RFCv2] doc: Proposal for LTE/IMS API

[=?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont]

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

On Tuesday 08 February 2011 16:29:17 ext Sjur Brændeland, you wrote:
> From: Sjur Brændeland <sjur.brandeland@stericsson.com>
> 
> 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

Re: [RFCv2] doc: Proposal for LTE/IMS API

[Sjur =?unknown-8bit?q?Br=C3=A6ndeland?=]

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

Hi Rémi,

> > +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.

Yes, this should be the modem object path. I'll fix this in the next patch.

> > +             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.

Yes, an array of strings might be a good idea here.

....
> > +             boolean PreConditionCheck(string Type, string PeerAddress,
> > +                                     uint16 PeerPort,  uint16 LocalPort)
> > +
> That stuff is per context. Should it not be in the context object rather than
> in the IMS manager?

oFono should only consider QoS information from the IMS
Default and Dedicated bearers when checking the precondition.

In theory there might be more than one IMS APN for a operator,
but I really don't see this as a real life scenario for this.
If anyone disagrees please speak out and explain...

> > +             array{string} PcscfAddresses [readonly]
> 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?

As mentioned above, I don't see why an operator would ever have more than
one IMS APN. If we only have one IMS APN, then we might as well present
this information here in the IMS API.


Regards,
Sjur

Re: [RFCv2] doc: Proposal for LTE/IMS API

[=?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont]

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

On Tuesday 08 February 2011 18:22:43 ext Sjur Brændeland, you wrote:
> > > +             boolean PreConditionCheck(string Type, string
> > > PeerAddress, +                                     uint16 PeerPort,
> > >  uint16 LocalPort) +
> > 
> > That stuff is per context. Should it not be in the context object rather
> > than in the IMS manager?
> 
> oFono should only consider QoS information from the IMS
> Default and Dedicated bearers when checking the precondition.
> 
> In theory there might be more than one IMS APN for a operator,
> but I really don't see this as a real life scenario for this.
> If anyone disagrees please speak out and explain...

Well, I don't care if it is part of the normal context interface, or if it is 
an extra IMS-specific interface on the IMS context object path. But this is 
clearly a per-context thing so it should be in the context.

I don't want to end up in a 'woops' situation down the line. And I don't trust 
operators not to actually implement those useless in real life scenarii...

> > > +             array{string} PcscfAddresses [readonly]
> > 
> > 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?
> 
> As mentioned above, I don't see why an operator would ever have more than
> one IMS APN. If we only have one IMS APN, then we might as well present
> this information here in the IMS API.

How do you cope with two connections to the same APN?

-- 
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki

Re: [RFCv2] doc: Proposal for LTE/IMS API

[Sjur =?unknown-8bit?q?Br=C3=A6ndeland?=]

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

Hi Rémi,

>> > > +             boolean PreConditionCheck(string Type, string
>> > > PeerAddress, +                                     uint16 PeerPort,
>> > >  uint16 LocalPort) +
>> >
>> > That stuff is per context. Should it not be in the context object rather
>> > than in the IMS manager?
>>
>> oFono should only consider QoS information from the IMS
>> Default and Dedicated bearers when checking the precondition.
>>
>> In theory there might be more than one IMS APN for a operator,
>> but I really don't see this as a real life scenario for this.
>> If anyone disagrees please speak out and explain...
>
> Well, I don't care if it is part of the normal context interface, or if it is
> an extra IMS-specific interface on the IMS context object path. But this is
> clearly a per-context thing so it should be in the context.
>
> I don't want to end up in a 'woops' situation down the line. And I don't trust
> operators not to actually implement those useless in real life scenarii...

One option could be to keep it here in the IMS API but
to include the Local IP Address as a argument to the PreConditionCheck.
This fits quite nicely with the QoS SIP Precondition operation and can
easily be used
by oFono core to map to the right APN.

There is still a theoretical problem here if you get the same Home Address from
two IMS APN, If anyone think this is an issue I'll throw in the towel
and move the
PreConditionCheck to the ConnectionContext object ;-)

Anyway, I think either solution would work just fine.
In terms of the "separation of concern" i think keeping it here is the
best solution,
but putting it in the ConnectionContext is more flexible.

I'm not going to keep arguing for this forever ;-)

>> > > +             array{string} PcscfAddresses [readonly]
>> >
>> > 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?
>>
>> As mentioned above, I don't see why an operator would ever have more than
>> one IMS APN. If we only have one IMS APN, then we might as well present
>> this information here in the IMS API.
>
> How do you cope with two connections to the same APN?

3GPP TS 24.229,  B.2.2.1 "PDP context activation and P-CSCF discovery",
describes that the P-CSCF can be provided as dynamic parameter with the
PDN connection, stored on the ISIM, or by provisioning. As far as I understand
this It is up to the IMS application to select which one of the P-CSCF
addresses it should use.

So I think the best would be to expose the P-CSCF address stored on ISIM
in the IMS API, and move add the P-CSCF provided with the PDN Connection
to the ConnectionContext API.


Regards,
Sjur

RE: [RFCv2] doc: Proposal for LTE/IMS API

[Kjetil ASDAL]

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

Hi Rémi,

Rémi wrote:
> > +			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.

We should remove the reference above as it is incorrect. There is 
no standard AT command specified for this as of today, however, we 
will be entering a CR on 3GPP TS 27.007 in the upcoming meeting to 
address the lack of such a command.

BR
Kjetil

RE: [RFCv2] doc: Proposal for LTE/IMS API

[Soum, RedouaneX]

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

Hi Sjur,


> +		void Register(string type)
> +
> +			Register a IMS Application. It must register
> +			with one of the types:
> +			"voice", "messaging", "voice_messaging".
> +
> +			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.
> +
> +			Possible Errors: [service].Error.InvalidArguments
> +
> +		void UnRegister(object path)
> +
> +			Un-register a IpMultimediaSubsystemAgent.

Register and UnRegister functions are not really symmetric here ...
How object path is used by UnRegister function ??

Maybe we should have :

void UnRegister(string type)

> +
> +			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.
> +

How to make the link between the primary context (or default bearer) activated by the IMS client , 
and the TFT and QOS.

We can imagine that we have a good QOS / TFT but it doesn't belong to the primary context (or default bearer) activated by the IMS client.


> +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
> +

Same here , IMS client will be notified for all dedicated bearer ?

I agree with Rémi, it 'll be better if we can put QOS/TFT somewhere under primary context.



Regards,
---------------------------------------------------------------------
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.

Re: [RFCv2] doc: Proposal for LTE/IMS API

[Sjur =?unknown-8bit?q?Br=C3=A6ndeland?=]

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

Hi Redouane,

>> +             void UnRegister(object path)
>> +
>> +                     Un-register a IpMultimediaSubsystemAgent.
>
> Register and UnRegister functions are not really symmetric here ...
> How object path is used by UnRegister function ??
> Maybe we should have :
> void UnRegister(string type)

Thanks for spotting this, it's a bug. It should have been
"void UnRegister()". I'll fix this in the next patch.

>> +             boolean PreConditionCheck(string Type, string PeerAddress,
>> +                                     uint16 PeerPort,  uint16 LocalPort)
>
> How to make the link between the primary context (or default bearer) activated by the IMS client ,
> and the TFT and QOS.

When Dedicated bearers are created  +CGEV: NW ACT reports both the
Default Bearer and the Dedicated bearer.

> We can imagine that we have a good QOS / TFT but it doesn't belong to the primary context (or default bearer) activated by the IMS client.

As mentioned to Rémi, we should only consider the QoS/TFT for the IMS
ConnectionContext
and related Dedicated Bearers. So oFono core only needs to keep track
of the QoS/TFTs for IMS.

>> +             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
>> +
>
> Same here , IMS client will be notified for all dedicated bearer ?
> I agree with Rémi, it 'll be better if we can put QOS/TFT somewhere under primary context.

I believe we will have only one IMS APN for each operator, so we might
as well keep it here in
the IMS Interface.


Regards,
Sjur

Re: [RFCv2] doc: Proposal for LTE/IMS API

[Fallon, Michael F]

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

>> In theory there might be more than one IMS APN for a operator,
>> but I really don't see this as a real life scenario for this.
>> If anyone disagrees please speak out and explain...

One such scenario is the in-vehicle use model, where the ISP provides network connectivity via one APN and the auto manufacturer has network connectivity through a separate, private, and independent APN. Connectivity, billing, bandwidth, reliability, roaming etc are all independent for each network. For example, auto manufacturer X may contract with ISP Y for remote access to the car, while the owner of the car may prefer ISP Z for personal use.

[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 5564 bytes --]

Re: [RFCv2] doc: Proposal for LTE/IMS API

[Marcel Holtmann]

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

Hi Michael,

> >> In theory there might be more than one IMS APN for a operator,
> 
> >> but I really don't see this as a real life scenario for this.
> 
> >> If anyone disagrees please speak out and explain...
> 
>  
> 
> One such scenario is the in-vehicle use model, where the ISP provides
> network connectivity via one APN and the auto manufacturer has network
> connectivity through a separate, private, and independent APN.
> Connectivity, billing, bandwidth, reliability, roaming etc are all
> independent for each network. For example, auto manufacturer X may
> contract with ISP Y for remote access to the car, while the owner of
> the car may prefer ISP Z for personal use.

and this case actually has two fully independent radio modules. One for
the consumer and one for the car manufacturer. And the car manufacturer
GSM/UMTS hardware has normally a builtin SIM card that can not be
removed. For obvious reasons of misuse.

Regards

Marcel