Bug 37291 - Clarify transitions and semantics of Call.Stream.LocalSendingState with regard to remotely requested changes
Summary: Clarify transitions and semantics of Call.Stream.LocalSendingState with regar...
Alias: None
Product: Telepathy
Classification: Unclassified
Component: tp-spec (show other bugs)
Version: git master
Hardware: Other All
: medium normal
Assignee: Telepathy bugs list
QA Contact: Telepathy bugs list
Depends on:
Reported: 2011-05-17 09:18 UTC by Mikhail Zabaluev
Modified: 2019-12-03 20:24 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Description Mikhail Zabaluev 2011-05-17 09:18:38 UTC
In SIP, an offer to stop sending media over a stream is binding: when the local endpoint receives SDP with one or more streams restricted to "sendonly" or "inactive" (from the sender's POV), it cannot answer with these streams allowed to send. Therefore, it would seem reasonable to change the LocalSendingState on the corresponding Stream objects to Pending_Stop_Sending (and stop sending on the Media face?). Upon this, the client can: 1) change nothing; 2) disable sending from its end with SetSending(false). In the first case, the local sending state can transition immediately back to Sending when the remote party allows sending again. In the second case, the local sending state will switch to None, from where it can transition to Pending_Send when the remote party allows sending.

If this interpretation is correct, the described transitions and client behaviour ought to be documented as the recommended practice. However, this would suggest that the name "Pending_Stop_Sending" is misleading, because this state does not necessarily prompt a reaction from the client signalling-wise, but it does mean that sending of media should already be stopped. Are there in fact protocols where an offer to stop sending may be constructively refused? I can't see how it can make practical sense.

This is complicated by the hold use case, which in SIP signalling is realized as requesting to stop sending on all streams without specific indication for the reason. Thus in case of SIP, the same logic should complement the CallState signalling about remote hold, as hiding it for this special case would produce ugly inconsistencies and corner cases.
Comment 1 GitLab Migration User 2019-12-03 20:24:13 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/115.

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.