Re: [Sip] Dual registration without Outbound

Bob Penfield <BPenfield@acmepacket.com> Tue, 14 October 2008 17:38 UTC

Return-Path: <sip-bounces@ietf.org>
X-Original-To: sip-archive@optimus.ietf.org
Delivered-To: ietfarch-sip-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CA173A6BA6; Tue, 14 Oct 2008 10:38:49 -0700 (PDT)
X-Original-To: sip@core3.amsl.com
Delivered-To: sip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0399A3A6BA6 for <sip@core3.amsl.com>; Tue, 14 Oct 2008 10:38:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 2ap6vwNdU7u9 for <sip@core3.amsl.com>; Tue, 14 Oct 2008 10:38:44 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id AF9FE3A6B51 for <sip@ietf.org>; Tue, 14 Oct 2008 10:38:43 -0700 (PDT)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.291.1; Tue, 14 Oct 2008 13:38:00 -0400
Received: from mail.acmepacket.com ([127.0.0.1]) by mail.acmepacket.com ([216.41.24.7]) with mapi; Tue, 14 Oct 2008 13:37:59 -0400
From: Bob Penfield <BPenfield@acmepacket.com>
To: "Elwell, John" <john.elwell@siemens.com>, Christer Holmberg <christer.holmberg@ericsson.com>, Juha Heinanen <jh@tutpro.com>, "sip@ietf.org" <sip@ietf.org>, Paul Kyzivat <pkyzivat@cisco.com>, Dean Willis <dean.willis@softarmor.com>
Date: Tue, 14 Oct 2008 13:37:57 -0400
Thread-Topic: [Sip] Dual registration without Outbound
Thread-Index: Ackta1Q4oPZYeoZEQAiUqa8JyoYU4gAAB04gACPIDEAABL7/QAAE9WcQ
Message-ID: <E6C2E8958BA59A4FB960963D475F7AC312843F60B4@mail.acmepacket.com>
References: <7C532034-8511-4191-9ABA-02D5C42AC74D@softarmor.com> <18668.50247.121832.271341@taimen.test.fi> <CA9998CD4A020D418654FCDEF4E707DF05C0F8C8@esealmw113.eemea.ericsson.se> <18668.51383.505850.963592@taimen.test.fi> <CA9998CD4A020D418654FCDEF4E707DF05C0F8E3@esealmw113.eemea.ericsson.se> <18672.19846.621765.332209@taimen.test.fi> <2210d2240810111235r5b786e94u7707730d8f1fa627@mail.gmail.com> <18673.5665.337048.880648@taimen.test.fi> <2210d2240810120145o2297ac07v3487d014955bf0@mail.gmail.com> <18673.62485.295631.933830@taimen.test.fi> <2210d2240810130000i30c61aaei8a7f88f2069e46c0@mail.gmail.com> <18675.7684.207071.901832@taimen.test.fi> <CA9998CD4A020D418654FCDEF4E707DF05C0F8EF@esealmw113.eemea.ericsson.se> <18675.41223.587006.241312@taimen.test.fi> <18675.41926.583512.912121@taimen.test.fi> <CA9998CD4A020D418654FCDEF4E707DF05C0F8F2@esealmw113.eemea.ericsson.se> <E6C2E8958BA59A4FB960963D475F7AC3128435A4EA@mail.acmepacket.com> <0D5F89FAC29E2C41B98A6A762007F5D0012A2353@GBNTHT12009MSX.gb002.siemens.net>
In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0012A2353@GBNTHT12009MSX.gb002.siemens.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
MIME-Version: 1.0
Subject: Re: [Sip] Dual registration without Outbound
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

I guess the problem arises when you want to do a single REGISTER request for both instances. If I the use case correctly, the UA would send two REGISTER requests (one on each interface) and both REGISTERs would have the two Contacts (one for each instance-id). Something like this:

First REGISTER to Outbound-proxy #1

   REGISTER sip:example.com SIP/2.0
   Via: SIP/2.0/TCP 1.1.1.1;branch=z9hG4bKnashds7-1
   From: Bob <sip:bob@example.com>;tag=7F94778B653B-1
   To: Bob <sip:bob@example.com>
   Call-ID: 16CB75F21C70-1
   CSeq: 1 REGISTER
   Supported: path, outbound
   Route: <sip:ep1.example.com;lr>
   Contact: <sip:bob@1.1.1.1;transport=tcp>;reg-id=1
    ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
   Contact: <sip:bob@2.2.2.2;transport=tcp>;reg-id=2
    ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-BBCCDDEEFF00>"

Second REGISTER to Outbound-proxy #2

   REGISTER sip:example.com SIP/2.0
   Via: SIP/2.0/TCP 2.2.2.2;branch=z9hG4bKnashds7-2
   From: Bob <sip:bob@example.com>;tag=7F94778B653B-2
   To: Bob <sip:bob@example.com>
   Call-ID: 16CB75F21C70-2
   CSeq: 1 REGISTER
   Supported: path, outbound
   Route: <sip:ep2.example.com;lr>
   Contact: <sip:bob@2.2.2.2;transport=tcp>;reg-id=1
    ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-BBCCDDEEFF00>"
   Contact: <sip:bob@1.1.1.1;transport=tcp>;reg-id=2
    ;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"

Thus the UA could receive requests for either Contact on either of the two outbound flows.

Is having two UA instances in the same request legal with the current text?

cheers,
(-:bob

-----Original Message-----
From: Elwell, John [mailto:john.elwell@siemens.com]
Sent: Tuesday, October 14, 2008 11:02 AM
To: Bob Penfield; Christer Holmberg; Juha Heinanen; sip@ietf.org; Paul Kyzivat; Dean Willis
Subject: RE: [Sip] Dual registration without Outbound



> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On
> Behalf Of Bob Penfield
> Sent: 14 October 2008 15:41
> To: Christer Holmberg; Juha Heinanen; sip@ietf.org; Paul
> Kyzivat; Dean Willis
> Subject: Re: [Sip] Dual registration without Outbound
>
> For both GRUU and Outbound a given instance-id
> (+sip-instance) actually represents a single UA contact
> instance rather than just a single User Agent. The basic idea
> behind GRUU is that a request addressed to a GRUU is
> forwarded by the proxy to a specific Contact address. The
> goal is the same with Outbound but it adds multiple
> flows/paths to that UA Contact. This is reflected in the
> proxy procedures in both GRUU and Outbound.
>
> In both cases, the proxy does serial forking to Contacts with
> the same instance-id.
>
> For GRUU it starts with the most-recently registered binding
> (according to section 6.1 of GRUU):
>
>        The proxy MUST select the most recently refreshed
>        contact.  As with draft-ietf-sip-outbound, if a request to this
>        target fails with a 408 (Request Timeout) or 430 (Flow Failed)
>        response, the proxy SHOULD retry with the next most recently
>        refreshed contact.  Furthermore, if the request fails with any
>        other response, the proxy MUST NOT retry on any other contacts
>        for this instance.
>
> For Outbound, it attempts the registered flows (according to
> section 7 of Outbound):
>
>    When a proxy uses the location service to look up a registration
>    binding and then proxies a request to a particular contact, it
>    selects a contact to use normally, with a few additional rules:
>
>    o  The proxy MUST NOT populate the target set with more than one
>       contact with the same AOR and instance-id at a time.
>    o  If a request for a particular AOR and instance-id fails
> with a 430
>       (Flow Failed) response, the proxy SHOULD replace the
> failed branch
>       with another target (if one is available) with the same AOR and
>       instance-id, but a different reg-id.
>    o  If the proxy receives a final response from a branch
> other than a
>       408 (Request Timeout) or a 430 (Flow Failed) response, the proxy
>       MUST NOT forward the same request to another target representing
>       the same AOR and instance-id.  The targeted instance has already
>       provided its response.
>
> Therefore, a User Agent that is registering multiple Contacts
> to allow the possibility of parallel forking would need to
> have a separate instance-id for each Contact.
>
> For User Agent's that have multiple interfaces, it could use
> the MAC address of each interface to create a unique UUID URN
> for each contact.
>
> Thus, the following scenario is possible:
>
>   UA_Contact_wlan;+sip-instance=ID_1;reg-id=1 ----- OB_1 ----- REG_1
>   UA_Contact_wlan;+sip-instance=ID_1;reg-id=2 ----- OB_2 ----- REG_2
>   UA_Contact_3g;+sip-instance=ID_2;reg-id=1   ----- OB_1 ----- REG_1
>   UA_Contact_3g;+sip-instance=ID_2;reg-id=2   ----- OB_2 ----- REG_2
>
> Unfortunately, the current text in section 4.1 says that a UA
> has "an Instance Identifier".
[JRE] In an earlier email I was trying to say roughly the same thing,
except the way I looked at it was that a device with multiple interfaces
would logically contain a UA for each interface, and each UA would than
have a single instance ID. In that case the text in section 4.1 still
works.

John
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip