Subject: [Sip] Question regarding SDP and holds

From: "Chris Whitaker" <[email-masked]>
Date: Sat, 27 Mar 2004 12:15:29 -0500

In rfc3264, it states:

If the stream to be placed on hold was previously a sendrecv media
   stream, it is placed on hold by marking it as sendonly.

So my question is this.
If the stream being altered was previously a sendrecv media stream, and has 
become a sendonly stream... how does one communicate that without implying 
that the stream is on hold [ie neither sending nor receiving]?  To be clear 
within the existing recommended proceedures for communcating a hold, I am 
trying to understand a means of differentiating when the source of media 
stream has stopped receiving but NOT stopped sending and when it has stopped 
BOTH.

Secondly, if a sendrecv stream is becoming neither a sending nor receiving 
stream [which often occurs when it goes on hold] why does the rfc suggest 
claiming it is sendonly... would not inactive be more accurate?

Chris

_________________________________________________________________
MSN Premium includes powerful parental controls and get 2 months FREE*   
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Apr 2004 18:12:33 -0400

Chris Whitaker wrote:
> If the stream being altered was previously a sendrecv media stream, and 
> has become a sendonly stream... how does one communicate that without 
> implying that the stream is on hold [ie neither sending nor receiving]?  
> To be clear within the existing recommended proceedures for communcating 
> a hold, I am trying to understand a means of differentiating when the 
> source of media stream has stopped receiving but NOT stopped sending and 
> when it has stopped BOTH.
> 
> Secondly, if a sendrecv stream is becoming neither a sending nor 
> receiving stream [which often occurs when it goes on hold] why does the 
> rfc suggest claiming it is sendonly... would not inactive be more accurate?

I *think* the assumption is that "putting on hold" may cause something 
(music, or beeps, ...) to be sent by the holder to the holdee. So 
sendonly is used.

If the intent is truly to neither send nor receive, then it would be 
more appropriate to use inactive.

	Paul