Andreas Bystr�m wrote:
Thanks for the response, I have looked more into RFC3264 and also found some examples of when using a=sendonly.
To me, using a=sendonly seems more like a mute functionality. If A talks to B and sends hold with a=sendonly, B will keep sending data to A.
Thats backwards. If A sends sendonly, it is saying it wants to send but not receive. B should respond with recvonly. Then A *may* send, but B isn't must not send. This provides the proper circumstances for A to send music on hold to B. Or A can choose to send nothing, in which case no bandwidth is used in either direction. A key difference between the approach and the older c=0.0.0.0 approach is that RTCP continues to flow in both directions regardless. (Also, I believe even when you are not supposed to send it may be necessary to send some junk packets to the RTP port to keep a nat pinhole open. See the discussions of ICE for more on that.)
If B, upon receiving the offer of sendonly, doesn't want to listen and wants to ensure bandwidth is conserved, then B may respond with inactive. This ensures that nothing is sent in either direction.
> It is also
possible that A will keep on sending to B if it trusts that B will stop receiving according to RFC3264 (if B sends a=recvonly I guess A will stop sending). I wont then save any bandwidth (or save only half) and what do I gain? As far as I can see the "only" thing that is good about this is that when A then puts B off hold again, A will hear B will hear each other some ms faster. Have I missed something or is this basicly the case?
Hopefully comments above helped.
Would it also be correct to send a=inactive to really stop the streams? Or is this not considered as Call Hold
You can do this if you wish. These are simply primitives that may be used to support a variety of features, including hold. There are no standards on how the features themselves are implemented.
> (I know that the definition of call hold
could vary)? If A has B on hold, and then B wants to put A on hold, is it then correct to send a=inactive?
Yes.
We maybe should do any difference on Call Hold and Mute, or what do you say?
In practice I think that both the hold feature and the mute feature could be implemented locally without changing the media streams. The a=sendonly/recvonly/inactive simply provides a way to optimize bandwidth utilization when the media isn't being used.
The one place where this sort of distinction as come up is in the "dialog" event package, where there is some desire to know whether a call is "on hold". I've lost track of whether a suitable definition has been agreed to - it actually turns out to be quite subtle.
Paul
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
