If you preserve the previous value of o line of your SDP in the re-INVITE, this indicates that the offer is not intended to change the session parameters since the SDP version is same. In this case, the UAS should not go through the processing of SDP ideally and you are free to put whatever you like in the SDP; rejected codecs too (i.e. the previous offer itself). if UAS does not match received o line (SDP version) before processing, it will again renegiotiate the offer and and send back the answer with different version. The UAC should be prepared to process this answered SDP.
On Tue, Sep 9, 2008 at 3:00 PM, Bram Verburg <[EMAIL PROTECTED]> wrote: > Vikram, > > Agreed, for the most part. But... > > > Once an offer answer completes, you are left with some > > state of session. You can not say that I have answer or > > offer now. There is nothing in the SDP that says that I > > am answer or offer. Therefore in case of session-timers, > > if the most recent answerer is sending session-refresh > > INVITE, it will have SDP same as the answer that it sent > > which would be its present session state. > > I agree that it should be safe to use the most recent answer as the > offer in the re-INVITE. My problem is with how the UAS selects the > answer for the session refresh. I don't think it is necessarily legal > for the UAS to send its latest SDP (it might contain m-lines or codecs > that were rejected). > > In order to support the ideal session refresh scenario, in which the SDP > offer/answer sequence simply exchanges copies of previous SDPs, the UAS > needs to keep track of whether it was the side offering or answering. If > it was previously answering it can simply copy the previous answer, but > if it was previously offering it has to either make an informed decision > whether its previous offer would be legal as an answer, or answer with a > new SDP by default. > > So it seems a UA needs to remember whether its most recent SDP was an > offer or an answer after all. > > Thanks, > > Bram > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
