IETF Logo Mail Archive

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

gao.yang2@zte.com.cn Wed, 31 March 2010 06:03 UTC

Return-Path: <gao.yang2@zte.com.cn>
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 8559F3A694C for <sip@core3.amsl.com>; Tue, 30 Mar 2010 23:03:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -94.118
X-Spam-Level:
X-Spam-Status: No, score=-94.118 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, 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 AKhTuYs1o4LS for <sip@core3.amsl.com>; Tue, 30 Mar 2010 23:03:18 -0700 (PDT)
Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id E954B3A68CF for <sip@ietf.org>; Tue, 30 Mar 2010 23:03:17 -0700 (PDT)
Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 128641112621526; Wed, 31 Mar 2010 14:01:38 +0800 (CST)
Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 64572.2097080191; Wed, 31 Mar 2010 14:03:38 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o2V62Oas070060; Wed, 31 Mar 2010 14:02:24 +0800 (CST) (envelope-from gao.yang2@zte.com.cn)
In-Reply-To: <98041FB94260464FB06D65C8E9E6473B9CC977@XMB-BGL-41D.cisco.com>
To: "Sreerekha Shenoy (sresheno)" <sresheno@cisco.com>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006
Message-ID: <OF272BB268.0954D14A-ON482576F7.002035C3-482576F7.002122EB@zte.com.cn>
From: gao.yang2@zte.com.cn
Date: Wed, 31 Mar 2010 14:00:18 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-03-31 14:02:17, Serialize complete at 2010-03-31 14:02:17
Content-Type: multipart/alternative; boundary="=_alternative 002122EA482576F7_="
X-MAIL: mse2.zte.com.cn o2V62Oas070060
Cc: sip@ietf.org
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 06:03:19 -0000

When UAC send two INVITE with the same from tag, it can recv two different 
response with different to tag, and establishing two different dialog. 

While in one dialog, there MUST be only one on-going INVITE transaction.

Cheers,

Gao

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : gao.yang2@zte.com.cn
===================================

sip-bounces@ietf.org 写于 2010-03-31 13:47:36:

> 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.


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

v2.8.7 | Report a Bug | By Email