> To my understanding , > In the scenario mentioned by you. > INVITE (Offer1) > 18x (Answer1) > UPDATE (Offer2) > 2xx UPDATE (Answer2) > 2xx INVITE (Offer3) /* This will be a new offer again */ > ACK INVITE (Answer3) > > So an answer for offer3 needs to be sent in ACK.
Within your example (assuming PRACK used but not shown), the SDP within INVITE 2xx must be ignored. Thus it is not an offer; and there would not be an answer within the ACK. > > *Hi All,* > > * Can U corect me, If i am wrong....* > > ** > > *Assume the UAC receives the SDP (answer_1) in a > > reliable 18x. After that, is sends eg an UPDATE with > > a new offer, and receives a new(answer_2) in the > > UPDATE response. Then, INVITE 200 OK is received, > > from the same UAS. > > Now, to my understanding the SDP in the > > INVITE 200 OK response shall still be the one > > first sent, ie answer_1, but since that is now not > > "valid" anymore (since answer_2 has been received after > > that) the UAC shall not use > the SDP received in > > the 200. Instead it shall use the > > latest answer, ie answer_2. The SDP within INVITE 2xx must be ignored. Vendors which place the useless SDP within the INVITE 2xx generally do so for perceived interoperability reasons with devices not yet compliant to rfc3261. Based upon rfc analysis after SIPit 21, the SIP working group appears to have agreed that the useless SDP is not required to be SDP from the reliable 18x; thus it may be the SDP resulting from UPDATE. Many answers concerning offer/answer can be found within draft-ietf-sipping-sip-offeranswer. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
