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
_______________________________________________
telepathy mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/telepathy
