[Telepathy] Spec meeting: call forwarding, emergency calls, GSM conferences, Location interface network traffic, pre-composed DTMF strings

[Will Thompson]

Welcome to the first of what I hope will become a series of increasingly 
UK General Election-themed spec meeting notes!

The candidates:

• Simon “smcv” McVittie;
• Sjoerd “sjoerd” Simons;
• Will “wjt” Thompson.

The manifesto:

• Call forwarding;
• ServicePoint interfaces (emergency calls);
• Remote party in GSM changing their side of a call into a conference;
• Unnecessary network traffic due to the Location interface;
• DTMF: pre-composed dial strings;
• Electoral reform.

== Call forwarding ==

https://bugs.freedesktop.org/show_bug.cgi?id=13351

This interface is for specifying forwarding rules if you don't answer a 
call, if you're busy, etc etc. For instance, with most mobile phone 
operators you can choose to redirect calls to another number (usually 
your voicemail) if you don't answer within 30 seconds.

Our consensus was that this interface is the right shape, but some types 
are not ideal, poorly named, etc. In particular:

The Forwarding_Rule enum isn't the type of a rule, it's the type of a 
condition to apply rules in. So it should be called Forwarding_Condition 
or similar.

The ForwardingRules property maps conditions to what to do in those 
situations, so it should be a dict not an array. So we get:

   ForwardingRules: a{ u — Forwarding_Condition
                  → a(uu) — Forwarding_Rule_Entry[]
                     }

There's ambiguity as to what the timeout in a forwarding rule entry 
means. According to the example, it means "the time to take before 
redirecting to this handle"; according to the struct definition, it 
means "the time to wait for this handle to answer before failing over to 
the next rule".

We could bike-shed which way round it should be... In the first case, we 
have no way to specify how long to wait for the handle in the last rule 
to answer before giving up; in the second case, we have no way to 
specify how long to wait for the local user to answer before trying the 
first rule. Perhaps we should take the second definition, and change the 
type of ForwardingRules further into:

   a{ u — Forwarding_Condition
    → ( u — initial timeout,
        a( u — handle,
           u — timeout for this action
         )
      )
    }

Then for example, the following value of ForwardingRules:

   { Busy: (30 seconds, [ (handle 3, 15 seconds)
                        , (handle 5, 20 seconds)
                        ]
           ),
     ...
   }

would mean: “if I'm on another call, keep the call waiting for 30 
seconds. If I don't answer the new call, redirect it to handle 3. If 
they don't answer within 15 seconds, redirect it to handle 5. Finally, 
if they don't answer within 20 seconds, give up.”

We should say what happens if your provider doesn't support call 
waiting, but you specify a Busy action with a non-zero time: the time is 
ignored.

In ‘a user's status is set to "Don't Bother Me"’, link to simple presence.

0 shouldn't mean default. 0 should mean "immediately", and MAX_UINT32 
should be the default. Or something (maybe make it signed so we can use 
-1? Maybe introduce maybe types to D-Bus? :þ).

SupportedForwardingRules should be renamed SupportedForwardingConditions.

How would we deal with Busy being handled locally, and NotReachable 
being on the server? Specifically: the server may only support one 
contact for NotReachable, but the local impl. can support >1. Maybe 
SupportedForwardingConditions should be an a{u: Condition → u: 
max_count} mapping supported conditions to how supported they are.

Side point: we need an error condition which says "this call ended 
because it was forwarded". (Do we want to say to whom?) Add an element 
to Call_State_Change_Reason.

How do we represent a call being forwarded immediately? It's easy with 
Call: we just announce a channel with the state already set to Ended. 
Call channels don't close themselves, so it'll be dispatched as normal. 
Hooray! Dancing in the streets, baked treats all round. Maybe we can 
clone this pattern onto the Group interface so it can deal with being 
booted immediately from a chat room.

== ServicePoint interfaces (emergency calls) ==

https://bugs.freedesktop.org/show_bug.cgi?id=24905

These interfaces deal with indicating that a channel is to an emergency 
service — such as 112 in the EU, or 911 in the US — and informing the UI 
which numbers correspond to which services on the current connection. A 
variant of this interface is implemented by telepathy-ring on Maemo 5; 
it could also be used on SIP, or even XMPP in some kind of 
utopian/dystopian (depending on your point of view) future.

We also added some comments on the bug during the meeting.

o.f.t.Channel.Interface.ServicePoint:

• GetCurrentService should become two properties [or maybe a single 
struct-typed property? -ed.] instead of being a getter method
• For documentation purposes there should be a TpSimpleType for URN 
strings, so we can use that as the type for ServicePoint.
• Service_Point_Type 0 should be None instead of Unknown for a dummy value

o.f.t.C.I.ServicePoint:

• ServiceHandle should be ServiceID, No need for it to  be handle: the 
UI will be dealing with it as an ID anyway
• And/Or AliasList should be ServiceIDs and ServiceHandle should 
disappear completely. It wasn't clear to us what the rationale/use-case 
for having one ServiceHandle and then a list of aliases is ?
• Simon would like to see a example of Service_Point_Struct in the spec.
• Also Service_Point_Struct should be renamed to Service_Point_Info

== Remote party in GSM changing their side of a call into a conference ==

When your peer in a GSM call makes the call a conference, one can only 
know that this has happened but not influence the conference or know who 
is in it. Which means that for all practical purposes it's not a 
conference usable from our local side. (For instance: Will can call 
Simon, Simon can turn his end of the call into a conference with Sjoerd, 
and Will can turn his end of the call into a conference with Nick Clegg. 
Little to no information is available to each participant on who else is 
on the call, besides the fact that a peer confed *someone* in at some 
point.)

Given that, we decided that the Conference interface should not be used 
for this but we should have a seperate interface (the name SideTalking 
was coined) that can indicate a remote party is doing conferencing of 
this sort.

This interface would have a property (+ change notification for it ) 
with a list of people that might have conferenced you in the current call.

== Location Interface ==

Currently Gabble always subscribes to PEP notification for location 
services, even if there isn't necessarily a client listening for them. 
Currently that's not such a big deal as not many people publish their 
location, but were thisto change than it could cause a reasonable amount 
of useless traffic

Simon and Sjoerd decided that we should add a a Subscribe and 
Unsubscribe method to the Location interface. Use GetLocation (or the 
contact attribute) will automagically subscribe your application (and 
thus keeping backwards compatibility). RequestLocation will do a 
one-time request for a persons   location and not thus subscribe to 
further change notification.

[Will, who left the room during this section of the discussion in order 
to declare the funds he has received to fund a part-time researcher, 
wonders while writing these notes up: why do we need explicit 
Subscribe() at all?]

== DTMF: pre-composed dial strings ==

https://bugs.freedesktop.org/show_bug.cgi?id=24902

This interface deals with dialing a number, and immediately sending a 
series of DTMF events. For instance, you might have a button in your 
address book that calls a teleconference service, and then automatically 
dials in the conference ID followed by #, waits a few seconds, then 
dials the PIN followed by #.

We commented on the bug. In summary:

• We decided we should support both including the dial string as part of 
the TargetHandle (eg: "+441234567890p1234#p666#"), and requesting a 
channel with { TargetHandle: "+441234567890", InitialTones: "p1234#p666#" }.
• There has been some discussion on the bug about how this works with 
protocols like SIP where the dial tones might be sent in the signalling, 
and might be sent in the RTP stream, so Farsight needs to get involved.


-- 
Will