Subject: RE: [Sipping] FW: I-DACTION:draft-sawada-sipping-sip-offeranswer-01.txt

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 22 Jun 2006 13:06:26 +0200

Hi Paul, 

>> I can't think of something that may legally be included in a 
>> subsequent offer for which the answered could not find some
meaningful answer that should be compatible with its current state.
> 
>[CHH] To give a very simple example (maybe not the most likely to
happen, and maybe we can forbid to do it with PRACK, but still): the new
offer contains a list of codecs 
>(formats), of which the receiver doesn't (for whatever reason) support
any. But, according to RFC3264 the answer MUST contain at least one of
those codecs.
> 
>Now, that's for audio. When we start talking about media types like
video, there may be much more information embedded in the offer, which
the receiver must be able to 
>process and/or reserve resources for in order generate a valid answer.
> 
>And, as I said before, the problem may not be the offer itself - but
the fact that the receiver simply isn't able to process it at a certain
time. It may not be a problem for a 
>SIP phone. And, e.g. in an interworking entity external signalling may
even be required in order to process the offer, and generate the answer.
> 
>I haven't checked whether there could be cases related to the
pre-conditions procedure, which is the reason we allowed PRACK for
offer/answer usage in the first place, 
>but maybe there is something. 
> 
>But, I am not sure we need to spend time on thinking about cases where 
>a receiver isn't able to generate an answer. The point is that I don't 
>want us to make that assumption. [/CHH]

>OK, I give. I could swear that 3264 used to say that the codecs in a
revised media line had to include one from before, but I can't find it,
so either I remember wrong or it 
>went away a long time ago.

[CHH] I was looking for something similar myself, but the only thing I
could say was that the answer MUST contain at least one of the codecs
from the offer.

>And there are indeed other kinds of changes allowed by 3264 that might
just not work - such as changing the media type.
>
>It is technically possible to still make all of this work by refusing
all the offered media streams. But that will 
>clearly be a poorer result than refusing the offer itself.
>Interestingly, there is no concept of rejecting an offer, in 3264 or in
3261. 3264 has the concept of refusing one or 
>more offered media lines (up to and including all of them) but that
does not have the semantic of reverting to the prior 
>offer/answer. And 3261 has the concept of rejecting a message that
might be carrying an offer or answer. But the 
>semantics of that are dependent on what the request was. In the case of
reINVITE, that has the effect of rolling back all 
>the changes that would have resulting, not just the offer/answer state.
Same with UPDATE. And same with PRACK, which is 
>the one that is bothering you.
>
>If we were to define a new way to reject an offer (rolling back to
prior completed offer/answer) without rejecting the 
>request carrying the offer, then we ought to do it in all the cases
where offers may be carried. For instance, a reINVITE 
>can carry an offer/answer but may also do a target refresh and refresh
a session timer. So rejecting just the offer in a 
>reINVITE would let those other things go to completion. (Its less clear
what rejecting just the offer in an initial 
>invite would mean, but we can probably come up with something
meaningful.)

One option would be to define that a zero port value in an SDP answer
only means that the offer request, for that specific m= line, was
rejected, and that would revert to the previous (if any) offer/answer
values (sending a zero port to a modification request of an existing
stream would not remove the stream). The advantage is that you could
accept some m= line modifications, while you reject others. But, as Paul
said, this is not specified behavior in 3261/3264 today.

Another option would be to e.g. send a "dummy" SDP in the 200 OK, but
DESCREASE the sess-version value in the SDP answer. The UAC would then
check the sess-version value (as it should already today), and since a
decreased value is not valid it would reject the answer and revert back
to the previous offer/answer values. It would not be possible to reject
individual streams, but it would be possible to reject the whole SDP
offer - no matter what the SIP response code is. Not sure it's a very
"clean" solution, though...

>This is a significant change. And of course we would have to deal with
backward compatibility. An alternative is simply 
>to ban offers in PRACK.
>Probably easier, except for the backward compatibility issues, which
remain.
>
>From an academic perspective I think introducing a way to reject offers
without rejecting the request seems interesting. 

The options I presented would do that.

>But I don't think it is the best use of everyone's time and energy. I
think *deprecating* offers in PRACK is a 
>possibility. But answerers would still have to deal with the case. So
it may be just as good to leave it to the 
>discretion of offerers to use offers in PRACK with care.

That is probably the easiest way, but I don't think it's going to solve
anything. And, who really then decides what a "valid" PRACK offer really
is?

Regards,

Christer

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP