Re: [sipcore] Bypassing out-of-service intermediate Proxy

Paul Kyzivat <pkyzivat@cisco.com> Thu, 18 November 2010 00:43 UTC

Return-Path: <pkyzivat@cisco.com>
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 C8D833A6778 for <sipcore@core3.amsl.com>; Wed, 17 Nov 2010 16:43:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.699
X-Spam-Level:
X-Spam-Status: No, score=-109.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 qa3Wxva7oX91 for <sipcore@core3.amsl.com>; Wed, 17 Nov 2010 16:43:37 -0800 (PST)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 550833A677D for <sipcore@ietf.org>; Wed, 17 Nov 2010 16:43:37 -0800 (PST)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAJ8F5EyrR7Hu/2dsb2JhbACiU3GkV5swhUsEhFiGAIMM
X-IronPort-AV: E=Sophos;i="4.59,214,1288569600"; d="scan'208";a="288357137"
Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 18 Nov 2010 00:44:19 +0000
Received: from [10.86.253.98] ([10.86.253.98]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id oAI0iICB020733; Thu, 18 Nov 2010 00:44:18 GMT
Message-ID: <4CE476E2.70801@cisco.com>
Date: Thu, 18 Nov 2010 08:44:18 +0800
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: youssef.chadli@orange-ftgroup.com
References: <9ECCF01B52E7AB408A7EB8535264214101CD7EE2@ftrdmel0.rd.francetelecom.fr><4C7FDBEE.6080305@nostrum.com>, <9ECCF01B52E7AB408A7EB85352642141020FD443@ftrdmel0.rd.francetelecom.fr> <CD5674C3CD99574EBA7432465FC13C1B22022889B6@DC-US1MBEX4.global.avaya.com><9ECCF01B52E7AB408A7EB8535264214102155080@ftrdmel0.rd.francetelecom.fr> <4CD16A52.7090006@cisco.com> <9ECCF01B52E7AB408A7EB853526421410221B4E3@ftrdmel0.rd.francetelecom.fr> <4CD53DFC.8020401@cisco.com> <9ECCF01B52E7AB408A7EB85352642141022A9552@ftrdmel0.rd.francetelecom.fr>
In-Reply-To: <9ECCF01B52E7AB408A7EB85352642141022A9552@ftrdmel0.rd.francetelecom.fr>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Bypassing out-of-service intermediate Proxy
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: Thu, 18 Nov 2010 00:43:39 -0000

Well, if the server knows it can be skipped it could simply not 
record-route.

Or, as Dale suggested, it could record-route with a DNS name that 
prefers to include it, but that names the predecessor as a lower 
priority alternative.

You are the first person I have ever heard ask for this functionality, 
so I expect it would be a hard sell to add any new mechanism to the 
specs to permit this in some other way. If you think it is important, 
start trying to make a case for it.

	Thanks,
	Paul

On 11/17/2010 1:01 AM, youssef.chadli@orange-ftgroup.com wrote:
>
>> How can the element doing the skipping know? In general it has no idea of the importance of an element in the route.
>> Its at the time of insertion into the route that the importance is known, so that is when such decisions should be made.
>
> I see two ways: at the moment of insertion into the Route, as you mentionned, via a URI parameters ( the element which inserts itself into the Route knows whether it's could be sikpped) or via a static configuration ( which is of course less flexible solution)
>
> Best Regards,
>
> Youssef
>
> -----Message d'origine-----
> De : Paul Kyzivat [mailto:pkyzivat@cisco.com]
> Envoyé : samedi 6 novembre 2010 12:38
> À : CHADLI Youssef RD-CORE-ISS
> Cc : sipcore@ietf.org
> Objet : Re: [sipcore] Bypassing out-of-service intermediate Proxy
>
>
>
> On 11/5/2010 2:44 PM, youssef.chadli@orange-ftgroup.com wrote:
>>
>> I don't think this analogy is correct.
>>
>> If you take the example of a SIP Server which is inserted in the SIP path only to provide a supplementary service in case this latter is requested by the user ( e.g. call transfer), I think that the user will not be satisfied if it's call does not succeed just because the network is not able to provide this service...
>
> Sure, the analogy *might* not always be correct, though it surely will be correct in some / many cases.
>
> How can the element doing the skipping know? In general it has no idea of the importance of an element in the route.
> Its at the time of insertion into the route that the importance is known, so that is when such decisions should be made.
>
> 	Thanks,
> 	Paul
>>
>> Youssef
>>
>> -----Message d'origine-----
>> De : sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] De la
>> part de Paul Kyzivat Envoyé : mercredi 3 novembre 2010 14:58 À :
>> sipcore@ietf.org Objet : Re: [sipcore] Bypassing out-of-service
>> intermediate Proxy
>>
>> This idea seems analogous to the auto assembly line deciding to bypass
>> the broken station where the engine is inserted into the car, and just
>> send the car on to the next station without its engine. The consumer
>> who receives this car may be less than satisfied. :-(
>>
>> 	Thanks,
>> 	Paul
>>
>> On 11/3/2010 5:55 AM, youssef.chadli@orange-ftgroup.com wrote:
>>>
>>> I understand that the usage of DNS to provide alternate server is a way to ensure redundancy. In such solution, to be able to handle SIP requests inside a SIP dialog and for which the proxy need to be "dialog statefull", there is a need to implement a mechanism that would allow the "alternate" server to share the same SIP dialog contexts.
>>>
>>> My idea is in case of unavailability of the next hop and in case no
>>> alternate server is returned by DNS (or alternate servers are
>>> unreachable too), instead of rejecting the request (which would make
>>> the call/session fails), the SIP Proxy may send it to the hop after
>>> the unreachable one in the Route. This alternative would be
>>> authorized only if the Proxy knows that it's better to bypass the
>>> unreachable node instead of rejecting the request. The SIP proxy may
>>> get this information via a URI parameter in the Route entry of the
>>> "unreachable" node for example
>>>
>>> Best regards,
>>>
>>> Youssef
>>>
>>> -----Message d'origine-----
>>> De : Worley, Dale R (Dale) [mailto:dworley@avaya.com] Envoyé :
>>> vendredi 29 octobre 2010 20:22 À : CHADLI Youssef RD-CORE-ISS;
>>> adam@nostrum.com Cc : sipcore@ietf.org Objet : RE: [sipcore]
>>> Bypassing out-of-service intermediate Proxy
>>>
>>> ________________________________________
>>> From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf
>>> Of youssef.chadli@orange-ftgroup.com
>>> [youssef.chadli@orange-ftgroup.com]
>>>
>>> I understand that the intention of this text in RFC 3261 is to fail over to an alternate server that serves the same function. Though, it's not explicitly stated.
>>>
>>> However, I did not find any text in RFC 3261 that would make forbidden failing over to a proxy further down the path.  Moreover, I did not see any problem to such behaviour.
>>> ________________________________
>>>
>>> If a particular URI is included in a Route header, then there is some important function the server with that URI is to perform.  If one element ignores this URI and sends the request to the next URI in the Route header, presumably the function of the skipped server will not be performed.
>>>
>>> In all cases that I have heard about, the correct way to provide alternate servers for a failed server is to construct a DNS SRV name which maps to the primary and alternate server as is desired.
>>>
>>> For instance, if functionA is to be serviced by serverA but in an emergency the request can be routed to serverB, and if functionB is serviced by serverB, then we construct two SRV names:
>>>
>>> functionA    SRV   serverA  priority=1
>>> functionA    SRV   serverB  priority=2
>>>
>>> functionB    SRV   serverB priority=1
>>>
>>> and use this Route header:
>>>
>>> Route:  sip:functionA, sip:functionB
>>>
>>> If an element has a request with this Route header, it will send the request to sp:functionA using the RFC 3263 rules, viz., attempt to send to serverA, and if that fails, attempt to send to serverB.
>>>
>>> Dale
>>> _______________________________________________
>>> sipcore mailing list
>>> sipcore@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
>>
>