Barring API

Barring API

[Pekka Pessi]

[-- Attachment #1: Type: text/plain, Size: 2704 bytes --]

Hi all,

I had a quick peek on barring API which is currently undocumented.

It seems to me that there is a good reason for it being documented as
the properties by GetProperties() returned are different from the
properties emitted. I kinda like the the emitted properties
(VoiceIncoming and VoiceOutgoing), they seem to capture the
functionality of the barring services as well as the limitations of
both the air and AT interface pretty well.

Here is my stab at the D-Bus API documentation; as it is, the
GetProperties takes 5 air operations in the most pessimal case (~25
seconds if all goes well on UMTS). There should probably be different
atoms for Fax, Data/Video and SMS, if someone ever needs them. Adding
them to this atom does not seem feasible as any basic service might
require 5 new AT+CLCK commands with ~5 seconds delay each.

--Pekka

--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--
Voice Call Barring hierarchy
============================

Service		org.ofono
Interface	org.ofono.CallBarring
Object path	[variable prefix]/{modem0,modem1,...}

Methods		dict GetProperties()

			Contains the properties for this object.

		void ChangePassword(string old_password, string new_password)

			Register new network password for the barring
			services.

		void DisableAll(string password)

			Disables all voice call barrings.

		void DisableAllIncoming(string password)

			Disables barrings for incoming voice calls.

		void DisableAllOutgoing(string password)

			Disables barrings for outgoing voice calls.

		void SetProperty(string property, variant value)

			Sets the given property value to that specified in
			call parameter.

Signals		PropertyChanged(string property, variant value)

			Signal is emitted whenever a property has changed.  The new
			value is passed as the signal argument.

Properties	string VoiceIncoming [readwrite]

			Contains the value of the barrings for the incoming
			voice calls. The possible values are
			- "always": bar all incoming calls
			- "whenroaming": bar incoming calls when roaming,
			or
			- "" if no barring is active

		string VoiceOutgoing [readwrite]

			Contains the value of the barrings for the outgoing
			voice calls. The possible values are
			- "all": bar all outgoing calls
			- "international": bar all outgoing international calls
			- "internationalnothome": bar all outgoing
			international calls except to home country
			- "" if no barring is active
--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<--

-- 
Pekka.Pessi mail@nokia.com

Re: Barring API

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 3590 bytes --]

Hi Pekka,

> Hi all,
> 
> I had a quick peek on barring API which is currently undocumented.
> 
> It seems to me that there is a good reason for it being documented as
> the properties by GetProperties() returned are different from the
> properties emitted. I kinda like the the emitted properties
> (VoiceIncoming and VoiceOutgoing), they seem to capture the
> functionality of the barring services as well as the limitations of
> both the air and AT interface pretty well.

The signals and properties are actually different.  The signals are reported 
via IncomingBarringInEffect and OutgoingBarringInEffect are reported by the 
classical 27.007 modem through +CSSI/+CSSU.  They're just simple notifications.  
The PropertyChanged is what reports the changes in properties.

> 
> Here is my stab at the D-Bus API documentation; as it is, the
> GetProperties takes 5 air operations in the most pessimal case (~25
> seconds if all goes well on UMTS). There should probably be different
> atoms for Fax, Data/Video and SMS, if someone ever needs them. Adding
> them to this atom does not seem feasible as any basic service might
> require 5 new AT+CLCK commands with ~5 seconds delay each.

We query all basic services at once, so in theory there should be no extra 
time needed for Fax, Data, SMS, etc.  The attributes are simply never exposed 
today.

> 
> --Pekka
> 
> --8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8
> <----8<----8<----8<----8<-- Voice Call Barring hierarchy
> ============================
> 
> Service		org.ofono
> Interface	org.ofono.CallBarring
> Object path	[variable prefix]/{modem0,modem1,...}
> 
> Methods		dict GetProperties()
> 
> 			Contains the properties for this object.
> 
> 		void ChangePassword(string old_password, string new_password)
> 
> 			Register new network password for the barring
> 			services.
> 
> 		void DisableAll(string password)
> 
> 			Disables all voice call barrings.
> 
> 		void DisableAllIncoming(string password)
> 
> 			Disables barrings for incoming voice calls.
> 
> 		void DisableAllOutgoing(string password)
> 
> 			Disables barrings for outgoing voice calls.
> 
> 		void SetProperty(string property, variant value)
> 
> 			Sets the given property value to that specified in
> 			call parameter.
> 
> Signals		PropertyChanged(string property, variant value)
> 
> 			Signal is emitted whenever a property has changed.  The new
> 			value is passed as the signal argument.

Can you also document the two other signals as well? They're informational 
only.

> 
> Properties	string VoiceIncoming [readwrite]
> 
> 			Contains the value of the barrings for the incoming
> 			voice calls. The possible values are
> 			- "always": bar all incoming calls
> 			- "whenroaming": bar incoming calls when roaming,
> 			or
> 			- "" if no barring is active
> 
> 		string VoiceOutgoing [readwrite]
> 
> 			Contains the value of the barrings for the outgoing
> 			voice calls. The possible values are
> 			- "all": bar all outgoing calls
> 			- "international": bar all outgoing international calls
> 			- "internationalnothome": bar all outgoing
> 			international calls except to home country
> 			- "" if no barring is active

Otherwise the documentation looks great.  Can you submit it using git-format-
patch or git-send-email so I can easily apply it with proper attribution?

> --8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8
> <----8<----8<----8<----8<--
> 

Regards,
-Denis

Re: Barring API

[Pekka Pessi]

[-- Attachment #1: Type: text/plain, Size: 868 bytes --]

2010/3/16 Denis Kenzior <denkenz@gmail.com>:
> The signals and properties are actually different.  The signals are reported
> via IncomingBarringInEffect and OutgoingBarringInEffect are reported by the
> classical 27.007 modem through +CSSI/+CSSU.  They're just simple notifications.
> The PropertyChanged is what reports the changes in properties.

Oh, looks like there was a bug in get_query_lock_callback() that I
could not figure out. It returned the initial reply based on the old
state and emitted signals based on the new state. I've sent patches,
too.

> We query all basic services at once, so in theory there should be no extra
> time needed for Fax, Data, SMS, etc.  The attributes are simply never exposed
> today.

Yes, it seems to me that you are right, I did not read the 27.007
closely enough.

-- 
Pekka.Pessi mail at nokia.com