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