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.