Parveen,
On 7/10/18 4:24 AM, Parveen Aggarwal wrote:
Hi Experts,
I have below scenario
1. A Calls B with "sendrecv"
2. B holds call with "sendonly"
3. A holds call with "inactive"-- both A and B media direction is "
*inactive" *now
Now, If B receives re-invite without SDP what should be media direction
attribute value
"*sendonly"* or *"inactive" *in offer of 200OK
*As per RFC 6337, Section 5.3. Hold and Resume of Media*
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.
The issue above is that when A held the call, it probably should not
have offered "inactive". Assuming it just wanted a normal hold and was
willing to offer music on hold, then it should have used "sendonly" in
its offer. In response, B would then probably have answered "inactive",
because it didn't want to receive media.
Then the above text you highlighted would work right.
The key principle is that the end generating an *offer* should offer
what *it* desires, without trying to guess what the other end wants.
Then the answerer generates an answer that is compatible with the offer
and otherwise reflects what the answerer wants.
Trying to guess what the other end wants often gets you into trouble,
because it unnecessarily limits what the answer can do. In your example,
when A offers "inactive" rather than "sendonly" then it is (probably)
doing so because it is *assuming* that B doesn't want to receive media.
However this depends on the implementation. A device that doesn't want
to send music on hold may indeed want to offer "inactive" to initiate a
hold.
Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
