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

From: [email-masked]
Date: Tue, 4 Oct 2005 13:25:16 -0400

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