[Sip] RE: Defining new requests

"Christer Holmberg (JO/LMF)" <christer.holmberg@ericsson.com> Fri, 20 February 2004 11:42 UTC

Received: from optimus.ietf.org (optimus.ietf.org [132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16608 for <sip-archive@odin.ietf.org>; Fri, 20 Feb 2004 06:42:35 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au92n-0000O9-G3 for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 06:42:09 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i1KBg9Iu001460 for sip-archive@odin.ietf.org; Fri, 20 Feb 2004 06:42:09 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au92g-0000M9-5A; Fri, 20 Feb 2004 06:42:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Au92Y-0000LW-NP for sip@optimus.ietf.org; Fri, 20 Feb 2004 06:41:54 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16605 for <sip@ietf.org>; Fri, 20 Feb 2004 06:41:49 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Au92U-000783-00 for sip@ietf.org; Fri, 20 Feb 2004 06:41:50 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Au91Z-00075r-00 for sip@ietf.org; Fri, 20 Feb 2004 06:40:54 -0500
Received: from albatross-ext.wise.edt.ericsson.se ([193.180.251.49]) by ietf-mx with esmtp (Exim 4.12) id 1Au91F-00073H-00 for sip@ietf.org; Fri, 20 Feb 2004 06:40:33 -0500
Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by albatross-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i1KBeXqY016735 for <sip@ietf.org>; Fri, 20 Feb 2004 12:40:33 +0100 (MET)
Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 20 Feb 2004 12:40:33 +0100
Received: by esealnt610.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <FGMCVQ4W>; Fri, 20 Feb 2004 12:42:01 +0100
Message-ID: <F8EFC4B4A8C016428BC1F589296D4FBF07B07A69@esealnt630.al.sw.ericsson.se>
From: "Christer Holmberg (JO/LMF)" <christer.holmberg@ericsson.com>
To: "Gonzalo Camarillo (JO/LMF)" <gonzalo.camarillo@ericsson.com>, sip <sip@ietf.org>
Cc: Rohan Mahy <rohan@cisco.com>, Dean Willis <dean.willis@softarmor.com>
Date: Fri, 20 Feb 2004 12:40:21 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-OriginalArrivalTime: 20 Feb 2004 11:40:33.0257 (UTC) FILETIME=[595F8590:01C3F7A6]
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.2 required=5.0 tests=AWL autolearn=no version=2.60
Subject: [Sip] RE: Defining new requests
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>

Hi Gonzalo,

Thanks for your reply!

>it seems that some people in the ITU-T are having some issues 
>figuring out whether or not certain requests can be sent by the UAS within an 
>early dialog. The confusion comes from statements like this 
>one (taken from the INFO spec):
> 
> "     Unless stated otherwise, the protocol rules for the INFO request
>        governing the usage of tags, Route and Record-Route,
>        retransmission and reliability, CSeq incrementing and message
>        formatting follow those in [1] as defined for the BYE request."
> 
>Since a UAS does not send BYEs within an early dialog, but a non-2xx 
>final response instead, to terminate the dialog, people assume that INFO 
>cannot be sent in this situation either.
> 
>Let's try to keep this in mind and clarify this point when/if 
>we define new SIP methods.
> 
>In any event, the clarification to this issue can be found in 
>RFC 3398:
> 
>"From the callee to the caller, if a message is received by a gateway
>before the call has been answered (i.e., ANM is received) 
>it SHOULD be encapsulated in an INFO, provided that this will not 
>be the first SIP message sent in the backwards direction (in which 
>case it SHOULD be encapsulated in a provisional 1xx response)."

The problem is that the ITU-T interworking spec doesn't reference RFC3398. The spec reference the INFO RFC, and that is also where I think the usage rules should be defined (not in another spec, RFC3398 in this case, simply using the method).

The INFO RFC, as you said, currently says that INFO "follows the rules of BYE" (whatever that means is another question :), and the rules for BYE specifically says that it must not be sent backward before the INVITE has finished. If the INFO RFC would say "follow the rules of UPDATE" we would not have this problem, since the UPDATE spec specifically allows the use of the method before the INVITE has finished.

Thanks!

Christer Holmberg
Ericsson Finland

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip