[Bug 37291] New: Clarify transitions and semantics of Call.Stream.LocalSendingState with regard to remotely requested changes

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=37291

           Summary: Clarify transitions and semantics of
                    Call.Stream.LocalSendingState with regard to remotely
                    requested changes
           Product: Telepathy
           Version: git master
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: tp-spec
        AssignedTo: telepathy-bugs at lists.freedesktop.org
        ReportedBy: mikhail.zabaluev at nokia.com
         QAContact: telepathy-bugs at lists.freedesktop.org


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.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.