Hi Daniel, > >>> 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. 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. > > 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. 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. Regards Marcel _______________________________________________ connman mailing list [email protected] http://lists.connman.net/listinfo/connman
