[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sip] RFC 3515: Multiple REFER Requests in a Dialog - Needclarification

Hi
 
To solve this problem we could use the mechanism defined in RFC 4488 -
Suppression of SIP Refer method Implicit subscripFrom sip-bounces at ietf.org  Thu Jul 24 23:52:29 2008
Return-Path: <sip-bounces at ietf.org>
X-Original-To: sip-archive at optimus.ietf.org
Delivered-To: ietfarch-sip-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id D345B3A68AE;
	Thu, 24 Jul 2008 23:52:29 -0700 (PDT)
X-Original-To: sip at core3.amsl.com
Delivered-To: sip at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 355523A68AE
	for <sip at core3.amsl.com>; Thu, 24 Jul 2008 23:52:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 RVH6iv9xXB86 for <sip at core3.amsl.com>;
	Thu, 24 Jul 2008 23:52:28 -0700 (PDT)
Received: from mail128.messagelabs.com (mail128.messagelabs.com
	[216.82.250.131])
	by core3.amsl.com (Postfix) with SMTP id 319E93A681C
	for <sip at ietf.org>; Thu, 24 Jul 2008 23:52:28 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: ranjit at motorola.com
X-Msg-Ref: server-15.tower-128.messagelabs.com!1216968747!20802475!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 14322 invoked from network); 25 Jul 2008 06:52:28 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8)
	by server-15.tower-128.messagelabs.com with SMTP;
	25 Jul 2008 06:52:28 -0000
Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131])
	by motgate8.mot.com (8.12.11/Motorola) with ESMTP id m6P6ppT1004440
	for <sip at ietf.org>; Thu, 24 Jul 2008 23:51:56 -0700 (MST)
Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143])
	by il06exr01.mot.com (8.13.5/Vontu) with SMTP id m6P6ppm8008334
	for <sip at ietf.org>; Fri, 25 Jul 2008 01:51:51 -0500 (CDT)
Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26])
	by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id m6P6pnQG008321
	for <sip at ietf.org>; Fri, 25 Jul 2008 01:51:50 -0500 (CDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Fri, 25 Jul 2008 14:51:48 +0800
Message-ID: <750BBC72E178114F9DC4872EBFF29A5B058B37AA at ZMY16EXM66.ds.mot.com>
In-Reply-To: <608D7BFF0D57794785CBC2C440BC4FA1048D7318 at ZMY16EXM67.ds.mot.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Sip] RFC 3515: Multiple REFER Requests in a Dialog -
	Needclarification
Thread-Index: AcjuHJYZPWQzPYLWSYCgHrKNNG0K7wAA/CnA
References: <608D7BFF0D57794785CBC2C440BC4FA1048D7318 at ZMY16EXM67.ds.mot.com>
From: "Avasarala Ranjit-A20990" <ranjit at motorola.com>
To: "Vavilapalli Srikanth-A19563" <srikanthv at motorola.com>, <sip at ietf.org>
X-CFilter-Loop: Reflected
Subject: Re: [Sip] RFC 3515: Multiple REFER Requests in a Dialog -
	Needclarification
X-BeenThere: sip at 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 at ietf.org?subject=unsubscribe>
List-Post: <mailto:sip at ietf.org>
List-Help: <mailto:sip-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>,
	<mailto:sip-request at ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="==============84984407=="
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org

This is a multi-part message in MIME format.
Hi
 
To solve this problem we could use the mechanism defined in RFC 4488 - Suppression of SIP Refer method Implicit subscription.
 
So here when the UAC i.e the REFER Issuer is sending the 2nd REFER request, it can follow the procedures defined in above RFC so that the REFER recipient does not create another implicit subscription for the REFER request.
 
But here too it is not clear how the REFER issuer would know if the REFER recipient supports RFC 4488 or not - unless REFER recipient inserts the mentioned option-tags in the response to first REFER request -- because if it does not, then implicit subscription is anyway created for 2nd REFER request too as per RFC 3515.

Regards
Ranjit

From: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of Vavilapalli Srikanth-A19563
Sent: Friday, July 25, 2008 11:37 AM
To: sip at ietf.org
Subject: [Sip] RFC 3515: Multiple REFER e REFER Requests in a Dialog - Needclarification

Hi
 
I have seen some discussion happened on this topic in the following mail trail, but still not clear with one thing:
https://lists.cs.columbia.edu/pipermail/sip-implementors/2003-December/005829.html
 
 
Is there any use case where we receive second REFER message that creates a subscription while there exists an already an 'active' REFER subscription in the same dialog? RFC 3515 has given a use case by saying that "If more than one REFER is issued in the same dialog (a second attempt at transferring a call for example)". But in the above scenario, I assume that the first attempt to call transfer has failed (i.e. first REFER subscription terminated).
 
Please clarify me.
 
Regards
Srikanth
 
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip