Hi Marcel, On 10/18/2011 06:32 PM, Marcel Holtmann wrote: >>>>> To be honest this all sounds fine on the surface, but once I look at the >>>>> implications I am having problems to come up with a good reason on doing >>>>> this. I am currently not seeing this need. >>>> >>>> If an application knows that the data link is suspended it could stop >>>> all timeout timers because it doesn't make sense to keep them running. >>>> >>>> If the link resumes the timer can also be resumed. This is what I have >>>> heard is working quite good for our current implementation here and >>>> hence the request to have something similar around. >>>> >>>> I see that oFono exports this information through the Suspended property >>>> in the ConnectionManager API. I didn't see anything like this on the >>>> BlueZ APIs (when ConnMan uses PAN). So this information is already there >>>> and can be used at least for real modems. I don't really understand your >>>> argument about the implications. >>> >>> The oFono Suspended property is different. That is a GPRS network >>> specific details of suspended data connection when you get a phone call. >>> It is a limitation of being on a GSM network. And that one is just >>> present so the UI can tell the user that its connection got suspended. >> >> This is what I was trying to explain what I want to signal to the >> application. >> >>> Keep in mind that this is also only useful for a limited amount time >>> where the network holds your IP details and your TCP connection timeout >>> did not kick in. If we are talking of 1 hour phone call you are just out >>> of luck anyway. >> >> Sure, for short phone calls it should work although. > > So we could signal this. I was just more thinking of just signaling that > we lost the IP address. And give it back later.
The application could distinguish between temporary suspended and a real connection lost. Well, it is hard to tell either way. > This would make the logic in the application simpler, but it also means > that we can not survive small suspend windows. Or we have to do some > internal magic in keeping the IP address for some time before we expire > it. Not sure if you really have to make it that complicated for this. For those application I have in mind we have to read the oFono API's anyway (MCC, MNC, Signal Strength). Reading an additional value is easy. >>> So far enough, GSM networks can signal a suspended state while >>> potentially keeping the IP address (TCP connection might still timeout). >>> >>> Where else do you see this? >> >> I am not sure if this kind of information would accessible over >> Bluetooth if we have a smartphone connected to the head unit and we are >> doing HFP and PAN at the same time. Need to dig into the standards first. > > The suspend only happens on GSM. With UMTS you can have phone calls and > data connections at the same time. > > And for Bluetooth PAN, this is not exported. Seems that Apple is giving > out extra status information over mDNS when you are using Tethering, but > that is not really a standard. Oh, yet another funky Apple mDNS thing :) Adding Suspend to the Session API would only make sense if we are planing to integrate this. > It would be better to extend the PAN profile with these details, but I > have not yet seen an updated specification. Except for some APN > configuration settings and even these were early drafts. Would it make sense to bring this kind of request to their standardization group? It sounds like a reasonable thing to do... cheers, daniel _______________________________________________ connman mailing list [email protected] http://lists.connman.net/listinfo/connman
