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
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
