IETF Logo Mail Archive

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

"Sreerekha Shenoy (sresheno)" <sresheno@cisco.com> Wed, 31 March 2010 05:47 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 C82003A68CF for <sip@core3.amsl.com>; Tue, 30 Mar 2010 22:47:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.979
X-Spam-Level:
X-Spam-Status: No, score=-7.979 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, 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 pvPxQRv5-h0M for <sip@core3.amsl.com>; Tue, 30 Mar 2010 22:47:25 -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 44F053A6830 for <sip@ietf.org>; Tue, 30 Mar 2010 22:47:24 -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: AuAFAHd+sktAaHte/2dsb2JhbACBP44Ci2dxpkOZEYUABIMe
X-IronPort-AV: E=Sophos; i="4.51,340,1267401600"; d="scan'208,217"; a="107983036"
Received: from hkg-core-1.cisco.com ([64.104.123.94]) by sj-iport-4.cisco.com with ESMTP; 31 Mar 2010 05:47:54 +0000
Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2V5lbgY009649 for <sip@ietf.org>; Wed, 31 Mar 2010 05:47:53 GMT
Received: from xmb-bgl-41d.cisco.com ([72.163.129.219]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 31 Mar 2010 11:17:39 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAD095.AC584203"
x-cr-puzzleid: {DA18FF87-68C6-4476-900E-F3C15217CE7F}
X-MimeOLE: Produced By Microsoft Exchange V6.5
x-cr-hashedpuzzle: AE97 AK2D ASTI AeNz Evbm E1k9 HNzX IBLy IVOc Ihxd I7iu JEJb JQtt KKxu KUae KeFw; 1; cwBpAHAAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {DA18FF87-68C6-4476-900E-F3C15217CE7F}; cwByAGUAcwBoAGUAbgBvAEAAYwBpAHMAYwBvAC4AYwBvAG0A; Wed, 31 Mar 2010 05:47:36 GMT; UQB1AGUAcgB5ACAAbwBuACAAUgBGAEMAIAAzADUANwA4ACAAdgAvAHMAIABSAEYAQwAgADMAMgA2ADEA
Content-class: urn:content-classes:message
Date: Wed, 31 Mar 2010 11:17:36 +0530
Message-ID: <98041FB94260464FB06D65C8E9E6473B9CC977@XMB-BGL-41D.cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Query on RFC 3578 v/s RFC 3261
Thread-Index: AcrQlaq8vhjqm0hpQSayZKH+cZfNiA==
From: "Sreerekha Shenoy (sresheno)" <sresheno@cisco.com>
To: <sip@ietf.org>
X-OriginalArrivalTime: 31 Mar 2010 05:47:39.0541 (UTC) FILETIME=[AC731C50:01CAD095]
Subject: [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 05:47:29 -0000

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

v2.8.7 | Report a Bug | By Email