Subject: [Sipping] RE: Warning codes discussion

From: "Sean Olson" <[email-masked]>
Date: Wed, 9 Nov 2005 14:29:51 -0800

Simply adding new status codes does not solve all the problems.
Sometimes what you want is a hierarchical status. E.g. you want distinct
sub-codes for various types of "Busy". (486.1, 486.2, etc.)

A problem with the current Warning codes is that many of the things you
may want to do have to fall in the 390-399 range reserved for
"miscellaneous warnings". We need a bigger range and that's assuming we
can cheat and use Warning codes to apply to problems other than the SDP
itself. The type of problems I want to solve can't depend on the warning
text or reason phrase; I need a static value that automata can handle.

I'd like to see some clarification on how best to solve these type of
problems, in particular if Warning should NOT be used.

Cheers,
sean

-----Original Message-----
From: Gonzalo Camarillo [mailto:[email-masked]] 
Sent: Wednesday, November 09, 2005 1:45 PM
To: sipping
Cc: Sean Olson; Jonathan Rosenberg
Subject: Warning codes discussion

Folks,

following up on the face-to-face discussion on Warning codes we just had
during the SIPPING session, I would like the WG to agree on how we use
Reason codes and Warning codes.

Would everybody agree that the WG should recommend defining new status
codes as opposed to defining new Warning codes?

The fact that the WG agreed on this would be useful for external
organizations that intend (or are in the process of) defining new
Warning codes for things that could be better resolved with new status
codes.

Thanks,

Gonzalo

_______________________________________________
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: "James M. Polk" <[email-masked]>
Date: Wed, 09 Nov 2005 17:30:42 -0600

>sub-codes for various types of "Busy". (486.1, 486.2, etc.)

I definitely like this in concept, with the subcodes within a given integer 
related to each other, rather than using the remaining ~21 warning codes to 
mean all we can envison someone else coding.

I don't like the idea of cheating away the meaning of the warning codes 
having to do with SDP though.

Structuring in subcodes in a way that the backwards compatibility is to use 
them as a known SIP integer response code would be good. Of course, this 
means we do *not* define a new "warning" protocol value for the Reason 
header. This gets interesting if we want to keep the same "SIP" protocol in 
the Reason header.

Maybe we figure out that we need to shove a 4th field in between the cause= 
value and the optional text field to give this subcode value. With the 
knowledge this can be ignored easily, and the meta meaning of the higher 
level Reason header value is maintained.

thinking out loud, which some wish I would stop doing  ;-)

>Warning codes for things that could be better resolved with new status

cheers,
James

                                 *******************
                 Truth is not to be argued... it is to be presented.

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 10 Nov 2005 18:55:49 +0000

I agree

John

> Sent: 09 November 2005 21:45
> To: sipping
> Cc: Sean Olson
> Subject: [Sipping] Warning codes discussion
> 
> Folks,
>