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

From: [email-masked]
Date: Tue, 4 Oct 2005 13:20:52 -0400

Hi Paul, 
Agree on all points   Just pointing out an additional practical issue in 
the Hold scenarios (and trying not to get flamed ;-). 
-- Peter

Paul Kyzivat <[email-masked]>
04.10.05 12:50

        To:     [email-masked]
        cc:     SIP IETF <[email-masked]>, [email-masked], SIP Implementors 
<[email-masked]>, [email-masked]
        Subject:        Re: [Sip] Re: [Sip-implementors] Hold SDP

[email-masked] wrote:
> 
> Some related discussion has also gone on in SIP Forum context recently. 
> 
> I believe an additional issue here is that, in many practical 
> deployments, there is something in between the UAs (softswitch, ip-pbx, 
> SBC, other B2B UA) which could mis-interpret the meaning of the SDPs and 

> take the wrong action based on assumptions.  For example the middle 
> entity could see the sendonly attribute, assume it is for Hold when it 
> actually being used to implement (say) a one-way audio conference/listen 

> session, and go ahead and insert it's own music on hold.  Oops!   There 
> are many, many such scenarios.  This can certainly happen, no matter how 

> well-behaved the UA is (... and not all UAs are well behaved of course 
> ;-). 
> 
> I'm NOT saying such middle boxes are good, bad or indifferent.  (I'm 
> sure others will chime in that they are inherently evil ;-)  However, 
> they are a practical reality. 
> 
> Having some form of explicit "reason" indicator, likely at SIP level not 

> in SDP, could be a big help to solve this issue, and similar ones. 
>  Would potentially help clean up both middle box and UA behavior. 

Peter,

I think this is a matter of philosophy. IMO the development of sip has 
been predicated on the assumtion that the UA is the one that knows what 
is going on, and that at least coordinates actions, if it doesn't do 
them itself. The other elements of the network have much less 
information about what is going on, and hence have a much harder time of 
deciding on their own how to "help" without "hurting" instead.

Certainly the sip signaling gives intermediates *some* information about 
what is going on, enough to do the limited sets of things that have been 
proposed that they do. But they certainly don't have the big picture.

In the case of hold, there is no problem as long as the endpoints do 
what they should and the intermediates just stay out of the way. The 
problem comes in when intermediates want to "help" without having 
adequate information to do so correctly. There are two solutions to this 
problem: they could stop trying to help, or they can be provided with 
more information so they can do a better job of helping.

Before proposing that more information be provided, I think it is first 
necessary to decide if this is the appropriate direction to be going.

                 Paul

> Thinking out loud ...
> 
> Peter Blatherwick
> 
> 
> 
> 
> 
>                *Paul Kyzivat <[email-masked]>*
> Sent by: [email-masked]
> 
> 04.10.05 10:08
> 
> 
>         To:        [email-masked]
>         cc:        SIP IETF <[email-masked]>, SIP Implementors 
> <[email-masked]>
>         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