Re: [RFCv2] doc: Proposal for LTE/IMS API
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. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [RFCv2] doc: Proposal for LTE/IMS API
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 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFCv2] doc: Proposal for LTE/IMS API
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
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [RFCv2] doc: Proposal for LTE/IMS API
On Tuesday 08 February 2011 16:29:17 ext Sjur Brændeland, you wrote: From: Sjur Brændeland sjur.brandel...@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 000..5404e61 --- /dev/null +++ b/doc/ims-api.txt @@ -0,0 +1,162 @@ +Ip Multimedia Subsystem hierarchy [experimental] += + +Service org.ofono +Interfaceorg.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
Re: [RFCv2] doc: Proposal for LTE/IMS API
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
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [RFCv2] doc: Proposal for LTE/IMS API
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 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFCv2] doc: Proposal for LTE/IMS API
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 RD, Maemo Software, Helsinki
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
