Subject: Re: [Sip] Re: [Sip-implementors] Hold SDP

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Oct 2005 17:32:48 -0400

Michael Hammer (mhammer) wrote:
> Why not a=no-send/no-recv or something equivalent?

That would be a=inactive

> I think people got too hung up over the character sequence "hold" to 
> mean exactly the same thing.

The problem seems to be that some people want something that means:

"I want to keep this call around, and I don't want to deal with the 
media, but I am hoping some other network element will take care of that 
for me, without me doing anything more than saying this."

I don't buy it, but that seems to be what people are asking for.

As far as I am concerned, HOLD is a concept that is known to the UA that 
initiates it, and nobody else. Others may know that a media stream is 
sendonly or inactive, but they can't really tell if that is because they 
have been put on hold or merely that the other party doesn't want to 
receive their audio. (E.g. I might reinvite with recvonly because my 
MUTE button was pressed. That doesn't mean the other end put me on hold.)

Trying to *define* hold will be a slippery slope. I don't see much 
upside to trying.

	Paul

> Mike
>  
> 
>     ------------------------------------------------------------------------
>     *From:* [email-masked] [mailto:[email-masked]] *On
>     Behalf Of *Gordon Ledgard
>     *Sent:* Tuesday, October 04, 2005 1:54 PM
>     *To:* [email-masked]
>     *Cc:* SIP IETF; Paul Kyzivat (pkyzivat); SIP Implementors
>     *Subject:* RE: [Sip] Re: [Sip-implementors] Hold SDP
> 
>      
> 
>     With Paul’s response to Peter Blatherwick, I think I now understand
>     Paul’s perspective.
> 
>      
> 
>     Historically, a Hold operation involved a scene using three pieces
>     of equipment; caller A’s phone,
> 
>     some intermediate equipment (a PBX) and caller B’s phone. The
>     semantics of the operation here are
> 
>     that Caller B forces the PBX equipment to behave a certain way such
>     that caller A now here’s something
> 
>     else, while caller B does some other thing.  Simple enough and
>     apologies for the obvious.
> 
>      
> 
>     Maybe the issue here, to Paul’s point, is that emulating this
>     behavior using the SIP model, is the
> 
>     wrong thing to attempt.  In current implementations of this
>     three-piece equipment emulation of Hold,
> 
>     the equipment (B2BUA? App Server?) in the middle tries to interpret
>     some REINVITE from Caller B
> 
>     to mean that it needs to alter Caller A’s media, and starts spewing
>     MOH to it.
> 
>      
> 
>     Inventing a mechanism for Caller B to tell the intermediate
>     equipment specifically to “go into this Hold mode”
> 
>     is probably evil, since the behavior would be undefined if there
>     were lots of intervening equipment between
> 
>     Caller A and Caller B. Unfortunately, that is precisely what we have
>     done by building stuff that interprets the
> 
>     SDP exchange as meaning “go into Hold”.
> 
>      
> 
>     But maybe inventing a mechanism to allow Caller B to tell Caller A
>     DIRECTLY to “go do whatever you do
> 
>     when you are waiting” is NOT inappropriate. Caller A is now free to
>     play its own music to itself, or to
> 
>     flip over to a music service or whatever. Perhaps this still crosses
>     Paul’s line of “IETF does not standardize features”.
> 
>     I dunno.
> 
>      
> 
>     This also, I realize, does not address the situation where Caller
>     B’s equipment wishes to control the content. J
> 
>     But in that event, why do you need to alter Caller A’s media at all?
> 
>      
> 
>      
> 
>     Gordon Ledgard,
> 
>     IPeria, Inc.
> 
>      
> 
>      
> 
>      
> 
>     ------------------------------------------------------------------------
> 
>     *From:* [email-masked] [mailto:[email-masked]]
>     *Sent:* Tuesday, October 04, 2005 1:25 PM
>     *To:* Gordon Ledgard
>     *Cc:* Paul Kyzivat; SIP IETF; SIP Implementors
>     *Subject:* RE: [Sip] Re: [Sip-implementors] Hold SDP
> 
>      
> 
> 
>     At one point we are saying that hold is a feature,
>     and in RFC 3264, we are saying if you want to put streams on hold,
>     then use "sendonly" attribute,
> 
>     So basically we are giving guidelines for UAC to indicate when it
>     wants to put streams on hold, but not differnetiating when it wants
>     to open one-way media stream.
> 
>     Actually, from UAC to UAS perspective, it is not much of an issue,
>     but for B2B applications, it is certainly an issue.
> 
>     Regarding the different flavous of hold, why do we need to define
>     all flavours, let it be the service responsibilty.
> 
>     I have seen similar thread going on SIPForum-techwg for UA behaviour
>     regarding MOH..
> 
>     "sendonly" attribute indicates that it wants to play some music or
>     announcements...
>     What if UAC does not want to play music and want to hold stream, and
>     services wants to play MOH to other party.
> 
>     Its better if we can just convey the information in SDP, that this
>     is for hold.
> 
>     Regads,
>     Udit
> 
> 
> 
> 
>     *"Gordon Ledgard" <[email-masked]>*
> 
>     10/04/2005 10:32 AM
> 
>     	
> 
>     To
> 
>     	
> 
>     "Paul Kyzivat" <[email-masked]>, Udit Goyal/C/US/3Com@3Com
> 
>     cc
> 
>     	
> 
>      
> 
>     Subject
> 
>     	
> 
>     RE: [Sip] Re: [Sip-implementors] Hold SDP
> 
>      
> 
>      
> 
>     	
> 
>      
> 
> 
> 
> 
> 
>     You guys have piqued my curiosity here.  I agree with just about
>     everything
>     you said, Paul, except that I'm not quite sure its so simple to say that
>     hold is a "feature" and not an "attribute".  The semantics are fuzzy.
> 
>     To the caller, the action of pressing some "hold" button is an
>     expectation
>     for a particular sort of behavior, music or not. >From the
>     perspective of
>     the
>     service receiving the request, the request for the behavior from the
>     caller
>     can be interpreted in a few ways, and thus becomes a "feature".  But in
>     any
>     event there seems to be no way to differentiate the users "intent"
>     simply
>     by examining the send/receive attributes of the SDP.  Is this not at the
>     heart of the complaint?
> 
> 
>     If so, I think Udit, and many others who have whined about the
>     inadequacy of
>     the send/receive semantics, have a point... why can there not be
>     something to signal this intent?  Perhaps we can hash out the
>     distinctions.
> 
> 
>     Gordon.
> 
> 
> 
> 
>>  -----Original Message-----
>>  From: [email-masked] [mailto:[email-masked]] On Behalf Of
>     Paul
>>  Kyzivat
>>  Sent: Tuesday, October 04, 2005 10:08 AM
>>  To: [email-masked]
>>  Cc: SIP IETF; SIP Implementors
>>  Subject: [Sip] Re: [Sip-implementors] Hold SDP
>>
>>
>>
>>  [email-masked] wrote:
>>  > I want to know is it the genral behaviour of all UAC?
>>
>>  There are a lot of UAs out there. Its hard to say what the "general"
>>  behavior is.
>>
>>  > because as per RFC, c=0 has not been recommended for RTCP purposes,
>>  > anyway in these cases, we might need RTCP reports also,
>>
>>  The use of c=0 is an old (now deprecated) action in response to a
>>  request to initiate hold. The mechanism still exists, and is still
>>  important for some call flows unrelated to hold. There is of course
>>  nothing to prevent a UA from using it when initiating Hold, and the
>     peer
>>  should do something reasonable in response.
>>
>>  > Why cant we have one more attribute "a=hold" which indicates its
>     meant
>>  for
>>  > hold and not for one-way media audio stream,
>>
>>  I think mostly because hold is a feature, and IETF doesn't standardize
>>  features. The existing directionality attributes are mechanisms that
>     may
>>  be used for hold or other things.
>>
>>  If you introduced a hold attribute, then there would be a lot of call
>     to
>>  have different flavors of hold - one way, two way, with music, without
>>  music, etc. And of course you would need to get into the precise
>>  semantics of hold.
>>
>>  As things stand, Hold is a local feature on an endpoint. The
>>  corresponding signaling should not really be considered as signaling
>>  "hold" - it is only signaling the desired media behavior. I think
>     there
>>  is no expectation, or need, for the other UA, or servers in the path
>     to
>>  be able to determine that the call is "held".
>>
>>          Paul
>>
>>  > Thanks,
>>  > Udit
>>  >
>>  >
>>  >
>>  >
>>  >
>>  > "Avasarala Ranjit-A20990" <[email-masked]>
>>  > Sent by: [email-masked]
>>  > 10/04/2005 02:23 AM
>>  >
>>  > To
>>  > Udit Goyal/C/US/3Com@3Com, "SIP Implementors"
>>  > <[email-masked]>
>>  > cc
>>  > SIP IETF <[email-masked]>
>>  > Subject
>>  > RE: [Sip-implementors] Hold SDP
>>  >
>>  >
>>  >
>>  >
>>  >
>>  >
>>  > Udit
>>  >
>>  > You can use c=IN IP4 0.0.0.0 to indicate hold in addition to
>     a-sendonly.
>>  >
>>  >
>>  >
>>  > Regards
>>  > Ranjit
>>  >
>>  >
>>  >
>>  >
>>  > -----Original Message-----
>>  > From: [email-masked]
>>  > [mailto:[email-masked]] On Behalf Of
>>  > [email-masked]
>>  > Sent: Monday, October 03, 2005 10:42 PM
>>  > To: SIP Implementors
>>  > Cc: SIP IETF
>>  > Subject: [Sip-implementors] Hold SDP
>>  >
>>  > Hi,
>>  >
>>  > As per RFC 3264, user agent indicate hold by sending "sendonly
>     attribute
>>  > (assuming sendrecv mode stream).
>>  > So when UAS receives this SDP, it should respond with "recvonly"
>>  > attribute.
>>  >
>>  > But same mechanism can be used by user agent if he wants to play
>>  > announcement or music to user, so it can send "sendonly" attribute
>     for
>>  > media stream.
>>  > I mean if it simply wants one-way connection (this is not hold).
>>  >
>>  > For 3PCC (as B2B), if it wants to provide MOH service, how can it
>>  > differentiate between two SDP because it will play MOH only in the
>     first
>>  > scenario when user press hold.
>>  >
>>  > Is there any other way where user agent can indicate that this is
>     hold
>>  > scenario and not one-way audio.
>>  >
>>  > Thanks,
>>  > Udit
>>  > _______________________________________________
>>  > Sip-implementors mailing list
>>  > [email-masked]
>>  > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>>  >
>>  > _______________________________________________
>>  > Sip-implementors mailing list
>>  > [email-masked]
>>  > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>>  > _______________________________________________
>>  > Sip-implementors mailing list
>>  > [email-masked]
>>  > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>>  >
>>
>>  _______________________________________________
>>  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
> 

_______________________________________________
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