IETF Logo Mail Archive

Re: [Stox] core: response code mappings

"Olle E. Johansson" <oej@edvina.net> Sat, 17 August 2013 07:28 UTC

Return-Path: <oej@edvina.net>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30E7721F9A99 for <stox@ietfa.amsl.com>; Sat, 17 Aug 2013 00:28:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.729
X-Spam-Level:
X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_MLH_Stock1=0.87]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71vgXAcyacMr for <stox@ietfa.amsl.com>; Sat, 17 Aug 2013 00:28:28 -0700 (PDT)
Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id EE6A021F8F07 for <stox@ietf.org>; Sat, 17 Aug 2013 00:28:20 -0700 (PDT)
Received: from [192.168.40.30] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 69F3E93C1AF; Sat, 17 Aug 2013 07:28:17 +0000 (UTC)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: "Olle E. Johansson" <oej@edvina.net>
In-Reply-To: <520EDFBB.90503@stpeter.im>
Date: Sat, 17 Aug 2013 09:28:16 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <DF2E9C50-1E56-4434-B28C-0CEE44B251A6@edvina.net>
References: <520EDFBB.90503@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1508)
Cc: "stox@ietf.org" <stox@ietf.org>, "Olle E. Johansson" <oej@edvina.net>
Subject: Re: [Stox] core: response code mappings
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Aug 2013 07:28:29 -0000

17 aug 2013 kl. 04:28 skrev Peter Saint-Andre <stpeter@stpeter.im>:

> The SIP Parameters Registry has a list of SIP response codes:
> 
> http://www.iana.org/assignments/sip-parameters/sip-parameters.xml#sip-parameters-7
> 
> A number of those are not specified in RFC 3261. Thus the question
> arises: for which codes do we need to define mappings? We could define
> mappings for all of them, but I wonder if that's advisable. Some of the
> additional codes are specified in RFCs that update RFC 3261 (e.g., code
> 440 from RFC 5393), whereas other codes are specified in "non-core" RFCs
> that don't update RFC 3261 (e.g., code 470 from RFC 5360). Would it
> perhaps make sense to map the "core" codes and not the "non-core" codes?

I don't really have any good answer. Can just look into the Asterisk code and see
that we've implemented a selection... :-)

The important part is to have a generic mapping for 2xx, 3xx, 4xx, 5xx and 6xx codes,
so that if a gateway gets an unknown code, it knows how to map it to something. In SIP,
an unknown 4xx code is the same as 400 etc.

After years of struggling with translations between SIP and ISDN in the Asterisk core,
I know that this is a hard problem. Especially in the case where you have SIP -> xmpp -> SIP 
and want the same error code on the other side. You simply can't please everyone when
mapping between two protocols.

/O

v2.23.0 | Report a Bug | By Email