Subject: Re: [sipcore] info-03 draft and "session negotiation exchange"

From: Eric Burger <[email-masked]>
Date: Fri, 1 May 2009 09:12:08 -0400

Section 3 is where "negotiation" occurs.  I put negotiation in quotes  
because it is an advertising model, not an offer/answer model.

Would changing negotiation language to advertising language reduce  
confusion, or is it semantic dressing?

On Apr 30, 2009, at 2:30 AM, Attila Sipos wrote:

> Hi,
>
> Sorry for questions late in the day but I'm not clear on the
> negotiation methods of the info package draft.
>
> The draft mentions "session negotiation exchange" several times.
>
> Can someone tell me where this is defined?
>
> Section 3.1 (UA Behavior) shows INVITE/OK/ACK as an exchange.
>
> I see from section "5.2.  INFO Headers" of the "INFO tables" e-mail
> that PRACK and UPDATE are allowed to carry the Recv-Info header. So
> what is the "exchange" if say, INVITE and PRACK are involved?
>
> From section 3.1, it seems that the initial "offer" is in the INVITE
> and then "confirmed" in the ACK. So if PRACK is received, can one
> "confirm" in a PRACK?
>
> Also, if Recv-Info is allowed in UPDATE, how does that get  
> "confirmed"?
> Or is it that UPDATE just lists the packages already negotiated?
>
> Or is it that package renegotiation is only ever done in
> INVITE/re-INVITE?
> If so, I would like to see some text explicitly stating this.
> If not, what renegotiation combinations are there?
>
> Then there is this...
>   The limitation on requiring the negotiation to occur within the
>   context of a session negotiation exchange means that if the
>   initiating UA issues a re-INVITE (after the above ACK) with the
>   following.
>
>   INVITE ...
>   ...
>   Recv-Info: P, R, T
>   ...
>
>   The target UA MUST NOT send any package P INFO methods until the
>   target UA sees P in the final ACK from the initiating UA.
>
>
> So, let's say P was being sent by the target.   Then when the
> re-INVITE arrives, P has to be stopped (or queued), until P is
> seen again in the ACK.
>
> So what happens if there is a re-INVITE/INFO(package P) crossover?
> I think we need to say that if the initiating UA receives the INFO
> for package P, it should either:
> 1. still process it as normal
> or
> 2. issue a 4xx response (something like 491 Request Pending)
>   so that the package P event can be re-attempted once the ACK
>   has been received.
>
> Regards,
>
> Attila
>
>
>
>
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Attila Sipos" <[email-masked]>
Date: Fri, 1 May 2009 18:18:41 +0100

>>because it is an advertising model, not an offer/answer model.
That sentence alone, for me, makes it much clearer.
I think the confusion comes from:
1. the word negotiation
2. the statement:
      the target UA MUST NOT send any package P INFO methods until the
      target UA sees P in the final ACK from the initiating UA.

Right now, I'd like the following to be considered:
1. call it a "capability exchange" not a "negotiation" or "renegotiation".
2. have a statement at the end of the first paragraph in section 3 - something like this:
   Note well: this is an advertising model - it is NOT a negotiation or offer/answer model.
3. define what set of messages constitutes an exchange (this I'm still not clear about - especially where PRACK is involved?  can a PRACK response be considered in the same way as the ACK? )
4. also can we remove the statement
      The target UA MUST NOT send any package P INFO methods until the
      target UA sees P in the final ACK from the initiating UA.
   There seems contradiction between saying it's an advertising model but making the target UA wait for the ACK.
   Making the target UA wait implies that it needs to see what the initiator says again, which seems more like negotiation behavior.
    Why not just allow event P anytime after the initiator has declared it in the Recv-Info of the re-INVITE/INVITE?
5.  If we must keep 4, then let's define what should happen if P occurs before the ACK (which could happen
    if the package P INFO is sent at the same time as the re-INVITE)

Regards,
Attila

________________________________

From: Eric Burger [mailto:[email-masked]]
Sent: Fri 01/05/2009 14:12
To: Attila Sipos
Cc: SIPCORE
Subject: Re: [sipcore] info-03 draft and "session negotiation exchange"