Re: [Sip] Is GRUU generated in the case of registration withinstance-ID and reg-ID
Paul Kyzivat <pkyzivat@cisco.com> Tue, 14 October 2008 12:17 UTC
Return-Path: <sip-bounces@ietf.org>
X-Original-To: sip-archive@optimus.ietf.org
Delivered-To: ietfarch-sip-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 152F828C132; Tue, 14 Oct 2008 05:17:53 -0700 (PDT)
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 E558B3A6BBB for <sip@core3.amsl.com>; Tue, 14 Oct 2008 05:17:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, 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 nJ12hUGEDmp4 for <sip@core3.amsl.com>; Tue, 14 Oct 2008 05:17:50 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 996CA3A6BB8 for <sip@ietf.org>; Tue, 14 Oct 2008 05:17:50 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,409,1220227200"; d="scan'208";a="24170128"
Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 14 Oct 2008 12:18:02 +0000
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m9ECI3RD022265; Tue, 14 Oct 2008 08:18:03 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9ECI25A027694; Tue, 14 Oct 2008 12:18:02 GMT
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Oct 2008 08:18:02 -0400
Received: from [10.86.251.129] ([10.86.251.129]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 14 Oct 2008 08:18:02 -0400
Message-ID: <48F48DF9.1000705@cisco.com>
Date: Tue, 14 Oct 2008 08:18:01 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: Erkki.Koivusalo@nokia.com
References: <CA9998CD4A020D418654FCDEF4E707DF05C0F8DF@esealmw113.eemea.ericsson.se> <1ECE0EB50388174790F9694F77522CCF19B03A76@zrc2hxm0.corp.nortel.com><CA9998CD4A020D418654FCDEF4E707DF083CCF7E@esealmw113.eemea.ericsson.se><48F23D27.8030305@voip.co.uk><CA9998CD4A020D418654FCDEF4E707DF083CCF85@esealmw113.eemea.ericsson.se><48F2FC13.1070308@voip.co.uk> <CA9998CD4A020D418654FCDEF4E707DF05C0F8ED@esealmw113.eemea.ericsson.se> <7A726F54F791494C8D8C87F13736E80EF52279@vaebe106.NOE.Nokia.com>
In-Reply-To: <7A726F54F791494C8D8C87F13736E80EF52279@vaebe106.NOE.Nokia.com>
X-OriginalArrivalTime: 14 Oct 2008 12:18:02.0547 (UTC) FILETIME=[E7797030:01C92DF6]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5169; t=1223986683; x=1224850683; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com> |Subject:=20Re=3A=20[Sip]=20Is=20GRUU=20generated=20in=20th e=20case=20of=20registration=09withinstance-ID=0A=20and=20re g-ID |Sender:=20 |To:=20Erkki.Koivusalo@nokia.com; bh=DXLpSbxo8bTOpRxoUDF+6TU6PqdteOd8DtDjwPy0/2s=; b=QmV9f9DTaj4PkmCePQ7VdyzCeFExx5daiNgFtDyEPybE8u0tetU3QL/RdE cGsIAIwu0WuzfWats2e9xu3kyG0dDBPaFdH1b1x2TZ9Vecc9sDkZEuhx8I4T pC4rghHB4f;
Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; );
Cc: sip@ietf.org, audet@nortel.com, christer.holmberg@ericsson.com
Subject: Re: [Sip] Is GRUU generated in the case of registration withinstance-ID and reg-ID
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-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>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
The reason outbound and gruu are using the same instance-id is that both uses share the same definition of the concept of a UA instance. Thanks, Paul Erkki.Koivusalo@nokia.com wrote: > Hi, > >>> Its been a long time, and the details are starting to get fuzzy in my >> mind. >> >> One should not have to remember the details - they should be clear by >> reading the specs :) > > I agree, however the specs often lack the rationale behind > the agreed design choices. So even if you see something has > specified in a certain way, in some cases you will have hard > time understanding why, unless you dig into the email archives. > >>> My question is still: if the REGISTER contains instance-id AND >>> Require:gruu, is a gruu generated? > >> Since reg-id isn't mentioned in gruu, its irrelevant to the gruu spec, >> just as any other parameters are. > > Right. Registrar compliant to the GRUU spec will create gruu > when it sees the Contact header field in the REGISTER message to > contain a "+sip.instance" header field parameter. The registrar > does not need to understand other parameters specified in Outbound > spec. I admit it is a bit confusing to use the same parameter in > two different specs that should be orthogonal, but it just happens > to be the specified behaviour. > >> So, what is the justification for generating a gruu, but not returning >> it (after all, the gruu will be sent to the UA if it registers to the >> regevent package, so...)??? > > I also raised this question in march 2007 while reviewing GRUU spec > and received an answer from Paul Kyzivat, who had a point: > > Erkki.Koivusalo@nokia.com wrote: >> Hi Jonathan, >> >> GRUU draft tells the registrar to create a public GRUU and a >> temporary GRUU whenever it receives a REGISTER request with >> "+sip.instance" Contact header parameter but only return >> them is the REGISTER request contains Supported: gruu. >> >> Does this make any sense ? Why would the registrar have to >> create those GRUUs if it would not return them to the UA ? >> >> The use case I am thinking is: >> >> - A registrar which supports both GRUU and Outbound >> - An UA which supports Outbound but not GRUU >> >> Such an UA would send its Contact header with "+sip.instance" >> parameter but it would not include Supported: gruu in its >> REGISTER. Strictly speaking GRUU draft currently tells >> the registrar to create GRUUs but not to return them to >> the UA. >> >> I would assume GRUU draft needs a small fix to tell the >> registrar to create the GRUUs only if the REGISTER >> request contains "gruu" option tag in Supported header. >> >> Do you agree or have I missed something ? > > This is partially one of those questions like "does a tree that falls > make any noise if nobody is listening?" > > If in fact nobody will learn about this gruu then there is no need to > create it. But that is all about the difference between the conceptual > model and the implementation, so it doesn't need to be stated. > > The problem arises when there are multiple observers of registration > state. There are at least two ways this can happen: > - other UAs that register > - subscribers to the reg event package > > After you register, if others register they will get your contact back > in the response to their register request, along with their own. If they > > support gruu, then they will will see the permanent gruu and latest temp > > gruu for your contact. > > Similarly, when you register, any subscribers to the reg event package > will get a notify telling of the change in registration state, including > > your contact and the gruus that were "assigned" to you. > > Everything hangs together better this way. Still, if nobody is looking > you don't have to assign these, as long as you do assign them when > somebody does start looking. > > Paul > -- > > Perhaps this could have been worth mentioning in the GRUU spec. > >> I think that the outbound spec should clarify that the >> instance-id, when used with outbound, will also create >> a gruu, according to the rules in the gruu-spec. > > I understand the point that Outbound spec should actually NOT > talk about creation of gruus, as that is the task of GRUU spec. > However Outbound refers to GRUU spec twice, so what about > modifying the note within section 6 as like this: > > A Contact header field value with an instance-id media feature tag > but no reg-id header field parameter is valid (this combination can > be used in the GRUU [I-D.ietf-sip-gruu] specification as creation > of gruu is not dependent on the presence or absence of reg-id > parameter), but one with a reg-id but no instance-id is not. > > Regards, > > Erkki > _______________________________________________ > Sip mailing list https://www.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 > _______________________________________________ Sip mailing list https://www.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
- [Sip] Is GRUU generated in the case of registrati… georg.mayer
- Re: [Sip] Is GRUU generated in the case of regist… Michael Procter
- Re: [Sip] Is GRUU generated in the case of regist… Francois Audet
- [Sip] Is GRUU generated in the case of registrati… Christer Holmberg
- Re: [Sip] Is GRUU generated in the case of regist… Francois Audet
- Re: [Sip] Is GRUU generated in the case of regist… Dale.Worley
- Re: [Sip] Is GRUU generated in the case of regist… Christer Holmberg
- Re: [Sip] Is GRUU generated in the case of regist… Christer Holmberg
- Re: [Sip] Is GRUU generated in the case of regist… Michael Procter
- Re: [Sip] Is GRUU generated in the case of regist… Paul Kyzivat
- Re: [Sip] Is GRUU generated in the case of regist… Francois Audet
- Re: [Sip] Is GRUU generated in the case of regist… Christer Holmberg
- Re: [Sip] Is GRUU generated in the case of regist… Christer Holmberg
- Re: [Sip] Is GRUU generated in the case of regist… Christer Holmberg
- Re: [Sip] Is GRUU generated in the case of regist… Michael Procter
- Re: [Sip] Is GRUU generated in the case of regist… Christer Holmberg
- Re: [Sip] Is GRUU generated in the case of regist… Michael Procter
- Re: [Sip] Is GRUU generated in the case of regist… Paul Kyzivat
- Re: [Sip] Is GRUU generated in the case of regist… Paul Kyzivat
- Re: [Sip] Is GRUU generated in the case of regist… Christer Holmberg
- Re: [Sip] Is GRUU generated in the case of regist… Erkki.Koivusalo
- Re: [Sip] Is GRUU generated in the case of regist… Christer Holmberg
- Re: [Sip] Is GRUU generated in the case of regist… Christer Holmberg
- Re: [Sip] Is GRUU generated in the case of regist… Paul Kyzivat
- Re: [Sip] Is GRUU generated in the case of regist… Francois Audet
- Re: [Sip] Is GRUU generated in the case of regist… Dean Willis
- Re: [Sip] Is GRUU generated in the case of regist… Christer Holmberg
- Re: [Sip] Is GRUU generated in the case of regist… Christer Holmberg
- Re: [Sip] Is GRUU generated in the case of regist… Dean Willis
- Re: [Sip] Is GRUU generated in the case of regist… Erkki.Koivusalo
- Re: [Sip] Is GRUU generated in the case of regist… Francois Audet
- Re: [Sip] Is GRUU generated in the case of regist… Francois Audet
- Re: [Sip] Is GRUU generated in the case of regist… Francois Audet
- Re: [Sip] Is GRUU generated in the case of regist… Christer Holmberg
- Re: [Sip] Is GRUU generated in the case of regist… Paul Kyzivat
- Re: [Sip] Is GRUU generated in the case of regist… DRAGE, Keith (Keith)