Bram Verburg wrote:
> 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.
IMO, if sending this would be illegal per 3264, then it must not be
sent. Rather, a valid response should be constructed. That response can
be consistent with the prior exchange, in that the result will be the
same number of m-lines, same agreed up codecs, same addresses and ports,
etc. (And while that is a plausible way to respond, I think there is no
*requirement* to respond that way. Any answer compatible with the offer
may be sent.)
> 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
IMO this is incorrect. The first priority is that the answer be correct.
If it also happens to be the same, then the o-line will indicate that it
is the same. The act of taking a different path when receiving an SDP
with an identical o-line is an *optimization*. It should not be required
behavior. It should be perfectly fine for an implementation to parse and
validate every offer and answer it receives.
> - 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.
In spite of its relatively recent RFC number, the session timer draft is
*ancient*. (It just took a very long time to progress to rfc.) I think
its origins may predate 3264. (I'm not certain of that.) So it tends to
have some quaint simplistic assumptions. When there is a conflict, such
as here, I think is best to just ignore what 4028 says about using the
existing sdp, even though that is MUST strength. I guess the option is
to send the reinvite with no offer. Note that the same paragraph
explicitly states "A re-INVITE generated to refresh the session is a
normal re-INVITE". So sending something that is invalid as a normal
reinvite would be a bad thing.
Thanks,
Paul
> 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
