[Telepathy] On Jingle and picking capabilities in Gabble

[Senko Rasic]

[Note: the issues discussed here arise in development of the new
jingle engine for Gabble, for details of how the new code will be
organised, please take a look at
http://people.collabora.co.uk/~ptlo/gabble-jingle.txt]

When initiating jingle session with a remote peer (or when adding a
content-type, ie. requesting new streams), we want to pick the best
possible thing that we both support.

The situation gets complicated in session init, because there might be
multiple resources for the peer, with different capabilities. To make
matters even more interesting, we might want to take into account
presence status of those resources (e.g. don't call someone on the
client that's away, even if purely capability-wise it's better choice).

Ideally, we want to pick a resource that:
  - is the "least away"
  - support the best content type (and the newest possible version of the
    standards)
  - support the best transport mechanism

Thus, we need ordering in all the above params. We already have ordering
for presence status (see GabblePresenceId enum).

For content types, we cannot have full ordering because it depends on
what the channel wants to do (video support is not required if we do a
file transfer, but video+audio is preferred to just audio for media
chans).

As the idea with JingleContent implementations (such as JingleMediaRtp)
is that they implement all related/equivalent functionality (so
JingleMediaRtp should be able to handle all content types related to
media stuff), we can hope that they can provide the ordering for the
types they implement.

Possibly the transport mechanism preferance also depends on the use-case
(e.g. calls would prefer ICE, while file transfer might prefer socks
bytestream).

Now, we have orderings for the three params. If we have to choose
amongst multiple resources, I think we should sort them by:

     presence status -> content type caps > transport mechanism caps

The important thing is to sort the resources, not to filter them
(pick best presence, then pick best content type(s), then pick best
transport).

Rationale:
   - if we have several resources, we want to initiate session with the
     one that's not away, or dnd, etc
   - we want to talk to resource that's most capable for our use-case
    (that means a/v versus only audio for calls)
   - if we have several equally present resources with equivalent caps
     for handling the content, we want to pick the one that's got the
     best transport mechanism, hoping that there's the best chance to
     achieve good and reliable connection

Effect of this:
   - we'd prefer available audio/only, rawudp resource to away a+v/ice
     resource (if we don't need video atm - if we do, we have to filter
     for that)

Related problem: we're growing a number of distinct jingle-related
capabilities that we have to know about. There's GTalk-caps
(http://www.google.com/... ns), Jingle v0.15 caps
(http://www.jabber.org/... ns), Jingle draft caps (urn:xmpp:...), many
of which are equivalent (except for the inner workings of Jingle engine)
and the Jingle feature namespaces will be versioned in the future, so
this will only grow.

Would it be wise to somehow hide this jingle namespacing jungle inside
the jingle engine, and to expose just e.g. "jingle, audio, video, fd,
tube" abstract caps to the rest of Gabble?

Also, are there existing proposals or standards describing the preferred
way of sorting these priorities out? If I've missed them, please point
them out :)