From alan.b.johnston@gmail.com Tue Apr 12 06:41:54 2011 Return-Path: X-Original-To: cuss@ietfc.amsl.com Delivered-To: cuss@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4B973E077D for ; Tue, 12 Apr 2011 06:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.372 X-Spam-Level: X-Spam-Status: No, score=-103.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZYTPrYs-GPN for ; Tue, 12 Apr 2011 06:41:53 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfc.amsl.com (Postfix) with ESMTP id 01ACBE0705 for ; Tue, 12 Apr 2011 06:41:49 -0700 (PDT) Received: by wyb29 with SMTP id 29so6297484wyb.31 for ; Tue, 12 Apr 2011 06:41:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QU9eX3SKRwZWx/AZz4enwM4AmMxwZfGMEWavM6ydIU4=; b=ELyf1IMIeUEyWHY91oNST8F3OlZIQ9TUwbSEs/OvA3le5N95YFaNzbswTYHlShGXzM ucOnfGWIjtyOPv0sq9s834rThcoiilbx3bs0U7P8lkgp87rTp3JQ7Oai0enCMvR5onze ZoPXJK96KrwGgw4D4/HEvKw4T0r9A10c2djAQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=CMm5KmDL/5wvXjX3ZPe1w3xJoR+Ag4BJq7VLFmeRpBnKdb3lq9/ZKLp82aDvP/O+7i uovDHf4lqVFIWTQhjHWz75kCzobuDmhIeW0R7EIC0c1EToi2Wy2xOxYsGrOyYnnCaAeT WRFiTgquMetSGQ7RpSI1X6/kyTMQZZFq8pr5o= MIME-Version: 1.0 Received: by 10.216.3.200 with SMTP id 50mr4148917weh.34.1302615709052; Tue, 12 Apr 2011 06:41:49 -0700 (PDT) Received: by 10.216.1.67 with HTTP; Tue, 12 Apr 2011 06:41:49 -0700 (PDT) In-Reply-To: References: Date: Tue, 12 Apr 2011 08:41:49 -0500 Message-ID: From: Alan Johnston To: "DRAGE, Keith (Keith)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "cuss@ietf.org" Subject: Re: [cuss] draft-ietf-cuss-sip-uui-reqs-01: REQ-8 and REQ-10 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2011 13:41:54 -0000 Keith, Thanks for your comments on the drafts. In getting the document ready for WGLC, I have given some thoughts to your questions - see my answers below. - Alan - On Wed, Dec 22, 2010 at 8:17 AM, DRAGE, Keith (Keith) wrote: > For the following two requirements, I am still not sure we understand how= we want to use these, and more importantly, I am not sure we have sufficie= nt understanding to allow us define a mechanism. I said this in Beijing, an= d I am repeating it now. > > =A0 REQ-8: The mechanism will allow a UAC to learn or request that a UAS > =A0 understands the call control UUI mechanism. > > =A0 =A0 =A0This could be useful in ensuring that a request destined for t= he > =A0 =A0 =A0PSTN is routed to a gateway that supports the ISDN UUI service > =A0 =A0 =A0rather than an otherwise equivalent PSTN gateway that does not > =A0 =A0 =A0support the ISDN UUI service. =A0Note that support of the UUI > =A0 =A0 =A0mechanism does not, by itself, imply that a particular user > =A0 =A0 =A0application is supported - see REQ-10. > > =A0 REQ-10: The mechanism will provide the ability for a UA to discover > =A0 which types or application usages of UUI another UA understands or > =A0 supports. > > =A0 =A0 =A0The creation of a registry of application usages for the SIP U= UI > =A0 =A0 =A0mechanism is implied by this requirement. =A0For the ISDN Serv= ice, > =A0 =A0 =A0there could be value in utilizing the protocol discriminator, > =A0 =A0 =A0which is the first octet of the ISDN UUI information, for this > =A0 =A0 =A0purpose. > > Note that we have to consider these in requirements in terms of the 1st r= equest in a dialog, and in terms of the first response in a dialog. Not necessarily. SIP has all kinds of discovery mechanisms including OPTIONs, and presence, and reg-events that allow quite a bit of information to be known prior to sending an INVITE. To couch the entire discussion of these requirements in these terms is not accurate for SIP. > > Looking at the first request: > > For REQ-8 the way this is written implies that SIP routeing is impacted b= y it. Yet this is not stated by the requirement. If it is not, then you wil= l reach a gateway where discard will occur anyway, or if it is Require: UUI= , then the request will be rejected. But we have already said that we are e= mulating ISDN user to user service 1 implicit, which does not have such a r= equired capability. That only occurs with UUS service 1 explicit. I could expect SIP routing to be impacted by this. If you feel this needs to be included in the requirement, then we can add it. > > RFC 4485 states: > > =A0 Because of the possibility of interoperability and complexity > =A0 problems that result from the usage of Require and Proxy-Require, we > =A0 believe the following guidelines are appropriate: > > =A0 o =A0The usage of these header fields in requests for basic SIP > =A0 =A0 =A0services (in particular, session initiation and termination) i= s > =A0 =A0 =A0NOT RECOMMENDED. =A0The less frequently a particular extension= is > =A0 =A0 =A0needed in a request, the more reasonable it is to use these he= ader > =A0 =A0 =A0fields. > > =A0 o =A0The Proxy-Require header field SHOULD be avoided at all costs. > =A0 =A0 =A0The failure likelihood in an individual proxy stays constant, = but > =A0 =A0 =A0the path failure grows exponentially with the number of hops. = =A0On > =A0 =A0 =A0the other hand, the Require header field only mandates that a > =A0 =A0 =A0single entity, the UAS, support the extension. =A0Usage of > =A0 =A0 =A0Proxy-Require is thus considered exponentially worse than usag= e of > =A0 =A0 =A0the Require header field. > > =A0 o =A0If either Require or Proxy-Require are used by an extension, the > =A0 =A0 =A0extension SHOULD discuss how to fall back to baseline SIP > =A0 =A0 =A0operation if the request is rejected with a 420 response. > > So I guess there are two major questions concerning this direction of ope= ration: > > 1) =A0 =A0 =A0Do we intend REQ-8 to influence SIP routing? > > 2) =A0 =A0 =A0Do we intend REQ-8 to generally be used in the same way as = a Require option tag? > My personal opinion is perhaps and perhaps. > For REQ-10, I am not sure how we make this work on the first request. If = I wish to include UUI in the first request, that is surely an automatic ind= ication that I support it in the first request. Again, I don't think it is appropriate to limit the analysis to a blind INV= ITE. > > Looking now at the usage in the first response. > > I don't see how we make REQ-8 support the usage in the first response, un= less you intend to do this with a Supported header field and option tag. Ho= wever this is totally different to the operation of the ISDN mechanism. No, the current thinking is to use feature tags instead of option tags. > > The ISDN mechanism requires inclusion of UUI in the request to allow the = usage in the response. That could well be an empty element containing only = the protocol discriminator. > I don't think we want to do exactly this in SIP - we should just include the feature tag. A SIP/ISDN GW could then map this into an empty element containing only a protocol discriminator, if this is appropriate. We should deal with this in the ISDN Interworking draft. > For REQ-10, the suggested feature tage mechanism does not really interwor= k cleanly with this. > We should discuss this in the ISDN Interworking draft. I think we can make this good enough. > Finally, I am unsure of the interaction of REQ-8 and REQ-10 with REQ-3 an= d REQ-4, i.e. in the presence of the forwarding and redirection. Does the f= orwarding user have access to either REQ-8 or REQ-10. How does the C (final= destination) user distinguish between mechanisms supported by the A user (= origin) and the various forwarding users? This will depend on the mechanism - I don't think there is any value in speculation or theoretical analysis in the requirements draft on this. > > > regards > > Keith > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > From alan.b.johnston@gmail.com Mon Apr 25 15:33:01 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC96DE06A3 for ; Mon, 25 Apr 2011 15:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.372 X-Spam-Level: X-Spam-Status: No, score=-103.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CR8Bm8pwSS1 for ; Mon, 25 Apr 2011 15:33:01 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE15E0670 for ; Mon, 25 Apr 2011 15:32:57 -0700 (PDT) Received: by wyb29 with SMTP id 29so52739wyb.31 for ; Mon, 25 Apr 2011 15:32:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=BqToUV1dthwUO1xmAKAUfjHCuUdgVas7AE6Z9CODjbI=; b=s+kEb3X4BJmTPfb8hNGRjEFGpBKyC/DmZu2xuCQY6LTq/EV3gjWZ6y5LyYWV0mxO3l AQe9OX2R52PnALtB6HtlcZnWS6AN/G2kz8zOrh/DLg5qwzldgcjBHhO7SO3XZJpzKPtA ouDM59QyuVj/kJIOghuGQuZ0lzgsszMdvl7VQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=dN8JYlvXHpmzTZW1IE1OY/KQfLMB8fgr1efDA7krg7CIz49WHcTRupNRSo4Pt45TwE fnDixQJFvzxzlKRrvZ0vNGmR9CKaKXv/29GZY3KmOuIkYNRq79jGuYP+RHRjXg5v0tJS l5v/5t1DUgrK2PDfUi3OOZQgGSQAn+mmVK5c4= MIME-Version: 1.0 Received: by 10.216.254.79 with SMTP id g57mr1329871wes.42.1303764009704; Mon, 25 Apr 2011 13:40:09 -0700 (PDT) Received: by 10.216.10.80 with HTTP; Mon, 25 Apr 2011 13:40:09 -0700 (PDT) In-Reply-To: References: Date: Mon, 25 Apr 2011 15:40:09 -0500 Message-ID: From: Alan Johnston To: "DRAGE, Keith (Keith)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "cuss@ietf.org" Subject: Re: [cuss] draft-ietf-cuss-sip-uui-reqs-01: REQ-8 and REQ-10 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2011 22:33:01 -0000 Keith, I've been thinking of some text to describe how these discovery requirements map to the ISDN service. I'll share on the list shortly. - Alan - On Tue, Apr 12, 2011 at 8:41 AM, Alan Johnston wrote: > Keith, > > Thanks for your comments on the drafts. =A0In getting the document ready > for WGLC, I have given some thoughts to your questions - see my > answers below. > > - Alan - > > On Wed, Dec 22, 2010 at 8:17 AM, DRAGE, Keith (Keith) > wrote: >> For the following two requirements, I am still not sure we understand ho= w we want to use these, and more importantly, I am not sure we have suffici= ent understanding to allow us define a mechanism. I said this in Beijing, a= nd I am repeating it now. >> >> =A0 REQ-8: The mechanism will allow a UAC to learn or request that a UAS >> =A0 understands the call control UUI mechanism. >> >> =A0 =A0 =A0This could be useful in ensuring that a request destined for = the >> =A0 =A0 =A0PSTN is routed to a gateway that supports the ISDN UUI servic= e >> =A0 =A0 =A0rather than an otherwise equivalent PSTN gateway that does no= t >> =A0 =A0 =A0support the ISDN UUI service. =A0Note that support of the UUI >> =A0 =A0 =A0mechanism does not, by itself, imply that a particular user >> =A0 =A0 =A0application is supported - see REQ-10. >> >> =A0 REQ-10: The mechanism will provide the ability for a UA to discover >> =A0 which types or application usages of UUI another UA understands or >> =A0 supports. >> >> =A0 =A0 =A0The creation of a registry of application usages for the SIP = UUI >> =A0 =A0 =A0mechanism is implied by this requirement. =A0For the ISDN Ser= vice, >> =A0 =A0 =A0there could be value in utilizing the protocol discriminator, >> =A0 =A0 =A0which is the first octet of the ISDN UUI information, for thi= s >> =A0 =A0 =A0purpose. >> >> Note that we have to consider these in requirements in terms of the 1st = request in a dialog, and in terms of the first response in a dialog. > > Not necessarily. =A0SIP has all kinds of discovery mechanisms including > OPTIONs, and presence, and reg-events that allow quite a bit of > information to be known prior to sending an INVITE. =A0To couch the > entire discussion of these requirements in these terms is not accurate > for SIP. > >> >> Looking at the first request: >> >> For REQ-8 the way this is written implies that SIP routeing is impacted = by it. Yet this is not stated by the requirement. If it is not, then you wi= ll reach a gateway where discard will occur anyway, or if it is Require: UU= I, then the request will be rejected. But we have already said that we are = emulating ISDN user to user service 1 implicit, which does not have such a = required capability. That only occurs with UUS service 1 explicit. > > I could expect SIP routing to be impacted by this. =A0If you feel this > needs to be included in the requirement, then we can add it. > >> >> RFC 4485 states: >> >> =A0 Because of the possibility of interoperability and complexity >> =A0 problems that result from the usage of Require and Proxy-Require, we >> =A0 believe the following guidelines are appropriate: >> >> =A0 o =A0The usage of these header fields in requests for basic SIP >> =A0 =A0 =A0services (in particular, session initiation and termination) = is >> =A0 =A0 =A0NOT RECOMMENDED. =A0The less frequently a particular extensio= n is >> =A0 =A0 =A0needed in a request, the more reasonable it is to use these h= eader >> =A0 =A0 =A0fields. >> >> =A0 o =A0The Proxy-Require header field SHOULD be avoided at all costs. >> =A0 =A0 =A0The failure likelihood in an individual proxy stays constant,= but >> =A0 =A0 =A0the path failure grows exponentially with the number of hops.= =A0On >> =A0 =A0 =A0the other hand, the Require header field only mandates that a >> =A0 =A0 =A0single entity, the UAS, support the extension. =A0Usage of >> =A0 =A0 =A0Proxy-Require is thus considered exponentially worse than usa= ge of >> =A0 =A0 =A0the Require header field. >> >> =A0 o =A0If either Require or Proxy-Require are used by an extension, th= e >> =A0 =A0 =A0extension SHOULD discuss how to fall back to baseline SIP >> =A0 =A0 =A0operation if the request is rejected with a 420 response. >> >> So I guess there are two major questions concerning this direction of op= eration: >> >> 1) =A0 =A0 =A0Do we intend REQ-8 to influence SIP routing? >> >> 2) =A0 =A0 =A0Do we intend REQ-8 to generally be used in the same way as= a Require option tag? >> > > My personal opinion is perhaps and perhaps. > >> For REQ-10, I am not sure how we make this work on the first request. If= I wish to include UUI in the first request, that is surely an automatic in= dication that I support it in the first request. > > Again, I don't think it is appropriate to limit the analysis to a blind I= NVITE. > >> >> Looking now at the usage in the first response. >> >> I don't see how we make REQ-8 support the usage in the first response, u= nless you intend to do this with a Supported header field and option tag. H= owever this is totally different to the operation of the ISDN mechanism. > > No, the current thinking is to use feature tags instead of option tags. > >> >> The ISDN mechanism requires inclusion of UUI in the request to allow the= usage in the response. That could well be an empty element containing only= the protocol discriminator. >> > > I don't think we want to do exactly this in SIP - we should just > include the feature tag. =A0A SIP/ISDN GW could then map this into an > empty element containing only a protocol discriminator, if this is > appropriate. =A0We should deal with this in the ISDN Interworking draft. > >> For REQ-10, the suggested feature tage mechanism does not really interwo= rk cleanly with this. >> > > We should discuss this in the ISDN Interworking draft. =A0I think we can > make this good enough. > >> Finally, I am unsure of the interaction of REQ-8 and REQ-10 with REQ-3 a= nd REQ-4, i.e. in the presence of the forwarding and redirection. Does the = forwarding user have access to either REQ-8 or REQ-10. How does the C (fina= l destination) user distinguish between mechanisms supported by the A user = (origin) and the various forwarding users? > > This will depend on the mechanism - I don't think there is any value > in speculation or theoretical analysis in the requirements draft on > this. > >> >> >> regards >> >> Keith >> _______________________________________________ >> cuss mailing list >> cuss@ietf.org >> https://www.ietf.org/mailman/listinfo/cuss >> >