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.
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.
(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.
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..
-- 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.