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 _______________________________________________ ofono mailing list [email protected] http://lists.ofono.org/listinfo/ofono
