[sipcore] draft-holmberg-sipcore-proxy-feature-00

"Worley, Dale R (Dale)" <dworley@avaya.com> Wed, 24 November 2010 15:22 UTC

Return-Path: <dworley@avaya.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 0ADBC28C10E for <sipcore@core3.amsl.com>; Wed, 24 Nov 2010 07:22:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.489
X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id W0R6R85YX4f9 for <sipcore@core3.amsl.com>; Wed, 24 Nov 2010 07:22:35 -0800 (PST)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com []) by core3.amsl.com (Postfix) with ESMTP id 1423428C0E1 for <sipcore@ietf.org>; Wed, 24 Nov 2010 07:22:34 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvcHAHG87EyHCzI1/2dsb2JhbACieWsGpUgCmSmFRwSEW4ku
X-IronPort-AV: E=Sophos;i="4.59,248,1288584000"; d="scan'208";a="220079193"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([]) by de307622-de-outbound.net.avaya.com with ESMTP; 24 Nov 2010 10:23:33 -0500
X-IronPort-AV: E=Sophos;i="4.59,248,1288584000"; d="scan'208";a="544454375"
Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 24 Nov 2010 10:23:32 -0500
Received: from DC-US1MBEX4.global.avaya.com ([]) by DC-US1HCEX3.global.avaya.com ([]) with mapi; Wed, 24 Nov 2010 10:23:32 -0500
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: "sipcore@ietf.org" <sipcore@ietf.org>
Date: Wed, 24 Nov 2010 10:23:31 -0500
Thread-Topic: draft-holmberg-sipcore-proxy-feature-00
Thread-Index: AQHLi+pQsOY1XYWsbEehaS5zfdjC8A==
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B2202288A6C@DC-US1MBEX4.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [sipcore] draft-holmberg-sipcore-proxy-feature-00
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, 24 Nov 2010 15:22:36 -0000

I previously wrote:
> Knowing that the Path can be used in the UA-to-registrar direction
> (as well as the registrar-to-UA direction) tells the UA something
> that it *already knows*, viz., how to get requests to the registrar.

Hadriel clarified this matter to me.  The expected architectural
situation is where:  The UA registers to one of a number of
registrars.  Based on which registrar the UA is registered to, the UA
must use a *corresponding* proxy.

I am told this is common in 3GPP designs, but it is an abnormal method
of operation in generic SIP.  (Our product can operate with a cluster
of proxy/registrars, but we have gone to signficant work to ensure
that the proxies and registrars are fully interchangable on a
request-by-request basis.)  This feature of the expected use case
should be made more clear for the (majority of) people in SIP who
aren't familiar with the 3GPP architecture.