IETF Logo Mail Archive

Re: [Sip] Query on RFC 3578 v/s RFC 3261

"Sreerekha Shenoy (sresheno)" <sresheno@cisco.com> Wed, 31 March 2010 08:30 UTC

Return-Path: <sresheno@cisco.com>
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 3F7723A6BEF for <sip@core3.amsl.com>; Wed, 31 Mar 2010 01:30:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.724
X-Spam-Level:
X-Spam-Status: No, score=-8.724 tagged_above=-999 required=5 tests=[AWL=0.745, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8]
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 3XCPn8xVDAF1 for <sip@core3.amsl.com>; Wed, 31 Mar 2010 01:30:46 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 3A4D33A67A7 for <sip@ietf.org>; Wed, 31 Mar 2010 01:27:08 -0700 (PDT)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAPajsktAaHte/2dsb2JhbACbMXGmKJkdhQAEgyE
X-IronPort-AV: E=Sophos;i="4.51,340,1267401600"; d="scan'208";a="108039742"
Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 31 Mar 2010 08:27:37 +0000
Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2V8RZrB027373; Wed, 31 Mar 2010 08:27:36 GMT
Received: from xmb-bgl-41d.cisco.com ([72.163.129.219]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 31 Mar 2010 13:57:35 +0530
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Wed, 31 Mar 2010 13:57:34 +0530
Message-ID: <98041FB94260464FB06D65C8E9E6473B9CCA31@XMB-BGL-41D.cisco.com>
In-Reply-To: <w2ocf0140031003302304k39ad7d10re6bd281b36a87ea0@mail.gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] Query on RFC 3578 v/s RFC 3261
Thread-Index: AcrQmBTo2IufeX3gTaSiHV0p3X5XGwAEuNGw
References: <98041FB94260464FB06D65C8E9E6473B9CC977@XMB-BGL-41D.cisco.com> <w2ocf0140031003302304k39ad7d10re6bd281b36a87ea0@mail.gmail.com>
From: "Sreerekha Shenoy (sresheno)" <sresheno@cisco.com>
To: "Arunachala" <arun1977@gmail.com>, <gao.yang2@zte.com.cn>, <sip@ietf.org>
X-OriginalArrivalTime: 31 Mar 2010 08:27:35.0882 (UTC) FILETIME=[04508AA0:01CAD0AC]
Subject: Re: [Sip] Query on RFC 3578 v/s RFC 3261
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-Archive: <http://www.ietf.org/mail-archive/web/sip>
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>
X-List-Received-Date: Wed, 31 Mar 2010 08:30:47 -0000

Thanks Gao, Arun,

RFC 3261 says 
"1. If there is an ongoing INVITE client transaction, the TU MUST
         wait until the transaction reaches the completed or terminated
         state before initiating the new INVITE."

RFC 3578 also mentions abt the first INVITE receiving a response (with a To Tag) [1xx/2xx/...]
The subsequent SAM still goes out with a new INVITE without this To-tag though.
So in essence, are we saying that we keep ignoring the dialog formation and still continue to do INVITEs until no more SAM's happen?

Arent we going against the "1" quoted above from 3261?


Thanks,
Best Regards,
Rekha



-----Original Message-----
From: Arunachala [mailto:arun1977@gmail.com] 
Sent: Wednesday, March 31, 2010 11:34 AM
To: Sreerekha Shenoy (sresheno)
Cc: sip@ietf.org
Subject: Re: [Sip] Query on RFC 3578 v/s RFC 3261

Hi,
   I don't think are contradictory.

  RFC 3261 is talking about an INVITE transaction within a dialog.
Since in the case of RFC 3578, there is NO dialog setup yet, as there
is NO response for the initial INVITE, RFC 3261 Section 14.1 does NOT
hold good here.

Regards,
Arun

On Tue, Mar 30, 2010 at 10:47 PM, Sreerekha Shenoy (sresheno)
<sresheno@cisco.com> wrote:
> Hi,
>
>  I was reading the RFC 3578 regarding ISUP overlap signaling to SIP.
>
>
>
> In RFC 3578:
>
> 3.2.  Generating Multiple INVITEs
>
> ...
>
> If a SAM arrives to the gateway, T10 is refreshed and a new INVITE
>
>    with the new digits received is sent.  The new INVITE has the same
>
>    Call-ID and the same From header field including the tag as the first
>
>    INVITE sent, but has an updated Request-URI.
>
>
>
> [This section seems to indicate that the new INVITE happens without awaiting
> the final response for the previous INVITE]
>
>
>
>
>
> In RFC 3261:
>
> 14.1 UAC Behavior
>
> ...
>
>   Note that a UAC MUST NOT initiate a new INVITE transaction within a
>
>    dialog while another INVITE transaction is in progress in either
>
>    direction.
>
>
>
> ...
>
>
>
>  I find the two RFCs contradicting each other w.r.t INVITE initiated before
> the previous INVITE transaction was over in case of RFC 3578.
>
>  Please let me know if I am wrong in my understanding.
>
>
>
>
>
> Thanks,
>
> Best Regards,
>
> Rekha
>
>
>
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is essentially closed and only used for finishing old business.
> Use sip-implementors@cs.columbia.edu for questions on how to develop a SIP
> implementation.
> Use dispatch@ietf.org for new developments on the application of sip.
> Use sipcore@ietf.org for issues related to maintenance of the core SIP
> specifications.
>

v2.8.7 | Report a Bug | By Email