Bug 46386

Summary:	document that requested stream directions can be unattainable, or make it discoverable
Product:	Telepathy	Reporter:	Simon McVittie <smcv>
Component:	tp-spec	Assignee:	Telepathy bugs list <telepathy-bugs>
Status:	RESOLVED MOVED	QA Contact:	Telepathy bugs list <telepathy-bugs>
Severity:	normal
Priority:	medium	CC:	olivier.crete
Version:	git master
Hardware:	Other
OS:	All
Whiteboard:	Call
i915 platform:		i915 features:

Description Simon McVittie 2012-02-21 03:45:48 UTC

In Gabble:

> + if (initial_direction == TP_MEDIA_STREAM_DIRECTION_NONE)
> + {
> + g_set_error (error, TP_ERRORS, TP_ERROR_INVALID_ARGUMENT,
> + "Jingle can not do contents with direction = NONE");
> + return NULL;
> + }

and

> f (initial_direction != TP_MEDIA_STREAM_DIRECTION_BIDIRECTIONAL)
> + {
> + g_set_error (error, TP_ERRORS, TP_ERROR_NOT_IMPLEMENTED,
> + "Adding un-directional contents is not supported"
> + " in MUC channels");
> + return NULL;
> + }

For the first case, it seems reasonable for the spec to say that CMs might not support contents whose streams' initial direction is NONE, and that clients SHOULD NOT ask for this (although the error should probably be NotAvailable or something - InvalidArgument generally implies "you got it wrong, you suck" rather than "sorry, this protocol can't do what you asked").

For the second case, I think we should have a way for UIs to discover whether unidirectional contents will work or not, so they can avoid having UI for it in this case.

My understanding of Call is pretty shaky, so I might be misunderstanding either or both of those: if so, please correct me.

Comment 1 Olivier Crête 2012-02-22 14:08:32 UTC

For the MUC case it's really that I didn't take the time to understand the muji code in gabble enough to propagate the information correctly.

I think that once it's fully implemented, it woudl have the same protocol restriction that NONE isn't allowed.

Comment 2 Simon McVittie 2012-02-23 05:10:20 UTC

(In reply to comment #1)
> For the MUC case it's really that I didn't take the time to understand the muji
> code in gabble enough to propagate the information correctly.

OK, great. I'll clone a bug.

> I think that once it's fully implemented, it woudl have the same protocol
> restriction that NONE isn't allowed.

Is there any valid reason why a UI might want to set a stream to be "no-directional"?

If there is, we should have some sort of flag to say "not possible" so it can not display that option, or something. (Or invert it, and have a flag for protocols like SIP where it *is* possible - I think I'd prefer that, actually.)

If there isn't, we should say that CMs might not support contents whose streams' initial direction is NONE, and that clients SHOULD NOT ask for it.

Comment 3 Olivier Crête 2012-02-23 07:30:39 UTC

Well, the UI can just remove the stream if it can't set it to NONE.. In SIP, you can use a=inactive, this is useful if you want to do the ICE stuff first and then quickly switch it on..

Comment 4 GitLab Migration User 2019-12-03 20:25:48 UTC

-- 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/130.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.