Bharath,
You previously sent a similar query to me and the other authors of
rfc6337. I encouraged you to send your query to this list, so I'm happy
to see that you did that.
Unfortunately your message here is harder to understand because it lacks
the diagram that the original did. So others may not be able to follow
the discussion.
I'm attaching a copy of the reply that I sent to you previously.
Best wishes,
Paul
On 1/27/17 5:18 AM, Bharath Reddy Mallepalli wrote:
Dear All,
I’m facing difficulty in understanding the below scenario especially to
determine what should be the media direction in M19 and M22. Kindly help me.
Party-A and Party-B: User Agents
Proxy: B2BUA
1. Party-A sends INVITE with media direction “sendrecv”
2. Party-B answers the call with the media direction “sendrecv”. Call
got successfully established
3. Party-A has initiated Call Hold, so it’s sending re-INVITE with
media direction as “sendonly” (as per 24.610
<https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1124>
)
4. Party-B has received re-INVITE with media direction as “sendonly”,
so it’s responding with “recvonly” (as per 24.610
<https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1124>).
Call hold is successful.
5. Server is sending re-INVITE without SDP to Party-A. As per rfc6337
<https://tools.ietf.org/html/rfc6337#section-5.1>, since the “Desired
State” of Party-A is “Hold” i.e “sendonly” so Party-A is sending an offer
with the media direction as “sendonly” in 200OK
6. Server is receiving an offer in 200OK with media direction as
“sendonly” and responding back with “recvonly” (Proxy’s previously
negotiated media direction is “recvonly” towards Party-A)
7. Server is sending re-INVITE without SDP to Party-B. As per rfc6337
<https://tools.ietf.org/html/rfc6337#section-5.1>, since the “Desired
State” of Party-B is “ACTIVE” i.e “sendrecv” so Party-B is sending an offer
with the media direction as “sendrecv” in 200OK
8. Server is receiving an offer in 200OK with media direction as
“sendrecv” and responding back with “sendonly” (Proxy’s previously
negotiated media direction is “sendonly” towards Party-B)
9. Party-B also has initiated Call Hold, so it’s sending re-INVITE
with media direction as “inactive” (as per 24.610
<https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1124>
)
10. Party-A has received re-INVITE with media direction as “inactive”, so
it’s responding with “inactive” (as per 24.610
<https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1124>).
Call hold is successful.
11. Server is sending re-INVITE without SDP to Party-A. As per rfc6337
<https://tools.ietf.org/html/rfc6337#section-5.1>, since the “Desired
State” of Party-A is “Hold” i.e “sendonly” so Party-A is sending an offer
with the media direction as “sendonly” in 200OK
12. Server is receiving an offer in 200OK with media direction as
“sendonly” and responding back with “inactive” (Proxy’s previously
negotiated media direction is “inactive” towards Party-A). *Is this
correct?*
13. Server is sending re-INVITE without SDP to Party-B. As per rfc6337
<https://tools.ietf.org/html/rfc6337#section-5.1>, since the “Desired
State” of Party-B is “HOLD” i.e “sendonly” so Party-B is sending an offer
with the media direction as “sendonly” in 200OK. *Is this correct?*
14. Server is receiving an offer in 200OK with media direction as
“sendonly” and responding back with “inactive” (Proxy’s previously
negotiated media direction is “inactive” towards Party-B)
*References:*
https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=1124
4.5.2 Invocation and operation
4.5.2.1 Actions at the invoking UE
In addition to the application of procedures according to 3GPP TS 24.229
[1], the following procedures shall be applied at the invoking UE in
accordance with RFC 3264 [4].
If not all the media streams are affected, the invoking UE shall generate a
new SDP offer where:
1) for each media stream that is to be held, the SDP offer
contains:
- an "inactive" SDP attribute if the stream was previously set
to "recvonly"; or
- a "sendonly" SDP attribute if the stream was previously set
to "sendrecv";
https://tools.ietf.org/html/rfc6337
Below sections:
5.1. General Principle for Constructing Offers and Answers
5.3. Hold and Resume of Media
I’m not sure whether the same issue is already discussed before on this
thread. Unfortunately could not able to locate anything related to this.
Please help me in figuring out an ideal media direction in the above
scenario.
Regards,
Bharath
Ph: +91-914 897 8095
"*Confidentiality Warning*: This message and any attachments are intended
only for the use of the intended recipient(s), are confidential and may be
privileged. If you are not the intended recipient, you are hereby notified
that any review, re-transmission, conversion to hard copy, copying,
circulation or other use of this message and any attachments is strictly
prohibited. If you are not the intended recipient, please notify the sender
immediately by return email and delete this message and any attachments
from your system.
*Virus Warning:* Although the company has taken reasonable precautions to
ensure no viruses are present in this email. The company cannot accept
responsibility for any loss or damage arising from the use of this email or
attachment."
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
--- Begin Message ---
Bharath ,
First, I see you have sent this to the authors of rfc6337. I would
prefer to have such discussions on a public list. That way others have
the opportunity to see and comment on the issue. Specifically I
recommend <sip-implementors@lists.cs.columbia.edu>. Feel free to repost
this response there.
On 1/27/17 5:00 AM, bharath.re...@ril.com wrote:
Dear Sirs,
Thanks a lot for detailed description and sharing the best practices of
the Offer/Answer model cited in https://tools.ietf.org/html/rfc6337. I’m
facing difficulty in understanding the below scenario especially to
determine what should be the media direction in M19 and M22. Kindly help me.
Party-A and Party-B: User Agents
Proxy: B2BUA
Yes, lets be clear that the "proxy" is a B2BUA, not a proxy. Hence all
those lines that show messages between A and B should really be broken
in the middle because you have two different dialogs.
It isn't clear from your message whether the B2BUA (I guess you call it
"Server" below) is also a media relay, or if it only does sip signaling.
1. Party-A sends INVITE with media direction “sendrecv”
2. Party-B answers the call with the media direction “sendrecv”.
Call got successfully established
3. Party-A has initiated Call Hold, so it’s sending re-INVITE with
media direction as “sendonly” (as per 24.610
<https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1124>)
4. Party-B has received re-INVITE with media direction as
“sendonly”, so it’s responding with “recvonly” (as per 24.610
<https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1124>).
Call hold is successful.
So far so good.
5. Server is sending re-INVITE without SDP to Party-A. As per
rfc6337 <https://tools.ietf.org/html/rfc6337#section-5.1>, since the
“Desired State” of Party-A is “Hold” i.e “sendonly” so Party-A is
sending an offer with the media direction as “sendonly” in 200OK
*Why* is the server doing this? Is it trying to impose itself as a
Music-on-Hold server?
Here it really matters if the server handles media locally. Is it, at
this point, intending to take over the media streams?
6. Server is receiving an offer in 200OK with media direction as
“sendonly” and responding back with “recvonly” (Proxy’s previously
negotiated media direction is “recvonly” towards Party-A)
The previous negotiation was between A and B, and so the response was
predicated on what B wanted *constrained* by the limits of what A
offered. So B might have wanted sendrecv or might have wanted recvonly.
But here the server is generating the response. If it is trying to
reflect what it thinks B wants (rather than what the server itself
wants) then this response is probably ok.
7. Server is sending re-INVITE without SDP to Party-B. As per
rfc6337 <https://tools.ietf.org/html/rfc6337#section-5.1>, since the
“Desired State” of Party-B is “ACTIVE” i.e “sendrecv” so Party-B is
sending an offer with the media direction as “sendrecv” in 200OK
Again I ask *why* it is doing this? The only reason I can see is that it
wants to decouple the media of A and B.
8. Server is receiving an offer in 200OK with media direction as
“sendrecv” and responding back with “sendonly” (Proxy’s previously
negotiated media direction is “sendonly” towards Party-B)
This is odd (or entirely broken). The server is calling the shots here.
It is arranging for both A and B to send to it, while not sending
anything back. It is a situation that would not arise if the server
weren't present.
9. Party-B also has initiated Call Hold, so it’s sending re-INVITE
with media direction as “inactive” (as per 24.610
<https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1124>)
I haven't read that 3gpp document, and don't want to take the time to
come up to speed on it now. It may be wrong, or you may be interpreting
it incorrectly.
If B wants to put the call on hold, then following rfc6337 it should
offer what it wants. Typically hold is indicated by offering sendonly,
so that is what I would expect here. (But I have no problem with B
offering inactive if it doesn't intend to send media while on hold.)
10. Party-A has received re-INVITE with media direction as “inactive”,
so it’s responding with “inactive” (as per 24.610
<https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1124>).
Call hold is successful.
This seems fine.
11. Server is sending re-INVITE without SDP to Party-A. As per rfc6337
<https://tools.ietf.org/html/rfc6337#section-5.1>, since the “Desired
State” of Party-A is “Hold” i.e “sendonly” so Party-A is sending an
offer with the media direction as “sendonly” in 200OK
Again I have to ask *why* is it doing this? Why doesn't it leave the
call as it is?
12. Server is receiving an offer in 200OK with media direction as
“sendonly” and responding back with “inactive” (Proxy’s previously
negotiated media direction is “inactive” towards Party-A). *Is this
correct?*
Again, what to do here depends on what you are trying to achieve.
13. Server is sending re-INVITE without SDP to Party-B. As per rfc6337
<https://tools.ietf.org/html/rfc6337#section-5.1>, since the “Desired
State” of Party-B is “HOLD” i.e “sendonly” so Party-B is sending an
offer with the media direction as “sendonly” in 200OK. *Is this correct?*
14. Server is receiving an offer in 200OK with media direction as
“sendonly” and responding back with “inactive” (Proxy’s previously
negotiated media direction is “inactive” towards Party-B)
I can't answer any more without further information on what you are
trying to achieve.
Thanks,
Paul
--- End Message ---
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
