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

From: "Shimon Nurick" <[email-masked]>
Date: Mon, 7 Nov 2005 06:40:13 +0200

I agree with adding response codes to match all other name spaces, and
make a single coherent "reason language"
This approach will be good also for the time when all legacy systems are
gone away -
Who will remember what Q.850 stands for??

The only issue about it is management (excuse my ignorance if one
already exists)
Do we have any one document specifying the mapping from all
PSTN/ISDN/SS7/H.323 codes to SIP?
And if not - who should create such a document?

Note: 
Remember we need to use existing mappings of PSTN/ISDN/SS7/H.323 and not
map each code from those name spaces to a single SIP reason.

Thanks,
Shimon Nurick
AVP R&D
Networking Business Unit
RADVISION
Tel: +972-3-7679421    Cell: +972-54-7769421  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jonathan Rosenberg
Sent: Sunday, 06 November, 2005 19:49
To: Cullen Jennings
Cc: sipping; Dean Willis
Subject: Re: [Sipping] Reason: Everybody's got one

inline.

Cullen Jennings wrote:
> 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.
>>>
>>
>>Are you suggesting that we'd  add a new SIP response code for every 
>>possible Q.850 "reason"?
>>
>>--
>>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 agree with Cullen here. I think that part of the reason that folks
have wanted different headers to convey this stuff, rather than adding
new response codes, is the perception that response code space is
precious and there isn't enough left. While it is true that it is
finite, there is still quite a bit left, and I would be curious whether
or not the number of as-yet-unmapped codes across various PSTN protocols
would overflow the space that is left.

If it would, it would be my preference for a general response code
extension mechanism that simply extended the number of response codes.

This is in contrast to another approach that folks like, which is to
include existing response codes from other namespaces by simply
including that existing code and declaring it as being from that
namespace. I don't like this approach in general because it runs into
problems when a code existing in different namespaces with roughly the
same meaning. If I'm a UAC, do I need to support one of these or both? 
Also, declaring these namespaces, like Q.850, seems to imply that an
implementation should only care about these values if its a gateway to
that protocol. However, these things do need to be implemented by
non-gateways in order to work. As such, I prefer the mapping approach,
and would rather just add more response codes as needed.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Mon, 07 Nov 2005 09:49:28 -0500

inline.

> And if not - who should create such a document?

No, and I dont see why a single document is needed either.

> map each code from those name spaces to a single SIP reason.

I'm not sure I follow you here. What I was proposing is that we have a 
single namespace of sip response codes, and that that namespace fill to 
the union of the codes needed for various interworking cases. A 
necessary requisite for this, of course, is that there is a meaningful 
semantic to that code for a recipient of the response. Furthermore, if a 
code in ss7 has been defined and a different code in h.323 has been 
defined with the same semantic, those map to the same sip response code, 
not different ones.

-Jonathan R.