http://people.freedesktop.org/~wjt/telepathy-spec-undraft_splittable_and_mergeable/spec/

I'm mainly saying r- to confirm what your opinion is on the points below, tbh; this looks fine to undraft soon.

> +      <p>Once a one-to-one channels has been merged into a conference using

'one-to-one channel has'

> [MergeableConference] might be made into a mandatory-to-implement part
> of Conference, or kept as a separate interface, when stabilized.

This sentence should be deleted. Are we happy to make this not be m-t-i?

If we've resolved that non-telephonic protocols aren't expected to implement MergeableConference, then the Merge() rationale shouldn't talk about XMPP.

(In reply to comment #2)
> If we've resolved that non-telephonic protocols aren't expected to implement
> MergeableConference, then the Merge() rationale shouldn't talk about XMPP.

So relatedly, the documentation for Merge() says:

    “The given channel SHOULD be added to Conference.Channels if and only if the underlying protocol signals the merge in some way.”

I wonder whether it's less confusing to just say Merge is only supported if the underlying protocol signals the merge in some way.

(In reply to comment #3)
> (In reply to comment #2)
> > If we've resolved that non-telephonic protocols aren't expected to implement
> > MergeableConference, then the Merge() rationale shouldn't talk about XMPP.
[...]
> I wonder whether it's less confusing to just say Merge is only supported if the
> underlying protocol signals the merge in some way.

With my ex-mathematician hat on, this is mixing two orthogonal things: MergeableConference is (intended) for protocols where you can only merge, not invite, whereas addition to Channels in Merge() is for protocols where merging is signalled.

However, with my software engineer hat on, I suspect that those two orthogonal things will always coincide in practice - protocols which "look like telephony" will require merging *and* signal merges, and protocols which don't "look like telephony" will do neither. So, yeah, I'd be fine with conflating those.

Mikhail, any thoughts on comment #2 and subsequent comments? (In particular, how would SIP behave?)

(In reply to comment #4)
> protocols which "look like telephony"
> will require merging *and* signal merges, and protocols which don't "look like
> telephony" will do neither. So, yeah, I'd be fine with conflating those.

That's pretty much my position.

>A channel with the same ChannelType as this one, but with TargetHandleType = CONTACT.

Is there a particular reason to restrict merges to one-to-one channels? Not that I'd like to handle conferences consisting of conferences..

(In reply to comment #6)> Is there a particular reason to restrict merges to one-to-one channels? Not
> that I'd like to handle conferences consisting of conferences..

Sanity? :-)

My understanding is that this is enough to represent every protocol we know about (including GSM, with suitable definitions of a conference); we can always add a flag for "this weird thing *also* works" later, if we need one.

My understanding is that we represent GSM conferences like this:

If Alice calls me, then calls Bob and merges the two calls, my GSM provider tells me "this call with Alice has gained one or more conference participants" (if anything), so I see this as a 1-1 call with the Conference_Host CallState flag.

If I then call Chris and merge my call with Chris into my call with Alice, *that* is where we start using a Telepathy Conference.

Am I right? Diagram:

            Telepathy Conference
      //================||=================\\
      ||                ||                 ||
      ||                ||                 ||
      ||                ||                 ||
    Chris ------------- me ---------------- Alice - - - - - - Bob
               ^        ||  ^ 1-1 Telepathy  || ^ not visible  ||
         1-1 Telepathy        Channel            in Telepathy
           Channel      ||                   ||                ||

                        \\ = = = = = = = = = ||= = = = = = = = //
                             ^ only visible as the Conference_Host flag

       ==== GSM conference
       ---- GSM call
       solid lines are Telepathy channels
       broken lines are not

(In reply to comment #7)
> Am I right? Diagram:

Yep, you are correct.

I'm just waiting for IMS and 24.147. ;-)

(In reply to comment #4)
> Mikhail, any thoughts on comment #2 and subsequent comments?

I think MergeableConference should be kept specific to cases where it is needed, that is, GSM-style conference calls.

> (In particular,
> how would SIP behave?)

What does SIP have to do with conferences? :)
I don't know any widely accepted ways to support conferences in SIP, apart from calling some special URI to participate in a conference, or being called from a conference service. Neither of which communicates anything about other conference participants, or carries other discernible differences with a one-to-one call.

(In reply to comment #9)
> I don't know any widely accepted ways to support conferences in SIP, apart from
> calling some special URI to participate in a conference, or being called from a
> conference service.

Now, IMS may provide a way to set up a conference "room" (sadly I didn't read the spec for details yet) and invite other participants to it with REFER. If this REFER can be received inside an established call session thus instructing to merge the call into a conference, this is probably a case that should be covered by MergeableConference.

On IMS there should be full-blown conference implementation with floor control and participant identification using conference event. (I have just browsed the specs, and I should probably read also the VoLTE profile...)

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-spec/issues/94.