Re: [Sip-implementors] RFC 6337, Section 5.3. Hold and Resume of Media
Parveen Aggarwal writes: > 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 Let's spell this out more clearly: 1. A offers "sendrecv" to B. B answers "sendrecv". 2. B holds call: B offers "sendonly". A answers "recvonly". 3. A holds call: A offers "sendonly". B answers "inactive". Note that in step 3, A wants to put the call on hold, so it is unwilling to *send* but it is willing to *receive*. However, B is unwilling to send, so it vetoes media in that direction, leaving only "inactive". Note the general principle that you can't describe what is happening by simply saing "X holds call with ", you have to show both the offer and the answer to understand the dynamics of the interaction. > Now, If B receives re-invite without SDP what should be media direction > attribute value > "*sendonly"* or *"inactive" *in offer of 200OK As others have noted, B should offer *everything that it is willing to do*. In this case, B still has the call on hold, so it is willing to do "sendonly", as it is willing to send music-on-hold but isn't willing to render any media that it receives. Since A still has the call on hold, it will likely answer "inactive". > *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. Note in the passage that you marked, "If it previously initiated a "hold"...". The use of "initiated" means "If it previously *offered* a=sendonly or a=inactive ...". Dale ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
Re: [Sip-implementors] RFC 6337, Section 5.3. Hold and Resume of Media
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
[Sip-implementors] RFC 6337, Section 5.3. Hold and Resume of Media
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. Thanks, Parveen ___ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
