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

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 06 Nov 2005 12:48:58 -0500

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

---

From: "Shimon Nurick" <[email-masked]>
Date: Mon, 7 Nov 2005 17:45:21 +0200

inline 

-----Original Message-----

>Shimon Nurick wrote:

>> 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?

>No, and I dont see why a single document is needed either.
[SN] Why we do need  (IMHO)
1. So all the SIP community will do the same mapping,
Like in H323 there is a mapping of Q.850 - all gateways follow the same
convention,
so going from ISDN to H323 back to ISDN yields the same code.
E.g. least cost routing over IP -
If the gateways would have a different translation, the ISDN code from
one end would be a different one on the other end.
2. Keep track of codes that have been "mapped" and eliminate the
duplication of mapped reasons.

>> 
>> 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.

>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.
[SN] this is exactly what I meant - having a single SIP reason mapping
to all other name spaces with same meaning

Shimon Nurick

---

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 7 Nov 2005 12:02:05 -0500

Please look at RFC-3398 and Q.1912.5, both of which include such
mappings of cause codes and response codes.

Note, that for a transit case of ISUP-SIP-ISUP or SIP-ISUP-SIP, the
mappings are not symmetrical.  That is, there are cases where:

A --> 1
B --> 1

and

1 --> A
2 --> A

Mike

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Shimon Nurick
> Sent: Monday, November 07, 2005 10:45 AM
> To: Jonathan Rosenberg (jdrosen)
> Cc: Cullen Jennings (fluffy); sipping; Dean Willis
> Subject: RE: [Sipping] Reason: Everybody's got one
> 
> inline 
> 
> 1. So all the SIP community will do the same mapping, Like in 
> H323 there is a mapping of Q.850 - all gateways follow the 
> same convention, so going from ISDN to H323 back to ISDN 
> yields the same code.
> If the gateways would have a different translation, the ISDN 
> code from one end would be a different one on the other end.
> 2. Keep track of codes that have been "mapped" and eliminate 
> the duplication of mapped reasons.
> 
> >> 
> >> Note: 
> 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.
> [SN] this is exactly what I meant - having a single SIP 
> reason mapping to all other name spaces with same meaning
> 
> Shimon Nurick
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>