Of course the refresher should always be prepared to receive a new SDP. What I was trying to establish is what can the UAC and UAS do to re-use a previous SDP (as RFC 4028 suggests) when the roles of the offer/answer dialog have been reversed since the last exchange.
For the refresher UAC to use its latest SDP shouldn't be a problem. So let's talk about the UAS: can it send a copy if its latest SDP when it detects the incoming SDP hasn't changed? Remember, it was originally an offer, possibly with m-lines, direction attributes, etc. that were modified by the original answer. That might make this particular offer/answer exchange illegal as per 3264. So to be on the safe side, for session refresh I should: - as a UAC, send my latest SDP and be prepared to receive either a new one or a copy of the previous SDP; if I receive a copy of the previous SDP I should NOT attempt to process it, since its contents might be illegal in the current context - as a UAS, if the incoming SDP version number hasn't changed AND my most recent SDP was an answer, send it as-is; otherwise, prepare a new answer based on the offer, as usual Or, alternatively, forget what 4028 says about re-using existing SDP, and just send a brand new SDP in the session refresh INVITE. Thanks, Bram Paul Kyzivat wrote: > There is nothing you can do when sending an offer that will guarantee > that the answer will be the same as the prior answer. For your offer you > may use the last SDP you sent, with an unchanged o-line, which at least > will mean that an answer the same as the prior will be valid. But it > does not impose a requirement on the answerer to send an unchanged answer. > > I think it is better to think of this the same as the getting-off-hold > scenarios in the offeranswer draft: If you are sending an offer, > regardless of why including because you are simply trying to do session > timer, send an offer that includes what you would currently like to > have. And the answer should include what the answerer would like to have > constrained by the offer. If desires have not changed at either end, > such as is likely to be the case for a session refresh, then you will > most likely end up agreeing on the same things as last time. But not > that if the UA sending the offer had been the answerer in the prior > exchange then the offer may well differ from the prior answer. This is > because the answer might not have included all the answerer wanted > because it was constrained by the prior offer. The new offer is less > constrained, and so may differ. > > You cannot count on the sdp remaining unchanged, and so should not > attempt to code session refresh assuming it won't. > > Thanks, > Paul > > Vikram Chhibber wrote: > > 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 > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
