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

From: "Gordon Ledgard" <[email-masked]>
Date: Tue, 4 Oct 2005 13:54:04 -0400

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. :-)

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

---

From: "Chris Whitaker" <[email-masked]>
Date: Tue, 04 Oct 2005 17:49:16 -0400

So after re-reading the original post I am left with the same question I 
have always had WRT to hold and SDPs.  RFC 3264 is a very nice document but 
why not just tell the truth.

If I have gone on hold and my flavour of hold is neither sending nor 
receiving why would I mark my SDP as sendonly?  I am not sendonly.  I should 
HONESTLY state I am inactive no matter what my stream was before.

If on the other hand my flavour of hold involves playing music to the other 
endpoint then I should HONESTLY state I am sendonly [or heck maybe my music 
oh hold server is a DTMF driven juke box, what fun... ie sendrecv]

If a B2B in the middle sees that you are NOT sending then if it wishes to 
get in the way... let it... after all, some might say it is not in the 
middle... there are two calls.  [A called the B2B and the B2B called B].

As for c=0... well that is very similar to being either inactive or sendonly 
in so much as you refuse to recv, but it does nothing to indicate if you are 
sending.  An agent in the middle cannot start MoH just because c=0, it is 
too weak.  An agent in the middle must have positive indication that you are 
NOT sending.  c=0 just dosn't cut it.

So there is no need for MORE info for an agent in the middle positively know 
that you are not sending.  You just need all UAs to tell the truth [in spite 
of RFC 3264's recommendation that you fib a little and claim you are sending 
even if you are not].

Chris

>From: "Gordon Ledgard" <[email-masked]>
>To: <[email-masked]>
>CC: SIP IETF <[email-masked]>, Paul Kyzivat <[email-masked]>,SIP 
>Implementors <[email-masked]>
>Date: Tue, 4 Oct 2005 13:54:04 -0400
>
>
>

---

From: [email-masked]
Date: Tue, 4 Oct 2005 19:21:21 -0400

"Chris Whitaker" <[email-masked]> 
10/04/2005 05:49 PM

To
[email-masked], Udit Goyal/C/US/3Com@3Com
cc
[email-masked], [email-masked], [email-masked]
Subject
RE: [Sip] Re: [Sip-implementors] Hold SDP

So after re-reading the original post I am left with the same question I
have always had WRT to hold and SDPs.  RFC 3264 is a very nice document 
but
why not just tell the truth.

If I have gone on hold and my flavour of hold is neither sending nor
receiving why would I mark my SDP as sendonly?  I am not sendonly.  I 
should
HONESTLY state I am inactive no matter what my stream was before.

>>[Udit] a="inactive" has one more different meaning as per RFC 3264 where 
you can use it to do capabilities negotiation without actually opening 
>>media [Udit] streams..same problem will arise as we will have two 
differnet interpretation of this mode.. RFC 3264 specifically say if media 
streams >>have to be put on hold, it should use "sendonly attribute, 
rather it should be if you want to play media/music then it must be 
sendonly,..

If on the other hand my flavour of hold involves playing music to the 
other
endpoint then I should HONESTLY state I am sendonly [or heck maybe my 
music
oh hold server is a DTMF driven juke box, what fun... ie sendrecv]

>>[Udit] This seems ok, and thats what the main concern is, if he doesnt 
want to d oanything and any third >>party wants to do something, how can 
it indicate this?

As for c=0... well that is very similar to being either inactive or 
sendonly
in so much as you refuse to recv, but it does nothing to indicate if you 
are
sending.  An agent in the middle cannot start MoH just because c=0, it is
too weak.  An agent in the middle must have positive indication that you 
are
NOT sending.  c=0 just dosn't cut it.

So there is no need for MORE info for an agent in the middle positively 
know
that you are not sending.  You just need all UAs to tell the truth [in 
spite
of RFC 3264's recommendation that you fib a little and claim you are 
sending
even if you are not].

Chris

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Oct 2005 09:22:05 -0400

Chris Whitaker wrote:
> but why not just tell the truth.

I haven't read it recently. But from memory I believe that 3264 is 
probably over-reaching in its statements about hold. At best I think 
they should be *examples* of what one *might* do upon local invocation 
of a HOLD feature.

> should HONESTLY state I am inactive no matter what my stream was before.

I agree with you.

> other endpoint then I should HONESTLY state I am sendonly [or heck maybe 
> my music oh hold server is a DTMF driven juke box, what fun... ie sendrecv]

Yes.

> If a B2B in the middle sees that you are NOT sending then if it wishes 
> to get in the way... let it... after all, some might say it is not in 
> the middle... there are two calls.  [A called the B2B and the B2B called 
> B].

Well, given that a B2BUA can do pretty much anything, I agree with you.
To the extent that the B2BUA is trying to be mostly transparent, and 
"just trying to help", I think it will be making a mistake to do this. 
There are many cases where butting in and sending something, in lieu of 
the endpoint doing so, will be just plain wrong. Of course, if the B2BUA 
knows its UAs well, and is certain there are no such cases, then this 
may be appropriate for it to do. But not in general.

> sendonly in so much as you refuse to recv, but it does nothing to 
> indicate if you are sending.  An agent in the middle cannot start MoH 
> just because c=0, it is too weak.  An agent in the middle must have 
> positive indication that you are NOT sending.  c=0 just dosn't cut it.

So I agree with you here, except that I don't think the other case is 
any stronger than this one.

	Paul

> know that you are not sending.  You just need all UAs to tell the truth 
> [in spite of RFC 3264's recommendation that you fib a little and claim 
> you are sending even if you are not].
> 
> Chris
> 
>