Pavan, The Re-INVITE in this use case is modifying a dialog. It is upto the UA to populate what is configured on that UA. If for some reason the UAC1 does not accept the offer, it shall roll back to the previous negotiated state.
Thanks, Neel > -----Original Message----- > From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- > implementors-boun...@lists.cs.columbia.edu] On Behalf Of Pavan Pandey > Sent: Tuesday, August 02, 2016 3:05 PM > To: sip-implementors@lists.cs.columbia.edu > Subject: [Sip-implementors] - RFC 6337 Section 5.1 - reINVITE without sdp > > > Hi All, > > In the below mentioned scenario, UA supports advanced Video, AVPF and > SAVPF features. > > UAC1 initiates an audio call with UA and subsequently sends reINVITE > without sdp. > > As per RFC 6337 section 5.1 understanding, UA should make an offer with all > the media capabilities. > > In step 4, we could potentially see one heavy offer from UA to UAC1 in > reINVITE 200 OK. If UA supports text, image etc, it would get even bulkier. > > > UAC1--------------------------------------------------------------------------------------- > -------------------------------------------UA > > > > > > > > 1)---------------------INVITE (audio > > AVP)--------------------------------------------- > -----------------------------------------------> > > > 2)<---------------------200-OK(audio > > AVP)------------------------------------------- > -------------------------------------------------- > > > > > 3)-------------------------------ACK------------------------------------------------------- > --------------------------------------------- > > > > > > > > > 4)<---------------------reINVITE > > (withoutsdp)--------------------------------------- > ----------------------------------------------------- > > > 5)---------------------200-OK(audio AVP + audio AVPF + video AVP + video > AVPF + audio SAVP + video SAVP + audio SAVPF + video SAVPF)---> > > > 6)<---------------------------ACK > > ()----------------------------------------------------- > ---------------------------------------------- > > > > > > Is it okay to just send all the media capabilities of just the negotiated > media > stream in step 5? Just offer all the media capabilities for the negotiated > media stream(s). > > > > 5)---------------------200-OK(audio AVP with all the media formats and the > capabilities)---> > > > > 5.1<https://tools.ietf.org/html/rfc6337#section-5.1>. General Principle for > Constructing Offers and Answers > > A UA should send an offer that indicates what it, and its user, are > > interested in using/doing at that time, without regard for what the > > other party in the call may have indicated previously. This is the > > case even when the offer is sent in response to an INVITE or re- > > INVITE that contains no offer. (However, in the case of re-INVITE, > > the constraints of [RFC3261<https://tools.ietf.org/html/rfc3261>] and > [RFC3264<https://tools.ietf.org/html/rfc3264>] must be observed.) > > > > A UA should send an answer that includes as close an approximation to > > what the UA and its user are interested in doing at that time, while > > remaining consistent with the offer/answer rules of > [RFC3264<https://tools.ietf.org/html/rfc3264>] and > > other RFCs. > > > > NOTE: "at that time" is important. The device may permit the user > > to configure which supported media are to be used by default. > > > > In some cases, a UA may not have direct knowledge of what it is > > interested in doing at a particular time. If it is an intermediary, > > it may be able to delegate the decision. In the worst case, it may > > apply a default, such as assuming it wants to use all of its > > capabilities. > > > > > Thanks and Regards, > Pavan > _______________________________________________ > 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
