Subject: RE: [Sipping] Re: draft-sawada-sipping-sip-offeranswer-01

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 19 Jul 2006 16:26:59 +0200

Hi Paul, 

>>If we forget the UPDATE, is offer2/answer2 in effect after the
reINVITE 4xx response?
>
>I'm not sure if I understand your question. Do you mean what is result
of a call flow like mine, but with the UPDATE 
>removed?

Yes.

- Alice calls Bob: INVITE w/offer1, 200ok w/answer1, ACK
- Alice reINVITE Bob w/offer2
- Bob respond reliable 18x w/answer2
- Alice PRACK the 18x
- Bob 200ok the PRACK
- Bob respond 4xx to reINVITE
- Alice ACK the reINVITE

>In that case IMO it is clear that offer1/answer1 are in effect.

What text do you base that "clearness" on? Eventhough the re-INVITE
request does fail, the offer2/answer2 transaction DID terminate
sucessfully when the reliable 18x was received.

>>IF so, I guess offer3/answer3 will be in effect after UPDATE 200 OK.
>
>I disagree above. Your conclusion here is apparently based on the same
logic.

The generic question is: if we receive information (SDP, Contact header,
whatever...) in a reliable 18x, is that thrown away if the re-INVITE
fails? You say it's clear, but I don't think it's very clear.

One way to solve that would be to forbid 18x with re-INVITEs.

>>Also, isn't this related to target refresh discussion? If I send a
re-INVITE with a new local Contact header value, 
>>receives a reliable 18x with a new remote Contact header value, and
then a 4xx response to the re-INVITE? Now, are the 
>>new Contact header values in affect?
>
>We could discuss the impact of a similar flow on target refresh. I'd
like that to be a separate discussion. (It doesn't 
>impact the offeranswer draft.) Maybe we can finish this one first.

I don't want to have that discussion here either. I just wanted to point
out that we have a similar problem with the Contact header, and that
issue IS already discussed in another thread.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Jul 2006 14:09:42 -0400

> sucessfully when the reliable 18x was received.

3261 section 14:

    If a UA receives a non-2xx final response to a re-INVITE, the session
    parameters MUST remain unchanged, as if no re-INVITE had been issued.
    Note that, as stated in Section 12.2.1.2, if the non-2xx final
    response is a 481 (Call/Transaction Does Not Exist), or a 408
    (Request Timeout), or no response at all is received for the re-
    INVITE (that is, a timeout is returned by the INVITE client
    transaction), the UAC will terminate the dialog.

This of course doesn't speak to reliable provisionals, since they are 
covered in 3262, but I don't think this language is overridden anywhere.

> One way to solve that would be to forbid 18x with re-INVITEs.

That would seem to prevent use of preconditions with reINVITEs too. For 
instance, if you have an audio session going and want to add video, but 
only if you can get QoS for it.

	Paul

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 19 Jul 2006 23:08:16 +0200

Hi,

>This of course doesn't speak to reliable provisionals, since they are
covered in 3262, but I don't think this language is 
>overridden anywhere.

Just because it's not overridden, I don't think we can just say that we
don't have an issue and whatever is written in 3261 applies. It's
something we haven't thought of. I think we need to have a closer look
at the impacts.

>>>I disagree above. Your conclusion here is apparently based on the 
>>>same logic.
>>> 
>>The generic question is: if we receive information (SDP, Contact 
>>header, whatever...) in a reliable 18x, is that thrown away if the
re-INVITE 
>That would seem to prevent use of preconditions with reINVITEs too. For
instance, if you have an audio session going and >want to add video, but
only if you can get QoS for it.

True.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Jul 2006 18:46:25 -0400

> something we haven't thought of. I think we need to have a closer look

I agree. But it is one piece of evidence that argues for a particular 
answer. There may be other pieces of evidence that argue a different 
way. And then even if all the evidence points one way it may still fail 
the smell test, so we might need to make a change to get it to smell better.

That is why I brought up the question in the first place.

Nevertheless, that piece of text is pretty clear.

	Paul