[Bug 13351] Forwarding spec

[bugzilla-daemon at freedesktop.org]

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





--- Comment #8 from Andres Salomon <dilinger at collabora.co.uk>  2010-03-22 16:32:41 PST ---
(In reply to comment #7)
> (In reply to comment #6)
> > Here's an initial spec based upon some of Mikhail's comments -
> > 
> > http://git.collabora.co.uk/?p=user/dilinger/telepathy-spec;a=shortlog;h=refs/heads/forwarding
> 
> Thanks. Some more comments:
> 
> MaxForwards can be confused with a header in SIP protocol, which has a
> different purpose. MaxForwardingContacts, perhaps?

I went w/ MaxForwardingEntries.


> 
> Timeout in Forwarding_Rule_Entry: is it correctly documented as the timeout of
> the forwarding attempt itself prescribed by this entry, or did you mean it to
> be the timeout before the attempt is taken, as I meant it to? If it's the
> first, we need some other way to specify the initial timeout, and I think it's
> unnecessary.
> 

The wording is kind of confusing; here's an example.

  ForwardingRules = [
    Busy = [   [Handle:3, Timeout:30]   ],
    NoReply = [   [Handle:5, Timeout:30], [Handle:3, Timeout:20]   ],
    NotReachable = []
  ]

Assuming a CM which is limited to only 1 media stream at a time, is capable of
chaining forwards, and can determine whether a remote handle has accepted a
channel or not.

Scenario 1) An incoming channel is detected; the media stream is already in
use.  The CM determines that the result should be Busy.  It looks at the
forwarding rule; the CM ignores the timeout for Busy, so it immediately
forwards the incoming channel to  Handle #3.

Scenario 2) An incoming channel is detected.  The media stream is available,
and the local user is online.  While the CM is waiting for the local user to
accept the channel, it looks at NoReply's first timeout value.  After 30s if
the local user hasn't accepted, the CM forwards the channel to Handle #5.  The
CM then waits 20s for Handle #5 to accept the channel.  If after 20s it does
not, the CM forwards the incoming channel to Handle #3.



> Type Forwarding_Rule_Entry is not referenced in the places that actually use
> it.


Yeah, I'm planning to update all of the references once we're happy w/ the API.


> 
> ForwardingRulesChanged: either rename to ForwardingRuleChanged because it has
> data for one rule only, or make it able to emit multiple rules (maybe the
> entire set currently active?); the latter change will remove the atomicity
> issue which is mentioned in the documentation to SetForwardingRule.
> 


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.