IETF Logo Mail Archive

[sipcore] RFC 3261, question on provisional timer

"Goren, Ofer (Ofer)" <oferg@avaya.com> Thu, 03 October 2013 08:18 UTC

Return-Path: <oferg@avaya.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB3821F967F for <sipcore@ietfa.amsl.com>; Thu, 3 Oct 2013 01:18:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 sV3k9U53AjYi for <sipcore@ietfa.amsl.com>; Thu, 3 Oct 2013 01:18:24 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id D5E7821F949F for <sipcore@ietf.org>; Thu, 3 Oct 2013 01:16:03 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkkFANsmTVLGmAcV/2dsb2JhbABagkMjIThSwTiBHxZtB4InAQEDEhteARUVViYBBBsah2QBm22ER5x0jyCDV4EEA5QkijmLI4MkgWgEPg
X-IronPort-AV: E=Sophos; i="4.90,1024,1371096000"; d="scan'208,217"; a="26392474"
Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 03 Oct 2013 04:16:01 -0400
Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP; 03 Oct 2013 04:12:28 -0400
Received: from AZ-FFEXMB01.global.avaya.com ([fe80::39ee:75fe:e67a:cf4a]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0146.000; Thu, 3 Oct 2013 04:16:00 -0400
From: "Goren, Ofer (Ofer)" <oferg@avaya.com>
To: "sipcore@ietf.org" <sipcore@ietf.org>
Thread-Topic: RFC 3261, question on provisional timer
Thread-Index: Ac7AEId/rJid4wbQT3OGGwF+WCGA3A==
Date: Thu, 03 Oct 2013 08:16:00 +0000
Message-ID: <E13E2A10A9E01C40B51180C484B57339031BB982@AZ-FFEXMB01.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.64.58.45]
Content-Type: multipart/alternative; boundary="_000_E13E2A10A9E01C40B51180C484B57339031BB982AZFFEXMB01globa_"
MIME-Version: 1.0
Subject: [sipcore] RFC 3261, question on provisional timer
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 03 Oct 2013 08:18:42 -0000

Hi.

According to RFC 3261, section 13.3.1.1:
   If the UAS desires an extended period of time to answer the INVITE,
   it will need to ask for an "extension" in order to prevent proxies
   from canceling the transaction.  A proxy has the option of canceling
   a transaction when there is a gap of 3 minutes between responses in a
   transaction.  To prevent cancellation, the UAS MUST send a non-100
   provisional response at every minute, to handle the possibility of
   lost provisional responses.

Does this mean that UACs should also reset their timer when receiving sequential provisional responses, or does this section only relevant to proxies?

Thanks!

Ofer

v2.23.0 | Report a Bug | By Email