Subject: [Sipping] Fwd: Submission: draft-ietf-sipping-dialogusage-04

From: Robert Sparks <[email-masked]>
Date: Sun, 22 Oct 2006 16:06:46 -0500

Here's an update to the dialog usage draft based on the WGLC comments.

I was able to build a table like Paul suggested. It does help by  
concentrating some information,
but it doesn't make the document much shorter (a little over 2 pages  
were removed). Hopefully,
the redundancy that was causing some reading difficulty is cleared up  
now.

I added a short overview driving home that this is an informative  
document and it will inform
the normative work we're going to pick up next.

I would have waited for the thread with Francois to finish, but  
there's this pesky deadline. If that conversation
results in a needed change, we'll rev after the blackout.

Thanks to everyone who put in the careful reviews!

RjS

Begin forwarded message:

> From: Robert Sparks <[email-masked]>
> Date: October 22, 2006 4:00:28 PM CDT
> To: Internet-Drafts Administrator <[email-masked]>
> Cc: [email-masked]
> Subject: Submission: draft-ietf-sipping-dialogusage-04
>
> Please accept
> http://www.nostrum.com/~rjsparks/draft-ietf-sipping-dialogusage-04.txt
> into the repository updating this SIPPING working group item.
>
> Thanks,
> RjS

_______________________________________________
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: "Francois Audet" <[email-masked]>
Date: Sun, 22 Oct 2006 19:33:31 -0500

Yes, I do find the table useful.

________________________________

	From: Robert Sparks [mailto:[email-masked]] 
	Sent: Sunday, October 22, 2006 2:07 PM
	To: SIPPING LIST; Paul Kyzivat; Vijay K. Gurbani; Audet,
Francois (SC100:3055)
	Subject: Fwd: Submission: draft-ietf-sipping-dialogusage-04

	Here's an update to the dialog usage draft based on the WGLC
comments. 

	I was able to build a table like Paul suggested. It does help by
concentrating some information,
	but it doesn't make the document much shorter (a little over 2
pages were removed). Hopefully,
	the redundancy that was causing some reading difficulty is
cleared up now.

	I added a short overview driving home that this is an
informative document and it will inform
	the normative work we're going to pick up next.

	RjS

	Begin forwarded message:

		From: Robert Sparks <[email-masked]>
		Date: October 22, 2006 4:00:28 PM CDT
		To: Internet-Drafts Administrator
<[email-masked]>
		Cc: [email-masked]
		Subject: Submission: draft-ietf-sipping-dialogusage-04

		Please accept
	
http://www.nostrum.com/~rjsparks/draft-ietf-sipping-dialogusage-04.txt
		into the repository updating this SIPPING working group
item.

		Thanks,
		RjS

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Oct 2006 09:02:32 -0400

I got a message that my mail was held for moderation because of its size 
(because of the attached html). And I haven't seen it posted yet. So it 
may be that only those explicitly listed will have seen what you are 
replying to.

Robert Sparks wrote:
> Agreed on more disclaimers around the section 6 text.
> 
> For the table - I tried the format you put forth first, and didn't go 
> with it mostly because it doesn't quickly
> convey that _most_ of the actions are "fail the transaction only".

I didn't see that as an issue. The problem I found with the format you 
chose was that I found it hard to look up a particular code, and it made 
it look like most codes had special cases.

> My sensitivity to that was particularly
> fueled by the conversation that was taking place with Francois at the 
> time. Would it be a bad thing
> to include both formats perhaps?

I don't know.

> (I'm hoping this isn't a document that 
> we will have to directly maintain in the long run).
> 
> I'll go through the revised descriptions you propose carefully tomorrow 
> or so. On a fast skim I don't
> see any reason not to use what you propose with one modification -

My goal was to genericize the exceptions, so that there aren't very 
many. I am inclined to think we could go further.

One thing I noticed, but didn't change, as I was going through this is 
that the descriptions mix two things: a clarification of *what* should 
be done to handle this, and a more detailed description of when and why 
the code occurs.

Perhaps these things could be separated: one section for the developer 
who just wants to know what to do, and a separate section for those that 
are interested in the reasoning.

> I would still like the response codes
> to appear in front of each note - relying on the indirection for context 
> without them will lead to implementer 
> disagreement. 

The problem with that is that it doesn't work well when the description 
applies to multiple codes. When it applies to a single code, in some 
cases I left a reference to the code in the text. In others I took it 
out because it didn't seem like it added anything. I think it is helpful 
to know that there are not so many distinct behaviors that must be 
implemented - not one per code.

	Paul

> On Oct 24, 2006, at 6:35 PM, Paul Kyzivat wrote:
> 
>> Robert,
>>
>> I reviewed the new draft, focusing on the changes. I have a few more 
>> comments.
>>
>> Robert Sparks wrote:
>> Its better. Somehow I was hoping it would help more than it does, but 
>> then I was only envisioning it, not doing it. You motivated me to see 
>> if I could do better. I came up with something I like a bit better - 
>> we will have to see what you and others think. I didn't have your 
>> document source, and wanted to do something quickly, so I've attached 
>> a cut at just the table and descriptions, in html, to this message. 
>> The main things I did:
>> - organize the table differently.
>> - moved some text from the some of the individual descriptions into
>>   the descriptions of the basic three actions.
>> - genericized the descriptions and tried to reuse them for more than
>>   one response.
>> - dropped specific descriptions for some responses when it seemd
>>   the revised standard actions were good enough. (I think maybe we
>>   could do more of this.)
>> Let me know if you like this any better (or worse).
>>
>> Other things:
>>
>> Section 6:
>>
>>    The Join [5] and Replaces [6] mechanisms can also be used to address
>>    problem 1.  When using this technique, a new request is sent outside
>>    any dialog with the expectation that it will fork to possibly many
>>    endpoints, including the one we're interested in.  ...
>>    ... This mechanism is
>>    reasonably robust, failing only when the routing logic for out-of-
>>    dialog requests changes such that the new request does not arrive at
>>    the endpoint holding the dialog of interest.
>>
>> One person's "reasonably robust" is another person's "not robust 
>> enough". In particular there is a quite common use case where this breaks:
>>
>> Alice calls Bob. Bob is busy, and has Forward on Busy activated, so 
>> the call goes to Charlie who answers. Subsequent to this, Bob hangs up 
>> and his phone is idle. Alice also has another call in progress with 
>> Dave. Then she tries to forward her call with Charlie to Dave. But her 
>> INVITE is addressed to Bob, and it goes to Bob, not Charlie. PUNT.
>>
>> This, and related cases, are common enough that I hate to see this 
>> solution being described as reasonably robust without any disclaimer.
>>
>> I just have to comment on:
>>
>>             sip:[email-masked];gr=urn:uuid:(Carol's UA's bits)
>>             \                                                   /
>>               \                                                /
>>                |                                              |
>>                v                                              v
>>         INVITE                                                  SIP/2.0
>>
>> Love it!
>>
>> That's it,
>> Paul
>>
>>>> *From: *Robert Sparks <[email-masked] 
>>>> <mailto:[email-masked]>>
>>>> *Date: *October 22, 2006 4:00:28 PM CDT
>>>> *To: *Internet-Drafts Administrator <[email-masked] 
>>>> <mailto:[email-masked]>>
>>>> *Cc: [email-masked] 
>>>> <mailto:[email-masked]>
>>>> *Subject: **Submission: draft-ietf-sipping-dialogusage-04*
>>>>
>>>> Please accept
>> For the failure responses with code 400 and greater, there are three 
>> common ways the failure can affect the transaction, usage, and dialog 
>> state.
>>
>> Transaction Only: The error affects only the transaction, not the 
>> usage or dialog the transaction occurs in (beyond affecting the local 
>> CSeq).  Any other usage of the dialog is unaffected.  The error is a 
>> complaint about this transaction, not the usage or dialog the 
>> transaction occurs in. If the response came to a request that was 
>> attempting to establish a new usage in an existing dialog, no new 
>> usage is created and existing usages are unaffected.
>>
>> Destroys Usage: The error destroys the usage, but not dialog.  Any 
>> other usages sharing this dialog are not affected. If this is the last 
>> usage sharing the dialog, the dialog is also terminated.
>>
>> Destroys Usage: This response destroys the dialog and all usages 
>> sharing it.  Getting this response means something has gone 
>> fundamentally wrong with the dialog state.
>>
>> Table 1 displays how the various codes affect transaction, usage, or 
>> dialog state.  Clarifications and exceptions are called out in the 
>> Notes column and follow the table.
>>
>>  
>>  
>>
>> */Code/*
>>
>> 	
>>
>> */Reason/*
>>
>> 	
>>
>> */Impact/*
>>
>> 	
>>
>> */Notes/*
>>
>> 400
>> / 4xx
>>
>> 	
>>
>> Bad Request
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>  
>>
>> 401
>>
>> 	
>>
>> Unauthorized
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>  
>>
>> 402
>>
>> 	
>>
>> Payment Required
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>
>> (1)
>>
>> 403
>>
>> 	
>>
>> Forbidden
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>  
>>
>> 404
>>
>> 	
>>
>> Not Found
>>
>> 	
>>
>> Destroys Dialog
>>
>> 	
>>  
>>
>> 405
>>
>> 	
>>
>> Method Not Allowed
>>
>> 	
>>
>> Destroys Usage
>>
>> 	
>>
>> (2)
>>
>> 406
>>
>> 	
>>
>> Not Acceptable
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>  
>>
>> 407
>>
>> 	
>>
>> Proxy Authentication Required
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>  
>>
>> 408
>>
>> 	
>>
>> Request Timeout
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>
>> (3)
>>
>> 410
>>
>> 	
>>
>> Gone
>>
>> 	
>>
>> Destroys Dialog
>>
>> 	
>>  
>>
>> 412
>>
>> 	
>>
>> Conditional Request Failed
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>  
>>
>> 413
>>
>> 	
>>
>> Request Entity Too Large
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>  
>>
>> 414
>>
>> 	
>>
>> Request-URI Too Long
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>  
>>
>> 415
>>
>> 	
>>
>> Unsupported Media Type
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>  
>>
>> 416
>>
>> 	
>>
>> Unsupported URI Scheme
>>
>> 	
>>
>> Destroys Dialog
>>
>> 	
>>  
>>
>> 417
>>
>> 	
>>
>> Unknown Resource-Priority
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>  
>>
>> 420
>>
>> 	
>>
>> Bad Extension
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>  
>>
>> 421
>>
>> 	
>>
>> Extension Required
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>  
>>
>> 422
>>
>> 	
>>
>> Session Interval Too Brief
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>
>> (4)
>>
>> 423
>>
>> 	
>>
>> Interval Too Brief
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>  
>>
>> 428
>>
>> 	
>>
>> Use Identity Header
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>  
>>
>> 429
>>
>> 	
>>
>> Provide Referrer Identity
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>  
>>
>> 436
>>
>> 	
>>
>> Bad Identity-Info
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>  
>>
>> 437
>>
>> 	
>>
>> Unsupported Certificate
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>  
>>
>> 438
>>
>> 	
>>
>> Invalid Identity header
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>  
>>
>> 480
>>
>> 	
>>
>> Temporarily Unavailable
>>
>> 	
>>
>> Destroys Usage
>>
>> 	
>>
>> (5)
>>
>> 481
>>
>> 	
>>
>> Call Leg / Transaction Does Not Exist
>>
>> 	
>>
>> Destroys Usage
>>
>> 	
>>
>> (6)
>>
>> 482
>>
>> 	
>>
>> Loop Detected
>>
>> 	
>>
>> Destroys Dialog
>>
>> 	
>>
>> (7)
>>
>> 483
>>
>> 	
>>
>> Too Many Hops
>>
>> 	
>>
>> Destroys Dialog*
>>
>> 	
>>
>> (8)
>>
>> 484
>>
>> 	
>>
>> Address Incomplete
>>
>> 	
>>
>> Destroys Dialog
>>
>> 	
>>  
>>
>> 485
>>
>> 	
>>
>> Ambiguous
>>
>> 	
>>
>> Destroys Dialog
>>
>> 	
>>  
>>
>> 486
>>
>> 	
>>
>> Busy Here
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>
>> (4)
>>
>> 487
>>
>> 	
>>
>> Request Terminated
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>  
>>
>> 488
>>
>> 	
>>
>> Not Acceptable Here
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>  
>>
>> 489
>>
>> 	
>>
>> Bad Event
>>
>> 	
>>
>> Destroys Usage
>>
>> 	
>>
>> (9)
>>
>> 491
>>
>> 	
>>
>> Request Pending
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>  
>>
>> 493
>>
>> 	
>>
>> Undecipherable
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>  
>>
>> 494
>>
>> 	
>>
>> Security Agreement Required
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>  
>>
>> 500
>> / 5xx
>>
>> 	
>>
>> Server Internal Error
>>
>> 	
>>
>> Transaction Only*
>>
>> 	
>>
>> (10)
>>
>> 501
>>
>> 	
>>
>> Not Implemented
>>
>> 	
>>
>> Destroys Usage*
>>
>> 	
>>
>> (2)
>>
>> 502
>>
>> 	
>>
>> Bad Gateway
>>
>> 	
>>
>> Destroys Dialog
>>
>> 	
>>
>> (11)
>>
>> 503
>>
>> 	
>>
>> Service Unavailable
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>
>> (12)
>>
>> 504
>>
>> 	
>>
>> Server Time-Out
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>
>> (10)(13)
>>
>> 505
>>
>> 	
>>
>> Version Not Supported
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>  
>>
>> 513
>>
>> 	
>>
>> Message Too Large
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>  
>>
>> 580
>>
>> 	
>>
>> Precondition Failure
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>  
>>
>> 600
>> / 6xx
>>
>> 	
>>
>> Busy Everywhere
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>
>> (10)
>>
>> 603
>>
>> 	
>>
>> Decline
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>  
>>
>> 604
>>
>> 	
>>
>> Does Not Exist Anywhere
>>
>> 	
>>
>> Destroys Dialog
>>
>> 	
>>  
>>
>> 606
>>
>> 	
>>
>> Not Acceptable
>>
>> 	
>>
>> Transaction Only
>>
>> 	
>>  
>>
>>                                   Table 1
>>
>> (1)                 This is a reserved response code.  If encountered, 
>> it should be treated as an unrecognized 4xx.
>>
>> (2)                 This would be an aberrant response in our example 
>> scenario since support for the NOTIFY method is implied by the usage.  
>> In this case, the UA knows the condition is unrecoverable and should 
>> stop attempting to send NOTIFYs on this usage.  (It may or may not 
>> destroy the usage.  If it remembers the bad behavior, it can reject 
>> any refresh subscription). 
>>
>> In general, this response may or may not affect the usage (in response 
>> to an unknown method or an INFO it will not end an invite usage).  It 
>> will never affect other usages sharing this usage's dialog.
>>
>> (3)                 Receiving a 408 will have the same effect on 
>> usages and dialogs as a real transaction timeout as described in 
>> Section 5.2.
>>
>> (4)                 This response does not make sense for any 
>> mid-usage request.  If it is received, an element in the path of the 
>> request is violating protocol, and the recipient should treat this as 
>> it would an unknown 4xx response.
>>
>> (5)                 RFC 3261 is unclear on what 480 means for 
>> mid-usage requests.  Future updates to that specification are expected 
>> to clarify that this response affects only the usage in which the 
>> request occurs.  No other usages are affected.  If the response 
>> included a Retry-After header field, further requests in that usage 
>> should not be sent until the indicated time has past.  Requests in 
>> other usages may still be sent at any time.
>>
>> (6)                 The 481 response indicates that the peer has lost 
>> its copy of the dialog usage state.  The dialog itself should not be 
>> destroyed unless this was the last usage.  The effects of a 481 on a 
>> dialog and its usages are the most ambiguous of any final response.  
>> There are implementations that have chosen the meaning recommended 
>> here, and others that destroy the entire dialog without regard to the 
>> number of outstanding usages.  Going forward with this clarification 
>> will allow those deployed implementations that assumed only the usage 
>> was destroyed to work with a wider number of implementations.  Those 
>> that made the other choice will continue to function as they do now, 
>> suffering at most the same extra messages needed for a peer to 
>> discover that that other usages have gone away that they currently 
>> do.  However, the necessary clarification to RFC 3261 needs to make it 
>> very clear that the ability to terminate usages independently from the 
>> overall dialog using a 481 is not justification for designing new 
>> applications that count on multiple usages in a dialog.
>>
>> (7)                 The 482 response is aberrant mid-dialog.  It will 
>> only occur if the Record-Route header field was improperly constructed 
>> by the proxies involved in setting up the dialog's initial usage, or 
>> if a mid-dialog request forks and merges (which should never happen).  
>> Future requests using this dialog state will also fail.
>>
>> An edge condition exists during RFC3263 failover at the element 
>> sending a request where the request effectively forks to multiple 
>> destinations from the client.  Some implementations increase risk 
>> entering this edge condition by trying the next potential location as 
>> determined by RFC3263 very rapidly if the first does not immediately 
>> respond.  In any situation where a client sends the same request to 
>> more than one endpoint, it must be prepared to receive a response from 
>> each branch (and should choose a "best" response to act on following 
>> the same guidelines as a forking proxy).  In this particular race 
>> condition, if multiple branches respond, all but one will most likely 
>> return a 482 Merged Request.  The client should select the remaining 
>> non-482 response as the "best" response.
>>
>> (8)                 Similar to 482, receiving this mid-dialog is 
>> aberrant.  Unlike 482, recovery may be possible by increasing 
>> Max-Forwards (assuming that the requester did something strange like 
>> using a smaller value for Max-Forwards in mid-dialog requests than it 
>> used for an initial request).  If the request isn't tried with an 
>> increased Max-Forwards, then the agent should follow the Destroy 
>> Dialog actions.
>>
>> (9)                 This response is only valid in the context of 
>> SUBSCRIBE and NOTIFY.  UAC behavior for receiving this response to 
>> other methods is not specified, but treating it as an unknown 4xx is a 
>> reasonable practice.
>>
>> (10)              If the response contains a Retry-After header field 
>> value, the server thinks the condition is temporary and the request 
>> can be retried after the indicated interval.  This usage, and any 
>> other usages sharing the dialog are unaffected.  If the response does 
>> not contain a Retry-After header field value, the UA may decide to 
>> retry after an interval of its choosing or attempt to gracefully 
>> terminate the usage.
>>
>>  Whether or not to terminate other usages depends on the application.  
>> If the UA receives this response as a result of an attempt to 
>> gracefully terminate this usage, it can treat this usage as terminated.
>>
>> (11)              This response is aberrant mid-dialog.  It will only 
>> occur if the Record-Route header field was improperly constructed by 
>> the proxies involved in setting up the dialog's initial usage.  Future 
>> requests using this dialog state will also fail.
>>
>> (12)              As per [2], the logic handling locating SIP servers 
>> for transactions may handle 503 requests (effectively sequentially 
>> forking at the endpoint based on DNS results).  If this process does 
>> not yield a better response, a 503 may be returned to the transaction 
>> user.  Because this response occurred in the context of an established 
>> dialog, the route-set has already been formed and any opportunity to 
>> try alternate servers (as recommended in [1]) has been exhausted by 
>> the RFC3263 logic.
>>
>> (13)              It is not obvious under what circumstances this 
>> response would be returned to a request in an existing dialog.
>>
>>  
>

---

From: Robert Sparks <[email-masked]>
Date: Tue, 24 Oct 2006 19:59:47 -0500

For the table - I tried the format you put forth first, and didn't go  
with it mostly because it doesn't quickly
convey that _most_ of the actions are "fail the transaction only". My  
sensitivity to that was particularly
fueled by the conversation that was taking place with Francois at the  
time. Would it be a bad thing
to include both formats perhaps? (I'm hoping this isn't a document  
that we will have to directly maintain
in the long run).

I'll go through the revised descriptions you propose carefully  
tomorrow or so. On a fast skim I don't
see any reason not to use what you propose with one modification - I  
would still like the response codes
to appear in front of each note - relying on the indirection for  
context without them will lead to implementer
disagreement.

RjS

On Oct 24, 2006, at 6:35 PM, Paul Kyzivat wrote:

> Robert,
>
> I reviewed the new draft, focusing on the changes. I have a few  
> more comments.
>
> Robert Sparks wrote:
>> the redundancy that was causing some reading difficulty is cleared  
>> up now.
>
> Its better. Somehow I was hoping it would help more than it does,  
> but then I was only envisioning it, not doing it. You motivated me  
> to see if I could do better. I came up with something I like a bit  
> better - we will have to see what you and others think. I didn't  
> have your document source, and wanted to do something quickly, so  
> I've attached a cut at just the table and descriptions, in html, to  
> this message. The main things I did:
> the call goes to Charlie who answers. Subsequent to this, Bob hangs  
> up and his phone is idle. Alice also has another call in progress  
> with Dave. Then she tries to forward her call with Charlie to Dave.  
> But her INVITE is addressed to Bob, and it goes to Bob, not  
> Charlie. PUNT.
>
>         INVITE                                                  SIP/ 
> 2.0
>>> *Cc: [email-masked] <mailto:sipping- 
>>> [email-masked]>
> For the failure responses with code 400 and greater, there are  
> three common ways the failure can affect the transaction, usage,  
> and dialog state.
>
> usage or dialog the transaction occurs in (beyond affecting the  
> local CSeq).  Any other usage of the dialog is unaffected.  The  
> error is a complaint about this transaction, not the usage or  
> dialog the transaction occurs in. If the response came to a request  
> that was attempting to establish a new usage in an existing dialog,  
> no new usage is created and existing usages are unaffected.
>
> other usages sharing this dialog are not affected. If this is the  
> last usage sharing the dialog, the dialog is also terminated.
>
> Table 1 displays how the various codes affect transaction, usage,  
> or dialog state.  Clarifications and exceptions are called out in  
> the Notes column and follow the table.
>
>
>
> Code
>
> Reason
>
> Impact
>
> Notes
>
> 400
> / 4xx
>
> Bad Request
>
> Transaction Only
>
>
> 401
>
> Unauthorized
>
> Transaction Only
>
>
> 402
>
> Payment Required
>
> Transaction Only
>
> (1)
>
> 403
>
> Forbidden
>
> Transaction Only
>
>
> 404
>
> Not Found
>
> Destroys Dialog
>
>
> 405
>
> Method Not Allowed
>
> Destroys Usage
>
> (2)
>
> 406
>
> Not Acceptable
>
> Transaction Only
>
>
> 407
>
> (1)                 This is a reserved response code.  If  
> encountered, it should be treated as an unrecognized 4xx.
>
> (2)                 This would be an aberrant response in our  
> example scenario since support for the NOTIFY method is implied by  
> the usage.  In this case, the UA knows the condition is  
> unrecoverable and should stop attempting to send NOTIFYs on this  
> usage.  (It may or may not destroy the usage.  If it remembers the  
> bad behavior, it can reject any refresh subscription).
>
> In general, this response may or may not affect the usage (in  
> response to an unknown method or an INFO it will not end an invite  
> usage).  It will never affect other usages sharing this usage's  
> dialog.
>
> (4)                 This response does not make sense for any mid- 
> usage request.  If it is received, an element in the path of the  
> request is violating protocol, and the recipient should treat this  
> as it would an unknown 4xx response.
>
> (5)                 RFC 3261 is unclear on what 480 means for mid- 
> usage requests.  Future updates to that specification are expected  
> (6)                 The 481 response indicates that the peer has  
> lost its copy of the dialog usage state.  The dialog itself should  
> not be destroyed unless this was the last usage.  The effects of a  
> 481 on a dialog and its usages are the most ambiguous of any final  
> response.  There are implementations that have chosen the meaning  
> recommended here, and others that destroy the entire dialog without  
> regard to the number of outstanding usages.  Going forward with  
> this clarification will allow those deployed implementations that  
> assumed only the usage was destroyed to work with a wider number of  
> implementations.  Those that made the other choice will continue to  
> function as they do now, suffering at most the same extra messages  
> needed for a peer to discover that that other usages have gone away  
> that they currently do.  However, the necessary clarification to  
> RFC 3261 needs to make it very clear that the ability to terminate  
> usages independently from the overall dialog using a 481 is not  
> justification for designing new applications that count on multiple  
> usages in a dialog.
>
> (7)                 The 482 response is aberrant mid-dialog.  It  
> will only occur if the Record-Route header field was improperly  
> constructed by the proxies involved in setting up the dialog's  
> initial usage, or if a mid-dialog request forks and merges (which  
> should never happen).  Future requests using this dialog state will  
> also fail.
>
> entering this edge condition by trying the next potential location  
> as determined by RFC3263 very rapidly if the first does not  
> immediately respond.  In any situation where a client sends the  
> same request to more than one endpoint, it must be prepared to  
> receive a response from each branch (and should choose a "best"  
> response to act on following the same guidelines as a forking  
> proxy).  In this particular race condition, if multiple branches  
> respond, all but one will most likely return a 482 Merged Request.   
> The client should select the remaining non-482 response as the  
> "best" response.
>
> aberrant.  Unlike 482, recovery may be possible by increasing Max- 
> Forwards (assuming that the requester did something strange like  
> using a smaller value for Max-Forwards in mid-dialog requests than  
> it used for an initial request).  If the request isn't tried with  
> an increased Max-Forwards, then the agent should follow the Destroy  
> Dialog actions.
>
> other methods is not specified, but treating it as an unknown 4xx  
> is a reasonable practice.
>
> (10)              If the response contains a Retry-After header  
> field value, the server thinks the condition is temporary and the  
> request can be retried after the indicated interval.  This usage,  
> and any other usages sharing the dialog are unaffected.  If the  
> response does not contain a Retry-After header field value, the UA  
> may decide to retry after an interval of its choosing or attempt to  
> gracefully terminate the usage.
>
>  Whether or not to terminate other usages depends on the  
> application.  If the UA receives this response as a result of an  
> attempt to gracefully terminate this usage, it can treat this usage  
> as terminated.
>
> (11)              This response is aberrant mid-dialog.  It will  
> only occur if the Record-Route header field was improperly  
> constructed by the proxies involved in setting up the dialog's  
> initial usage.  Future requests using this dialog state will also  
> fail.
>
> (12)              As per [2], the logic handling locating SIP  
> servers for transactions may handle 503 requests (effectively  
> sequentially forking at the endpoint based on DNS results).  If  
> this process does not yield a better response, a 503 may be  
> returned to the transaction user.  Because this response occurred  
> in the context of an established dialog, the route-set has already  
> been formed and any opportunity to try alternate servers (as  
> recommended in [1]) has been exhausted by the RFC3263 logic.
>

For the table - I tried the format you put forth first, and didn't go  
with it mostly because it doesn't quickly
convey that _most_ of the actions are "fail the transaction only". My  
sensitivity to that was particularly
fueled by the conversation that was taking place with Francois at the  
time. Would it be a bad thing
to include both formats perhaps? (I'm hoping this isn't a document  
that we will have to directly maintain
in the long run).

I'll go through the revised descriptions you propose carefully  
tomorrow or so. On a fast skim I don't
see any reason not to use what you propose with one modification - I  
would still like the response codes
to appear in front of each note - relying on the indirection for  
context without them will lead to implementer
disagreement.

RjS

On Oct 24, 2006, at 6:35 PM, Paul Kyzivat wrote:

> Robert,
>
> I reviewed the new draft, focusing on the changes. I have a few  
> more comments.
>
> Robert Sparks wrote:
>> the redundancy that was causing some reading difficulty is cleared  
>> up now.
>
> Its better. Somehow I was hoping it would help more than it does,  
> but then I was only envisioning it, not doing it. You motivated me  
> to see if I could do better. I came up witign: center; "><SPAN =
lang=3D"FR" style=3D"font-size:10.0pt">=A0</SPAN><BR =
class=3D"khtml-block-placeholder"></DIV>  </TD></TR><TR><TD valign=3D"top"=
 style=3D"border:solid windowtext 1.0pt;border-top:none;  padding:0in =
5.4pt 0in 5.4pt"><P class=3D"MsoBodyTextIndent" =
style=3D"margin-left:0in"><SPAN lang=3D"FR" =
style=3D"font-size:10.0pt">404</SPAN></P>  </TD><TD valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" style=3D"margin-left:0in"><SPAN =
lang=3D"FR" style=3D"font-size:10.0pt">Not Found</SPAN></P>  </TD><TD =
valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" align=3D"center" =
style=3D"margin-left:0in;text-align:  center"><SPAN lang=3D"FR" =
style=3D"font-size:10.0pt">Destroys Dialog</SPAN></P>  </TD><TD =
valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><DIV style=3D"margin-left: 0in; text-align: center; "><SPAN =
lang=3D"FR" style=3D"font-size:10.0pt">=A0</SPAN><BR =
class=3D"khtml-block-placeholder"></DIV>  </TD></TR><TR><TD valign=3D"top"=
 style=3D"border:solid windowtext 1.0pt;border-top:none;  padding:0in =
5.4pt 0in 5.4pt"><P class=3D"MsoBodyTextIndent" =
style=3D"margin-left:0in"><SPAN lang=3D"FR" =
style=3D"font-size:10.0pt">405</SPAN></P>  </TD><TD valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" style=3D"margin-left:0in"><SPAN =
lang=3D"FR" style=3D"font-size:10.0pt">Method Not Allowed</SPAN></P>  =
</TD><TD valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" align=3D"center" =
style=3D"margin-left:0in;text-align:  center"><SPAN lang=3D"FR" =
style=3D"font-size:10.0pt">Destroys Usage</SPAN></P>  </TD><TD =
valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" align=3D"center" =
style=3D"margin-left:0in;text-align:  center"><SPAN lang=3D"FR" =
style=3D"font-size:10.0pt">(2)</SPAN></P>  </TD></TR><TR><TD =
valign=3D"top" style=3D"border:solid windowtext 1.0pt;border-top:none;  =
padding:0in 5.4pt 0in 5.4pt"><P class=3D"MsoBodyTextIndent" =
style=3D"margin-left:0in"><SPAN lang=3D"FR" =
style=3D"font-size:10.0pt">406</SPAN></P>  </TD><TD valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" style=3D"margin-left:0in"><SPAN =
lang=3D"FR" style=3D"font-size:10.0pt">Not Acceptable</SPAN></P>  =
</TD><TD valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" align=3D"center" =
style=3D"margin-left:0in;text-align:  center"><SPAN lang=3D"FR" =
style=3D"font-size:10.0pt">Transaction Only</SPAN></P>  </TD><TD =
valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><DIV style=3D"margin-left: 0in; text-align: center; "><SPAN =
lang=3D"FR" style=3D"font-size:10.0pt">=A0</SPAN><BR =
class=3D"khtml-block-placeholder"></DIV>  </TD></TR><TR><TD valign=3D"top"=
 style=3D"border:solid windowtext 1.0pt;border-top:none;  padding:0in =
5.4pt 0in 5.4pt"><P class=3D"MsoBodyTextIndent" =
style=3D"margin-left:0in"><SPAN lang=3D"FR" =
style=3D"font-size:10.0pt">407</SPAN></P>  </TD><TD valign=3Dh something I like a bit  
> better - we will have to see what you and others think. I didn't  
> have your document source, and wanted to do something quickly, so  
> I've attached a cut at just the table and descriptions, in html, to  
> this message. The main things I did:
> the call goes to Charlie who answers. Subsequent to this, Bob hangs  
> up and his phone is idle. Alice also has another call in progress  
> with Dave. Then she tries to forward her call with Charlie to Dave.  
> But her INVITE is addressed to Bob, and it goes to Bob, not  
> Charlie. PUNT.
>
>         INVITE                                                  SIP/ 
> 2.0
>>> *Cc: [email-masked] <mailto:sipping- 
>>> [email-masked]>
> For the failure responses with code 400 and greater, there are  
> three common ways the failure can affect the transaction, usage,  
> and dialog state.
>
> usage or dialog the transaction occurs in (beyond affecting the  
> local CSeq).  Any other usage of the dialog is unaffected.  The  
> error is a complaint about this transaction, not the usage or  
> dialog the transaction occurs in. If the response came to a request  
> that was attempting to establish a new usage in an existing dialog,  
> no new usage is created and existing usages are unaffected.
>
> Destroys Usa"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" style=3D"margin-left:0in"><SPAN =
lang=3D"FR" style=3D"font-size:10.0pt">Proxy Authentication =
Required</SPAN></P>  </TD><TD valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" align=3D"center" =
style=3D"margin-left:0in;text-align:  center"><SPAN lang=3D"FR" =
style=3D"font-size:10.0pt">Transaction Only</SPAN></P>  </TD><TD =
valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><DIV style=3D"margin-left: 0in; text-align: center; "><SPAN =
lang=3D"FR" style=3D"font-size:10.0pt">=A0</SPAN><BR =
class=3D"khtml-block-placeholder"></DIV>  </TD></TR><TR><TD valign=3D"top"=
 style=3D"border:solid windowtext 1.0pt;border-top:none;  padding:0in =
5.4pt 0in 5.4pt"><P class=3D"MsoBodyTextIndent" =
style=3D"margin-left:0in"><SPAN lang=3D"FR" =
style=3D"font-size:10.0pt">408</SPAN></P>  </TD><TD valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" style=3D"margin-left:0in"><SPAN =
lang=3D"FR" style=3D"font-size:10.0pt">Request Timeout</SPAN></P>  =
</TD><TD valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" align=3D"center" =
style=3D"margin-left:0in;text-align:  center"><SPAN lang=3D"FR" =
style=3D"font-size:10.0pt">Transaction Only</SPAN></P>  </TD><TD =
valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" align=3D"center" =
style=3D"margin-left:0in;text-align:  center"><SPAN lang=3D"FR" =
style=3D"font-size:10.0pt">(3)</SPAN></P>  </TD></TR><TR><TD =
valign=3D"top" style=3D"border:solid windowtext 1.0pt;border-top:none;  =
padding:0in 5.4pt 0in 5.4pt"><P class=3D"MsoBodyTextIndent" =
style=3D"margin-left:0in"><SPAN style=3D"font-size:  =
10.0pt">410</SPAN></P>  </TD><TD valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" style=3D"margin-left:0in"><SPAN =
style=3D"font-size:  10.0pt">Gone</SPAN></P>  </TD><TD valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" align=3D"center" =
style=3D"margin-left:0in;text-align:  center"><SPAN =
style=3D"font-size:10.0pt">Destroys Dialog</SPAN></P>  </TD><TD =
valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><DIV style=3D"margin-left: 0in; text-align: center; "><SPAN =
style=3D"font-size:10.0pt">=A0</SPAN><BR =
class=3D"khtml-block-placeholder"></DIV>  </TD></TR><TR><TD valign=3D"top"=
 style=3D"border:solid windowtext 1.0pt;border-top:none;  padding:0in =
5.4pt 0in 5.4pt"><P class=3D"MsoBodyTextIndent" =
style=3D"margin-left:0in"><SPAN style=3D"font-size:  =
10.0pt">412</SPAN></P>  </TD><TD valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" style=3D"margin-left:0in"><SPAN =
style=3D"font-size:  10.0pt">Conditional Request Failed</SPAN></P>  =
</TD><TD valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtexge: The error destroys the usage, but not dialog.  Any  
> other usages sharing this dialog are not affected. If this is the  
> last usage sharing the dialog, the dialog is also terminated.
>
> Table 1 displays how the various codes affect transaction, usage,  
> or dialog state.  Clarifications and exceptions are called out in  
> the Notes column and follow the table.
>
>
>
> Code
>
> Reason
>
> Impact
>
> Notes
>
> 400
> / 4xx
>
> Bad Request
>
> Transaction Only
>
>
> 401
>
> Unauthorized
>
> Transaction Only
>
>
> 402
>
> Payment Required
>
> Transaction Only
>
> (1)
>
> 403
>
> Forbidden
>
> Transaction Only
>
>
> 404
>
> Not Found
>
> Destroys Dialog
>
>
> 405
>
> Method Not Allowed
>
> Destroys Usage
>
> (2)
>
> 406
>
> Not Acceptable
>
> Transaction Only
>
>
> 407
>
> (1)                 This is a reserved response code.  If  
> encountered, it should be treated as an unrecognized 4xx.
>
> (2)                 This would be an aberrant response in our  
> example scenario since support for the NOTIFY method is implied by  
> the usage.  In this case, the UA knows the condition is  
> unrecoverable and should stop attempting to send NOTIFYs on this  
> usage.  (It may or may not destroy the usage.  If it remembers the  
> bad behavior, it can reject any refresh subscription).
>
> In general, this response may or may not affect the usage (in  
> response to an unknown method or an INFO it will not end an invite  t 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" align=3D"center" =
style=3D"margin-left:0in;text-align:  center"><SPAN =
style=3D"font-size:10.0pt">Transaction Only</SPAN></P>  </TD><TD =
valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><DIV style=3D"margin-left: 0in; text-align: center; "><SPAN =
style=3D"font-size:10.0pt">=A0</SPAN><BR =
class=3D"khtml-block-placeholder"></DIV>  </TD></TR><TR><TD valign=3D"top"=
 style=3D"border:solid windowtext 1.0pt;border-top:none;  padding:0in =
5.4pt 0in 5.4pt"><P class=3D"MsoBodyTextIndent" =
style=3D"margin-left:0in"><SPAN style=3D"font-size:  =
10.0pt">413</SPAN></P>  </TD><TD valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" style=3D"margin-left:0in"><SPAN =
style=3D"font-size:  10.0pt">Request Entity Too Large</SPAN></P>  =
</TD><TD valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" align=3D"center" =
style=3D"margin-left:0in;text-align:  center"><SPAN =
style=3D"font-size:10.0pt">Transaction Only</SPAN></P>  </TD><TD =
valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><DIV style=3D"margin-left: 0in; text-align: center; "><SPAN =
style=3D"font-size:10.0pt">=A0</SPAN><BR =
class=3D"khtml-block-placeholder"></DIV>  </TD></TR><TR><TD valign=3D"top"=
 style=3D"border:solid windowtext 1.0pt;border-top:none;  padding:0in =
5.4pt 0in 5.4pt"><P class=3D"MsoBodyTextIndent" =
style=3D"margin-left:0in"><SPAN style=3D"font-size:  =
10.0pt">414</SPAN></P>  </TD><TD valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" style=3D"margin-left:0in"><SPAN =
style=3D"font-size:  10.0pt">Request-URI Too Long</SPAN></P>  </TD><TD =
valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" align=3D"center" =
style=3D"margin-left:0in;text-align:  center"><SPAN =
style=3D"font-size:10.0pt">Transaction Only</SPAN></P>  </TD><TD =
valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><DIV style=3D"margin-left: 0in; text-align: center; "><SPAN =
style=3D"font-size:10.0pt">=A0</SPAN><BR =
class=3D"khtml-block-placeholder"></DIV>  </TD></TR><TR><TD valign=3D"top"=
 style=3D"border:solid windowtext 1.0pt;border-top:none;  padding:0in =
5.4pt 0in 5.4pt"><P class=3D"MsoBodyTextIndent" =
style=3D"margin-left:0in"><SPAN style=3D"font-size:  =
10.0pt">415</SPAN></P>  </TD><TD valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" style=3D"margin-left:0in"><SPAN =
style=3D"font-size:  10.0pt">Unsupported Media Type</SPAN></P>  </TD><TD =
valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" align=3D"center" =
style=3D"margin-left:0in;text-align:  center"><SPAN =
style=3D"font-size:10.0pt">Transaction Only</SPAN></P>  </TD><TD =
valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><DIV style=3D"margin-left: 0in; text-align: center; "><SPAN =
style=3D"font-size:10.0pt">=A0</SPAN><BR =
class
> usage).  It will never affect other usages sharing this usage's  
> dialog.
>
> (4)                 This response does not make sense for any mid- 
> usage request.  If it is received, an element in the path of the  
> request is violating protocol, and the recipient should treat this  
> as it would an unknown 4xx response.
>
> (5)                 RFC 3261 is unclear on what 480 means for mid- 
> usage requests.  Future updates to that specification are expected  
> (6)                 The 481 response indicates that the peer has  
> lost its copy of the dialog usage state.  The dialog itself should  
> not be destroyed unless this was the last usage.  The effects of a  
> 481 on a dialog and its usages are the most ambiguous of any final  
> response.  There are implementations that have chosen the meaning  
> recommended here, and others that destroy the entire dialog without  
> regard to the number of outstanding usages.  Going forward with  
> this clarification will allow those deployed implementations that  
> assumed only the usage was destroyed to work with a wider number of  
> implementations.  Those that made the other choice will continue to  
> function as they do now, suffering at most the same extra messages  
> needed for a peer to discover that that other usages have gone away  
> that they currently do.  However, the necessary clarification to  
> RFC 3261 needs to make it very clear that the ability to terminate  
> usages independently from the overall dialog using a 481 is not  
> justification for designing new applications that count on multiple  
> usages in a dialog.
>
> (7)                 The 482 response is aberrant mid-dialog.  It  
> will only occur if the Record-Route header field was improperly  
> constructed by the proxies involved in setting up the dialog's  
> initial usage, or if a mid-dialog request forks and merges (which  
> should never happen).  Future requests using this dialog state will  
> also fail.
>
> entering this edge condition by trying the next potential location  
> as determined by RFC3263 very rapidly if the first does not  
> immediately respond.  In any situation where a client sends the  
> same request to more than one endpoint, it must be prepared to  
> receive a response from each branch (and should choose a "best"  
> response to act on following the same guidelines as a forking  
> proxy).  In this particular race condition, if multiple branches  
> respond, all but one will most likely return a 482 Merged Request.   
> The client should select the remaining non-482 response as the  
> "best" response.
>
> aberrant.  Unlike 482, recovery may be possible by increasing Max- 
> Forwards (assuming that the requester did something strange like  
> using a smaller value for Max-Forwards in mid-dialog requests than  
> it used for an initial request).  If the request isn't tried with  
> an increased Max-Forwards, then the agent should follow the Destroy  
> Dialog actions.
>
> other methods is not specified, but treating it as an unknown 4xx  
> is a reasonable practice.
>
> (10)              If the response contains a Retry-After header  
> field value, the server thinks t=3D"khtml-block-placeholder"></DIV>  </TD></TR><TR><TD valign=3D"top"=
 style=3D"border:solid windowtext 1.0pt;border-top:none;  padding:0in =
5.4pt 0in 5.4pt"><P class=3D"MsoBodyTextIndent" =
style=3D"margin-left:0in"><SPAN style=3D"font-size:  =
10.0pt">416</SPAN></P>  </TD><TD valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" style=3D"margin-left:0in"><SPAN =
style=3D"font-size:  10.0pt">Unsupported URI Scheme</SPAN></P>  </TD><TD =
valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" align=3D"center" =
style=3D"margin-left:0in;text-align:  center"><SPAN =
style=3D"font-size:10.0pt">Destroys Dialog</SPAN></P>  </TD><TD =
valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><DIV style=3D"margin-left: 0in; text-align: center; "><SPAN =
style=3D"font-size:10.0pt">=A0</SPAN><BR =
class=3D"khtml-block-placeholder"></DIV>  </TD></TR><TR><TD valign=3D"top"=
 style=3D"border:solid windowtext 1.0pt;border-top:none;  padding:0in =
5.4pt 0in 5.4pt"><P class=3D"MsoBodyTextIndent" =
style=3D"margin-left:0in"><SPAN style=3D"font-size:  =
10.0pt">417</SPAN></P>  </TD><TD valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" style=3D"margin-left:0in"><SPAN =
style=3D"font-size:  10.0pt">Unknown Resource-Priority</SPAN></P>  =
</TD><TD valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" align=3D"center" =
style=3D"margin-left:0in;text-align:  center"><SPAN =
style=3D"font-size:10.0pt">Transaction Only</SPAN></P>  </TD><TD =
valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><DIV style=3D"margin-left: 0in; text-align: center; "><SPAN =
style=3D"font-size:10.0pt">=A0</SPAN><BR =
class=3D"khtml-block-placeholder"></DIV>  </TD></TR><TR><TD valign=3D"top"=
 style=3D"border:solid windowtext 1.0pt;border-top:none;  padding:0in =
5.4pt 0in 5.4pt"><P class=3D"MsoBodyTextIndent" =
style=3D"margin-left:0in"><SPAN style=3D"font-size:  =
10.0pt">420</SPAN></P>  </TD><TD valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" style=3D"margin-left:0in"><SPAN =
style=3D"font-size:  10.0pt">Bad Extension</SPAN></P>  </TD><TD =
valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" align=3D"center" =
style=3D"margin-left:0in;text-align:  center"><SPAN =
style=3D"font-size:10.0pt">Transaction Only</SPAN></P>  </TD><TD =
valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><DIV style=3D"margin-left: 0in; text-align: center; "><SPAN =
style=3D"font-size:10.0pt">=A0</SPAN><BR =
class=3D"khtml-block-placeholder"></DIV>  </TD></TR><TR><TD valign=3D"top"=
 style=3D"border:solid windowtext 1.0pt;border-top:none;  padding:0in =
5.4pt 0in 5.4pt"><P class=3D"MsoBodyTextIndent" =
style=3D"margin-left:0in"><SPAN style=3D"font-size:  =
10.0pt">421</SPAN></P>  </TD><TD valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" style=3D"marginhe condition is temporary and the  
> request can be retried after the indicated interval.  This usage,  
> and any other usages sharing the dialog are unaffected.  If the  
> response does not contain a Retry-After header field value, the UA  
> may decide to retry after an interval of its choosing or attempt to  
> gracefully terminate the usage.
>
>  Whether or not to terminate other usages depends on the  
> application.  If the UA receives this response as a result of an  
> attempt to gracefully terminate this usage, it can treat this usage  
> as terminated.
>
> (11)              This response is aberrant mid-dialog.  It will  
> only occur if the Record-Route header field was improperly  
> constructed by the proxies involved in setting up the dialog's  
> initial usage.  Future requests using this dialog state will also  
> fail.
>
> (12)              As per [2], the logic handling locating SIP  
> servers for transactions may handle 503 requests (effectively  
> sequentially forking at the endpoint based on DNS results).  If  
> this process does not yield a better response, a 503 may be  
> returned to the transaction user.  Because this response occurred  
> in the context of an established dialog, the route-set has already  
> been formed and any opportunity to try alternate servers (as  
> recommended in [1]) has been exhausted by the RFC3263 logic.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Oct 2006 19:35:17 -0400

Robert,

Robert Sparks wrote:
> the redundancy that was causing some reading difficulty is cleared up now.

Its better. Somehow I was hoping it would help more than it does, but 
then I was only envisioning it, not doing it. You motivated me to see if 
I could do better. I came up with something I like a bit better - we 
will have to see what you and others think. I didn't have your document 
source, and wanted to do something quickly, so I've attached a cut at 
just the table and descriptions, in html, to this message. The main 
things I did:
- organize the table differently.
- moved some text from the some of the individual descriptions into
   the descriptions of the basic three actions.
- genericized the descriptions and tried to reuse them for more than
   one response.
- dropped specific descriptions for some responses when it seemd
   the revised standard actions were good enough. (I think maybe we
   could do more of this.)
Let me know if you like this any better (or worse).

Other things:

Section 6:

Alice calls Bob. Bob is busy, and has Forward on Busy activated, so the 
call goes to Charlie who answers. Subsequent to this, Bob hangs up and 
his phone is idle. Alice also has another call in progress with Dave. 
Then she tries to forward her call with Charlie to Dave. But her INVITE 
is addressed to Bob, and it goes to Bob, not Charlie. PUNT.

Love it!

	That's it,
	Paul

> I would have waited for the thread with Francois to finish, but there's 
> this pesky deadline. If that conversation
>> *To: *Internet-Drafts Administrator <in:10.0pt">=A0</SPAN><BR =
class=3D"khtml-block-placeholder"></DIV>  </TD></TR><TR><TD valign=3D"top"=
 style=3D"border:solid windowtext 1.0pt;border-top:none;  padding:0in =
5.4pt 0in 5.4pt"><P class=3D"MsoBodyTextIndent" =
style=3D"margin-left:0in"><SPAN style=3D"font-size:  =
10.0pt">486</SPAN></P>  </TD><TD valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" style=3D"margin-left:0in"><SPAN =
style=3D"font-size:  10.0pt">Busy Here</SPAN></P>  </TD><TD valign=3D"top"=
 style=3D"border-top:none;border-left:none;border-bottom:solid =
windowtext 1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt =
0in 5.4pt"><P class=3D"MsoBodyTextIndent" align=3D"center" =
style=3D"margin-left:0in;text-align:  center"><SPAN =
style=3D"font-size:10.0pt">Transaction Only</SPAN></P>  </TD><TD =
valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" align=3D"center" =
style=3D"margin-left:0in;text-align:  center"><SPAN lang=3D"FR" =
style=3D"font-size:10.0pt">(4)</SPAN></P>  </TD></TR><TR><TD =
valign=3D"top" style=3D"border:solid windowtext 1.0pt;border-top:none;  =
padding:0in 5.4pt 0in 5.4pt"><P class=3D"MsoBodyTextIndent" =
style=3D"margin-left:0in"><SPAN style=3D"font-size:  =
10.0pt">487</SPAN></P>  </TD><TD valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" style=3D"margin-left:0in"><SPAN =
style=3D"font-size:  10.0pt">Request Terminated</SPAN></P>  </TD><TD =
valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" align=3D"center" =
style=3D"margin-left:0in;text-align:  center"><SPAN =
style=3D"font-size:10.0pt">Transaction Only</SPAN></P>  </TD><TD =
valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><DIV style=3D"margin-left: 0in; text-align: center; "><SPAN =
style=3D"font-size:10.0pt">=A0</SPAN><BR =
class=3D"khtml-block-placeholder"></DIV>  </TD></TR><TR><TD valign=3D"top"=
 style=3D"border:solid windowtext 1.0pt;border-top:none;  padding:0in =
5.4pt 0in 5.4pt"><P class=3D"MsoBodyTextIndent" =
style=3D"margin-left:0in"><SPAN style=3D"font-size:  =
10.0pt">488</SPAN></P>  </TD><TD valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" style=3D"margin-left:0in"><SPAN =
style=3D"font-size:  10.0pt">Not Acceptable Here</SPAN></P>  </TD><TD =
valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"MsoBodyTextIndent" align=3D"center" =
style=3D"margin-left:0in;text-align:  center"><SPAN =
style=3D"font-size:10.0pt">Transaction Only</SPAN></P>  </TD><TD =
valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><DIV style=3D"margin-left: 0in; text-align: center; "><SPAN =
style=3D"font-size:10.0pt">=A0</SPAN><BR =
class=3D"khtml-block-placeholder"></DIV>  </TD></TR><TR><TD valign=3D"top"=
 style=3D"border:solid windowtext 1.0pt;border-top:none;  padding:0in =
5.4pt 0in 5.4pt"><P class=3D"MsoBodyTextIndent" =
style=3D"margin-left:0in"><SPAN style=3D"font-size:  =
10.0pt">489</SPAN></P>  </TD><TD valign=3D"top" =
style=3D"border-top:none;border-left:none;border-bottom:solid windowtext =
1.0pt;  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in =
5.4pt"><P class=3D"[email-masked] 
>> *Cc: [email-masked] <mailto:[email-masked]>
For
the failure responses with code 400 and greater, there are three common ways
the failure can affect the transaction, usage, and dialog state.

Transaction Only: The error affects only the transaction, not the usage
or dialog the transaction occurs in (beyond affecting the local CSeq).  Any
other usage of the dialog is unaffected.  The error is a complaint about this
transaction, not the usage or dialog the transaction occurs in. If the response
came to a request that was attempting to establish a new usage in an existing
dialog, no new usage is created and existing usages are unaffected.

Destroys Usage: The error destroys the usage, but not dialog.  Any
other usages sharing this dialog are not affected. If this is the last usage
sharing the dialog, the dialog is also terminated.

Destroys Usage: This response destroys the dialog and all usages
sharing it.  Getting this response means something has gone fundamentally wrong
with the dialog state.

Table
1 displays how the various codes affect transaction, usage, or dialog state.  Clarifications
and exceptions are called out in the Notes column and follow the table.

Code

Reason

Bad Event

Destroys Usage

(9)

491

Request Pending

Transaction Only

=A0

493

Undecipherable

Transaction Only

=A0

494

=

Transaction Only

Impact

Notes

400

/ 4xx

Bad Request

Transaction Only

401

Unauthorized

Transaction Only

402

Payment Required

Transaction Only

(1)

403

Forbidden

Transaction Only

404

Not Found

Destroys Dialog

405

Method Not Allowed

Destroys Usage

(2)

406

Not Acceptable

503

Service Unavailable

Transaction Only

(12)

504

Server Time-Out

Transaction Only

(10)(13)

505

Version Not Supported

Transaction Only

=A0

513

Message Too Large

Transaction Only

407

Transaction Only

408

Request Timeout

Transaction Only

(3)

410

Gone

Destroys Dialog

Transaction Only

=A0

580

Precondition Failure

Transaction Only

=A0

600
/ =
6xx

Busy Everywhere

Transaction Only

(10)

603

Decline

Transaction Only

=A0
412

Transaction Only

413

Request Entity Too Large

Transaction Only

414

Request-URI Too Long

Transaction Only

415

Unsupported Media Type

Transaction Only

604

Does Not Exist Anywhere
=

Destroys Dialog

=A0

606

Not Acceptable

Transaction Only

=A0

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0Table 1

(1)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
This is a reserved =
response code.=A0 If encountered, it should be treated as an =
unrecognized 4xx.

(2)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
This would be an aberrant =
response in our example scenario since support for the NOTIFY method is =
implied by the usage.=A0 In this case, the UA knows the condition is =
unrecoverable and should stop attempting to send NOTIFYs on this usage.=A0=
(It may or may not destroy the usage.=A0 If it remembers the bad =
behavior, it can reject any refresh subscription).=A0

In general, this response may or may not =
affect the usage (in response to an unknown method or an INFO it will =
not end an invite usage).=A0 It will never affect other usages sharing =
this usage's dialog.

416

Unsupported URI Scheme

Destroys Dialog

417

Transaction Only

420

Bad Extension

Transaction Only

421

An edge =
condition exists during RFC3263 failover at the element sending a =
request where the request effectively forks to multiple destinations =
from the client.=A0 Some implementations increase risk entering this =
edge condition by trying the next potential location as determined by =
RFC3263 very rapidly if the first does not immediately respond.=A0 In =
any situation where a client sends the same t 0in 5.4pt'>

Extension Required

Transaction Only

422

Transaction Only

(4)

423

Interval Too Brief

Transaction Only

428

Use Identity Header

Transaction Only

(9)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
This response is only =
valid in the context of SUBSCRIBE and NOTIFY.=A0 UAC behavior for =
receiving this response to other methods is not specified, but treating =
it as an unknown 4xx is a reasonable practice.

(10)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
If the response contains =
a Retry-After header field value, the server thinks the condition is =
temporary and the request can be retried after the indicated interval.=A0 =
This usage, and any other usages sharing the dialog are unaffected.=A0 =
If the response does not contain a Retry-After header field value, the =
UA may decide to retry after an interval of its choosing or attempt to =
gracefully terminate the usage.

=A0Whether =
or not to terminate other usages depends on the application.=A0 If the =
UA receives this response as a result of an attempt to gracefully =
terminate this usage, it can treat this usage as =
terminated.

(11)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
This response is aberrant =
mid-dialog.=A0 It will only occur if the Record-Route header field was =
improperly constructed by the proxies involved in setting up the =
dialog's initial usage.=A0 Future requests using this dialog state will =
also fail.

(12)=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
As per [2], the logic =
handling locating SIP servers for transactions may handle 503 requests =
(effectively sequentially forking at the endpoint based on DNS =
results).=A0 If this process does not yield a better response, a 503 may =
be returned to the transaction user.=A0 Because this response occurred =
in the context of an established dialog, the route-set has already been =
formed and any opportunity to try alternate servers (as recommended in =
[1]) has been exhausted by the RFC3263 logic.

(13)

429

Transaction Only

436

Bad Identity-Info

Transaction Only

437

Unsupported Certificate

Transaction Only

438

Invalid Identity header

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 24 Oct 2006 19:35:17 -0400

Robert,

Other things:

Section 6:

Love it!

	That's it,
	Paul

>> *To: *Internet-Drafts Administrator <inid windowtext 1.0pt;border-top:none;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoBodyTextIndent style='margin-left:0in'><span style='font-size:
  10.0pt'>483</span></p>
  </td>
  <td valign=top style='border-top:none;border-left:none;border-bottom:solid windowtext 1.0pt;
  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoBodyTextIndent style='margin-left:0in'><span style='font-size:
  10.0pt'>Too Many Hops</span></p>
  </td>
  <td valign=top style='border-top:none;border-left:none;border-bottom:solid windowtext 1.0pt;
  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoBodyTextIndent align=center style='margin-left:0in;text-align:
  center'><span style='font-size:10.0pt'>Destroys Dialog*</span></p>
  </td>
  <td valign=top style='border-top:none;border-left:none;border-bottom:solid windowtext 1.0pt;
  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoBodyTextIndent align=center style='margin-left:0in;text-align:
  center'><span lang=FR style='font-size:10.0pt'>(8)</span></p>
  </td>
 </tr>
 <tr>
  <td valign=top style='border:solid windowtext 1.0pt;border-top:none;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoBodyTextIndent style='margin-left:0in'><span style='font-size:
  10.0pt'>484</span></p>
  </td>
  <td valign=top style='border-top:none;border-left:none;border-bottom:solid windowtext 1.0pt;
  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoBodyTextIndent style='margin-left:0in'><span style='font-size:
  10.0pt'>Address Incomplete</span></p>
  </td>
  <td valign=top style='border-top:none;border-left:none;border-bottom:solid windowtext 1.0pt;
  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoBodyTextIndent align=center style='margin-left:0in;text-align:
  center'><span style='font-size:10.0pt'>Destroys Dialog</span></p>
  </td>
  <td valign=top style='border-top:none;border-left:none;border-bottom:solid windowtext 1.0pt;
  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoBodyTextIndent align=center style='margin-left:0in;text-align:
  center'><span style='font-size:10.0pt'>&nbsp;</span></p>
  </td>
 </tr>
 <tr>
  <td valign=top style='border:solid windowtext 1.0pt;border-top:none;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoBodyTextIndent style='margin-left:0in'><span style='font-size:
  10.0pt'>485</span></p>
  </td>
  <td valign=top style='border-top:none;border-left:none;border-bottom:solid windowtext 1.0pt;
  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoBodyTextIndent style='margin-left:0in'><span style='font-size:
  10.0pt'>Ambiguous</span></p>
  </td>
  <td valign=top style='border-top:none;border-left:none;border-bottom:solid windowtext 1.0pt;
  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoBodyTextIndent align=center style='margin-left:0in;text-align:
  center'><span style='font-size:10.0pt'>Destroys Dialog</span></p>
  </td>
  <td valign=top style='border-top:none;border-left:none;border-bottom:solid windowtext 1.0pt;
  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoBodyTextIndent align=center style='margin-left:0in;text-align:
  center'><span style='font-size:10.0pt'>&nbsp;</span></p>
  </td>
 </tr>
 <tr>
  <td valign=top style='border:solid windowtext 1.0pt;border-top:none;
  padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoBodyTextIndent style='margin-left:0in'><span style='font-size:
  10.0pt'>486</span></p>
  </td>
  <td valign=top style='border-top:none;border-left:none;border-bottom:solid windowtext 1.0pt;
  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoBodyTextIndent style='margin-left:0in'><span style='font-size:
  10.0pt'>Busy Here</span></p>
  </td>
  <td valign=top style='border-top:none;border-left:none;border-bottom:solid windowtext 1.0pt;
  border-right:solid windowtext 1.0pt;padding:0in 5.4pt 0in 5.4pt'>
  <p class=MsoBodyTextIndent align=center style='margin-left:0in;[email-masked] 
For

Table

Code

Reason

Transaction Only

(4)

487

Request Terminated

Transaction Only

488

Not Acceptable Here

Transaction Only

489

Bad Event

Destroys Usage

(9)

491

Impact

Notes

400

/ 4xx

Bad Request

Transaction Only

401

Unauthorized

Transaction Only

402

Payment Required

Transaction Only

(1)

Request Pending

Transaction Only

493

Undecipherable

Transaction Only

494

Transaction Only

500

/ 5xx

Server Internal Error

Transaction Only*

403

Forbidden

Transaction Only

404

Not Found

Destroys Dialog

405

Method Not Allowed

Destroys Usage

(2)

406

Not Acceptable

(10)

501

Not Implemented

Destroys Usage*

(2)

502

Bad Gateway

Destroys Dialog

(11)

503

Service Unavailable

Transaction Only

(12)

504

Server Time-OutTransaction Only

407

Transaction Only

408

Request Timeout

Transaction Only

(3)

410

Gone

Destroys Dialog

Transaction Only

(10)(13)

505

Version Not Supported

Transaction Only

513

Message Too Large

Transaction Only

580

Precondition Failure

Transaction Only

412

Transaction Only

413

Request Entity Too Large

Transaction Only

414

Request-URI Too Long

Transaction Only

415

Unsupported Media Type

Transaction Only

600

/ 6xx

Busy Everywhere

Transaction Only

(10)

603

Decline

Transaction Only

604

Does Not Exist Anywhere

Destroys Dialog

606

Not Acceptable

416

Unsupported URI Scheme

Destroys Dialog

417

Transaction Only

420

Bad Extension

Transaction Only

421

Transaction Only

Table 1

(1)
This is a reserved response code.
If encountered, it should be treated as an unrecognized 4xx.

(2)
This would be an aberrant response
in our example scenario since support for the NOTIFY method is implied by the
usage.  In this case, the UA knows the condition is unrecoverable and should
stop attempting to send NOTIFYs on this usage.  (It may or may not destroy the
usage.  If it remembers the bad behavior, it can reject any refresh
subscription).

In general, this response may or may not affect the usage (in response
to an unknown method or an INFO it will not end an invite usage).  It will
never affect other usages sharing this usage's dialog.

(3)
Receiving a 408 will have the same
effect on usages and dialogs as a real transaction timeout as described in
Section 5.2.

(4)
This response does not make sense
for any mid-usage request.  If it is received, an element in the path of the
request is violating protocol, and the recipient should treat this as it would
an unknown 4xx response.

(5)
RFC 3261 is unclear on what 480
means for mid-usage requests.  Future updates to that specification are
expected to clarify that this response affects only the usage in which the
request occurs.  No other usages are affected.  If the response included a
Retry-After header field, further requests in that usage should not be sent
until the indicated time has past.  Requests in other usages may still be sent
at any time.

(6)
The 481 response indicates that
the peer has lost its copy of the dialog usage state.  The dialog itself should
not be destroyed unless this was the last usage.  The effects of a 481 on a
dialog and its usages are the most ambiguous of t 0in 5.4pt'>

Extension Required

Transaction Only

422

Transaction Only

(4)

423

Interval Too Brief

Transaction Only

428

Use Identity Header

Transaction Only

(7)
The 482 response is aberrant
mid-dialog.  It will only occur if the Record-Route header field was improperly
constructed by the proxies involved in setting up the dialog's initial usage,
or if a mid-dialog request forks and merges (which should never happen).
Future requests using this dialog state will also fail.

An edge condition exists during RFC3263 failover at the element sending
a request where the request effectively forks to multiple destinations from the
client.  Some implementations increase risk entering this edge condition by
trying the next potential location as determined by RFC3263 very rapidly if the
first does not immediately respond.  In any situation where a client sends the
same request to more than one endpoint, it must be prepared to receive a
response from each branch (and should choose a "best" response to act
on following the same guidelines as a forking proxy).  In this particular race
condition, if multiple branches respond, all but one will most likely return a
482 Merged Request.  The client should select the remaining non-482 response as
the "best" response.

(8)
Similar to 482, receiving this
mid-dialog is aberrant.  Unlike 482, recovery may be possible by increasing
Max-Forwards (assuming that the requester did something strange like using a
smaller value for Max-Forwards in mid-dialog requests than it used for an
initial request).  If the request isn't tried with an increased Max-Forwards,
then the agent should follow the Destroy Dialog actions.

(9)
This response is only valid in the
context of SUBSCRIBE and NOTIFY.  UAC behavior for receiving this response to
other methods is not specified, but treating it as an unknown 4xx is a
reasonable practice.

(10)
If the response contains a
Retry-After header field value, the server thinks the condition is temporary
and the request can be retried after the indicated interval.  This usage, and
any other usages sharing the dialog are unaffected.  If the response does not
margin-left:0in;text-align:
center'>

429

Transaction Only

436

Bad Identity-Info

Transaction Only

437

Unsupported Certificate

Transaction Only

438

Invalid Identity header

Whether or not to terminate other usages depends on the application.
If the UA receives this response as a result of an attempt to gracefully
terminate this usage, it can treat this usage as terminated.

(11)
This response is aberrant
mid-dialog.  It will only occur if the Record-Route header field was improperly
constructed by the proxies involved in setting up the dialog's initial usage.
Future requests using this dialog state will also fail.

(12)
As per [2], the logic handling
locating SIP servers for transactions may handle 503 requests (effectively
sequentially forking at the endpoint based on DNS results).  If this process
does not yield a better response, a 503 may be returned to the transaction
user.  Because this response occurred in the context of an established dialog,
the route-set has already been formed and any opportunity to try alternate
servers (as recommended in [1]) has been exhausted by the RFC3263 logic.

(13)
It is not obvious under what
circumstances this response would be returned to a request in an existing
dialog.

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 25 Oct 2006 13:52:02 -0500

From: Robert Sparks [mailto:[email-masked]] 
	Sent: Tuesday, October 24, 2006 6:00 PM
	To: Paul Kyzivat
	Cc: SIPPING LIST; Vijay K. Gurbani; Audet, Francois (SC100:3055)
	Subject: Re: Submission: draft-ietf-sipping-dialogusage-04

	For the table - I tried the format you put forth first, and
didn't go with it mostly because it doesn't quickly
	convey that _most_ of the actions are "fail the transaction
only". My sensitivity to that was particularly
	fueled by the conversation that was taking place with Francois
at the time. Would it be a bad thing
	to include both formats perhaps? (I'm hoping this isn't a
document that we will have to directly maintain
	in the long run).

Right. I like the "short" table precisely for the reason Roberts alludes
to. 
 
But I also agree that including both formats could be useful. I like
that idea.