On 12/21/18 12:27 AM, Amarnath Kanchivanam wrote:
Thanks Paul, yes it helps.
I have one more question - What should be the SDP answer for empty
Re-Invite (without SDP) in hold and non hold scenario?
The SDP in the response to a INVITE/reINVITE is an *offer*, not an *answer*.
As I noted before, it doesn't really matter whether it is a hold or
non-hold case. The one sending the offer should offer what *it* wants at
that time, without regard to what it might guess that the other end
might want. The other end can deal with its desires in the answer.
To cover some common cases,
1) assume that Alice and Bob are in a call and Alice put the call on hold:
1a) if Bob receives an offerless reinvite, he most likely should put
sendrecv in the offer he sends back. Note that it is valid but odd for
Alice to send this, but it makes more sense if it was sent by a
middlebox. (I presume Bob doesn't *want* hold, or he would already have
sent another invite to indicate that.)
1b) if Alice receives an oferless reinvite, she will most likely want to
put sendonly in the offer she sends back. (If she had changed her mind
about wanting to be on hold she would have then sent a reinvite with an
offer with sendrecv.
1c) Suppose Bob now also wants to put the call on hold. (Doesn't want to
receive media from Alice.) He will send a reinvite with an offer to
accomplish this. He may put either sendonly or inactive in that offer.
Either way, assuming Alice still wants the call on hold she must put
inactive in her answer.
1d) suppose in the initial invite of the call Alice had offered both
audio and video, and Bob had accepted the audio and rejected the video.
When Alice sends subsequent offers within the call she may well want to
continue to offer video, just in case Bob has a change of heart and
might accept it, though this might seem to be unlikely. This becomes
more interesting when there is a middlebox in the call, such as a device
managing 3pcc (third party call control). It is common for such a device
to send an offerless invite to Alice when it wants to transfer the call
from Bob to Charlie. In that case it may be that Charlie would accept
the video.
But this needs to be tempered by the UI between Alice and her phone. It
may be that she is no longer prepared for video in the call. Perhaps the
video resource is being used for something else. So in the end this is
an implementation choice.
There are similar issues regarding alternative codecs for the media.
Ideally the offerer will include all supported codecs in every offer.
But optimization of the implementation may result it in wanting to limit
what it puts in subsequent offers, based on what is being used. Doing so
can cause trouble in the 3pcc case.
Note that while I say that offers should reflect what the offerer wants
without regard to what it thinks the answerer will want, there are some
constraints on this documented in 3261 and 3265. For instance, if a
payload type has been used earlier in the call for an rtp session then
it can't be used for a *different* codec or codec configuration later in
the session.
Thanks,
Paul
Regards,
Amarnath
On Wed, Dec 19, 2018 at 10:19 PM Paul Kyzivat <pkyzi...@alum.mit.edu
<mailto:pkyzi...@alum.mit.edu>> wrote:
Amarnath,
Take a look at RFC6337 for an in-depth treatment of offer/answer issues
and best practices. More below, consistent with what is in that rfc.
On 12/19/18 12:28 AM, Amarnath Kanchivanam wrote:
> Hi,
>
> I have below call flow and would like to know the correct behavior.
>
> UAC UAS
> INVITE ----------------->
> <---------------200 OK
> Ack ---------------------->
>
> Now UAS puts call on Hold
>
> <---------------Re-Invite with
send-only
> attribute
> 200 OK ----------> recv-only
> <--------------Ack
>
> Now UAS does Un-Hold
> <-------------Re-Invite*
without SDP*
> 200 OK ----------> recv-only
> <----------------Ack with SDP
As already noted, the offerless reinvite doesn't indicate a desire
to go
off hold. Nor does it indicate a desire to stay on hold. Rather, it
asks
the other side to indicate its preference at this time.
The subsequent offer of recvonly is however probably at least an unwise
choice for the left UA. It wasn't the end that initiated the hold, and
so *presumably* it would prefer to *not* be on hold. Assuming that is
the case, it should have send an offer with sendrecv. If it had done
that, then the UA on the right would have been able to choose to answer
sendrecv if it wanted to be off hold, or sendonly if it wanted to
remain
on hold.
In general, when sending a subsequent *offer* in a session a UA should
reflect its own needs and refrain from inferring what it thinks the
other end wants.
> In final Ack there is no SDP attribute (sendrecv or send-only).
This is *wrong*. Since there is no attribute indicating a preference,
the default is sendrecv. And sendrecv is not permitted as an answer in
response to recvonly. Rather, it must respond with either sendonly or
inactive.
> With this
> call flow UAC failed to Un-Hold and continue to be on hold operation.
This reflects screwups by both ends.
> I would like you to share your comments which would help to
understand the
> correct behavior.
I hope this helps.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
<mailto:Sip-implementors@lists.cs.columbia.edu>
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
