Subject: [Sipping] Reason: Everybody's got one

From: Dean Willis <[email-masked]>
Date: Fri, 28 Oct 2005 00:32:15 -0500

SIP's Reason header field seems to be one of the most attractive  
targets for extensions.

We've had lots of drafts proposing extensions to the Reason header,  
including both adding new values and namespace for values, and  
extending it for use in responses as well as requests. We've even had  
proposals for adding new response values and namespaces at the same  
time. We've also had proposals that the plethora of different reasons  
should all be codified at the protocol level as new response codes.

Not only that, but a lot of the things that people are trying to do  
with Reason (or maybe, response codes) sound a lot like some use- 
cases for other headers we've seen, notably Diversion and History-Info.

That says to me "with this much smoke, there has to be a fire  
somewhere."

But I'm not exactly sure where the fire is, or what we're burning on it.

A lot of these drafts have been good, their results useful (and in  
some cases, like Diversion, widely deployed despite bitter  
controversy).  But we keep coming back to the same discussions, which  
has raised my doubts. It's been gnawing at me for some time, but  
oddly enough, the discussion of Alert-Info and URNs seems to have  
crystallized my vague misgivings. Now I'm convinced that we're like a  
bunch of blind philosophers trying to describe the motivation of an  
elephant by how it feels when the elephant steps on us.

So, I'd like to suggest that before we start extending Reason, or  
even before we talk much more about it, we should take a step back  
and think about what we're doing, and why.

Would anyone like to volunteer to put together a draft along the  
lines of "Requirements For Communicating Why I Did What I Did When I  
Did It With SIP" ?

Or does anybody else have an idea as to how we can come to closure  
before the elephant has finished trampling what's left of my sanity?

Thanks,

--
Dean Willis
Your mismetaphored co-chair

_______________________________________________
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: Cullen Jennings <[email-masked]>
Date: Fri, 28 Oct 2005 12:10:41 -0700

My humble opinion is that there might be good Reasons to add a few new
response codes to SIP. I've yet to see a scenario that could not be
satisfied with this approach.

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 28 Oct 2005 22:31:38 +0300

Hi,

SIP has two ways of encoding the information we are looking for: status 
codes and Warning values (which, by the way, have not been used much so 
far). Reason can already carry status codes and there is a draft 
defining the namespace for Warning values in Reason.

As Cullen said, it would be interesting to see scenarios that cannot be 
covered by a (maybe new) status code and a (maybe new) Warning value.

Note that Reason can carry stuff like Q.850 cause values because that is 
useful in certain interworking situations.

Cheers,

Gonzalo

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo

---

From: Dean Willis <[email-masked]>
Date: Fri, 28 Oct 2005 16:19:11 -0500

> satisfied with this approach.

Are you suggesting that we'd  add a new SIP response code for every  
possible Q.850 "reason"?

--
dean

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 28 Oct 2005 19:21:41 -0700

> Are you suggesting that we'd  add a new SIP response code for every

No, I'm suggesting that when you go through all the reason codes that anyone
has a need to express, you find they map to an existing code or that in a
few cases, we may need a new code. On the "need to express" I am perfectly
willing to realize that some other people may have needs that I don't need
but that they do need.

Codes are cheap, making new namespaces that clients have no idea how to
interpret is very expensive from point of view of getting something that
actually works and is widely deployed. We have a very clear extensions
mechanism for sip response codes, unless people have a clear reason why it
does not work, there are many advantages of using it.

I am not impressed if the only advantage of mapping in some other code space
is that  "I want to use standard X because I can't be bothered to figure out
what codes already exist I could map to and what new codes I would need to
define."

Let me give a clear example of what I am talking about. There may very well
be a good need for a new SIP code that means "this request failed because
the call processing elements are currently too busy". Now there might be an
existing code that means that - we might need a new code. I'm happy to help
figure that out. I'm happy to admit that having some code that clearly maps
to "the network is too busy" is a thing that some networks might want to use
and would be a good thing to have. The idea that this code is only useful
with the PSTN is clearly not true. Having the code work in some sane way
with the existing deployed UAs would be good.

Lets look at the error condition we need to report, see how they map, and
for ones where we expect a UA to behave differently depending on what it
received, figure out if it is possible to express this in the existing
mechanism and what new codes would be needed. If this is by far the simplest
path and if it is proven not to work, then lets do something more
complicated but why complicate life when we don't have to. This whole
problem is treated like there are 10,000 Q.850 codes we are trying to map.
This is simply not the case - it is a very short list.

Cullen