addParticipant should be totally rewritten

[jmcanterafonseca]

We need to define a kind of join method that allows to join the active call to the current held conference call

[zolkis]

The issue raised on the F2F was to remove 'addParticipant', and not to 'totally rewrite' it.

Before removing it, is should be considered whether the Telephony API wants to carry the semantics of GSM/CDMA specifications (and break if/when they change as a result of wider adoption of IMS), or does it choose to model the user interaction needed to manage multiparty calls, which is stable and independent of the underlying telephony technology.

[zolkis]

"We need to define a kind of join method that allows to join the active call to the current held conference call"

That is already defined: 'join' called without any parameters.

[zolkis]

The following changes are proposed:

From ConferenceCall

• remove the 'addParticipant()' method
• for simmetry, remove the 'removeParticipant()' method, and use disconnect on the participating TelephonyCall object instead

From TelephonyCall

• remove the optional parameter from the 'join()' method

There are at least 2 non-breaking ways forward when IMS/SIP calls will be supported:

1. add back the aformentioned methods and use the same ConferenceCall object for cellular and SIP calls
2. define a separate SipConference object, and add back the optional parameter on the join method on TelephonyCall, which will be mandatory if the call is a SIP call. For any case, the suggested scope reduction to cellular-only services can be done in this version.

[hsinyi]

"for simmetry, remove the 'removeParticipant()' method, and use disconnect on the participating TelephonyCall object instead"

Does "disconnect" indicate splitting a participating telephonyCall from the ConferenceCall or simply releasing the telephonyCall?

[zolkis]

"Does "disconnect" indicate splitting a participating telephonyCall from the ConferenceCall or simply releasing the telephonyCall?" Releasing the participating call. Start disconnect multiparty transaction with the call id of the call to be released; the network will initiate the call clearing procedure towards the served mobile subscriber as defined in GSM 04.08 with the transaction identifier corresponding to the disconnecting party.

[hsinyi]

Don't we need 'split' function to separate a remote party from a conference call? See GSM 22.084, sec. 1.3.8.2

[zolkis]

No, we don't split, we release the call. Facility/Disconnect.

[hsinyi]

I can easily imagine the use case of creating a private channel with a single participant. Why does this proposal not support the function, especially this function is mentioned in spec?

[zolkis]

Yes, that is supported by the 'split()' method, which is still there :). Perhaps we should wait until I update the spec, and do a review then.

[hsinyi]

Ha, I see. I thought you're gonna get rid of split() because your proposal above didn't mention that. Sorry for the noise and looking forward to an update. :)