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
