[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] configuration NOTIFY in example 9.1 of outbound i-d
Francois Audet writes:
> I am not sure why this is worded like this. I was thinking that using
> a GRUU as a contact in a dialog-forming request would mandate that
> requests sent to that Contact would be sent using the same flow, but
> I see no such rule in draft-ietf-sip-gruu.
based on cullen's reply, text
If the UAC is sending a dialog-forming request, and wants all
subsequent requests in the dialog to arrive over the same flow, the
UAC adds an 'ob' parameter to its Contact header. Typically this is
desirable, but it is not necessary for example if the Contact is a
GRUU [I-D.ietf-sip-gruu].
needs to be changed, because no matter gruu or not, ob needs to be
included if UA wants the same flow to be used for requests of the dialog
from the proxy.
> Maybe I'm misunderstanding the question, but this draft relies on an
> outbound proxy. So, in this specific example, the configuration server
> needs to have outbound proxy behavior otherwise you are correct, this
> NOTIFY won't bFrom sip-bounces at ietf.org Tue Sep 30 01:35: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 D65513A6839;
Tue, 30 Sep 2008 01:35: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 543983A6839
for <sip at core3.amsl.com>; Tue, 30 Sep 2008 01:35:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
tests=[BAYES_00=-2.599]
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 yjX486-byluS for <sip at core3.amsl.com>;
Tue, 30 Sep 2008 01:35:27 -0700 (PDT)
Received: from tutpro.com (sip.tutpro.com [192.98.100.10])
by core3.amsl.com (Postfix) with ESMTP id BBC9E3A67F4
for <sip at ietf.org>; Tue, 30 Sep 2008 01:35:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1])
by tutpro.com (Postfix) with ESMTP id C11D21EC306;
Tue, 30 Sep 2008 11:35:00 +0300 (EEST)
Received: from tutpro.com ([127.0.0.1])
by localhost (tutpro.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id lMBwS6K3N6tv; Tue, 30 Sep 2008 11:34:58 +0300 (EEST)
Received: from taimen (gprs-prointernet-ff5b6a00-251.dhcp.inet.fi
[93.106.91.251])
(using TLSv1 with cipher ADH-AES256-SHA (256/256 bits))
(No client certificate requested)
by tutpro.com (Postfix) with ESMTPSA;
Tue, 30 Sep 2008 11:34:58 +0300 (EEST)
Received: by taimen (Postfix, from userid 1000)
id 982EAAC194; Tue, 30 Sep 2008 11:34:54 +0300 (EEST)
MIME-Version: 1.0
Message-ID: <18657.58542.594175.943037 at taimen.test.fi>
Date: Tue, 30 Sep 2008 11:34:54 +0300
To: "Francois Audet" <audet at nortel.com>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF197354D8 at zrc2hxm0.corp.nortel.com>
References: <18656.60044.302965.535846 at harjus.tutpro.com>
<1ECE0EB50388174790F9694F77522CCF197351A7 at zrc2hxm0.corp.nortel.com>
<18657.2518.651908.902884 at harjus.tutpro.com>
<1ECE0EB50388174790F9694F77522CCF197354D8 at zrc2hxm0.corp.nortel.com>
X-Mailer: VM 7.19 under Emacs 22.1.1
From: jh at tutpro.com (Juha Heinanen)
Cc: Cullen Jennings <fluffy at cisco.com>, Rohan Mahy <rohan at ekabal.com>,
sip at ietf.org
Subject: Re: [Sip] configuration NOTIFY in example 9.1 of outbound i-d
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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
Francois Audet writes:
> I am not sure why this is worded like this. I was thinking that using
> a GRUU as a contact in a dialog-forming request would mandate that
> requests sent to that Contact would be sent using the same flow, but
> I see no such rule in draft-ietf-sip-gruu.
based on cullen's reply, text
If the UAC is sending a dialog-forming request, and wants all
subsequent requests in the dialog to arrive over the same flow, the
UAC adds an 'ob' parameter to its Contact header. Typically this is
desirable, but it is not necessary for example if the Contact is a
GRUU [I-D.ietf-sip-gruu].
needs to be changed, because no matter gruu or not, ob needs to be
included if UA wants the same flow to be used for requests of the dialog
from the proxy.
> Maybe I'm misunderstanding the question, but this draft relies on an
> outbound proxy. So, in this specific example, the configuration server
> needs to have outbound proxy behavior otherwise you are correct, this
> NOTIFY won't be delivered. It's kind of like the co-located registrar
> and proxy described explicitly in the document, but for co-located
> Config server and proxy.
outbound behavior is also needed in case of regular presence server.
that is why i don't quite understand is why is this "usage of the same
flow for in-dialog requests" feature tied to outbound proxy. why is it
not useful to have a generic capability for UAC to tell to the next hop
(a proxy or UAS) in its dialog initiating request that "please use this
flow for subsequent requests of this dialog"?
-- juha
_______________________________________________
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
e delivered. It's kind of like the co-located registrar
> and proxy described explicitly in the document, but for co-located
> Config server and proxy.
outbound behavior is also needed in case of regular presence server.
that is why i don't quite understand is why is this "usage of the same
flow for in-dialog requests" feature tied to outbound proxy. why is it
not useful to have a generic capability for UAC to tell to the next hop
(a proxy or UAS) in its dialog initiating request that "please use this
flow for subsequent requests of this dialog"?
-- juha
_______________________________________________
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