Subject: RE: [Sipping] Re: Update: dialogusage

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 23 Mar 2006 22:00:02 +0100

Hi, 

>no, but you can have UPDATE/200 in between an INVITE and a 4xx.

Yes, that's what I meant by "or whatever other request" :)

Regards,

Christer

On Mar 23, 2006, at 2:43 PM, Christer Holmberg ((JO/LMF)) wrote:

>
> Hi,
>
> You don't send rel18x for UPDATE, do you?
>
> Regards,
>
> Christer
>
> -----Original Message-----
> From: Robert Sparks [mailto:[email-masked]]
> Sent: 23. maaliskuuta 2006 22:27
> To: Christer Holmberg (JO/LMF)
> Cc: Paul Kyzivat; sipping WG
> Subject: Re: [Sipping] Re: Update: dialogusage
>
> UPDATE plays here too.
>
> On Mar 23, 2006, at 2:19 PM, Christer Holmberg ((JO/LMF)) wrote:
>
>>
>> Hi,
>>
>>>> Q4: You say that a target refresh is updated when a 200 OK is 
>>>> sent/received for the target refresh request. What if I use 
>>>> reliable
>
>>>> 18x responses for a target refresh re-INVITE request? Do I send the

>>>> PRACK according to the old target? In order to avoid yet another 
>>>> can-I-send-18x-responses-to-a-reINVITE-request discussion I would 
>>>> propose that we somehow change the wording to something that also 
>>>> covers reliable 18x responses.
>>>>
>>> I don't recall at the moment how clear things are that the target
>> refresh takes effect at the 200. Logically I think it
>>> has to be this way, because it would make little sense to have the
>> target refresh take effect on a reliable 1xx and then >have the 
>> request fail.
>>
>> So, you are saying that PRACKs, or whatever other request may be sent

>> AFTER a rel18x has been received, but BEFORE 200 has been received, 
>> should use the old target?
>>
>> Or, should it use some kind of a "temporary target"? I think we do 
>> that already for the INITIAL INVITE, in case the UAC from the same 
>> UAS
>
>> receive different Contact header values in the rel18x and 200 OK...
>>
>> I agree with you that if a non-200 final response is received, the 
>> target which was used before the request was sent should be the valid

>> one - no matter how many rel18x you may have received. The question 
>> is
>
>> what is valid between the request and the final response :)
>>
>> 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: "Brian Stucker" <[email-masked]>
Date: Thu, 23 Mar 2006 22:30:46 -0600

FWIW-- We've found that terminating a SUBSCRIBE because of a timeout to a NOTIFY is generally a bad thing to do (ie. it caused enough problems on large deployed networks that we went back and got rid of it in favor of 481).

Repeated timeouts to a NOTIFY makes more sense, and we thought that a single timeout was probably a good indicator of client death, but in reality we found that a single failure (including retransmissions) caused us more hassle than it was worth.

You may want to limit the wording for NOTIFY timeouts destroying the usage to a MAY type posture instead of a MUST.

Also, I am unaware (playing catch-up a bit here) of where the origin of the error code survey came from (great job btw) but the description for error codes like 3xx and 403 conflict directly with 3261. Is the intent to deprecate the reINVITE wording in section 14.1 of 3261 that says that non-2xx responses should be ignored in so much that the only thing that (should) change for the usage is the cseq? Specifically, I'm concerned about real-world (highly deployed) services that would be broken by the update to 403 logic.

Regards,
Brian

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]]
Sent: Friday, March 03, 2006 12:58 PM
To: sipping WG
Cc: Paul Kyzivat; Christer Holmberg ((JO/LMF))
Subject: [Sipping] Update: dialogusage

I've just submitted
http://www.nostrum.com/~rjsparks/draft-ietf-sipping-dialogusage-01.txt
http://www.nostrum.com/~rjsparks/draft-ietf-sipping-dialogusage-01.html

 From the changelog section:

A.1.  draft-ietf-00->draft-ietf-01

    o  Changed 481 to only affect the usage the response occured in,
       closing the last open issue.  Added some text justifying this
       recommendation.
    o  Added 422 Session Interval Too Small
    o  Added 417 Uknown Resource-Priority
    o  Added 428 Use Identity Header
    o  Added 436 Bad Identity-Info
    o  Added 437 Unsupported Certificate
    o  Added 438 Invalid Identity header
    o  Added a section categorizing messages that create and destroy
       usages
    o  Made sure all descriptions in Section 4 addressed the generic
       multi-usage case.
    o  Clarified that the mechanics described in matching messages to
       usages applied equally to UACs and UASs.
    o  More explicitly noted that REFER creates a subscribe-usage

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Fri, 24 Mar 2006 08:07:32 +0100

Hi,

I was thinking a little more about UPDATE between INVITE and its final
response.

Assume the following:

The UAC sends a INVITE/re-INVITE (I will use re-INVITE in the examples),
with a new local target (i.e. a new Contact header value). Before a
final response is received, it sends an UPDATE.

Q1. The new local target (LT2) in the re-INVITE and UPDATE are
identical: The UAC receives a 200 OK for the UPDATE, but a 4xx for the
re-INVITE. I ASSUME the new local target is now valid, since the UPDATE
request was accepted.

Example:

UAC                                  UAS

----- re-INVITE (Contact: LT2) ------->
<---- 18x/PRACK -----------------------
----- UPDATE (Contact: LT2) ---------->
<---- 200 (PRACK) ---------------------
<---- 4xx (INVITE) --------------------

Q2: The local target in the re-INVITE (LT2) and UPDATE (LT3) are NOT
identical. The UAC receives a 200 OK for the UPDATE, but a 4xx for the
re-INVITE. Again, I ASSUME the new local target is now valid, since the
UPDATE request was accepted.

UAC                                  UAS

----- re-INVITE (Contact: LT2) ------->
<---- 18x/PRACK -----------------------
----- UPDATE (Contact: LT3) ---------->
<---- 200 (UPDATE) --------------------
<---- 4xx (INVITE) --------------------

Q3: The local target in the re-INVITE (LT2) and UPDATE (LT3) are NOT
identical. The UAC receives a 200 OK for the UPDATE, AND a 200 for the
re-INVITE. WHICH of the new local targets is now valid? I ASSUME that
LT3 is valid until 200 (re-INVITE) is received, when LT2 becomes valid.

UAC                                  UAS

----- re-INVITE (Contact: LT2) ------->
<---- 18x/PRACK -----------------------
----- UPDATE (Contact: LT3) ---------->
<---- 200 (UPDATE) --------------------
<---- 200 (re-INVITE) -----------------

Q4: The UAC receives 200 for the PRACK, the UPDATE and the re-INVITE,
but they contain different remote targets. WHICH of the new remote
targets is now valid? I ASSUME that RT2 is valid until 200 (UPDATE) is
received, RT3 is valied until (re-INVITE) is received, when RT4 becomes
valid.

UAC                                  UAS

----- re-INVITE ---------------------->
<---- 18x (Contact: RT2)/PRACK --------
----- UPDATE ------------------------->
<---- 200 (UPDATE Contact: RT3) -------
<---- 200 (re-INVITE Contact: RT4) ----

NOW, in Q1, Q2 and Q3 one could claim that the UAC is not allowed to
update the local target in the UPDATE before a final response has been
received for the previous local target update request, i.e. the
re-INVITE. BUT, the UAC HAS received a reliable provisional response
with a remote target.

In Q4 one could claim that the remote targets must not change from the
18x to 200 (UPDATE), but as far as I understand the remote target can
change from the early dialog to the fully established dialog, i.e. the
18x and 200 (re-INVITE) may contain different Contact header values.

Whatever of these use-cases are allowed/not allowed I think it needs to
be clarified. RFC3261 is currently a littly fuzzy when it comes to
local- and remote targets, and their association with early dialogs and
fully established dialogs...

Regards,

Christer

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]] 
Sent: 23. maaliskuuta 2006 22:51
To: Christer Holmberg (JO/LMF)
Cc: Paul Kyzivat; sipping WG
Subject: Re: [Sipping] Re: Update: dialogusage

No, but you can have an UPDATE/200 between an INVITE and its 4xx.

RjS