IETF Logo Mail Archive

Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature

<R.Jesske@telekom.de> Wed, 26 January 2011 13:05 UTC

Return-Path: <R.Jesske@telekom.de>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 619123A69AE for <sipcore@core3.amsl.com>; Wed, 26 Jan 2011 05:05:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level:
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxSHd+-s6eM6 for <sipcore@core3.amsl.com>; Wed, 26 Jan 2011 05:05:50 -0800 (PST)
Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 34DFC3A6857 for <sipcore@ietf.org>; Wed, 26 Jan 2011 05:05:49 -0800 (PST)
Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 26 Jan 2011 14:07:59 +0100
Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.69]) by he110890 ([10.134.92.131]) with mapi; Wed, 26 Jan 2011 14:07:50 +0100
From: R.Jesske@telekom.de
To: adam@nostrum.com, christer.holmberg@ericsson.com
Date: Wed, 26 Jan 2011 14:07:49 +0100
Thread-Topic: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature
Thread-Index: Acu8xaMn6Z+NjWqQSlqpf3vn6ry6yQAkzBwA
Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67DFA9550FF@HE111648.emea1.cds.t-internal.com>
References: <7F2072F1E0DE894DA4B517B93C6A058502B84084@ESESSCMS0356.eemea.ericsson.se> <BDBFB6CE314EDF4CB80404CACAEFF5DE07C6C68C@XCH02DFW.rim.net>, <4D3A2C3D.10508@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585194414F717@ESESSCMS0356.eemea.ericsson.se> <4D3EEC64.2080302@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05851944155A13@ESESSCMS0356.eemea.ericsson.se> <4D3F2365.2070504@nostrum.com>
In-Reply-To: <4D3F2365.2070504@nostrum.com>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jan 2011 13:05:51 -0000

Hi,
there is an scenario which I would see also within the Internet approach. Perhaps others too.

When you register it would be useful to know if the proper emergency service is served by the provider you are connected to.
Such an explicit indication would help.


   Alice                             P1                     REGISTRAR
          |                           |                           |
          |--- REGISTER-------------->|                           |
          |                           |                           |
          |                           |--- REGISTER-------------->|
          |                           |    Path: P1;emergency     |
          |                           |                           |
          |                           |                           |
          |                           |<-- 200 OK ----------------|
          |                           |    Path: P1;emergency     |
          |                           |    Service-Route: REG     |
          |<-- 200 OK ----------------|                           |
          |    Path: P1;emergency     |                           |
          |    Service-Route: REG     |                           |
          |                           |                           |

So that Alice is now sure that an emergency call will get thought and the correct emergency centre will be reached. Which is not even guaranteed in an pure internet environment depended which service provider is chosen.

Best Regards

Roland




> -----Ursprüngliche Nachricht-----
> Von: sipcore-bounces@ietf.org
> [mailto:sipcore-bounces@ietf.org] Im Auftrag von Adam Roach
> Gesendet: Dienstag, 25. Januar 2011 20:24
> An: Christer Holmberg
> Cc: sipcore@ietf.org
> Betreff: Re: [sipcore] Draft new version:
> draft-holmberg-sipcore-proxy-feature
>
> [as individual]
>
> On 1/25/11 10:33, Jan 25, Christer Holmberg wrote:
> > I'll try to put something together.
> > But, just for my understanding: what happens if there are
> no non-IMS use cases?
>
> Then we need to try to figure out whether the inapplicability of the
> problem is due to the fact that it is being stated in overly-narrow
> terms (i.e., is there a more general problem here that does have
> applicability to the Internet?), or whether it is due to the
> fact that
> it only arises because of a specific architecture.
>
> If it's the first case, we'll probably need to generalize the
> problem to
> include the Internet (you know, the "I" in "IETF"). Then,
> you'll have a
> much easier time getting the WG to adopt it and the IESG to
> approve it.
>
> If the problem only exists because of certain walled-garden
> architectures, then things get trickier -- both in the WG and
> in the IESG.
>
> /a
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>

v2.23.0 | Report a Bug | By Email