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

From: "Mary Barnes" <[email-masked]>
Date: Fri, 28 Oct 2005 08:53:32 -0500

I had originally started this email response suggesting there really
wasn't a need for a document, however, that email was getting really
long (even longer than my normal responses). So, I do think a short
document would be useful.  I think there are several issues involved;
some philosophical and some historical in terms of the WG decision to
progress History-Info as a general purpose mechanism rather than
Diversion, which solves some very specific problems and is useful for
only a subset of services.  Then, of course, there are the recent
proposals to extend the Reason header, which does seem to be a handy
place to capture the "why".  That all said, it's not entirely clear to
me whether just requirements will be useful, as I think these issues
fundamentally get down to design decisions, so perhaps, in the end, we
need to agree guidelines for doing these sorts of things. 

Anyways, I can go ahead and capture these ideas (and others) in a
document and see if there aren't some fundamental requirements to be
distilled.  I do think in the long run that would be useful, given that
we've been having similar debates for almost 5 years and they only seem
to be increasing in frequency recently.

Mary

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dean Willis
Sent: Friday, October 28, 2005 12:32 AM
To: sipping WG
Subject: [Sipping] Reason: Everybody's got one

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

_______________________________________________
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: "Shimon Nurick" <[email-masked]>
Date: Sat, 29 Oct 2005 15:45:42 +0200

>From a quick look is seems to me,
that according to rfc3326 (unless this RFC is no longer valid) Q.850 is
included -
Can someone clarify this point? 

-----Original Message-----
From: Dean Willis [mailto:[email-masked]] 
Sent: Saturday, 29 October, 2005 04:42
To: Shimon Nurick
Cc: Cullen Jennings; sipping
Subject: Re: [Sipping] Reason: Everybody's got one

On Oct 28, 2005, at 7:01 PM, Shimon Nurick wrote:

>
>> Are you suggesting that we'd  add a new SIP response code for every
>>
> possible Q.850 "reason"?
>
> This would be a good idea - otherwise how do you do a complete IWF 
> from PSTN to SIP?

ok, so how many codes are we talking about?

Do we have clear documentation of their semantics?

--
Dean

---

From: "Shimon Nurick" <[email-masked]>
Date: Sat, 29 Oct 2005 15:45:44 +0200

I agree, and would take this one step further -
We need to interwork with H.323 and PSTN/ISDN/SS7 and so on.

When ever we try to define anything, we need to learn from the existing
heritage, and there needs to be a good reason to invent something new
Rather then reuse an existing definition -

This kind of approach will help avoid redoing mistakes they have done
and corrected,
And help build multi protocol devices and gateways - helping the NW
migrate easily to SIP.

Shimon 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Cullen Jennings
Sent: Saturday, 29 October, 2005 04:22
To: Dean Willis
Cc: sipping
Subject: Re: [Sipping] Reason: Everybody's got one

On 10/28/05 2:19 PM, "Dean Willis" <[email-masked]> wrote:

> 
> On Oct 28, 2005, at 2:10 PM, Cullen Jennings wrote:
> 
>> 
>> 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.
>> 
> 
> dean

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

_______________________________________________
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: "Elwell, John" <[email-masked]>
Date: Mon, 31 Oct 2005 07:59:25 +0000

Yes, we have indeed fought long and hard to get a list of Q.850-SIP cause
mappings, and the result of those efforts is recorded in RFC 3398 and
draft-ietf-sipping-qsig2sip. Personally I am satisfied that this job is
complete.

However, first there are additional ISUP causes relating to diversion in
Q.732.2, which I have an interest in. Second, we have also seen requests
from elsewhere for mapping additional fields in an ISUP cause (not the cause
values themselves) onto SIP (e.g., the location field).

John

> From: Gonzalo Camarillo [mailto:[email-masked]] 
> Sent: 29 October 2005 20:10
> To: Cullen Jennings
> Cc: Shimon Nurick; Dean Willis; sipping; Elwell, John
> Hi,
> as input to the discussion, a mapping between cause values and SIP 
> status codes can be found in Sections 7.2.4.1 and 8.2.6.1 of RFC 3398.
> 
> Cheers,
> 
> Gonzalo
> 
> Cullen Jennings wrote:
> > Cool - nice list. John has been very helpful in getting me 
> to understand
> > this in the past. 
> > 
> > John, any chance you could take a list of ISUP codes and 
> show which ones
> > already have clear mapping to SIP and which ones are 
> ambiguous and need to
> > be sorted out?
> > 
> > 
> > 
> > On 10/29/05 6:45 AM, "Shimon Nurick" <[email-masked]> wrote:
> > 
> > 
> >>Q.850 code list (unofficial) can be found on several sites -
> >>E.g.
> >>http://www.quintum.com/support/products/rs/sysdoc/webhelp/tr
> anslate_caus
> >>e_code.htm
> >>The original is in the ITU-T and costs to get it
> >>

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 31 Oct 2005 15:51:52 -0500

But, if I recall the RFC-3398 and Q.1912.5 are not consistent and may
not be bi-directional in mapping.

Also, the pointer below is missing a few.

Mike

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Elwell, John
> Sent: Monday, October 31, 2005 2:59 AM
> To: Gonzalo Camarillo; Cullen Jennings (fluffy)
> Cc: sipping; Dean Willis
> Subject: RE: [Sipping] Reason: Everybody's got one
> 
> Yes, we have indeed fought long and hard to get a list of 
> Q.850-SIP cause mappings, and the result of those efforts is 
> recorded in RFC 3398 and draft-ietf-sipping-qsig2sip. 
> Personally I am satisfied that this job is complete.
> 
> However, first there are additional ISUP causes relating to 
> diversion in Q.732.2, which I have an interest in. Second, we 
> have also seen requests from elsewhere for mapping additional 
> fields in an ISUP cause (not the cause values themselves) 
> onto SIP (e.g., the location field).
> 
> John
> 
> > >>Q.850 code list (unofficial) can be found on several sites - E.g.
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>