[SIPForum-discussion] Sdp attribute for Call hold

[ankur bansal]

Hi All

As most of you mentioned when user wants to put Music on hold then it sends
a= sendonly so this is use-case driven and seems fine .
But in case of normal hold , whats need of sending a=sendonly ?
OR can we say if music need not be played when on hold ,then there is no
issue in sending a=inactive?

>From Vijay's explanation , i can think of one probable reason of sending
a=sendonly in normal hold case .
As  the Hold scenario is in context of  local end .Once User A puts call on
hold ,User B can also hold the call from his end.

Case 1 (a=sendonly used for putting call on hold)
=====
A wants to put call on Hold
 A(INVITE a=sendonly)----------------->
 B(200 ok a=recvonly)<------------------

Now B wants to put call on hold ..it will send inactive or sendonly...this
is also debatable
 B(INVITE a=inactive) <-----------------
 A(200 ok a=inactive) ------------------>


Case 2 (a=inactive used for putting call on hold)
=====
A wants to put call on Hold
 A(INVITE a=inactive)----------------->
 B(200 ok a=inactive)<------------------

Now B wants to put call on hold and it has to send inactive ,but that does
not make sense to send new INVITE with inactive as session already updated
with inactive .

So to allow User B to put call on hold when call is already held from other
party ,User A send a= sendonly and also to make sure call is not stuck
in hold status only for subsequent offers   as explained in RFC 6337 :

                     *If UA2 has been "placed on hold" by UA1 via receipt
of "a=inactive"*
*                     attribute, and subsequently wants to initiate its own
hold, also*
*                     using "a=inactive" attribute, it need not send a new
offer, since the*
*                    only valid response is "a=inactive" attribute and that
is already in*
*                    effect. However, its local desired state will now be
either*
*                     "inactive" or "a=sendonly" attribute. This affects
what it will send*
*                     in future offers and answers.*
*
*
*                     If a UA has occasion to send another offer in the
session, without*
*                    any desire to change the hold status (e.g., in
response to a re-*
*                    INVITE without an offer, or when sending a re-INVITE
to refresh the*
*                   session timer), it should follow the "General Principle
for*
*                  Constructing Offers and Answers" (Section 5.1). If it
previously*
*                  initiated a "hold" by sending "a=sendonly" attribute or
"a=inactive"*
*                  attribute, then it should offer that again. If it had
not previously*
*                  initiated "hold", then it should offer "a=sendrecv"
attribute, even*
*                  if it had previously been forced to answer something
else. Without*
*                 this behavior it is possible to get "stuck on hold" in
some cases,*
*                 especially when a 3pcc is involved*

Is my understanding correct ?


Thanks & regards
Ankur Bansal


On Thu, Jun 20, 2013 at 9:38 AM, Vijay Badola <Vijay.Badola at onmobile.com>wrote:

>  If A and B parties are communicating with each other and A wants to put
> B on hold it will send “SENDONLY” in INVITE
>
> and B in response to it should send “RECVONLY”.
>
> After some time if in between of hold condition, B also wants to put A on
> hold then B will send “INACTIVE” in INVITE and in response
>
> to it A will send also “INACTIVE”.
>
> ,Vijay
>
>
>
> *From:* discussion-bounces at sipforum.org [mailto:
> discussion-bounces at sipforum.org] *On Behalf Of *ankur bansal
> *Sent:* Wednesday, June 19, 2013 11:26 AM
>
> *To:* discussion at sipforum.org
> *Subject:* [SIPForum-discussion] Sdp attribute for Call hold
>
>
>
> Hi All
>
>
>
> Can anyone explain why a=sendonly is sent in offer from side performing
> HOLD ?
>
> I think a=inactive should be right way of holding call .
>
> Any specific scenario which explain when to use sendonly and when inactive
>
>
>
> Thanks & regards
>
> Ankur Bansal
>
> ------------------------------
>
> DISCLAIMER: The information in this message is confidential and may be
> legally privileged. It is intended solely for the addressee. Access to this
> message by anyone else is unauthorized. If you are not the intended
> recipient, any disclosure, copying, or distribution of the message, or any
> action or omission taken by you in reliance on it, is prohibited and may be
> unlawful. Please immediately contact the sender if you have received this
> message in error. Further, this e-mail may contain viruses and all
> reasonable precaution to minimize the risk arising there from is taken by
> OnMobile. OnMobile is not liable for any damage sustained by you as a
> result of any virus in this e-mail. All applicable virus checks should be
> carried out by you before opening this e-mail or any attachment thereto.
> Thank you - OnMobile Global Limited.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20130620/726a2c0d/attachment-0002.html>