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?
Regards, Amarnath On Wed, Dec 19, 2018 at 10:19 PM Paul Kyzivat <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 > 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
