Subject: RE: [Sipping] BCP for Offer/Answer Use - PLEASE COMMENT

From: "Lyons, Terry" <[email-masked]>
Date: Mon, 31 Oct 2005 11:45:18 -0500

Paul,

Could you clarify what you are thinking of here?
How does rejecting ALL of the streams within an offer change their state?

> Rejecting an offer causes the state of media streams to remain as it was 
> before the offer. Rejecting some/all of the streams within an offer may 
> result in changes to the state of previously negotiated streams.

- [email-masked]  +1 732 625 3003 x212

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Monday, October 24, 2005 11:48 AM
To: Lyons, Terry
Cc: [email-masked]
Subject: Re: [Sipping] BCP for Offer/Answer Use - PLEASE COMMENT

Lyons, Terry wrote:
>  * Table 1 is marked 'Est' for the use of 1xx-rel in Patterns 3 and 4
> to update an established session, but this is an unusual practice.  18x
> responses more often occur while initiating a session, where they provide
> feedback on the progress of a call, such as ringing at the called party.

In a pre-00 draft Takuya did comment that this was an unusual practice. 
I wanted to remove that because there has been more discussion recently 
about cases where this behavior is indeed appropriate.

I don't think the verdict is in on that - there are important call flows 
that won't work right if a reinvite is delayed. But I'm thinking that is 
not a value judgement we ought to be making here. If it is, then we need 
to have some discussion on the pros and cons of using provisionals on 
reinvites.

>  * It should be noted that Pattern 4, allowed for Est, cannot be used
> more than once within an initial INVITE transaction.
> 
>  * Section 1.2 "Rejection against an Offer" should perhaps be reworded
> to clarify the intention.  Isn't it true that an explicit rejection is
> always possible, according to section 6 of RFC 3264?
> 
>    An offered stream MAY be rejected in the answer, for any reason.  If
>    a stream is rejected, the offerer and answerer MUST NOT generate
>    media (or RTCP packets) for that stream.  To reject an offered
>    stream, the port number in the corresponding stream in the answer
>    MUST be set to zero.

There is a significant difference between "rejecting an offer" and 
"rejecting streams within an offer".

Rejecting an offer causes the state of media streams to remain as it was 
before the offer. Rejecting some/all of the streams within an offer may 
result in changes to the state of previously negotiated streams.

It is unfortunate that in some cases there is no way to reject an offer. 
If one receives an offer that seems unacceptable but in a way that can't 
be rejected, then the best one can do is create the most acceptable 
valid response. This could refuse all the m-lines (port=0), or it could 
accept them with a=inactive, or it could accept them with c=0.0.0.0, or 
it might take one approach with one stream and a different approach with 
another stream. The effect of course depends on what approach is taken, 
but most of them will result in the cessation of media flow where 
perhaps there had been flow before.

> What may need explaining is what happens next if an offer is rejected.

Do you think it would help to say something like the above?

> Patterns 5 and 6 are subsequent offers, so there are one or more prior
> answers to consider.  If one of those answers was not a rejection, then
> the media streams continue under the latest such offer-answer outcome.
> 
> Patterns 1 through 4 may also be subsequent offers used to update an
> established session, in which case the same would apply:  the media
> streams continue under a prior outcome, if not all were rejections.
> 
> In these cases where a prior outcome continues, it is not necessary
> to explain what happens next.  Rejection need not be followed by a
> new offer.
> 
> If ALL prior offers were rejected, a UA may simply give up the dialog.
> Either UA may do so.  Or either UA may follow with a new offer.
> 
>  * To reduce the probability of glare, it could be suggested that only
> the UA whose offer was rejected should follow with a new offer.

I don't think that works very well, since there is no guarantee that 
there will be any such attempt. Also, rejection isn't all or nothing.

I think its better to just let the normal glare resolution techniques do 
their thing if it does happen.

	Paul

> - [email-masked]  +1 732 625 3003 x212
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Paul Kyzivat
> Sent: Wednesday, October 19, 2005 4:02 PM
> To: sipping
> Subject: [Sipping] BCP for Offer/Answer Use - PLEASE COMMENT
> 
> 
> I would like to call attention to a new draft:
> 
> http://www.ietf.org/internet-drafts/draft-sawada-sipping-sip-offeranswer-00.txt
> 
> This draft attempts to codify a lot of folklore about how offer/answer 
> works. The need for this is apparent from the number of times the 
> subject comes up on the sip-implementors (or sipping, or sip) lists. In 
> responding to queries I have often had to refer back to list archives 
> that are now probably almost two years old.
> 
> Thanks go to Takuya Sawada for preparing it. It would be incredibly 
> helpful to get feedback on this document, to make it clearer and more 
> complete. Feedback from two kinds of people would be especially helpful:
> 
> - those who are confused about offer/answer:
>    Tell us if this helps, or just leaves you more confused.
> 
> - those who think they understand offer/answer:
>    Do you disagree with anything here?
>    Has anything been left out that should be here?
> 
> 	Paul

_______________________________________________
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