User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.76 Safari/537.36 Steps to reproduce: Request for multiple dataCall bring ups, say for example supl and default Actual results: Received DataCallStateChanged, but the nsIRILDAtaCallInfo does not indicate for which call type the dataCall state has changed. Expected results: In the callback we should know somehow for which dataCall type we have received the state change

Moving to 1.4+ as it blocks QC CS.

What is the user's use case? AFAIk the Dialer app can do without this just fine.

(In reply to Julien Wajsberg [:julienw] from comment #2) > What is the user's use case? AFAIk the Dialer app can do without this just > fine. Sorry, nothing related to the Dialer here, forget my noise. But knowing what you're trying to achieve would still help.

The use case here is to bring -up two DataCalls at the same time, for example supl and default data call.

Removed it from v1.4 FC blockers list. The above comment got saved incomplete, stating it again here: The use case here is to bring -up two DataCalls at the same time, for example supl and default data call. so if we have started 2 datacalls we are waiting for 2 DataCallStateChanged callbacks which really do not indicate for which dataCall type the callback is ?

Listing out again the need for this interface change: 1. On receiving the DataCallStateChanged callback the caller has no idea the callback is for which data call type, whether its for supl, default etc. 2. if a data call is already connected, then we only need to find its corresponding APN and the APN bearer type i.e. whether the it is a IPV4, IPV6 or both. APN can be found using querying for ril.data.apn property, but to find the bearer type we still need to request for the DataCallList. Now when iterating through this list the caller will not know the type of the DataCall to match. for example if the caller is interested in only supl data call, then from the list how does the caller know which one one of them is for SUPL ? Phil, suggested matching the apn string from the nsirildatacallinfo, but its just way to going around than required.

As mentioned by Bhavna, there is no easy and direct way to get a lot of information out of an existing data call. The only way to currently get to the information is to get the apn settings from ril.data.apnSettings, figure out which APN on which subscription matches the type you care about, while preemptively monitoring all data call changes via nsIRadioInterface::RegisterDataCallCallback(). At this point if nsIRadioInterface::GetDataCallStateByType("supl") returns true, you'd have to examine your saved list of nsIRILDataCallInfo, try to match the APN that you pulled from the apn settings, and hope that you've got the right connection. From there you can then look back at the apn settings to see what protocol is being used for that call (ipv4, ipv6, ipv4v6, ppp, etc...) This is a lot more trouble than it should be, and a lot more error prone. Having the supported types as part of nsIRILDataCallInfo would help alleviate the issue, along with probably adding the protocol used. Further along that path, it would probably be nice to have nsIRadioInterface::GetRILDataCallInfoByType(nsAString aType) available. Then the code could wouldn't have to rely on passively listening to all data call changes, it could just fetch the information it needs when it needs it.

I agree, nsIRadioInterface::GetRILDataCallInfoByType(nsAString aType) seems to be the right way to get hold of all DataCallInfo information in one call. Anshul, can you help drive this ?

mvines - This is jumping in & out of being a FC blocker. Triage is confused on what to do here. Can you figure out if you need this or not.

this is a nice to have for developers, but it can't possibly be blocking.

Hi Smith, I am sorry about the big moving in and out of FC blocking but the need for it has become important now because of having no straight forward way of getting DataCallInfo from a radio interface. Location client is an extensive user of the DataCallInfo member like apn, apn bearer type etc. Lets just jump to issue we are for which I am requesting for the nsIRadioInterface::GetRILDataCallInfoByType(nsAString aType). There are 2 ways that we get the DataCallInfo 1. If data connection is not already up then we request for SetupDataCallByType and just receive the DataCallInfo in the DataCallStateChange callback. 2. But if the data call is not up then we used to query for the ril.data.apn to get the APN string. This was fairly straight forward, but this change (https://bugzilla.mozilla.org/show_bug.cgi?id=842252) has caused a regression now and we need to get a list of APN's , filter it out based on what radio interface we are using and further filter it out based on what DataCall type we are interested in. Just way too much overhead and error prone. If we simply get this interface nsIRadioInterface::GetRILDataCallInfoByType(nsAString aType), the client does not have to do any filtering based on radio interface or DataCall type. I understand that there will always be a work around but its too much overhead on a client who really does not want to know about the complete list of APN's. This has been jumping in and out of FC blocker because the type filed i had earlier requested for had a simple work around but now with the APN fetching change, its way too much overhead. - Bhavna

Okay - will discuss this more in tomorrow's triage.

Bhavna Can we wait to do a correct fix in 1.5 instead?

Hi Preeti, This issue was brought up in January itself, which was way before v1.4. The work around for this issue is pretty unclean. - Bhavna

Bhavna, I know this bug has been on file for a while, but let's discuss given when we currently are. Inder will update the bug soon to clarify the position.

Hi Bhavna, as you, anshul and I discussed before, we all agreed that this was a refactor and should not be a 1.4 blockers. Futhermore, there is already a plan to do a refactor for current design(you can check bug 904514 and 939046). But it's not a simple modification and we should not rush in having a workaround solution in current stage.

Thanks all for the discussion. Based on the feedback, removing the blocker.

Closing this issue as per my discussion with Wesley.

(In reply to Bhavna Sharma from comment #11) > Hi Smith, > > I am sorry about the big moving in and out of FC blocking but the need for > it has become important now because of having no straight forward way of > getting DataCallInfo from a radio interface. Location client is an extensive > user of the DataCallInfo member like apn, apn bearer type etc. > > Lets just jump to issue we are for which I am requesting for the > nsIRadioInterface::GetRILDataCallInfoByType(nsAString aType). Maybe a little too late, but we'd really want to eliminate the use of data call callbacks. Related interfaces are supposed to be removed in bug 978709 for IPV4V6. For your use scenario here, I believe the thing you really need is to sub-class nsIRILDataInfo: interface nsIDerivedRilDataInfo : nsIRILDataInfo { readonly attribute DOMString type; // "mms", "supl", "default", etc. }; Then when you want to instantiate a nsIRILDataInfo, use nsIDerivedRilDataInfo instead. Then you can still pass it to data call callbacks while having a new attribute 'type' that you're desperate for. No interface is changed. As for the removed register/unregister function in nsIRadioInterface in bug 978709, the same trick applies. interface nsIDerivedRadioInterface : nsIRadioInterface { void registerDataCallCallback(in nsIRILDataCallback); void unregisterDataCallCallback(in nsIRILDataCallback); }; I don't really recommend this, but that's an easy solution. And the most important of all, you don't get blocked. You can do whatever you want in private.