From brett@broadsoft.com Mon Mar 1 05:40:30 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4350D28C36D for ; Mon, 1 Mar 2010 05:40:30 -0800 (PST) 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 xoxuZYdBhe3E for ; Mon, 1 Mar 2010 05:40:29 -0800 (PST) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 53CBE28C3A8 for ; Mon, 1 Mar 2010 05:35:44 -0800 (PST) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Mon, 1 Mar 2010 05:35:41 -0800 From: Brett Tate To: Christer Holmberg , SIPCORE Date: Mon, 1 Mar 2010 05:35:04 -0800 Thread-Topic: [sipcore] OPTIONS: What does it mean? Thread-Index: Acq2VHLmNUzGkfPGRM+Lq1sg6ka55gABBs8wALmfypA= Message-ID: <747A6506A991724FB09B129B79D5FEB614803AA992@EXMBXCLUS01.citservers.local> References: <4B7E9EAD.20201@cisco.com> <4B85B02E.6000500@cisco.com> <747A6506A991724FB09B129B79D5FEB61480306949@EXMBXCLUS01.citservers.local> <4B86AAEF.9000108@cisco.com> <747A6506A991724FB09B129B79D5FEB61480306CD4@EXMBXCLUS01.citservers.local> <4B86D597.6060009@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] OPTIONS: What does it mean? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 13:40:30 -0000 > > *If* the OPTIONS has a to-tag, and there is no matching=20 > > dialog there are several things that might happen: > > - it might be rejected with a 481 > > - it might succeed because it is treated as if received=20 > > outside a dialog > > - it might cause the dialog to be recreated, and then=20 > > succeed within it > > In the latter case, presumably the dialog would then end,=20 > > because there are no dialog usages. >=20 > And, this will of course depend on whether the UAS still has=20 > any knowledge about the dialog. >=20 > Personally I think this alternative is rather strange, and=20 > I've never heard about it being used. But, I agree that the=20 > text seems to allow it. Regardless if justified by the above bullets 2 or 3, some venders do return= 200 instead of 481. For instance if OPTIONS is sent within dialog associa= ted with a currently/formerly known subscription, the UAS wouldn't want to = return 481 (because of the potential impacts) unless it actually verified t= hat the subscription is no longer known. Since it highlights why potentially relevant to get OPTIONS 481 ambiguity c= larified, the following is snippet a 2008 thread. "Just trying to understand what rfc3261 and rfc5057 indicate or tried to in= dicate concerning 1) if OPTIONS 481 should ever be sent, and 2) the related= impacts upon the dialog usages if OPTIONS 481 is received, 3) OPTIONS' abi= lity to temporality revive/recreate the dialog per UAS' desire to return 20= 0. If OPTIONS 481 really MUST be sent and SHOULD trigger subsequent requests/r= esponses to terminate the dialog, I'm sure some would like to use it within= early dialogs, subscriptions, and elsewhere." From christer.holmberg@ericsson.com Mon Mar 1 10:39:32 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE6DA28C51E for ; Mon, 1 Mar 2010 10:39:32 -0800 (PST) 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 U6jtFlxaGQq7 for ; Mon, 1 Mar 2010 10:39:32 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id AE63828C51B for ; Mon, 1 Mar 2010 10:39:31 -0800 (PST) X-AuditID: c1b4fb3d-b7c72ae00000040e-ea-4b8c09e2e1e5 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id BB.D4.01038.2E90C8B4; Mon, 1 Mar 2010 19:39:31 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.139]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Mon, 1 Mar 2010 19:39:30 +0100 From: Christer Holmberg To: 'Brett Tate' , SIPCORE Date: Mon, 1 Mar 2010 19:39:30 +0100 Thread-Topic: [sipcore] OPTIONS: What does it mean? Thread-Index: Acq2VHLmNUzGkfPGRM+Lq1sg6ka55gABBs8wALmfypAAC7YLIA== Message-ID: References: <4B7E9EAD.20201@cisco.com> <4B85B02E.6000500@cisco.com> <747A6506A991724FB09B129B79D5FEB61480306949@EXMBXCLUS01.citservers.local> <4B86AAEF.9000108@cisco.com> <747A6506A991724FB09B129B79D5FEB61480306CD4@EXMBXCLUS01.citservers.local> <4B86D597.6060009@cisco.com> <747A6506A991724FB09B129B79D5FEB614803AA992@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB614803AA992@EXMBXCLUS01.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] OPTIONS: What does it mean? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 18:39:33 -0000 Hi, If we forget what the RFCs say (or, what we believe they say :), how would = people like the UAS to handle OPTIONS in the case when it contains a to-tag= but the UAS currently has no state of a dialog associated with that to-tag= value? Regards, Christer =20 -----Original Message----- From: Brett Tate [mailto:brett@broadsoft.com]=20 Sent: 1. maaliskuuta 2010 15:35 To: Christer Holmberg; SIPCORE Subject: RE: [sipcore] OPTIONS: What does it mean? > > *If* the OPTIONS has a to-tag, and there is no matching dialog there=20 > > are several things that might happen: > > - it might be rejected with a 481 > > - it might succeed because it is treated as if received=20 > > outside a dialog > > - it might cause the dialog to be recreated, and then=20 > > succeed within it > > In the latter case, presumably the dialog would then end, because=20 > > there are no dialog usages. >=20 > And, this will of course depend on whether the UAS still has any=20 > knowledge about the dialog. >=20 > Personally I think this alternative is rather strange, and I've never=20 > heard about it being used. But, I agree that the text seems to allow=20 > it. Regardless if justified by the above bullets 2 or 3, some venders do return= 200 instead of 481. For instance if OPTIONS is sent within dialog associa= ted with a currently/formerly known subscription, the UAS wouldn't want to = return 481 (because of the potential impacts) unless it actually verified t= hat the subscription is no longer known. Since it highlights why potentially relevant to get OPTIONS 481 ambiguity c= larified, the following is snippet a 2008 thread. "Just trying to understand what rfc3261 and rfc5057 indicate or tried to in= dicate concerning 1) if OPTIONS 481 should ever be sent, and 2) the related= impacts upon the dialog usages if OPTIONS 481 is received, 3) OPTIONS' abi= lity to temporality revive/recreate the dialog per UAS' desire to return 20= 0. If OPTIONS 481 really MUST be sent and SHOULD trigger subsequent requests/r= esponses to terminate the dialog, I'm sure some would like to use it within= early dialogs, subscriptions, and elsewhere." From pkyzivat@cisco.com Mon Mar 1 10:58:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2485128C483 for ; Mon, 1 Mar 2010 10:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 HmE5BxbXD1lh for ; Mon, 1 Mar 2010 10:58:51 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 312A43A87D8 for ; Mon, 1 Mar 2010 10:58:49 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKdmi0tAZnwM/2dsb2JhbACbD3OicJdYhHsEgxc X-IronPort-AV: E=Sophos;i="4.49,561,1262563200"; d="scan'208";a="94076234" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by sj-iport-4.cisco.com with ESMTP; 01 Mar 2010 18:58:49 +0000 Received: from [10.86.253.204] ([10.86.253.204]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o21Iwmxd008761; Mon, 1 Mar 2010 18:58:49 GMT Message-ID: <4B8C0E68.3050802@cisco.com> Date: Mon, 01 Mar 2010 13:58:48 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4B7E9EAD.20201@cisco.com> <4B85B02E.6000500@cisco.com> <747A6506A991724FB09B129B79D5FEB61480306949@EXMBXCLUS01.citservers.local> <4B86AAEF.9000108@cisco.com> <747A6506A991724FB09B129B79D5FEB61480306CD4@EXMBXCLUS01.citservers.local> <4B86D597.6060009@cisco.com> <747A6506A991724FB09B129B79D5FEB614803AA992@EXMBXCLUS01.citservers.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: What does it mean? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 18:58:52 -0000 IMO, if the request has a to-tag, then the UAS should treat it as an in-dialog request not associated with any particular usage. If there is no matching dialog, then it should return a 481 response. Thanks, Paul Christer Holmberg wrote: > Hi, > > If we forget what the RFCs say (or, what we believe they say :), how would people like the UAS to handle OPTIONS in the case when it contains a to-tag but the UAS currently has no state of a dialog associated with that to-tag value? > > Regards, > > Christer > > > > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: 1. maaliskuuta 2010 15:35 > To: Christer Holmberg; SIPCORE > Subject: RE: [sipcore] OPTIONS: What does it mean? > >>> *If* the OPTIONS has a to-tag, and there is no matching dialog there >>> are several things that might happen: >>> - it might be rejected with a 481 >>> - it might succeed because it is treated as if received >>> outside a dialog > > > >>> - it might cause the dialog to be recreated, and then >>> succeed within it >>> In the latter case, presumably the dialog would then end, because >>> there are no dialog usages. >> And, this will of course depend on whether the UAS still has any >> knowledge about the dialog. >> >> Personally I think this alternative is rather strange, and I've never >> heard about it being used. But, I agree that the text seems to allow >> it. > > Regardless if justified by the above bullets 2 or 3, some venders do return 200 instead of 481. For instance if OPTIONS is sent within dialog associated with a currently/formerly known subscription, the UAS wouldn't want to return 481 (because of the potential impacts) unless it actually verified that the subscription is no longer known. > > Since it highlights why potentially relevant to get OPTIONS 481 ambiguity clarified, the following is snippet a 2008 thread. > > "Just trying to understand what rfc3261 and rfc5057 indicate or tried to indicate concerning 1) if OPTIONS 481 should ever be sent, and 2) the related impacts upon the dialog usages if OPTIONS 481 is received, 3) OPTIONS' ability to temporality revive/recreate the dialog per UAS' desire to return 200. > > If OPTIONS 481 really MUST be sent and SHOULD trigger subsequent requests/responses to terminate the dialog, I'm sure some would like to use it within early dialogs, subscriptions, and elsewhere." > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From brett@broadsoft.com Mon Mar 1 11:40:26 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 424C528C17C for ; Mon, 1 Mar 2010 11:40:26 -0800 (PST) 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 YXSpEsaM5Qgr for ; Mon, 1 Mar 2010 11:40:25 -0800 (PST) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id D03543A8538 for ; Mon, 1 Mar 2010 11:40:24 -0800 (PST) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Mon, 1 Mar 2010 11:40:25 -0800 From: Brett Tate To: Christer Holmberg , SIPCORE Date: Mon, 1 Mar 2010 11:39:49 -0800 Thread-Topic: [sipcore] OPTIONS: What does it mean? Thread-Index: Acq2VHLmNUzGkfPGRM+Lq1sg6ka55gABBs8wALmfypAAC7YLIAABCrDg Message-ID: <747A6506A991724FB09B129B79D5FEB614803AADA7@EXMBXCLUS01.citservers.local> References: <4B7E9EAD.20201@cisco.com> <4B85B02E.6000500@cisco.com> <747A6506A991724FB09B129B79D5FEB61480306949@EXMBXCLUS01.citservers.local> <4B86AAEF.9000108@cisco.com> <747A6506A991724FB09B129B79D5FEB61480306CD4@EXMBXCLUS01.citservers.local> <4B86D597.6060009@cisco.com> <747A6506A991724FB09B129B79D5FEB614803AA992@EXMBXCLUS01.citservers.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] OPTIONS: What does it mean? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 19:40:26 -0000 > If we forget what the RFCs say (or, what we believe they say :), > how would people like the UAS to handle OPTIONS in the case when=20 > it contains a to-tag but the UAS currently has no state of a=20 > dialog associated with that to-tag value? To avoid encouraging the use of OPTIONS to check dialog state (INVITE usage= and/or SUBSCRIBE usage), I'd prefer it not be mandatory to return 481. > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: 1. maaliskuuta 2010 15:35 > To: Christer Holmberg; SIPCORE > Subject: RE: [sipcore] OPTIONS: What does it mean? >=20 > > > *If* the OPTIONS has a to-tag, and there is no matching dialog > there > > > are several things that might happen: > > > - it might be rejected with a 481 > > > - it might succeed because it is treated as if received > > > outside a dialog >=20 > >=20 > > > - it might cause the dialog to be recreated, and then > > > succeed within it > > > In the latter case, presumably the dialog would then end, because > > > there are no dialog usages. > > > > And, this will of course depend on whether the UAS still has any > > knowledge about the dialog. > > > > Personally I think this alternative is rather strange, and I've never > > heard about it being used. But, I agree that the text seems to allow > > it. >=20 > Regardless if justified by the above bullets 2 or 3, some venders do > return 200 instead of 481. For instance if OPTIONS is sent within > dialog associated with a currently/formerly known subscription, the UAS > wouldn't want to return 481 (because of the potential impacts) unless > it actually verified that the subscription is no longer known. >=20 > Since it highlights why potentially relevant to get OPTIONS 481 > ambiguity clarified, the following is snippet a 2008 thread. >=20 > "Just trying to understand what rfc3261 and rfc5057 indicate or tried > to indicate concerning 1) if OPTIONS 481 should ever be sent, and 2) > the related impacts upon the dialog usages if OPTIONS 481 is received, > 3) OPTIONS' ability to temporality revive/recreate the dialog per UAS' > desire to return 200. >=20 > If OPTIONS 481 really MUST be sent and SHOULD trigger subsequent > requests/responses to terminate the dialog, I'm sure some would like to > use it within early dialogs, subscriptions, and elsewhere." From ietf.hanserik@gmail.com Mon Mar 1 11:44:45 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 674923A8BAE for ; Mon, 1 Mar 2010 11:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 6IRwwluVrB5d for ; Mon, 1 Mar 2010 11:44:44 -0800 (PST) Received: from mail-ew0-f215.google.com (mail-ew0-f215.google.com [209.85.219.215]) by core3.amsl.com (Postfix) with ESMTP id E953028C181 for ; Mon, 1 Mar 2010 11:44:43 -0800 (PST) Received: by ewy7 with SMTP id 7so1060658ewy.29 for ; Mon, 01 Mar 2010 11:44:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Ans+dMTPK3oDA87lpwWBcAMf0khj1521NmZsOqNvp4E=; b=ZwfFL8KmEdeNj2GhNMZQiIG3C3z44azns+BDETGXb+PEB6DGThhoDCA5E+dga4LaC/ lkMYnHm1BkK7yi3OLDGlOVFqCok2eW5Fgn4lN1m/XFfkTwLpbKB2kTdrpehbixrER5aG grE9jT6vq21CLQgAemeM+zOLt5PRMoCaC2CQo= 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; b=oWpgZd3jrlDklqM4oq+CYn0z9/tKzQPgACWeAw41T2YikhjvBzbDXo8eeF5dI+1kjb OJva5O1B2hqRP8Yxneum94VgGJt1ZXzI+OQydM/esBcoHhjvznQP16D85/EbJZZfxwEK RMreb4uFDwpjlZ54kRgpT4eN0U5FiwqrhX3c0= MIME-Version: 1.0 Received: by 10.213.52.17 with SMTP id f17mr131087ebg.69.1267472680071; Mon, 01 Mar 2010 11:44:40 -0800 (PST) In-Reply-To: <4B8C0E68.3050802@cisco.com> References: <747A6506A991724FB09B129B79D5FEB61480306949@EXMBXCLUS01.citservers.local> <4B86AAEF.9000108@cisco.com> <747A6506A991724FB09B129B79D5FEB61480306CD4@EXMBXCLUS01.citservers.local> <4B86D597.6060009@cisco.com> <747A6506A991724FB09B129B79D5FEB614803AA992@EXMBXCLUS01.citservers.local> <4B8C0E68.3050802@cisco.com> Date: Mon, 1 Mar 2010 20:44:39 +0100 Message-ID: <9ae56b1e1003011144g39987844u2671c6180333a7ab@mail.gmail.com> From: Hans Erik van Elburg To: Paul Kyzivat Content-Type: multipart/alternative; boundary=00163602611adbb5790480c27a86 Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: What does it mean? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 19:44:45 -0000 --00163602611adbb5790480c27a86 Content-Type: text/plain; charset=ISO-8859-1 Agree. /Hans Erik van Elburg On Mon, Mar 1, 2010 at 7:58 PM, Paul Kyzivat wrote: > IMO, if the request has a to-tag, then the UAS should treat it as an > in-dialog request not associated with any particular usage. If there is no > matching dialog, then it should return a 481 response. > > Thanks, > Paul > > > Christer Holmberg wrote: > >> Hi, >> >> If we forget what the RFCs say (or, what we believe they say :), how would >> people like the UAS to handle OPTIONS in the case when it contains a to-tag >> but the UAS currently has no state of a dialog associated with that to-tag >> value? >> >> Regards, >> >> Christer >> >> >> -----Original Message----- >> From: Brett Tate [mailto:brett@broadsoft.com] Sent: 1. maaliskuuta 2010 >> 15:35 >> To: Christer Holmberg; SIPCORE >> Subject: RE: [sipcore] OPTIONS: What does it mean? >> >> *If* the OPTIONS has a to-tag, and there is no matching dialog there are >>>> several things that might happen: >>>> - it might be rejected with a 481 >>>> - it might succeed because it is treated as if received outside a >>>> dialog >>>> >>> >> >> >> - it might cause the dialog to be recreated, and then succeed within it >>>> In the latter case, presumably the dialog would then end, because there >>>> are no dialog usages. >>>> >>> And, this will of course depend on whether the UAS still has any >>> knowledge about the dialog. >>> >>> Personally I think this alternative is rather strange, and I've never >>> heard about it being used. But, I agree that the text seems to allow it. >>> >> >> Regardless if justified by the above bullets 2 or 3, some venders do >> return 200 instead of 481. For instance if OPTIONS is sent within dialog >> associated with a currently/formerly known subscription, the UAS wouldn't >> want to return 481 (because of the potential impacts) unless it actually >> verified that the subscription is no longer known. >> >> Since it highlights why potentially relevant to get OPTIONS 481 ambiguity >> clarified, the following is snippet a 2008 thread. >> >> "Just trying to understand what rfc3261 and rfc5057 indicate or tried to >> indicate concerning 1) if OPTIONS 481 should ever be sent, and 2) the >> related impacts upon the dialog usages if OPTIONS 481 is received, 3) >> OPTIONS' ability to temporality revive/recreate the dialog per UAS' desire >> to return 200. >> >> If OPTIONS 481 really MUST be sent and SHOULD trigger subsequent >> requests/responses to terminate the dialog, I'm sure some would like to use >> it within early dialogs, subscriptions, and elsewhere." >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --00163602611adbb5790480c27a86 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Agree.

/Hans Erik van Elburg


On Mon, Mar 1, 2010 at 7:58 PM, Paul Kyz= ivat <pkyzivat@c= isco.com> wrote:
IMO, if the request has a to-tag, then the UAS should treat it as an in-dia= log request not associated with any particular usage. If there is no matchi= ng dialog, then it should return a 481 response.

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul


Christer Holmberg wrote:
Hi,

If we forget what the RFCs say (or, what we believe they say :), how would = people like the UAS to handle OPTIONS in the case when it contains a to-tag= but the UAS currently has no state of a dialog associated with that to-tag= value?

Regards,

Christer

=A0
-----Original Message-----
From: Brett Tate [mailto:brett@broadsoft.com] Sent: 1. maaliskuuta 2010 15:35
To: Christer Holmberg; SIPCORE
Subject: RE: [sipcore] OPTIONS: What does it mean?

*If* the OPTIONS has a to-tag, and there is no matching dialog there are se= veral things that might happen:
- it might be rejected with a 481
- it might succeed because it is treated as if received =A0outside a dialo= g

<snip>

- it might cause the dialog to be recreated, and then =A0succeed within it=
In the latter case, presumably the dialog would then end, because there are= no dialog usages.
And, this will of course depend on whether the UAS still has any knowledge = about the dialog.

Personally I think this alternative is rather strange, and I've never h= eard about it being used. But, I agree that the text seems to allow it.

Regardless if justified by the above bullets 2 or 3, some venders do return= 200 instead of 481. =A0For instance if OPTIONS is sent within dialog assoc= iated with a currently/formerly known subscription, the UAS wouldn't wa= nt to return 481 (because of the potential impacts) unless it actually veri= fied that the subscription is no longer known.

Since it highlights why potentially relevant to get OPTIONS 481 ambiguity c= larified, the following is snippet a 2008 thread.

"Just trying to understand what rfc3261 and rfc5057 indicate or tried = to indicate concerning 1) if OPTIONS 481 should ever be sent, and 2) the re= lated impacts upon the dialog usages if OPTIONS 481 is received, 3) OPTIONS= ' ability to temporality revive/recreate the dialog per UAS' desire= to return 200.

If OPTIONS 481 really MUST be sent and SHOULD trigger subsequent requests/r= esponses to terminate the dialog, I'm sure some would like to use it wi= thin early dialogs, subscriptions, and elsewhere."

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

--00163602611adbb5790480c27a86-- From pkyzivat@cisco.com Mon Mar 1 12:24:02 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E26928C574 for ; Mon, 1 Mar 2010 12:24:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 uNY+86unA6Js for ; Mon, 1 Mar 2010 12:24:01 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 1D2CC28C55F for ; Mon, 1 Mar 2010 12:24:01 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAC6xi0tAZnwN/2dsb2JhbACbCHOkdpdhhHsEgxc X-IronPort-AV: E=Sophos;i="4.49,562,1262563200"; d="scan'208";a="89805147" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 01 Mar 2010 20:24:00 +0000 Received: from [10.86.253.204] ([10.86.253.204]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o21KO0PH002616; Mon, 1 Mar 2010 20:24:00 GMT Message-ID: <4B8C2260.5060201@cisco.com> Date: Mon, 01 Mar 2010 15:24:00 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Brett Tate References: <4B7E9EAD.20201@cisco.com> <4B85B02E.6000500@cisco.com> <747A6506A991724FB09B129B79D5FEB61480306949@EXMBXCLUS01.citservers.local> <4B86AAEF.9000108@cisco.com> <747A6506A991724FB09B129B79D5FEB61480306CD4@EXMBXCLUS01.citservers.local> <4B86D597.6060009@cisco.com> <747A6506A991724FB09B129B79D5FEB614803AA992@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB614803AADA7@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB614803AADA7@EXMBXCLUS01.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: What does it mean? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 20:24:02 -0000 Brett, I would prefer that what to respond in this case had always been unambiguous. Given that is has been ambiguous, the question is whether its worthwhile to attempt to fix it. Practically speaking, the UAC will have to deal with UASes that were implemented long ago with the ambiguity. So it will continue to be improper to draw a conclusion about the status of the dialog from a 200 response. Thanks, Paul Brett Tate wrote: >> If we forget what the RFCs say (or, what we believe they say :), >> how would people like the UAS to handle OPTIONS in the case when >> it contains a to-tag but the UAS currently has no state of a >> dialog associated with that to-tag value? > > To avoid encouraging the use of OPTIONS to check dialog state (INVITE usage and/or SUBSCRIBE usage), I'd prefer it not be mandatory to return 481. > > >> -----Original Message----- >> From: Brett Tate [mailto:brett@broadsoft.com] >> Sent: 1. maaliskuuta 2010 15:35 >> To: Christer Holmberg; SIPCORE >> Subject: RE: [sipcore] OPTIONS: What does it mean? >> >>>> *If* the OPTIONS has a to-tag, and there is no matching dialog >> there >>>> are several things that might happen: >>>> - it might be rejected with a 481 >>>> - it might succeed because it is treated as if received >>>> outside a dialog >> >> >>>> - it might cause the dialog to be recreated, and then >>>> succeed within it >>>> In the latter case, presumably the dialog would then end, because >>>> there are no dialog usages. >>> And, this will of course depend on whether the UAS still has any >>> knowledge about the dialog. >>> >>> Personally I think this alternative is rather strange, and I've never >>> heard about it being used. But, I agree that the text seems to allow >>> it. >> Regardless if justified by the above bullets 2 or 3, some venders do >> return 200 instead of 481. For instance if OPTIONS is sent within >> dialog associated with a currently/formerly known subscription, the UAS >> wouldn't want to return 481 (because of the potential impacts) unless >> it actually verified that the subscription is no longer known. >> >> Since it highlights why potentially relevant to get OPTIONS 481 >> ambiguity clarified, the following is snippet a 2008 thread. >> >> "Just trying to understand what rfc3261 and rfc5057 indicate or tried >> to indicate concerning 1) if OPTIONS 481 should ever be sent, and 2) >> the related impacts upon the dialog usages if OPTIONS 481 is received, >> 3) OPTIONS' ability to temporality revive/recreate the dialog per UAS' >> desire to return 200. >> >> If OPTIONS 481 really MUST be sent and SHOULD trigger subsequent >> requests/responses to terminate the dialog, I'm sure some would like to >> use it within early dialogs, subscriptions, and elsewhere." > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Mon Mar 1 13:53:54 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C4EF28C1D2 for ; Mon, 1 Mar 2010 13:53:54 -0800 (PST) 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 DpIgIxktRgOY for ; Mon, 1 Mar 2010 13:53:53 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 22C6128C1BE for ; Mon, 1 Mar 2010 13:53:52 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-c9-4b8c3770c00b Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id CB.86.31641.0773C8B4; Mon, 1 Mar 2010 22:53:52 +0100 (CET) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0256.eemea.ericsson.se (153.88.115.96) with Microsoft SMTP Server (TLS) id 8.1.375.2; Mon, 1 Mar 2010 22:53:51 +0100 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.139]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Mon, 1 Mar 2010 22:53:51 +0100 From: Christer Holmberg To: Paul Kyzivat , Brett Tate Date: Mon, 1 Mar 2010 22:50:02 +0100 Thread-Topic: [sipcore] OPTIONS: What does it mean? Thread-Index: Acq5fSLe87EgZLDaSXO2pGYEMZGi5AADAJOt Message-ID: References: <4B7E9EAD.20201@cisco.com> <4B85B02E.6000500@cisco.com> <747A6506A991724FB09B129B79D5FEB61480306949@EXMBXCLUS01.citservers.local> <4B86AAEF.9000108@cisco.com> <747A6506A991724FB09B129B79D5FEB61480306CD4@EXMBXCLUS01.citservers.local> <4B86D597.6060009@cisco.com> <747A6506A991724FB09B129B79D5FEB614803AA992@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB614803AADA7@EXMBXCLUS01.citservers.local>, <4B8C2260.5060201@cisco.com> In-Reply-To: <4B8C2260.5060201@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: What does it mean? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 21:53:54 -0000 Hi, >I would prefer that what to respond in this case had always been >unambiguous. > >Given that is has been ambiguous, the question is whether its worthwhile >to attempt to fix it. Practically speaking, the UAC will have to deal >with UASes that were implemented long ago with the ambiguity. So it will >continue to be improper to draw a conclusion about the status of the >dialog from a 200 response. I agree. But, just because it has been ambiguos, it doesn't mean we can cla= rify how it should be in future. Regards, Christer Brett Tate wrote: >> If we forget what the RFCs say (or, what we believe they say :), >> how would people like the UAS to handle OPTIONS in the case when >> it contains a to-tag but the UAS currently has no state of a >> dialog associated with that to-tag value? > > To avoid encouraging the use of OPTIONS to check dialog state (INVITE usa= ge and/or SUBSCRIBE usage), I'd prefer it not be mandatory to return 481. > > >> -----Original Message----- >> From: Brett Tate [mailto:brett@broadsoft.com] >> Sent: 1. maaliskuuta 2010 15:35 >> To: Christer Holmberg; SIPCORE >> Subject: RE: [sipcore] OPTIONS: What does it mean? >> >>>> *If* the OPTIONS has a to-tag, and there is no matching dialog >> there >>>> are several things that might happen: >>>> - it might be rejected with a 481 >>>> - it might succeed because it is treated as if received >>>> outside a dialog >> >> >>>> - it might cause the dialog to be recreated, and then >>>> succeed within it >>>> In the latter case, presumably the dialog would then end, because >>>> there are no dialog usages. >>> And, this will of course depend on whether the UAS still has any >>> knowledge about the dialog. >>> >>> Personally I think this alternative is rather strange, and I've never >>> heard about it being used. But, I agree that the text seems to allow >>> it. >> Regardless if justified by the above bullets 2 or 3, some venders do >> return 200 instead of 481. For instance if OPTIONS is sent within >> dialog associated with a currently/formerly known subscription, the UAS >> wouldn't want to return 481 (because of the potential impacts) unless >> it actually verified that the subscription is no longer known. >> >> Since it highlights why potentially relevant to get OPTIONS 481 >> ambiguity clarified, the following is snippet a 2008 thread. >> >> "Just trying to understand what rfc3261 and rfc5057 indicate or tried >> to indicate concerning 1) if OPTIONS 481 should ever be sent, and 2) >> the related impacts upon the dialog usages if OPTIONS 481 is received, >> 3) OPTIONS' ability to temporality revive/recreate the dialog per UAS' >> desire to return 200. >> >> If OPTIONS 481 really MUST be sent and SHOULD trigger subsequent >> requests/responses to terminate the dialog, I'm sure some would like to >> use it within early dialogs, subscriptions, and elsewhere." > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >= From christer.holmberg@ericsson.com Mon Mar 1 14:09:21 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00D6228C5AF for ; Mon, 1 Mar 2010 14:09:21 -0800 (PST) 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=[AWL=0.000, 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 E4jU6mvuuxZi for ; Mon, 1 Mar 2010 14:09:20 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id E0A1028C5DB for ; Mon, 1 Mar 2010 14:09:19 -0800 (PST) X-AuditID: c1b4fb3d-b7c72ae00000040e-6a-4b8c3b0e737e Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 16.BF.01038.E0B3C8B4; Mon, 1 Mar 2010 23:09:19 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.139]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Mon, 1 Mar 2010 23:09:18 +0100 From: Christer Holmberg To: SIPCORE Date: Mon, 1 Mar 2010 23:09:18 +0100 Thread-Topic: OPTIONS 3xx: To fork or not to fork? Thread-Index: AQHKuYvWT1hsnnkftEOcLIqApxZ2Gg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 22:09:21 -0000 Hi, Moving forward the the OPTIONS 3xx solution, one issue (raised by Paul, I t= hink) is how a registrar, responsible for an AOR, makes a decission whether= to send a 3xx response to a received OPTIONS request addressed for that AO= R, or whether to fork the request towards the registered UAS(s). Alternative 1: The decission is based on local policy (by operators and/= or other SDOs) Alternative 2: The registrar always sends a 3xx response. Alternative 3: The decission is based on some information contained in t= he OPTIONS request. Again, we cannot do very much about existing deployments, but at least we w= ould be able to provide clear guidelines for future implementations/specifi= cations. Regards, Christer NOTE: The issue only applies when the request is addressed to an AOR, and r= eceived by a registrar responseible for that AOR. In all other cases I assu= me the request will be forwarded by the proxy.= From kpfleming@digium.com Mon Mar 1 14:40:49 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 554AD28C14D for ; Mon, 1 Mar 2010 14:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 avdE2o-1Vw14 for ; Mon, 1 Mar 2010 14:40:48 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id 52A3B3A871C for ; Mon, 1 Mar 2010 14:40:48 -0800 (PST) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1NmEIA-00025Q-2d; Mon, 01 Mar 2010 16:40:46 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 241DED8005; Mon, 1 Mar 2010 16:40:46 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiWyF9VNcSAq; Mon, 1 Mar 2010 16:40:45 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id CB1ACD8003; Mon, 1 Mar 2010 16:40:45 -0600 (CST) Message-ID: <4B8C426D.3090702@digium.com> Date: Mon, 01 Mar 2010 16:40:45 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Paul Kyzivat References: <4B7E9EAD.20201@cisco.com> <4B85B02E.6000500@cisco.com> <747A6506A991724FB09B129B79D5FEB61480306949@EXMBXCLUS01.citservers.local> <4B86AAEF.9000108@cisco.com> <747A6506A991724FB09B129B79D5FEB61480306CD4@EXMBXCLUS01.citservers.local> <4B86D597.6060009@cisco.com> <747A6506A991724FB09B129B79D5FEB614803AA992@EXMBXCLUS01.citservers.local> <4B8C0E68.3050802@cisco.com> In-Reply-To: <4B8C0E68.3050802@cisco.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: What does it mean? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 22:40:49 -0000 Paul Kyzivat wrote: > IMO, if the request has a to-tag, then the UAS should treat it as an > in-dialog request not associated with any particular usage. If there is > no matching dialog, then it should return a 481 response. +1 (based entirely on my desire to not have to special-case OPTIONS when deciding whether a request is to be treated as in-dialog or not) -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org From adam@nostrum.com Mon Mar 1 15:06:26 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87D313A8BA2 for ; Mon, 1 Mar 2010 15:06:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] 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 C5slu0TQfkvO for ; Mon, 1 Mar 2010 15:06:25 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 22F1528C1B7 for ; Mon, 1 Mar 2010 15:06:24 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o21N6IPZ034422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Mar 2010 17:06:18 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B8C486A.5060400@nostrum.com> Date: Mon, 01 Mar 2010 17:06:18 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Christer Holmberg References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 23:06:26 -0000 I would like to see #2 as a BCP. Not just for OPTIONS, but for all cases that a proxy/registrar might fork an inbound request. /a On 3/1/10 16:09, Mar 1, Christer Holmberg wrote: > Hi, > > Moving forward the the OPTIONS 3xx solution, one issue (raised by Paul, I think) is how a registrar, responsible for an AOR, makes a decission whether to send a 3xx response to a received OPTIONS request addressed for that AOR, or whether to fork the request towards the registered UAS(s). > > Alternative 1: The decission is based on local policy (by operators and/or other SDOs) > > Alternative 2: The registrar always sends a 3xx response. > > Alternative 3: The decission is based on some information contained in the OPTIONS request. > > Again, we cannot do very much about existing deployments, but at least we would be able to provide clear guidelines for future implementations/specifications. > > Regards, > > Christer > > NOTE: The issue only applies when the request is addressed to an AOR, and received by a registrar responseible for that AOR. In all other cases I assume the request will be forwarded by the proxy. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@cisco.com Mon Mar 1 15:08:17 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2888028C1F2 for ; Mon, 1 Mar 2010 15:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 lj1xomf0trkP for ; Mon, 1 Mar 2010 15:08:16 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 5FD0C3A85A1 for ; Mon, 1 Mar 2010 15:08:16 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABbYi0tAZnwM/2dsb2JhbACbB3OlQZd6hHsEgxc X-IronPort-AV: E=Sophos;i="4.49,563,1262563200"; d="scan'208";a="214785315" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by sj-iport-3.cisco.com with ESMTP; 01 Mar 2010 23:08:16 +0000 Received: from [10.86.253.204] ([10.86.253.204]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o21N8GsH001190; Mon, 1 Mar 2010 23:08:16 GMT Message-ID: <4B8C48E1.8090901@cisco.com> Date: Mon, 01 Mar 2010 18:08:17 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Mar 2010 23:08:17 -0000 Unless we make some radical change in philosophy, the "proxy" has ultimate discretion here, though I think we could produce a BCP on it. There is already a header that can be used to indicate your preference: Request-Disposition: proxy or Request-Disposition: redirect But it is still up to the proxy to honor it or not. My recommendation for a BCP would be: - honor Request-Disposition if present. Else - return 3xx if there is more than one contact - either 3xx or forward is ok if there is only one contact This has to be discretionary because some may not want to return the registered contact to the caller. (Certainly *some* contact will have to be returned to the caller for an INVITE to succeed, but it might not be the registered contact. It might be a temp gruu, or something from an SBC, ...) And of course no contact has to be returned if the called UA rejects the request. And none need be returned for an OPTIONS either. Thanks, Paul Christer Holmberg wrote: > Hi, > > Moving forward the the OPTIONS 3xx solution, one issue (raised by Paul, I think) is how a registrar, responsible for an AOR, makes a decission whether to send a 3xx response to a received OPTIONS request addressed for that AOR, or whether to fork the request towards the registered UAS(s). > > Alternative 1: The decission is based on local policy (by operators and/or other SDOs) > > Alternative 2: The registrar always sends a 3xx response. > > Alternative 3: The decission is based on some information contained in the OPTIONS request. > > Again, we cannot do very much about existing deployments, but at least we would be able to provide clear guidelines for future implementations/specifications. > > Regards, > > Christer > > NOTE: The issue only applies when the request is addressed to an AOR, and received by a registrar responseible for that AOR. In all other cases I assume the request will be forwarded by the proxy. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From adam@nostrum.com Mon Mar 1 16:08:50 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52F4528C608 for ; Mon, 1 Mar 2010 16:08:50 -0800 (PST) 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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 RFIvGN+pxyz2 for ; Mon, 1 Mar 2010 16:08:49 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 0CDF628C0E3 for ; Mon, 1 Mar 2010 16:08:47 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o2208jGx038954 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 1 Mar 2010 18:08:45 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B8C570D.8000307@nostrum.com> Date: Mon, 01 Mar 2010 18:08:45 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: "Elwell, John" References: <20100219200001.9598F28C0F8@core3.amsl.com> <4B7EF00F.9060909@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000902040300090401010403" Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: "sipcore@ietf.org" Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc3265bis-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 00:08:50 -0000 This is a multi-part message in MIME format. --------------000902040300090401010403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks. This will be fixed in the -02 version. /a On 2/22/10 04:27, Feb 22, Elwell, John wrote: > Adam, > The newly added reference RFC 4528 is wrong - should be RFC 4538. > John > > ------------------------------------------------------------------------ > *From:* sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] > *On Behalf Of *Adam Roach > *Sent:* 19 February 2010 20:10 > *To:* sipcore@ietf.org > *Subject:* Re: [sipcore] I-D > Action:draft-ietf-sipcore-rfc3265bis-01.txt > > [as participant] > > There are only a handful of changes in this version of the > document, none of them pertaining to the open issues. I will be > posting the open issues to the mailing list ahead of the Anaheim > meeting to hopefully get closure on them, so that we don't need to > spend much time discussing them at the face-to-face meeting. > > As always, comments are welcome -- especially on the identified > open issues. > > /a > > On 2/19/10 2:00 PM, Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. >> >> >> Title : SIP-Specific Event Notification >> Author(s) : A. Roach >> Filename : draft-ietf-sipcore-rfc3265bis-01.txt >> Pages : 52 >> Date : 2010-02-19 >> >> This document describes an extension to the Session Initiation >> Protocol (SIP). The purpose of this extension is to provide an >> extensible framework by which SIP nodes can request notification from >> remote nodes indicating that certain events have occurred. >> >> Note that the event notification mechanisms defined herein are NOT >> intended to be a general-purpose infrastructure for all classes of >> event subscription and notification. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc3265bis-01.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > --------------000902040300090401010403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks. This will be fixed in the -02 version.

/a

On 2/22/10 04:27, Feb 22, Elwell, John wrote:
Adam,
 
The newly added reference RFC 4528 is wrong - should be RFC 4538.
 
John
 

From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach
Sent: 19 February 2010 20:10
To: sipcore@ietf.org
Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc3265bis-01.txt

[as participant]

There are only a handful of changes in this version of the document, none of them pertaining to the open issues. I will be posting the open issues to the mailing list ahead of the Anaheim meeting to hopefully get closure on them, so that we don't need to spend much time discussing them at the face-to-face meeting.

As always, comments are welcome -- especially on the identified open issues.

/a

On 2/19/10 2:00 PM, Internet-Drafts@ietf.org wrote: 
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF.


	Title           : SIP-Specific Event Notification
	Author(s)       : A. Roach
	Filename        : draft-ietf-sipcore-rfc3265bis-01.txt
	Pages           : 52
	Date            : 2010-02-19

This document describes an extension to the Session Initiation
Protocol (SIP).  The purpose of this extension is to provide an
extensible framework by which SIP nodes can request notification from
remote nodes indicating that certain events have occurred.

Note that the event notification mechanisms defined herein are NOT
intended to be a general-purpose infrastructure for all classes of
event subscription and notification.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc3265bis-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
  

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore


--------------000902040300090401010403-- From christer.holmberg@ericsson.com Mon Mar 1 21:52:12 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C9D828C6DA for ; Mon, 1 Mar 2010 21:52:12 -0800 (PST) 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 EgMhBOzy1ti9 for ; Mon, 1 Mar 2010 21:52:11 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 39A393A8C38 for ; Mon, 1 Mar 2010 21:52:11 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-33-4b8ca78973b9 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id BB.44.31641.987AC8B4; Tue, 2 Mar 2010 06:52:10 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.139]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 2 Mar 2010 06:52:09 +0100 From: Christer Holmberg To: Adam Roach Date: Tue, 2 Mar 2010 06:52:07 +0100 Thread-Topic: [sipcore] OPTIONS 3xx: To fork or not to fork? Thread-Index: Acq5k891EcV0ZuxwS6GppP52VsGr/QAOIHDg Message-ID: References: <4B8C486A.5060400@nostrum.com> In-Reply-To: <4B8C486A.5060400@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 05:52:12 -0000 Hi,=20 >I would like to see #2 as a BCP. Not just for OPTIONS, but for all cases t= hat a proxy/registrar might fork an inbound request. Just to clarify, I guess you don't include dialog establsihment requests (I= NVITE, SUBSCRIBE)? They should always be forwarded/forked even if addressed= to the AOR for which the registrar is responseible. Regards, Christer > On 3/1/10 16:09, Mar 1, Christer Holmberg wrote: > > Hi, > > > > Moving forward the the OPTIONS 3xx solution, one issue=20 > (raised by Paul, I think) is how a registrar, responsible for=20 > an AOR, makes a decission whether to send a 3xx response to a=20 > received OPTIONS request addressed for that AOR, or whether=20 > to fork the request towards the registered UAS(s). > > > > Alternative 1: The decission is based on local policy=20 > (by operators and/or other SDOs) > > > > Alternative 2: The registrar always sends a 3xx response. > > > > Alternative 3: The decission is based on some=20 > information contained in the OPTIONS request. > > > > Again, we cannot do very much about existing deployments,=20 > but at least we would be able to provide clear guidelines for=20 > future implementations/specifications. > > > > Regards, > > > > Christer > > > > NOTE: The issue only applies when the request is addressed=20 > to an AOR, and received by a registrar responseible for that=20 > AOR. In all other cases I assume the request will be=20 > forwarded by the proxy. > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > =20 >=20 > = From christer.holmberg@ericsson.com Mon Mar 1 21:57:34 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEDD13A8C3E for ; Mon, 1 Mar 2010 21:57:34 -0800 (PST) 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=[AWL=0.000, 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 qT4gbhI6F0VI for ; Mon, 1 Mar 2010 21:57:34 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id A88313A6802 for ; Mon, 1 Mar 2010 21:57:33 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-73-4b8ca8cd0686 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 8E.B4.31641.DC8AC8B4; Tue, 2 Mar 2010 06:57:33 +0100 (CET) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 2 Mar 2010 06:57:32 +0100 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.139]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Tue, 2 Mar 2010 06:57:32 +0100 From: Christer Holmberg To: Paul Kyzivat Date: Tue, 2 Mar 2010 06:57:31 +0100 Thread-Topic: [sipcore] OPTIONS 3xx: To fork or not to fork? Thread-Index: Acq5lBVwRdj4ADYWTySdEDcoEge2xAAOHXSg Message-ID: References: <4B8C48E1.8090901@cisco.com> In-Reply-To: <4B8C48E1.8090901@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 05:57:35 -0000 Hi,=20 >Unless we make some radical change in philosophy, the "proxy"=20 >has ultimate discretion here, though I think we could produce=20 >a BCP on it. >=20 >There is already a header that can be used to indicate your=20 >preference: >=20 >Request-Disposition: proxy >or >Request-Disposition: redirect >=20 >But it is still up to the proxy to honor it or not. True. But, having clear guidelines will at least ensure (hopefully) that al= l have a common understanding on how to do it - whether they choose to impl= ement/honor it or not. >My recommendation for a BCP would be: >- honor Request-Disposition if present. Else >- return 3xx if there is more than one contact >- either 3xx or forward is ok if there is only one contact >=20 >This has to be discretionary because some may not want to=20 >return the registered contact to the caller. (Certainly=20 >*some* contact will have to be returned to the caller for an=20 >INVITE to succeed, but it might not be the registered=20 >contact. It might be a temp gruu, or something from an SBC,=20 >...) > >And of course no contact has to be returned if the=20 >called UA rejects the request. And none need be returned for=20 >an OPTIONS either. If the proxy does not want to return a contact (other than its own perhaps)= , I guess it should not send a 3xx in the first place. In that case a 200 O= K might be better? Regards, Christer > Christer Holmberg wrote: > > Hi, > >=20 > > Moving forward the the OPTIONS 3xx solution, one issue=20 > (raised by Paul, I think) is how a registrar, responsible for=20 > an AOR, makes a decission whether to send a 3xx response to a=20 > received OPTIONS request addressed for that AOR, or whether=20 > to fork the request towards the registered UAS(s). > >=20 > > Alternative 1: The decission is based on local policy=20 > (by operators and/or other SDOs) > >=20 > > Alternative 2: The registrar always sends a 3xx response. > >=20 > > Alternative 3: The decission is based on some=20 > information contained in the OPTIONS request. > >=20 > > Again, we cannot do very much about existing deployments,=20 > but at least we would be able to provide clear guidelines for=20 > future implementations/specifications. > >=20 > > Regards, > >=20 > > Christer > >=20 > > NOTE: The issue only applies when the request is addressed=20 > to an AOR, and received by a registrar responseible for that=20 > AOR. In all other cases I assume the request will be=20 > forwarded by the proxy. > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 > = From gonzalo.camarillo@ericsson.com Tue Mar 2 00:16:23 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDB383A87BF for ; Tue, 2 Mar 2010 00:16:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 Au5P1Ba+rsel for ; Tue, 2 Mar 2010 00:16:22 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 67D653A8499 for ; Tue, 2 Mar 2010 00:16:21 -0800 (PST) X-AuditID: c1b4fb3d-b7c72ae00000040e-32-4b8cc954af97 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 72.9E.01038.459CC8B4; Tue, 2 Mar 2010 09:16:20 +0100 (CET) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 09:16:20 +0100 Received: from [131.160.126.169] ([131.160.126.169]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 09:16:19 +0100 Message-ID: <4B8CC953.9020205@ericsson.com> Date: Tue, 02 Mar 2010 10:16:19 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <4B7EBF91.8020506@nostrum.com> <4B8284CC.8050800@cisco.com> <4B84A181.90008@nostrum.com> In-Reply-To: <4B84A181.90008@nostrum.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Mar 2010 08:16:19.0637 (UTC) FILETIME=[A342FE50:01CAB9E0] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] SIP Table 2 (was Re: 3265bis and Call-Info) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 08:16:23 -0000 Hi, just to stress Adam's point, we need to understand if doing this is worth the effort. If this is causing interoperability problems and confusion about implementers, then we should go ahead fix it. If we are doing this just for completeness so that our table 2 is up to date, then we'd better employ our cycles on something else. Note that I am not arguing one way or the other. My point is that given the amount of cycles we have available (clearly a limited resource) we need to be careful when choosing how to use them. Cheers, Gonzalo Adam Roach wrote: > Re-sending with a new subject line, since this has almost nothing to do > with 3265bis any longer. Sorry for the additional noise. > > [as a participant] > > On 2/22/10 07:21, Feb 22, Paul Kyzivat wrote: >> >> >> Dean Willis wrote: >> >>>> We had this discussion a while ago, and it may be good to start it >>>> again. I think at least Dean mentioned abandoning Table 2. I talked >>>> about having a website instead, which would be easier to keep up to >>>> date, but I think the IETF proceures didn't allow that. >>> >>> Right. for things that one might use a website for, we have IANA >>> registries. >>> >>> One could replace Table 2 with a registry, and have new RFCs update >>> that registry. >> >> I support this approach. > > Okay. If we go down this path -- and I think it's a little bit crazy -- > then we'll need to ferret out the correct values for the current header > fields and methods to set up the initial registry. > > Because of the haphazard way we've handled this, the table contains > substantial gaps. I wrote a script to parse out all the formal Table 2 > expansions from the RFCs that define SIP header fields and SIP methods, > and merge them into a single view of what has been defined to date. With > the caveat that this is a lot of data, and something might have been > missed, here's what it looks like: > > Header Field Where Proxy ACK BYE CAN INF INV MES NOT OPT > PRA PUB REF REG SUB UPD > Accept 2xx > - - - ? o - - m* - - - o - o > Accept 415 > - c - ? c m* o c c m* c c o c > Accept R > - o - o o - o m* o o o o o o > Accept-Contact R ar o o o o o o o o o ? o - o o > Accept-Encoding 2xx > - - - ? o - - m* - - - o - o > Accept-Encoding 415 > - c - ? c m* o c c m* c c o c > Accept-Encoding R > - o - o o - o o o o o o o o > Accept-Language 2xx > - - - ? o - - m* - - - o - o > Accept-Language 415 > - c - ? c m* o c c m* c c o c > Accept-Language R > - o - o o - o o o o o o o o > Accept-Resource-Priority 200 amdr - o o o o o o o o > o o o o o > Accept-Resource-Priority 417 amdr - o o o o o o o o > o o o o o > Alert-Info 180 > - - - ? o - - - - ? ? - - ? > Alert-Info R > - - - ? o - - - - - - - - - > Alert-Info r > ? ? ? ? ? ? ? ? ? - - ? ? - > Allow 2xx > - o - ? m* o o m* o ? ? o o o > Allow 405 > - m - o m m m m m m m m m m > Allow R > - o - ? o o o o o o ? o o o > Allow r > - o - ? o o o o o o ? o o o > Allow-Events 2xx > - o - ? o ? o o o ? ? o o ? > Allow-Events 489 > - - - ? - ? m - - m ? - m ? > Allow-Events R > o o - ? o ? o o o o ? o o - > Allow-Events r > ? ? ? ? ? ? ? ? ? ? ? ? ? - > Answer-Mode ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > Authentication-Info 2xx > - o - ? o o o o o o o o o o > Authorization R > o o o o o o o o o o o o o o > Call-ID c r m m m m m m m m m m m m m m > Call-Info R ar - - - ? o o ? o - o - o ? o > Call-Info r ar - - - ? o o ? o - o - o ? o > Contact 1xx > - - - - o - o - - - - - o o > Contact 2xx > - - - - m - o o - - m o m m > Contact 3xx > - o - - o o m o o o ? o m o > Contact 485 > - o - - o o o o o o ? o o o > Contact R > o - - o m - m o - - m o m m > Content-Disposition R > o o - ? o o o o o o o o o o > Content-Disposition r > o o - ? o o o o o o o o o o > Content-Encoding R > o o - o o o o o o o o o o o > Content-Encoding r > o o - o o o o o o o o o o o > Content-Language R > o o - ? o o o o o o o o o o > Content-Language r > o o - ? o o o o o o o o o o > Content-Length R ar t t t o t t t t t t o t t t > Content-Length r ar t t t o t t t t t t o t t t > Content-Type R > * * - * * * * * * * * * * * > Content-Type r > * * - * * * * * * * * * * * > CSeq c r m m m m m m m m m m m m m m > Date R a o o o o o o o o o o o o o o > Date r a o o o o o o o o o o o o o o > Encryption ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > Error-Info 300-699 a - o o ? o o o o o o ? o o o > Event R > - - - ? - ? m - - m ? - m - > Event r > ? ? ? ? ? ? ? ? ? ? ? ? ? - > Expires R > - - - o o o - - - o o o o - > Expires r > - - - o o o - - - o ? o o - > Flow-Timer ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > From c r m m m m m m m m m m m m m m > History-Info R amdr - - - - o o o o - o o o o - > History-Info r amdr - - - - o o o o - o o o o - > Identity R a o o - ? o ? ? o ? ? ? o ? ? > Identity-Info R a o o - ? o ? ? o ? ? ? o ? ? > In-Reply-To R > - - - ? o o - - - - - - - - > In-Reply-To r > ? ? ? ? ? ? ? ? ? ? - ? ? - > Join R > - - - - o - - - - - - - - - > Max-Breadth ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > Max-Forwards R amr m m m o m m m m m m m m m m > MIME-Version R > o o - ? o ? o o o o o o o o > MIME-Version r > o o - ? o ? o o o o o o o o > Min-Expires 423 > - - - ? - ? - - - m ? m m ? > Min-Expires R > ? ? ? ? ? ? ? ? ? ? - ? ? - > Min-Expires r > ? ? ? ? ? ? ? ? ? ? - ? ? - > Min-SE 422 > - - - ? m ? - - - ? ? - - m > Min-SE R amr - - - ? o ? - - - ? ? - - o > Organization R ar - - - o o o - o - o o o o o > Organization r ar - - - o o o - o - o o o o o > P-Access-Network-Info R dr - o - o o o o o o ? o o o o > P-Access-Network-Info r dr - o - o o o o o o ? o o o o > P-Answer-State 18x ar - - - ? o ? ? - ? ? ? - - ? > P-Answer-State 2xx ar - - - ? o ? ? - ? ? ? - - ? > P-Asserted-Identity R adr - o - ? o ? ? o ? ? ? - ? ? > P-Asserted-Identity r adr - o - ? o ? ? o ? ? ? - ? ? > P-Associated-URI 2xx > - - - ? - ? ? - ? ? ? o ? ? > P-Called-Party-ID R amr - - - - o o - o - ? o - o - > P-Charging-Function-Addresses ? ? ? ? ? ? ? ? ? ? ? > ? ? ? ? ? > P-Charging-Vector R admr - o - o o o o o o ? o o o o > P-Charging-Vector r admr - o - o o o o o o ? o o o o > P-DCS-Trace-Party-ID R dmr - - - ? o ? ? - ? - ? - ? ? > P-DCS-OSPS R dr - - - ? o ? ? - ? - ? - ? ? > P-DCS-Billing-Info R admr - - - ? o ? ? - ? - ? - ? ? > P-DCS-Billing-Info r admr - - - ? o ? ? - ? - ? - ? ? > P-DCS-LAES R adr - - - ? o ? ? - ? - ? - ? ? > P-DCS-LAES r adr - - - ? o ? ? - ? - ? - ? ? > P-DCS-Redirect R adr - - - ? o ? ? - ? - ? - ? ? > P-DCS-Redirect r adr - - - ? o ? ? - ? - ? - ? ? > P-Early-Media 18x amr - - - ? o ? ? - - ? ? - ? - > P-Early-Media 2xx amr - - - ? - ? ? - o ? ? - ? o > P-Early-Media R amr - - - ? o ? ? - o ? ? - ? o > P-Media-Authorization 101-199 ad - - - ? o ? ? - ? ? > ? - ? ? > P-Media-Authorization 2xx ad - - - - o ? - - o ? ? - - o > P-Media-Authorization R ad o - - - o ? - - o ? ? - - o > P-Preferred-Identity R adr - o - ? o ? ? o ? ? ? - ? ? > P-Preferred-Identity r adr - o - ? o ? ? o ? ? ? - ? ? > P-Profile-Key ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > P-Refused-URI-List ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > P-Served-User ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > P-User-Database ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > P-Visited-Network-ID R ad - - - - o o - o - ? o o o - > Path 2xx - - - - ? - ? ? - ? ? ? o ? ? > Path R ar - - - ? - ? ? - ? ? ? o ? ? > Permission-Missing ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > Priority R ar - - - o o o - - - o - - o - > Priority r > ? ? ? ? ? ? ? ? ? ? ? ? ? - > Priv-Answer-Mode ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > Privacy R amrd o o o ? o o o o ? ? ? o o o > Privacy r amrd o o o ? o o o o ? ? ? o o o > Proxy-Authenticate 401 ar - o o ? o o ? o o o o o ? o > Proxy-Authenticate 407 ar - m - o m m m m m m m m m m > Proxy-Authorization R dr o o - o o o o o o o o o o o > RAck R > - - - ? - ? - - m ? ? - - - > Reason ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > Record-Route 18x mr - o o ? o ? ? o o ? o - ? o > Record-Route 2xx mr - o o o o ? o o o ? o - o o > Record-Route R ar o o o o o - o o o - o - o o > Record-Route r ar ? ? ? ? ? - ? ? ? - ? ? ? ? > Refer-Sub 2xx > - - - - - - - - - - o - - - > Refer-Sub R > - - - - - - - - - - o - - - > Refer-To R > - - - ? - ? ? - ? ? ? - ? ? > Referred-By R > - o - ? o ? ? o ? ? ? o ? ? > Reject-Contact R ar o o o o o o o o o ? o - o o > Replaces R > - - - - o - - - - - - - - - > Reply-To R > - - - ? o o - - - - - - - - > Reply-To r > - - - ? o o - - - - - - - - > Request-Disposition R ar o o o o o o o o o ? o o o o > Require R ar - c - o c c o c c o c c o c > Require r ar - c - ? c c o c c o c c o c > Resource-Priority R amdr o o o o o o o o o o o o o o > Response-Key ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > Retry-After 404 > - o o o o ? o o o o o o o o > Retry-After 413 > - o o ? o ? o o o o o o o o > Retry-After 480 > - o o o o ? o o o o o o o o > Retry-After 486 > - o o o o ? o o o o o o o o > Retry-After 4xx > ? ? ? ? ? o ? ? ? ? ? ? ? ? > Route R adr c c c o c o c c c c c c c c > RSeq 1xx > - - - ? o ? o - - ? ? - o ? > RSeq R > ? ? ? ? ? ? ? ? ? ? ? ? ? - > RSeq r > ? ? ? ? ? ? ? ? ? ? ? ? ? - > Security-Client R ard - o - ? o o o o ? ? ? o o o > Security-Server 421 > - o - ? o o o o ? ? ? o o o > Security-Server 494 > - o - ? o o o o ? ? ? o o o > Security-Verify R ard - o - ? o o o o ? ? ? o o o > Server r > - o o o o o o o o o o o o o > Service-Route 2xx ar - - - ? - ? ? - - ? ? o ? ? > Session-Expires 2xx ar - - - ? o ? - - - ? ? - - o > Session-Expires R amr - - - ? o ? - - - ? ? - - o > SIP-ETag 2xx > - - - - - - - - - m - - - - > SIP-If-Match R > - - - - - - - - - o - - - - > Subject R > - - - o o o - - - o - - - - > Subject r > ? ? ? ? ? ? ? ? ? ? ? ? ? - > Subscription-State R > - - - ? - ? m - - ? ? - - - > Subscription-State r > ? ? ? ? ? ? ? ? ? ? ? ? ? - > Supported 2xx > - o o ? m* ? o m* o o o o o o > Supported R > - o o ? m* ? o o o o o o o o > Target-Dialog R - - - - - o - - - - - o - o - > Timestamp R > o o o o o o o o o o o o o o > Timestamp r > o o o o o o o o o o o o o o > To c r m m m m m m m m m m m m m m > Trigger-Consent ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > Unsupported 420 > - m - o m o o m m o o m o m > User-Agent R > o o o o o o o o o o o o o o > User-Agent r > o o o o o o o o o o o o o o > Via R amr m m m ? m m ? m ? m ? m ? m > Via rc dr m m m ? m m ? m ? m ? m ? m > Warning r > - o o o o o o o o o o o o o > WWW-Authenticate 401 ar - m - o m m m m m m m m m m > WWW-Authenticate 407 ar - o - ? o o ? o ? o o o ? o > > > > See all those question marks? Someone needs to come up with actual > values for each of those cells. Some are going to be pretty easy to > answer; others will require substantial research and/or debate. > > It seems like a lot of effort to me. Are we certain the return on our > investment of time will be worth it? > > /a > From christer.holmberg@ericsson.com Tue Mar 2 00:28:34 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75FA628C114 for ; Tue, 2 Mar 2010 00:28:34 -0800 (PST) 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=[AWL=0.000, 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 qB5SIGe8Ruvf for ; Tue, 2 Mar 2010 00:28:32 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 9F3E53A89A6 for ; Tue, 2 Mar 2010 00:28:31 -0800 (PST) X-AuditID: c1b4fb3d-b7c72ae00000040e-60-4b8ccc2f683f Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 23.90.01038.F2CCC8B4; Tue, 2 Mar 2010 09:28:31 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.139]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 2 Mar 2010 09:28:30 +0100 From: Christer Holmberg To: Gonzalo Camarillo , Adam Roach Date: Tue, 2 Mar 2010 09:28:29 +0100 Thread-Topic: [sipcore] SIP Table 2 (was Re: 3265bis and Call-Info) Thread-Index: Acq54KvYHKCuhT83S32NqlRjaMQZ8AAAR1rg Message-ID: References: <4B7EBF91.8020506@nostrum.com> <4B8284CC.8050800@cisco.com> <4B84A181.90008@nostrum.com> <4B8CC953.9020205@ericsson.com> In-Reply-To: <4B8CC953.9020205@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] SIP Table 2 (was Re: 3265bis and Call-Info) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 08:28:34 -0000 Hi, I agree that we should be careful, and try to ensure that we have the neede= d commitment from people. But, note that it is not only about interoperability. If we do not do this,= I still think we need some guideline on how to deal with the header/method= tables whenever we define a new method and/or header field. Do we list all= methods/headers that have currently been specified at that moment, or? Regards, Christer > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > Sent: 2. maaliskuuta 2010 10:16 > To: Adam Roach > Cc: SIPCORE > Subject: Re: [sipcore] SIP Table 2 (was Re: 3265bis and Call-Info) > > Hi, > > just to stress Adam's point, we need to understand if doing > this is worth the effort. If this is causing interoperability > problems and confusion about implementers, then we should go > ahead fix it. If we are doing this just for completeness so > that our table 2 is up to date, then we'd better employ our > cycles on something else. > > Note that I am not arguing one way or the other. My point is > that given the amount of cycles we have available (clearly a > limited resource) we need to be careful when choosing how to use them. > > Cheers, > > Gonzalo > > > Adam Roach wrote: > > Re-sending with a new subject line, since this has almost > nothing to > > do with 3265bis any longer. Sorry for the additional noise. > > > > [as a participant] > > > > On 2/22/10 07:21, Feb 22, Paul Kyzivat wrote: > >> > >> > >> Dean Willis wrote: > >> > >>>> We had this discussion a while ago, and it may be good > to start it > >>>> again. I think at least Dean mentioned abandoning Table > 2. I talked > >>>> about having a website instead, which would be easier to > keep up to > >>>> date, but I think the IETF proceures didn't allow that. > >>> > >>> Right. for things that one might use a website for, we have IANA > >>> registries. > >>> > >>> One could replace Table 2 with a registry, and have new > RFCs update > >>> that registry. > >> > >> I support this approach. > > > > Okay. If we go down this path -- and I think it's a little > bit crazy > > -- then we'll need to ferret out the correct values for the current > > header fields and methods to set up the initial registry. > > > > Because of the haphazard way we've handled this, the table contains > > substantial gaps. I wrote a script to parse out all the > formal Table 2 > > expansions from the RFCs that define SIP header fields and SIP > > methods, and merge them into a single view of what has been > defined to > > date. With the caveat that this is a lot of data, and > something might > > have been missed, here's what it looks like: > > > > Header Field Where Proxy ACK BYE CAN > INF INV MES NOT OPT > > PRA PUB REF REG SUB UPD > > Accept 2xx > > - - - ? o - - > m* - - - o - o > > Accept 415 > > - c - ? c m* o > c c m* c c o c > > Accept R > > - o - o o - o > m* o o o o o o > > Accept-Contact R ar o o o > o o o o o o ? o > - o o > > Accept-Encoding 2xx > > - - - ? o - - > m* - - - o - o > > Accept-Encoding 415 > > - c - ? c m* o > c c m* c c o c > > Accept-Encoding R > > - o - o o - o > o o o o o o o > > Accept-Language 2xx > > - - - ? o - - > m* - - - o - o > > Accept-Language 415 > > - c - ? c m* o > c c m* c c o c > > Accept-Language R > > - o - o o - o > o o o o o o o > > Accept-Resource-Priority 200 amdr - o > o o o o o o o > > o o o o o > > Accept-Resource-Priority 417 amdr - o > o o o o o o o > > o o o o o > > Alert-Info 180 > > - - - ? o - - > - - ? ? - - ? > > Alert-Info R > > - - - ? o - - > - - - - - - - > > Alert-Info r > > ? ? ? ? ? ? ? > ? ? - - ? ? - > > Allow 2xx > > - o - ? m* o o > m* o ? ? o o o > > Allow 405 > > - m - o m m m > m m m m m m m > > Allow R > > - o - ? o o o > o o o ? o o o > > Allow r > > - o - ? o o o > o o o ? o o o > > Allow-Events 2xx > > - o - ? o ? o > o o ? ? o o ? > > Allow-Events 489 > > - - - ? - ? m > - - m ? - m ? > > Allow-Events R > > o o - ? o ? o > o o o ? o o - > > Allow-Events r > > ? ? ? ? ? ? ? > ? ? ? ? ? ? - > > Answer-Mode ? ? ? ? ? > ? ? ? ? ? ? ? ? > ? ? ? > > Authentication-Info 2xx > > - o - ? o o o > o o o o o o o > > Authorization R > > o o o o o o o > o o o o o o o > > Call-ID c r m m m m > m m m m m m m m > m m > > Call-Info R ar - - - ? > o o ? o - o - o > ? o > > Call-Info r ar - - - ? > o o ? o - o - o > ? o > > Contact 1xx > > - - - - o - o > - - - - - o o > > Contact 2xx > > - - - - m - o > o - - m o m m > > Contact 3xx > > - o - - o o m > o o o ? o m o > > Contact 485 > > - o - - o o o > o o o ? o o o > > Contact R > > o - - o m - m > o - - m o m m > > Content-Disposition R > > o o - ? o o o > o o o o o o o > > Content-Disposition r > > o o - ? o o o > o o o o o o o > > Content-Encoding R > > o o - o o o o > o o o o o o o > > Content-Encoding r > > o o - o o o o > o o o o o o o > > Content-Language R > > o o - ? o o o > o o o o o o o > > Content-Language r > > o o - ? o o o > o o o o o o o > > Content-Length R ar t t t > o t t t t t t o > t t t > > Content-Length r ar t t t > o t t t t t t o > t t t > > Content-Type R > > * * - * * * * > * * * * * * * > > Content-Type r > > * * - * * * * > * * * * * * * > > CSeq c r m m m m > m m m m m m m m > m m > > Date R a o o o o > o o o o o o o o > o o > > Date r a o o o o > o o o o o o o o > o o > > Encryption ? ? ? ? ? ? > ? ? ? ? ? ? ? ? > ? ? > > Error-Info 300-699 a - o o > ? o o o o o o ? > o o o > > Event R > > - - - ? - ? m > - - m ? - m - > > Event r > > ? ? ? ? ? ? ? > ? ? ? ? ? ? - > > Expires R > > - - - o o o - > - - o o o o - > > Expires r > > - - - o o o - > - - o ? o o - > > Flow-Timer ? ? ? ? ? ? > ? ? ? ? ? ? ? ? > ? ? > > From c r m m m m > m m m m m m m m > m m > > History-Info R amdr - - - > - o o o o - o o > o o - > > History-Info r amdr - - - > - o o o o - o o > o o - > > Identity R a o o - ? > o ? ? o ? ? ? o > ? ? > > Identity-Info R a o o - > ? o ? ? o ? ? ? > o ? ? > > In-Reply-To R > > - - - ? o o - > - - - - - - - > > In-Reply-To r > > ? ? ? ? ? ? ? > ? ? ? - ? ? - > > Join R > > - - - - o - - > - - - - - - - > > Max-Breadth ? ? ? ? ? > ? ? ? ? ? ? ? ? > ? ? ? > > Max-Forwards R amr m m m > o m m m m m m m > m m m > > MIME-Version R > > o o - ? o ? o > o o o o o o o > > MIME-Version r > > o o - ? o ? o > o o o o o o o > > Min-Expires 423 > > - - - ? - ? - > - - m ? m m ? > > Min-Expires R > > ? ? ? ? ? ? ? > ? ? ? - ? ? - > > Min-Expires r > > ? ? ? ? ? ? ? > ? ? ? - ? ? - > > Min-SE 422 > > - - - ? m ? - > - - ? ? - - m > > Min-SE R amr - - - ? > o ? - - - ? ? - > - o > > Organization R ar - - - > o o o - o - o o > o o o > > Organization r ar - - - > o o o - o - o o > o o o > > P-Access-Network-Info R dr - o > - o o o o o o ? > o o o o > > P-Access-Network-Info r dr - o > - o o o o o o ? > o o o o > > P-Answer-State 18x ar - - - > ? o ? ? - ? ? ? > - - ? > > P-Answer-State 2xx ar - - - > ? o ? ? - ? ? ? > - - ? > > P-Asserted-Identity R adr - o > - ? o ? ? o ? ? > ? - ? ? > > P-Asserted-Identity r adr - o > - ? o ? ? o ? ? > ? - ? ? > > P-Associated-URI 2xx > > - - - ? - ? ? > - ? ? ? o ? ? > > P-Called-Party-ID R amr - - - > - o o - o - ? o > - o - > > P-Charging-Function-Addresses ? ? ? > ? ? ? ? ? ? ? ? > > ? ? ? ? ? > > P-Charging-Vector R admr - o - > o o o o o o ? o > o o o > > P-Charging-Vector r admr - o - > o o o o o o ? o > o o o > > P-DCS-Trace-Party-ID R dmr - - > - ? o ? ? - ? - > ? - ? ? > > P-DCS-OSPS R dr - - - ? > o ? ? - ? - ? - > ? ? > > P-DCS-Billing-Info R admr - - - > ? o ? ? - ? - ? > - ? ? > > P-DCS-Billing-Info r admr - - - > ? o ? ? - ? - ? > - ? ? > > P-DCS-LAES R adr - - - ? > o ? ? - ? - ? - > ? ? > > P-DCS-LAES r adr - - - ? > o ? ? - ? - ? - > ? ? > > P-DCS-Redirect R adr - - - > ? o ? ? - ? - ? > - ? ? > > P-DCS-Redirect r adr - - - > ? o ? ? - ? - ? > - ? ? > > P-Early-Media 18x amr - - - > ? o ? ? - - ? ? > - ? - > > P-Early-Media 2xx amr - - - > ? - ? ? - o ? ? > - ? o > > P-Early-Media R amr - - - > ? o ? ? - o ? ? > - ? o > > P-Media-Authorization 101-199 ad - > - - ? o ? ? - ? ? > > ? - ? ? > > P-Media-Authorization 2xx ad - - > - - o ? - - o ? > ? - - o > > P-Media-Authorization R ad o - > - - o ? - - o ? > ? - - o > > P-Preferred-Identity R adr - o > - ? o ? ? o ? ? > ? - ? ? > > P-Preferred-Identity r adr - o > - ? o ? ? o ? ? > ? - ? ? > > P-Profile-Key ? ? ? ? ? > ? ? ? ? ? ? ? ? > ? ? ? > > P-Refused-URI-List ? ? ? ? ? > ? ? ? ? ? ? ? ? > ? ? ? > > P-Served-User ? ? ? ? ? > ? ? ? ? ? ? ? ? > ? ? ? > > P-User-Database ? ? ? ? ? > ? ? ? ? ? ? ? ? > ? ? ? > > P-Visited-Network-ID R ad - - > - - o o - o - ? > o o o - > > Path 2xx - - - - ? > - ? ? - ? ? ? o > ? ? > > Path R ar - - - ? > - ? ? - ? ? ? o > ? ? > > Permission-Missing ? ? ? ? ? > ? ? ? ? ? ? ? ? > ? ? ? > > Priority R ar - - - o > o o - - - o - - > o - > > Priority r > > ? ? ? ? ? ? ? > ? ? ? ? ? ? - > > Priv-Answer-Mode ? ? ? ? ? > ? ? ? ? ? ? ? ? > ? ? ? > > Privacy R amrd o o o ? > o o o o ? ? ? o > o o > > Privacy r amrd o o o ? > o o o o ? ? ? o > o o > > Proxy-Authenticate 401 ar - o o > ? o o ? o o o o > o ? o > > Proxy-Authenticate 407 ar - m - > o m m m m m m m > m m m > > Proxy-Authorization R dr o o > - o o o o o o o > o o o o > > RAck R > > - - - ? - ? - > - m ? ? - - - > > Reason ? ? ? ? ? ? > ? ? ? ? ? ? ? ? > ? ? > > Record-Route 18x mr - o o > ? o ? ? o o ? o > - ? o > > Record-Route 2xx mr - o o > o o ? o o o ? o > - o o > > Record-Route R ar o o o > o o - o o o - o > - o o > > Record-Route r ar ? ? ? > ? ? - ? ? ? - ? > ? ? ? > > Refer-Sub 2xx > > - - - - - - - > - - - o - - - > > Refer-Sub R > > - - - - - - - > - - - o - - - > > Refer-To R > > - - - ? - ? ? > - ? ? ? - ? ? > > Referred-By R > > - o - ? o ? ? > o ? ? ? o ? ? > > Reject-Contact R ar o o o > o o o o o o ? o > - o o > > Replaces R > > - - - - o - - > - - - - - - - > > Reply-To R > > - - - ? o o - > - - - - - - - > > Reply-To r > > - - - ? o o - > - - - - - - - > > Request-Disposition R ar o o > o o o o o o o ? > o o o o > > Require R ar - c - o > c c o c c o c c > o c > > Require r ar - c - ? > c c o c c o c c > o c > > Resource-Priority R amdr o o o > o o o o o o o o > o o o > > Response-Key ? ? ? ? ? > ? ? ? ? ? ? ? ? > ? ? ? > > Retry-After 404 > > - o o o o ? o > o o o o o o o > > Retry-After 413 > > - o o ? o ? o > o o o o o o o > > Retry-After 480 > > - o o o o ? o > o o o o o o o > > Retry-After 486 > > - o o o o ? o > o o o o o o o > > Retry-After 4xx > > ? ? ? ? ? o ? > ? ? ? ? ? ? ? > > Route R adr c c c o > c o c c c c c c > c c > > RSeq 1xx > > - - - ? o ? o > - - ? ? - o ? > > RSeq R > > ? ? ? ? ? ? ? > ? ? ? ? ? ? - > > RSeq r > > ? ? ? ? ? ? ? > ? ? ? ? ? ? - > > Security-Client R ard - o - > ? o o o o ? ? ? > o o o > > Security-Server 421 > > - o - ? o o o > o ? ? ? o o o > > Security-Server 494 > > - o - ? o o o > o ? ? ? o o o > > Security-Verify R ard - o - > ? o o o o ? ? ? > o o o > > Server r > > - o o o o o o > o o o o o o o > > Service-Route 2xx ar - - - > ? - ? ? - - ? ? > o ? ? > > Session-Expires 2xx ar - - - > ? o ? - - - ? ? > - - o > > Session-Expires R amr - - - > ? o ? - - - ? ? > - - o > > SIP-ETag 2xx > > - - - - - - - > - - m - - - - > > SIP-If-Match R > > - - - - - - - > - - o - - - - > > Subject R > > - - - o o o - > - - o - - - - > > Subject r > > ? ? ? ? ? ? ? > ? ? ? ? ? ? - > > Subscription-State R > > - - - ? - ? m > - - ? ? - - - > > Subscription-State r > > ? ? ? ? ? ? ? > ? ? ? ? ? ? - > > Supported 2xx > > - o o ? m* ? o > m* o o o o o o > > Supported R > > - o o ? m* ? o > o o o o o o o > > Target-Dialog R - - - - > - o - - - - - o > - o - > > Timestamp R > > o o o o o o o > o o o o o o o > > Timestamp r > > o o o o o o o > o o o o o o o > > To c r m m m m m > m m m m m m m m m > > Trigger-Consent ? ? ? ? ? > ? ? ? ? ? ? ? ? > ? ? ? > > Unsupported 420 > > - m - o m o o > m m o o m o m > > User-Agent R > > o o o o o o o > o o o o o o o > > User-Agent r > > o o o o o o o > o o o o o o o > > Via R amr m m m ? > m m ? m ? m ? m > ? m > > Via rc dr m m m ? > m m ? m ? m ? m > ? m > > Warning r > > - o o o o o o > o o o o o o o > > WWW-Authenticate 401 ar - m - > o m m m m m m m > m m m > > WWW-Authenticate 407 ar - o - > ? o o ? o ? o o > o ? o > > > > > > > > See all those question marks? Someone needs to come up with actual > > values for each of those cells. Some are going to be pretty easy to > > answer; others will require substantial research and/or debate. > > > > It seems like a lot of effort to me. Are we certain the > return on our > > investment of time will be worth it? > > > > /a > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From gonzalo.camarillo@ericsson.com Tue Mar 2 00:54:14 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1142B3A8760 for ; Tue, 2 Mar 2010 00:54:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 3f40jQ-2Y9b0 for ; Tue, 2 Mar 2010 00:54:13 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 108FD3A871B for ; Tue, 2 Mar 2010 00:54:12 -0800 (PST) X-AuditID: c1b4fb3d-b7c72ae00000040e-06-4b8cd234fcb9 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 07.25.01038.432DC8B4; Tue, 2 Mar 2010 09:54:12 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 09:54:12 +0100 Received: from [131.160.126.169] ([131.160.126.169]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 2 Mar 2010 09:54:11 +0100 Message-ID: <4B8CD233.4030206@ericsson.com> Date: Tue, 02 Mar 2010 10:54:11 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4B7EBF91.8020506@nostrum.com> <4B8284CC.8050800@cisco.com> <4B84A181.90008@nostrum.com> <4B8CC953.9020205@ericsson.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Mar 2010 08:54:11.0948 (UTC) FILETIME=[EDAA22C0:01CAB9E5] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] SIP Table 2 (was Re: 3265bis and Call-Info) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 08:54:14 -0000 Hi Christer, > I agree that we should be careful, and try to ensure that we have the > needed commitment from people. in addition to the commitment bit, which is obviously essential, I was talking about the usefulness of the exercise. I want to make sure people commit to something useful. So, discussing the usefulness of the whole thing would be, well, useful :o) > But, note that it is not only about interoperability. If we do not do > this, I still think we need some guideline on how to deal with the > header/method tables whenever we define a new method and/or header > field. Do we list all methods/headers that have currently been > specified at that moment, or? Providing guidance would be easy. Fixing the whole table would require more work... we need to have a good ROI in terms of cycles committed and usefulness to the community. Cheers, Gonzalo From christer.holmberg@ericsson.com Tue Mar 2 01:06:13 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F364328C0E1 for ; Tue, 2 Mar 2010 01:06:12 -0800 (PST) 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 ZcvRs7ggZNoO for ; Tue, 2 Mar 2010 01:06:12 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id BC0B828C0D6 for ; Tue, 2 Mar 2010 01:06:11 -0800 (PST) X-AuditID: c1b4fb3d-b7c72ae00000040e-d9-4b8cd503e529 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id D6.67.01038.305DC8B4; Tue, 2 Mar 2010 10:06:11 +0100 (CET) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 2 Mar 2010 10:06:10 +0100 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.139]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Tue, 2 Mar 2010 10:06:09 +0100 From: Christer Holmberg To: Gonzalo Camarillo Date: Tue, 2 Mar 2010 10:06:09 +0100 Thread-Topic: [sipcore] SIP Table 2 (was Re: 3265bis and Call-Info) Thread-Index: Acq55e63EkAKnRDtTBi2hL+7gtMmjQAAYZ+g Message-ID: References: <4B7EBF91.8020506@nostrum.com> <4B8284CC.8050800@cisco.com> <4B84A181.90008@nostrum.com> <4B8CC953.9020205@ericsson.com> <4B8CD233.4030206@ericsson.com> In-Reply-To: <4B8CD233.4030206@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] SIP Table 2 (was Re: 3265bis and Call-Info) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 09:06:13 -0000 Hi,=20 >>I agree that we should be careful, and try to ensure that we have the=20 >>needed commitment from people. >=20 >in addition to the commitment bit, which is obviously=20 >essential, I was talking about the usefulness of the=20 >exercise. I want to make sure people commit to something=20 >useful. So, discussing the usefulness of the whole thing=20 >would be, well, useful :o) >=20 >>But, note that it is not only about interoperability. If we=20 >>do not do this, I still think we need some guideline on how to deal with = the=20 >>header/method tables whenever we define a new method and/or header=20 >>field. Do we list all methods/headers that have currently been=20 >>specified at that moment, or? >=20 >Providing guidance would be easy. Fixing the whole table=20 >would require more work... we need to have a good ROI in=20 >terms of cycles committed and usefulness to the community. Sure. Adam, are you planning to request agenda time in order to discuss this in A= naheim? Regards, Christer From christer.holmberg@ericsson.com Tue Mar 2 03:45:58 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E4923A845C for ; Tue, 2 Mar 2010 03:45:58 -0800 (PST) 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 6OzdWUiCJXlI for ; Tue, 2 Mar 2010 03:45:57 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 6E6703A69BE for ; Tue, 2 Mar 2010 03:45:57 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-99-4b8cfa744e3b Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 7F.C8.31641.47AFC8B4; Tue, 2 Mar 2010 12:45:56 +0100 (CET) Received: from esessmw0191.eemea.ericsson.se (153.88.115.86) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 2 Mar 2010 12:45:51 +0100 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.139]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Tue, 2 Mar 2010 12:45:44 +0100 From: Christer Holmberg To: Gonzalo Camarillo Date: Tue, 2 Mar 2010 12:45:43 +0100 Thread-Topic: [sipcore] SIP Table 2 (was Re: 3265bis and Call-Info) Thread-Index: Acq55e63EkAKnRDtTBi2hL+7gtMmjQAF7aHA Message-ID: References: <4B7EBF91.8020506@nostrum.com> <4B8284CC.8050800@cisco.com> <4B84A181.90008@nostrum.com> <4B8CC953.9020205@ericsson.com> <4B8CD233.4030206@ericsson.com> In-Reply-To: <4B8CD233.4030206@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] SIP Table 2 (was Re: 3265bis and Call-Info) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 11:45:58 -0000 Hi,=20 >>I agree that we should be careful, and try to ensure that we have the=20 >>needed commitment from people. >=20 >in addition to the commitment bit, which is obviously=20 >essential, I was talking about the usefulness of the=20 >exercise. I want to make sure people commit to something=20 >useful. So, discussing the usefulness of the whole thing=20 >would be, well, useful :o) Yes, having useful discussions is normally useful :) Based on the comments on this issue so far, I DO think people consider it u= seful. But, more input is welcome. >>But, note that it is not only about interoperability. If we=20 >>do not do this, I still think we need some guideline on how to deal with = the=20 >>header/method tables whenever we define a new method and/or header=20 >>field. Do we list all methods/headers that have currently been=20 >>specified at that moment, or? >=20 >Providing guidance would be easy. Do you have any ideas on what such guidance would say? Regards, Christer From adam@nostrum.com Tue Mar 2 06:25:43 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F9293A8A86 for ; Tue, 2 Mar 2010 06:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] 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 180iUaqE6OkE for ; Tue, 2 Mar 2010 06:25:42 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 5D63E3A8A3B for ; Tue, 2 Mar 2010 06:25:42 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o22EPdcY006787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Mar 2010 08:25:39 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B8D1FE3.1050107@nostrum.com> Date: Tue, 02 Mar 2010 08:25:39 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <4B8C486A.5060400@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 14:25:43 -0000 On 3/1/10 23:52, Mar 1, Christer Holmberg wrote: > Hi, > > >> I would like to see #2 as a BCP. Not just for OPTIONS, but for all cases that a proxy/registrar might fork an inbound request. >> > Just to clarify, I guess you don't include dialog establsihment requests (INVITE, SUBSCRIBE)? They should always be forwarded/forked even if addressed to the AOR for which the registrar is responseible. > Nope -- I mean INVITE and SUBSCRIBE as well. It's somewhat orthogonal to the discussion at hand, but it solves the HERFP problem in the general case, and it solves it perfectly. /a From adam@nostrum.com Tue Mar 2 06:27:19 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE8FD3A840A for ; Tue, 2 Mar 2010 06:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] 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 yBv2IX6Vc+5r for ; Tue, 2 Mar 2010 06:27:19 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id A96933A7B33 for ; Tue, 2 Mar 2010 06:27:18 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o22ERE0x006870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Mar 2010 08:27:14 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B8D2042.4010407@nostrum.com> Date: Tue, 02 Mar 2010 08:27:14 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Christer Holmberg References: <4B7EBF91.8020506@nostrum.com> <4B8284CC.8050800@cisco.com> <4B84A181.90008@nostrum.com> <4B8CC953.9020205@ericsson.com> <4B8CD233.4030206@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] SIP Table 2 (was Re: 3265bis and Call-Info) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 14:27:19 -0000 On 3/2/10 03:06, Mar 2, Christer Holmberg wrote: > Adam, are you planning to request agenda time in order to discuss this > in Anaheim? I hadn't really planned on it, but if people want to spend face-to-face time on the topic, I'll put something together. /a From dean.willis@softarmor.com Tue Mar 2 06:58:55 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3295928C11B for ; Tue, 2 Mar 2010 06:58:55 -0800 (PST) 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 oYW3QGKdROci for ; Tue, 2 Mar 2010 06:58:54 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 7098428C0F8 for ; Tue, 2 Mar 2010 06:58:54 -0800 (PST) Received: from [192.168.2.101] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o22Ewk8h023819 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 2 Mar 2010 08:58:48 -0600 Date: Tue, 02 Mar 2010 08:58:37 -0600 From: "Dean Willis" To: "Paul Kyzivat" MIME-Version: 1.0 X-Mailer: LCG ProfiMail Message-ID: <6251149348.951987517@softarmor.com> In-Reply-To: <4B8C48E1.8090901@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Cc: sipcore@ietf.org Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 14:58:55 -0000 ------- Original message ------- > From: Paul Kyzivat > My recommendation for a BCP would be: > - honor Request-Disposition if present. Else > - return 3xx if there is more than one contact > - either 3xx or forward is ok if there is only one contact > What hapened to a 3xx with temp-gruus instead of contacts? -- Dean From ietf.hanserik@gmail.com Tue Mar 2 07:01:58 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 24A1C28C10B for ; Tue, 2 Mar 2010 07:01:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 Aik6MXzVZAnP for ; Tue, 2 Mar 2010 07:01:57 -0800 (PST) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id 1B40228C103 for ; Tue, 2 Mar 2010 07:01:55 -0800 (PST) Received: by ey-out-2122.google.com with SMTP id d26so79663eyd.51 for ; Tue, 02 Mar 2010 07:01:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=+wWWfPDLe325hIaGiIffAzZw3ZQ20/bpejLjm4gOoRI=; b=Tq4hW3K2bhE3znNEnQKr+r/n+xNluDWA+3YTzcyGo0COWdmhYiQLtM9+J/XM+hO4xT PcOFoFEIHsDzyR+8eynJnMepS7v7kxB1lmP4ZZARprNXGqR97OPE9WWsw3fi3ZT1EI7o LNx3AZt97tJYaBBCCZQ5IaJXVD1zPWzQJHQgQ= 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; b=ESHlBvy4SocRjW+fGxTCHvxrlY0K26qZ3NnAKLS+Ru66nWFsQfqzfjLrTe7JUc0MNd CCj+3V5Ht0QRyUBXW6SLIDKMXIRpRllWCau6mtdhWOflE4so/EeJViZ0iZwVUfxwTrS7 0/LnQsjicVB+U45MOyBhYUy8VnM3Cl470pPHQ= MIME-Version: 1.0 Received: by 10.213.51.195 with SMTP id e3mr988705ebg.96.1267542111977; Tue, 02 Mar 2010 07:01:51 -0800 (PST) In-Reply-To: <4B8D1FE3.1050107@nostrum.com> References: <4B8C486A.5060400@nostrum.com> <4B8D1FE3.1050107@nostrum.com> Date: Tue, 2 Mar 2010 16:01:51 +0100 Message-ID: <9ae56b1e1003020701t731ca950s1c6968256399ebc3@mail.gmail.com> From: Hans Erik van Elburg To: Adam Roach Content-Type: multipart/alternative; boundary=00163613756a5283bd0480d2a5bb Cc: SIPCORE Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 15:01:58 -0000 --00163613756a5283bd0480d2a5bb Content-Type: text/plain; charset=ISO-8859-1 You mean bypassing all the RFC3261 forking logic in the proxy responsible for the domain and pushing back that burden to the UAC? /Hans Erik van Elburg On Tue, Mar 2, 2010 at 3:25 PM, Adam Roach wrote: > On 3/1/10 23:52, Mar 1, Christer Holmberg wrote: > >> Hi, >> >> >> >>> I would like to see #2 as a BCP. Not just for OPTIONS, but for all cases >>> that a proxy/registrar might fork an inbound request. >>> >>> >> Just to clarify, I guess you don't include dialog establsihment requests >> (INVITE, SUBSCRIBE)? They should always be forwarded/forked even if >> addressed to the AOR for which the registrar is responseible. >> >> > > Nope -- I mean INVITE and SUBSCRIBE as well. It's somewhat orthogonal to > the discussion at hand, but it solves the HERFP problem in the general case, > and it solves it perfectly. > > /a > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --00163613756a5283bd0480d2a5bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You mean bypassing all the RFC3261 forking logic in the proxy responsible f= or the domain and pushing back that burden to the UAC?

/Hans Erik van Elburg


On Tue, Mar 2, 2010 at 3:25 PM, Adam Roa= ch <adam@nostrum.c= om> wrote:
On 3/1/10 23:52, Mar 1, Christer Holmberg wrote:
Hi,

=A0
I would like to see #2 as a BCP. Not just for OPTIONS, but for all cases th= at a proxy/registrar might fork an inbound request.
=A0 =A0
Just to clarify, I guess you don't include dialog establsihment request= s (INVITE, SUBSCRIBE)? They should always be forwarded/forked even if addre= ssed to the AOR for which the registrar is responseible.
=A0

Nope -- I mean INVITE and SUBSCRIBE as well. It's somewhat orthogonal t= o the discussion at hand, but it solves the HERFP problem in the general ca= se, and it solves it perfectly.

/a

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

--00163613756a5283bd0480d2a5bb-- From dean.willis@softarmor.com Tue Mar 2 07:09:57 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52FDA3A8781 for ; Tue, 2 Mar 2010 07:09:57 -0800 (PST) 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 e1ij9grAVzQU for ; Tue, 2 Mar 2010 07:09:56 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 98B9F3A8B16 for ; Tue, 2 Mar 2010 07:09:56 -0800 (PST) Received: from [192.168.2.101] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o22F9qQJ023962 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 2 Mar 2010 09:09:54 -0600 Date: Tue, 02 Mar 2010 09:09:43 -0600 From: "Dean Willis" To: christer.holmberg@ericsson.com MIME-Version: 1.0 X-Mailer: LCG ProfiMail Message-ID: <3656743157.951988183@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Cc: sipcore@ietf.org Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 15:09:57 -0000 ------- Original message ------- > From: Christer Holmberg > >>I would like to see #2 as a BCP. Not just for OPTIONS, but for all cases >> that a proxy/registrar might fork an inbound request. > > Just to clarify, I guess you don't include dialog establsihment requests > (INVITE, SUBSCRIBE)? They should always be forwarded/forked even if > addressed to the AOR for which the registrar is responseible. I think he really meant ALL REQUESTS. Replace forked-up behavior with more predictable redirection. When you really need downstream-node forking, you probably need to do it in a B28UA to handle all the possible responses, including media-path responses. Look at how Google Voice handles forking for an example. We have known for years that forking does not play well with PSTN gateways and early media, but have persistently failed to deal with that problem. -- Dean From pkyzivat@cisco.com Tue Mar 2 07:27:05 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A64B28C0F9 for ; Tue, 2 Mar 2010 07:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 YrvNiqFhM+JW for ; Tue, 2 Mar 2010 07:27:04 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2905328C111 for ; Tue, 2 Mar 2010 07:27:04 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAIq9jEtAZnwM/2dsb2JhbACDBZd9c6cPiByQNYE0gl1qBIMX X-IronPort-AV: E=Sophos;i="4.49,567,1262563200"; d="scan'208";a="90028673" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 02 Mar 2010 15:26:59 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o22FQxFN027290; Tue, 2 Mar 2010 15:26:59 GMT Message-ID: <4B8D2E42.2060909@cisco.com> Date: Tue, 02 Mar 2010 10:26:58 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dean Willis References: <6251149348.951987517@softarmor.com> In-Reply-To: <6251149348.951987517@softarmor.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 15:27:05 -0000 Dean Willis wrote: > > > ------- Original message ------- >> From: Paul Kyzivat >> My recommendation for a BCP would be: >> - honor Request-Disposition if present. Else >> - return 3xx if there is more than one contact >> - either 3xx or forward is ok if there is only one contact >> > What hapened to a 3xx with temp-gruus instead of contacts? AFAIK it would be inappropriate for the proxy to select and return gruus, especially temp gruus in a 3xx. I think the UAS would have to do that. While the proxy could choose the perm gruu, its a policy decision to use the perm/temp gruu, and normally I think it would be the UAS that would make that decision. Thanks, Paul From adam@nostrum.com Tue Mar 2 07:40:26 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A09828C128 for ; Tue, 2 Mar 2010 07:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] 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 UD+oA722xz5s for ; Tue, 2 Mar 2010 07:40:25 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id F1A4D28C12C for ; Tue, 2 Mar 2010 07:40:24 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o22FeLWa012338 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Mar 2010 09:40:21 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B8D3165.2010305@nostrum.com> Date: Tue, 02 Mar 2010 09:40:21 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Paul Kyzivat References: <6251149348.951987517@softarmor.com> <4B8D2E42.2060909@cisco.com> In-Reply-To: <4B8D2E42.2060909@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 15:40:26 -0000 On 3/2/10 09:26, Mar 2, Paul Kyzivat wrote: > AFAIK it would be inappropriate for the proxy to select and return > gruus, especially temp gruus in a 3xx. I think the UAS would have to > do that. While the proxy could choose the perm gruu, its a policy > decision to use the perm/temp gruu, and normally I think it would be > the UAS that would make that decision. I'm not sure why -- in this context, it's just an opaque cookie that the proxy/registrar minted for this one-time use and handed out. I don't think people are proposing that this be a temp-gruu that the proxy actually issued to the terminal, so the terminal's policy about what to do with the temp-gruus it receives is maintained. /a From pkyzivat@cisco.com Tue Mar 2 08:00:30 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4AA2A3A8B7C for ; Tue, 2 Mar 2010 08:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 sgF-QDdueLuu for ; Tue, 2 Mar 2010 08:00:29 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5397B3A8B7A for ; Tue, 2 Mar 2010 08:00:29 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJLEjEtAZnwM/2dsb2JhbACbAnOmX4prCI1hgmMIghAEgxc X-IronPort-AV: E=Sophos;i="4.49,567,1262563200"; d="scan'208";a="90035189" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 02 Mar 2010 16:00:29 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o22G0TUs015659; Tue, 2 Mar 2010 16:00:29 GMT Message-ID: <4B8D361C.708@cisco.com> Date: Tue, 02 Mar 2010 11:00:28 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Adam Roach References: <6251149348.951987517@softarmor.com> <4B8D2E42.2060909@cisco.com> <4B8D3165.2010305@nostrum.com> In-Reply-To: <4B8D3165.2010305@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 16:00:30 -0000 Adam Roach wrote: > On 3/2/10 09:26, Mar 2, Paul Kyzivat wrote: >> AFAIK it would be inappropriate for the proxy to select and return >> gruus, especially temp gruus in a 3xx. I think the UAS would have to >> do that. While the proxy could choose the perm gruu, its a policy >> decision to use the perm/temp gruu, and normally I think it would be >> the UAS that would make that decision. > > I'm not sure why -- in this context, it's just an opaque cookie that the > proxy/registrar minted for this one-time use and handed out. > > I don't think people are proposing that this be a temp-gruu that the > proxy actually issued to the terminal, so the terminal's policy about > what to do with the temp-gruus it receives is maintained. Oh, then you are postulating a new mechanism, similar to the temp gruu mechanism, but with (presumably) different value. Certainly such is possible. We just haven't defined any such mechanism yet. I was going to say that it wouldn't even need to be standardized. But gruus tend to break a lot of other things unless special account is taken of them. So it probably does need to be specified. This is likely a long road to go down, so we should only start down it if we are prepared for such a long journey. Thanks, Paul From kpfleming@digium.com Tue Mar 2 09:08:32 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 499383A8AB5 for ; Tue, 2 Mar 2010 09:08:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 pzuYvGF1V38k for ; Tue, 2 Mar 2010 09:08:31 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id E2F433A87DF for ; Tue, 2 Mar 2010 09:08:30 -0800 (PST) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1NmVaA-0002yj-VH for sipcore@ietf.org; Tue, 02 Mar 2010 11:08:31 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id E22FBD8004 for ; Tue, 2 Mar 2010 11:08:30 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xi2nHRi-BJvf for ; Tue, 2 Mar 2010 11:08:30 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 940E9D8003 for ; Tue, 2 Mar 2010 11:08:30 -0600 (CST) Message-ID: <4B8D460E.3040205@digium.com> Date: Tue, 02 Mar 2010 11:08:30 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: sipcore@ietf.org X-Enigmail-Version: 0.95.7 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [sipcore] Comments on draft-ieft-sipcore-reinvite-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 17:08:32 -0000 Editorial comments: Section 1: "There has been some confusion among implentors regarding how a UAS" ... should be 'implementors'. Section 3.7: SDP4 is improperly formatted. Content comments: Section 3.3: "A change to the session state is considered to have been executed if an offer/answer without preconditions [RFC4032] for the stream has completed successfully or the UAs have exchanged media using the new parameters. Connection establishment messages (e.g., TCP SYN), connectivity checks (e.g., when using ICE [I-D.ietf-mmusic-ice]), and any other messages used in the process of meeting the preconditions for a stream are not considered media." This is the issue I spoke briefly with Gonzalo about in Hiroshima, that we've seen in the field. The scenario is that a UAC sends an INVITE with only an audio stream; the UAS accepts it with 200 OK and the ACK is sent by the UAC. Later, one party (does not matter which) sends a re-INVITE requesting that that single stream be changed from audio to image/t38, using the *same port number* to receive the media. Because the port number did not change, and there is likely already audio media in RTP packets in-flight towards that endpoint, as soon as any of those RTP packets are received by that endpoint, it will consider that change to have been executed by the party that received the re-INVITE, even before receiving any SIP response to the re-INVITE itself. If the party receiving the re-INVITE does not want to switch to T.38, it can send a 488 Not Acceptable Here, but from the point of view of the party that sent the re-INVITE, this is too late... the change has been executed. This will occur any time the re-INVITE changes an existing media stream in a way that cannot easily be detected via packet inspection and does *not* change port numbers. Given that, I see only two possibilities to improve the interoperability situation: 1) We include a normative statement in this document that specifies that a re-INVITE that changes the content-type of a media stream SHOULD NOT use the same port number as was previously used for that media stream, so that the offerer can explicitly determine whether the answerer is executing the change or 2) We include a set of statements in this document telling implementors that if they receive a re-INVITE that changes the content type of an existing media stream and does not change port numbers, that they will not be effectively able to send a rejection of that re-INVITE if the previous stream state was such that media was already flowing, and that they should either use UPDATE within the re-INVITE transaction (as documented in this draft) to attempt to revert to the pre-re-INVITE state, or they should accept the re-INVITE and then issue one of their own to revert to the pre-re-INVITE state. While section 3.4 attempts to address this situation, my concern is that the unless the UAS takes the lack of port number change into account, it may send an error response to the re-INVITE under the (valid) assumption that none of the requested changes have been executed... but the UAC thinks that they have been executed. Does everyone else on the list think that section 3.4's language adequately addresses this situation? -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org From pkyzivat@cisco.com Tue Mar 2 09:27:49 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B7EF28C1E8 for ; Tue, 2 Mar 2010 09:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 TuI37utwGqI2 for ; Tue, 2 Mar 2010 09:27:48 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 622C528C0E6 for ; Tue, 2 Mar 2010 09:27:48 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKrZjEtAZnwN/2dsb2JhbACbAnOnJ4prCI1bgmMIghAEgxc X-IronPort-AV: E=Sophos;i="4.49,568,1262563200"; d="scan'208";a="89928498" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 02 Mar 2010 17:27:49 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o22HRmvK002603; Tue, 2 Mar 2010 17:27:48 GMT Message-ID: <4B8D4A90.30508@cisco.com> Date: Tue, 02 Mar 2010 12:27:44 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Kevin P. Fleming" References: <4B8D460E.3040205@digium.com> In-Reply-To: <4B8D460E.3040205@digium.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Comments on draft-ieft-sipcore-reinvite-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 17:27:49 -0000 Kevin, I don't understand your scenario. IIUC, - A & B negotiate a voice stream - A is receiving voice media - A sends reinvite to B with offer of t.38 - A continues to receive voice media in accord with session in effect prior to the reinvite - B rejects the reinvite with 488 - A and B continue to use voice media I don't see where there was a problem there. The alternate scenario is - A & B negotiate a voice stream - A is receiving voice media - A sends reinvite to B with offer of t.38 - A continues to receive voice media in accord with session in effect prior to the reinvite - B sends 2xx accepting the change - B sends t.38 media - A receives t.38 media and infers change was accepted - A receives the 2xx - session continues with t.38. What is significant above is that A must be prepared to receive *either* voice or t.38 on that port for some period of time. If it can't tolerate that, then it had better use a different port. What am I missing? Thanks, Paul Kevin P. Fleming wrote: > Editorial comments: > > Section 1: > > "There has been some confusion among implentors regarding how a UAS" > > ... should be 'implementors'. > > Section 3.7: > > SDP4 is improperly formatted. > > Content comments: > > Section 3.3: > > "A change to the session state is considered to have been executed if > an offer/answer without preconditions [RFC4032] for the stream has > completed successfully or the UAs have exchanged media using the new > parameters. Connection establishment messages (e.g., TCP SYN), > connectivity checks (e.g., when using ICE [I-D.ietf-mmusic-ice]), and > any other messages used in the process of meeting the preconditions > for a stream are not considered media." > > This is the issue I spoke briefly with Gonzalo about in Hiroshima, that > we've seen in the field. > > The scenario is that a UAC sends an INVITE with only an audio stream; > the UAS accepts it with 200 OK and the ACK is sent by the UAC. Later, > one party (does not matter which) sends a re-INVITE requesting that that > single stream be changed from audio to image/t38, using the *same port > number* to receive the media. Because the port number did not change, > and there is likely already audio media in RTP packets in-flight towards > that endpoint, as soon as any of those RTP packets are received by that > endpoint, it will consider that change to have been executed by the > party that received the re-INVITE, even before receiving any SIP > response to the re-INVITE itself. If the party receiving the re-INVITE > does not want to switch to T.38, it can send a 488 Not Acceptable Here, > but from the point of view of the party that sent the re-INVITE, this is > too late... the change has been executed. This will occur any time the > re-INVITE changes an existing media stream in a way that cannot easily > be detected via packet inspection and does *not* change port numbers. > > Given that, I see only two possibilities to improve the interoperability > situation: > > 1) We include a normative statement in this document that specifies that > a re-INVITE that changes the content-type of a media stream SHOULD NOT > use the same port number as was previously used for that media stream, > so that the offerer can explicitly determine whether the answerer is > executing the change > > or > > 2) We include a set of statements in this document telling implementors > that if they receive a re-INVITE that changes the content type of an > existing media stream and does not change port numbers, that they will > not be effectively able to send a rejection of that re-INVITE if the > previous stream state was such that media was already flowing, and that > they should either use UPDATE within the re-INVITE transaction (as > documented in this draft) to attempt to revert to the pre-re-INVITE > state, or they should accept the re-INVITE and then issue one of their > own to revert to the pre-re-INVITE state. > > While section 3.4 attempts to address this situation, my concern is that > the unless the UAS takes the lack of port number change into account, it > may send an error response to the re-INVITE under the (valid) assumption > that none of the requested changes have been executed... but the UAC > thinks that they have been executed. Does everyone else on the list > think that section 3.4's language adequately addresses this situation? > From kpfleming@digium.com Tue Mar 2 09:36:34 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF5F53A8BCC for ; Tue, 2 Mar 2010 09:36:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 pd+cjXC4nmJQ for ; Tue, 2 Mar 2010 09:36:32 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id B453D3A8BC4 for ; Tue, 2 Mar 2010 09:36:32 -0800 (PST) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1NmW1J-0003Oq-DT; Tue, 02 Mar 2010 11:36:33 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 51CA2D8004; Tue, 2 Mar 2010 11:36:33 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAzLzYV1LCbR; Tue, 2 Mar 2010 11:36:32 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id E250BD8003; Tue, 2 Mar 2010 11:36:32 -0600 (CST) Message-ID: <4B8D4CA0.6090904@digium.com> Date: Tue, 02 Mar 2010 11:36:32 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Paul Kyzivat References: <4B8D460E.3040205@digium.com> <4B8D4A90.30508@cisco.com> In-Reply-To: <4B8D4A90.30508@cisco.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Comments on draft-ieft-sipcore-reinvite-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 17:36:34 -0000 Paul Kyzivat wrote: > I don't see where there was a problem there. The alternate scenario is > > - A & B negotiate a voice stream > - A is receiving voice media > - A sends reinvite to B with offer of t.38 > - A continues to receive voice media in accord with > session in effect prior to the reinvite > - B sends 2xx accepting the change > - B sends t.38 media > - A receives t.38 media and infers change was accepted > - A receives the 2xx > - session continues with t.38. > > What is significant above is that A must be prepared to receive *either* > voice or t.38 on that port for some period of time. If it can't tolerate > that, then it had better use a different port. > > What am I missing? That is in fact the issue, and the problem we see in the field is that because there is no such thing as a protocol number at the UDP level, and T.38 doesn't use RTP for transport, there is no reliable way to discriminate an incoming packet to determine whether it is RTP carrying G.711 PCMU audio or UDPTL carrying a T.38 IFP. At best you can attempt to completely decode it as both forms, and then try to decide what you think it is, but it could very easily be the case that the first 'n' bytes of a UDPTL frame when interpreted as an RTP header contain a valid payload number for the existing audio session in the right location, and then there's really no way the endpoint can know for sure. This really falls into the 'best practices' area I suppose, and we'll certainly consider including a recommendation of this type in the SIP Forum work we are doing, but it seems that given the RFC3261 language about a change being 'executed' as soon as the offerer receives media using the 'new parameters', implementors should be cautioned (if not strongly warned) about sending a re-INVITE that would not allow them to determine whether the new parameters are being used or not. If the UAC and UAS can't explicitly indicate to each other that the new parameters are in use because of this problem, then implicit behavior will result, and the endpoints will get out of sync. This can be completely avoided with very little effort on the part of the implementor, though, which was my goal in raising this issue. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org From john.elwell@siemens-enterprise.com Tue Mar 2 09:45:11 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BE5328C1DD for ; Tue, 2 Mar 2010 09:45:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[AWL=-0.750, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6] 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 bUXD+Cxt453U for ; Tue, 2 Mar 2010 09:45:10 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id D406B28C125 for ; Tue, 2 Mar 2010 09:45:09 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1067994 for sipcore@ietf.org; Tue, 2 Mar 2010 18:45:10 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 2CE2623F02A6 for ; Tue, 2 Mar 2010 18:45:10 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 2 Mar 2010 18:45:10 +0100 From: "Elwell, John" To: "sipcore@ietf.org" Date: Tue, 2 Mar 2010 18:45:08 +0100 Thread-Topic: WGLC comments on draft-ietf-sipcore-reinvite-01 Thread-Index: Acq6MBmS6YNITjWXS0+saDkJYna2+Q== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] WGLC comments on draft-ietf-sipcore-reinvite-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 17:45:11 -0000 I read this document again and didn't find anything to prevent it progressi= ng (although I would not claim to have done a thorough review). Minor comments and nits: - Section 1: "A UAC willing to act the offerer" Change "act" to "act as". - Section 2: Where "UAC" and "UAS" expanded, it would probably be worth sta= ting that the terms are used with respect to INVITE and re-INVITE transacti= ons only. Other transactions within an INVITE or re-INVITE transaction can = be in the reverse direction and the roles are reversed. - Section 3.1: "SDP4: m=3Daudio 31000 RTP/AVP 0 c=3DIN IP4 192.0.2.5 m=3Dvideo 0 RTP/AVP 31 c=3DIN IP4 192.0.2.2"=20 It seems unreasonable to include in an answer, below a rejected m-line, a c= -line echoing the c-line in the offer. - In the last example in 3.1, it should perhaps be pointed out that SDP5 (i= n the UPDATE request) is an offer. Also the contents of SDP6 (SDP answer) s= hould perhaps also be shown for completeness. - In section 3.3: "During a session establishment, the UAS can wait for using the media parameters until " Change "wait for" to "wait before" (or alternatively "delay"). - In section 3.7: "The proxy relays the UPDATE request (9) to UA1. The UPDATE request (9) arrives at UA1 before the 4xx response (7) that had been previously sent. UA2 accepts the changes in the UPDATE request and returns a 200 (OK) response (10) to it ." I think the last sentence should begin "UA1 accepts the changes..." - " SDP4: m=3Daudio 20000 RTP/AVP 0 a=3Dsendonly m=3Dvideo 30002 RTP/AVP = 31 a=3Dinactive" Line breaks missing (c.f., the other examples). - In section 4.4: "In this document, reliable provisional responses are those that use the mechanism defined in RFC 3262 [RFC3262] on any other SIP-based mechanism that may be specified in the future." Change "on" to "or". - Change "If instead sending" to "If instead of sending" John From pkyzivat@cisco.com Tue Mar 2 09:58:57 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DAF728C1EE for ; Tue, 2 Mar 2010 09:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 f5GAFdqCKVnV for ; Tue, 2 Mar 2010 09:58:56 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5C13628C1D6 for ; Tue, 2 Mar 2010 09:58:56 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALPgjEtAZnwM/2dsb2JhbACbAnOnFJhRhHsEgxc X-IronPort-AV: E=Sophos;i="4.49,568,1262563200"; d="scan'208";a="90069658" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 02 Mar 2010 17:58:56 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o22HwuSo027994; Tue, 2 Mar 2010 17:58:56 GMT Message-ID: <4B8D51D8.6090501@cisco.com> Date: Tue, 02 Mar 2010 12:58:48 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Kevin P. Fleming" References: <4B8D460E.3040205@digium.com> <4B8D4A90.30508@cisco.com> <4B8D4CA0.6090904@digium.com> In-Reply-To: <4B8D4CA0.6090904@digium.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Comments on draft-ieft-sipcore-reinvite-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 17:58:57 -0000 OK. I agree this falls into the category of a "logical necessity" that could be well handled by a BCP. Thanks, Paul Kevin P. Fleming wrote: > Paul Kyzivat wrote: > >> I don't see where there was a problem there. The alternate scenario is >> >> - A & B negotiate a voice stream >> - A is receiving voice media >> - A sends reinvite to B with offer of t.38 >> - A continues to receive voice media in accord with >> session in effect prior to the reinvite >> - B sends 2xx accepting the change >> - B sends t.38 media >> - A receives t.38 media and infers change was accepted >> - A receives the 2xx >> - session continues with t.38. >> >> What is significant above is that A must be prepared to receive *either* >> voice or t.38 on that port for some period of time. If it can't tolerate >> that, then it had better use a different port. >> >> What am I missing? > > That is in fact the issue, and the problem we see in the field is that > because there is no such thing as a protocol number at the UDP level, > and T.38 doesn't use RTP for transport, there is no reliable way to > discriminate an incoming packet to determine whether it is RTP carrying > G.711 PCMU audio or UDPTL carrying a T.38 IFP. At best you can attempt > to completely decode it as both forms, and then try to decide what you > think it is, but it could very easily be the case that the first 'n' > bytes of a UDPTL frame when interpreted as an RTP header contain a valid > payload number for the existing audio session in the right location, and > then there's really no way the endpoint can know for sure. > > This really falls into the 'best practices' area I suppose, and we'll > certainly consider including a recommendation of this type in the SIP > Forum work we are doing, but it seems that given the RFC3261 language > about a change being 'executed' as soon as the offerer receives media > using the 'new parameters', implementors should be cautioned (if not > strongly warned) about sending a re-INVITE that would not allow them to > determine whether the new parameters are being used or not. If the UAC > and UAS can't explicitly indicate to each other that the new parameters > are in use because of this problem, then implicit behavior will result, > and the endpoints will get out of sync. This can be completely avoided > with very little effort on the part of the implementor, though, which > was my goal in raising this issue. > From adam@nostrum.com Tue Mar 2 11:47:42 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 536AC3A8C85 for ; Tue, 2 Mar 2010 11:47:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] 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 mClprJGivNRO for ; Tue, 2 Mar 2010 11:47:41 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 0A1963A8C84 for ; Tue, 2 Mar 2010 11:47:40 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o22Jlald031355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Mar 2010 13:47:36 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B8D6B58.1070406@nostrum.com> Date: Tue, 02 Mar 2010 13:47:36 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: Hans Erik van Elburg References: <4B8C486A.5060400@nostrum.com> <4B8D1FE3.1050107@nostrum.com> <9ae56b1e1003020701t731ca950s1c6968256399ebc3@mail.gmail.com> In-Reply-To: <9ae56b1e1003020701t731ca950s1c6968256399ebc3@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 19:47:42 -0000 On 3/2/10 09:01, Mar 2, Hans Erik van Elburg wrote: > You mean bypassing all the RFC3261 forking logic in the proxy > responsible for the domain and pushing back that burden to the UAC? Burden? The client already has logic to handle this. Servers can throw 300-class responses back for INVITEs whenever they want. So the development cost is already built into every SIP terminal in the world. There is no additional software burden. In terms of CPU burden... An average large network server has to handle several thousand or several tens of thousands of transactions per second. Your average terminal probably has to handle several dozen a day. Let's aim high and ballpark it around 0.001 transactions per second. You honestly think that moving some small portion of processing from the thing doing 10,000 TPS to the thing doing 0.001 TPS is going in the wrong direction? Or it could be that I completely missed your point, since both of these interpretations of "burden" make your assertion nonsense. Would you like to clarify your statement? /a From christer.holmberg@ericsson.com Tue Mar 2 12:40:39 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A042D3A6920 for ; Tue, 2 Mar 2010 12:40:39 -0800 (PST) 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=[AWL=0.000, 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 FLVS+qB11Tjq for ; Tue, 2 Mar 2010 12:40:38 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 7D3FF3A8991 for ; Tue, 2 Mar 2010 12:40:38 -0800 (PST) X-AuditID: c1b4fb3d-b7c72ae00000040e-04-4b8d77c515d8 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 94.E2.01038.5C77D8B4; Tue, 2 Mar 2010 21:40:38 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.139]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 2 Mar 2010 21:40:38 +0100 From: Christer Holmberg To: 'Paul Kyzivat' , Adam Roach Date: Tue, 2 Mar 2010 21:40:37 +0100 Thread-Topic: [sipcore] OPTIONS 3xx: To fork or not to fork? Thread-Index: Acq6IX7UL6KFk8VTR4aVRhz7eIitkQAJj1ag Message-ID: References: <6251149348.951987517@softarmor.com> <4B8D2E42.2060909@cisco.com> <4B8D3165.2010305@nostrum.com> <4B8D361C.708@cisco.com> In-Reply-To: <4B8D361C.708@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 20:40:39 -0000 Hi,=20 >>>AFAIK it would be inappropriate for the proxy to select and return=20 >>>gruus, especially temp gruus in a 3xx. I think the UAS would have to=20 >>>do that. While the proxy could choose the perm gruu, its a policy=20 >>>decision to use the perm/temp gruu, and normally I think it would be=20 >>>the UAS that would make that decision. >>>=20 >>I'm not sure why -- in this context, it's just an opaque cookie that=20 >>the proxy/registrar minted for this one-time use and handed out. >>=20 >>I don't think people are proposing that this be a temp-gruu that the=20 >>proxy actually issued to the terminal, so the terminal's policy about=20 >>what to do with the temp-gruus it receives is maintained. > >Oh, then you are postulating a new mechanism, similar to the temp gruu mec= hanism, but with (presumably) different value. > >Certainly such is possible. We just haven't defined any such mechanism yet= . I was going to say that it wouldn't even need to be standardized.=20 >But gruus tend to break a lot of other things unless special account is ta= ken of them. So it probably does need to be specified. > >This is likely a long road to go down, so we should only start down it if = we are prepared for such a long journey. I think we shall start from the fact that the registrar returns a Contact h= eader field for the UAS(s) in the 3xx response. Then, if the registrar includes the actual UAS contact information, or some= thing else, could be a policy decission. It is not really bound to the 3xx = mechanism itself - as long as the UAC can use whatever was returned to cont= act the UAS(s). Regarding the usage of gruus, I don't see any problem/risk in returning the= perm-gruu, but agin, that could be a policy decission. Regards, Christer From jmpolk@cisco.com Tue Mar 2 12:54:01 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3490D28C137 for ; Tue, 2 Mar 2010 12:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 j5p+CF6pRUjy for ; Tue, 2 Mar 2010 12:54:00 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 6844428C1AF for ; Tue, 2 Mar 2010 12:54:00 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAC8KjUurRN+J/2dsb2JhbACbAnOmbJhOhHsEgxc X-IronPort-AV: E=Sophos;i="4.49,569,1262563200"; d="scan'208";a="304428194" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 02 Mar 2010 20:54:01 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o22Ks1cr004067; Tue, 2 Mar 2010 20:54:01 GMT Message-Id: <201003022054.o22Ks1cr004067@sj-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 02 Mar 2010 14:54:00 -0600 To: Adam Roach , Christer Holmberg From: "James M. Polk" In-Reply-To: <4B8D2042.4010407@nostrum.com> References: <4B7EBF91.8020506@nostrum.com> <4B8284CC.8050800@cisco.com> <4B84A181.90008@nostrum.com> <4B8CC953.9020205@ericsson.com> <4B8CD233.4030206@ericsson.com> <4B8D2042.4010407@nostrum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] SIP Table 2 (was Re: 3265bis and Call-Info) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 20:54:01 -0000 At 08:27 AM 3/2/2010, Adam Roach wrote: >On 3/2/10 03:06, Mar 2, Christer Holmberg wrote: >>Adam, are you planning to request agenda time in order to discuss >>this in Anaheim? > >I hadn't really planned on it, but if people want to spend >face-to-face time on the topic, I'll put something together. Having at least some meeting time is a good way to have a high bandwidth exchange about the pros and cons of this effort, and whether or not it is worth the cycles. bluntly - I think there are many individuals that don't or aren't right now writing SIPCORE IDs, and do few of the reviews -- yet are able (i.e., have the necessary clue about SIP) and would be willing to spend cycles doing this effort. This would therefore (if true) not necessarily drain from existing efforts to get this Table 2 effort done. This isn't ignoring the ultimate review by the WG on any such effort, and doesn't ignore the impact on the chairs. That said -- this would fix an unsettled item this WG has had since it's inception, as was the case for the SIP WG once the first extension to SIP occurred after 3261 was published and Table 2 became "not accurate". my 1.89 cents (before deflation) james >/a >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Tue Mar 2 12:55:26 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54B5728C1DF for ; Tue, 2 Mar 2010 12:55:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 aa1TBrFpu0Du for ; Tue, 2 Mar 2010 12:55:25 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 82FB728C1B9 for ; Tue, 2 Mar 2010 12:55:25 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALcJjUtAZnwM/2dsb2JhbACbAnOmb4prCI1bgk8UCIIQBIMX X-IronPort-AV: E=Sophos;i="4.49,569,1262563200"; d="scan'208";a="159442190" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by sj-iport-5.cisco.com with ESMTP; 02 Mar 2010 20:55:26 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o22KtPUE026305; Tue, 2 Mar 2010 20:55:26 GMT Message-ID: <4B8D7B54.5050501@cisco.com> Date: Tue, 02 Mar 2010 15:55:48 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <6251149348.951987517@softarmor.com> <4B8D2E42.2060909@cisco.com> <4B8D3165.2010305@nostrum.com> <4B8D361C.708@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 20:55:26 -0000 Christer, I agree - its mostly policy. If somebody referenced the AoR, then it seems like it ought to be ok to return the public gruu, since that doesn't disclose anything the caller didn't already know. However that may not be true if the call was forwarded. E.g. Alice calls Bob, who forwards the call to Carol. However, Bob may not want Alice to know it was forwarded to Carol, or Carol might be willing to take the call for Bob, but doesn't want her AoR disclosed to Alice. If this were an INVITE reaching Carol's phone, it could use a temp gruu to hide identity. The proxy for Carol could perhaps do that on her behalf based on policy, but there might need to be new gruu-like mechanisms to do so. Nevertheless, I think we can simply specify that the 3xx contain contacts that reference each candidate UA. Thanks, Paul Christer Holmberg wrote: > Hi, > >>>> AFAIK it would be inappropriate for the proxy to select and return >>>> gruus, especially temp gruus in a 3xx. I think the UAS would have to >>>> do that. While the proxy could choose the perm gruu, its a policy >>>> decision to use the perm/temp gruu, and normally I think it would be >>>> the UAS that would make that decision. >>>> >>> I'm not sure why -- in this context, it's just an opaque cookie that >>> the proxy/registrar minted for this one-time use and handed out. >>> >>> I don't think people are proposing that this be a temp-gruu that the >>> proxy actually issued to the terminal, so the terminal's policy about >>> what to do with the temp-gruus it receives is maintained. >> Oh, then you are postulating a new mechanism, similar to the temp gruu mechanism, but with (presumably) different value. >> >> Certainly such is possible. We just haven't defined any such mechanism yet. I was going to say that it wouldn't even need to be standardized. >> But gruus tend to break a lot of other things unless special account is taken of them. So it probably does need to be specified. >> >> This is likely a long road to go down, so we should only start down it if we are prepared for such a long journey. > > I think we shall start from the fact that the registrar returns a Contact header field for the UAS(s) in the 3xx response. > > Then, if the registrar includes the actual UAS contact information, or something else, could be a policy decission. It is not really bound to the 3xx mechanism itself - as long as the UAC can use whatever was returned to contact the UAS(s). > > Regarding the usage of gruus, I don't see any problem/risk in returning the perm-gruu, but agin, that could be a policy decission. > > Regards, > > Christer > > From christer.holmberg@ericsson.com Tue Mar 2 12:57:30 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A84D28C1EE for ; Tue, 2 Mar 2010 12:57:30 -0800 (PST) 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=[AWL=0.000, 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 b4WrVUdB7w8Z for ; Tue, 2 Mar 2010 12:57:29 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 421D428C226 for ; Tue, 2 Mar 2010 12:57:28 -0800 (PST) X-AuditID: c1b4fb3d-b7c72ae00000040e-f7-4b8d7bb8fac6 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 6F.43.01038.8BB7D8B4; Tue, 2 Mar 2010 21:57:29 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.139]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 2 Mar 2010 21:57:28 +0100 From: Christer Holmberg To: 'Dean Willis' Date: Tue, 2 Mar 2010 21:57:28 +0100 Thread-Topic: [sipcore] OPTIONS 3xx: To fork or not to fork? Thread-Index: Acq6GnCg+CZ8xeU2T1G7wVf/ompLDAAL6t+A Message-ID: References: <3656743157.951988183@softarmor.com> In-Reply-To: <3656743157.951988183@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 20:57:30 -0000 Hi,=20 >>>I would like to see #2 as a BCP. Not just for OPTIONS, but for all=20 >>>cases that a proxy/registrar might fork an inbound request. >> >>Just to clarify, I guess you don't include dialog establsihment=20 >>requests (INVITE, SUBSCRIBE)? They should always be forwarded/forked=20 >>even if addressed to the AOR for which the registrar is responseible. > >I think he really meant ALL REQUESTS. Replace forked-up behavior with more= predictable redirection. When you really need downstream-node forking, you= probably need to do it in a B28UA to handle all the=20 >possible responses, including media-path responses. Look at how Google Voi= ce handles forking for an example. We have known for years that forking doe= s not play well with PSTN gateways and early media,=20 >but have persistently failed to deal with that problem. I think serial forking can normally be handled pretty well, when it comes t= o early media etc. The problem is generally parallel forking. Regards, Christer From christer.holmberg@ericsson.com Tue Mar 2 13:10:28 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EE7A3A86FF for ; Tue, 2 Mar 2010 13:10:28 -0800 (PST) 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=[AWL=0.000, 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 TUsfJc1g8a4p for ; Tue, 2 Mar 2010 13:10:27 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id D0D163A8587 for ; Tue, 2 Mar 2010 13:10:26 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-64-4b8d7ec246b5 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 9A.FA.31641.2CE7D8B4; Tue, 2 Mar 2010 22:10:26 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.139]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 2 Mar 2010 22:10:26 +0100 From: Christer Holmberg To: 'Adam Roach' , Hans Erik van Elburg Date: Tue, 2 Mar 2010 22:10:26 +0100 Thread-Topic: [sipcore] OPTIONS 3xx: To fork or not to fork? Thread-Index: Acq6QTd+fsDMrporT/SBBXKPdiCkGgACwGQQ Message-ID: References: <4B8C486A.5060400@nostrum.com> <4B8D1FE3.1050107@nostrum.com> <9ae56b1e1003020701t731ca950s1c6968256399ebc3@mail.gmail.com> <4B8D6B58.1070406@nostrum.com> In-Reply-To: <4B8D6B58.1070406@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 21:10:28 -0000 Hi, It sure is an interesting idea. But, apart from the fact that it would give= the UAC total control on which UAS(s) to contact, when and in which order = to contact them, would it bring much advantage from using parallel forking,= perhaps together with feature tags in order to "control" the forking?=20 Regards, Christer -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: 2. maaliskuuta 2010 21:48 To: Hans Erik van Elburg Cc: Christer Holmberg; SIPCORE Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? On 3/2/10 09:01, Mar 2, Hans Erik van Elburg wrote: > You mean bypassing all the RFC3261 forking logic in the proxy=20 > responsible for the domain and pushing back that burden to the UAC? Burden? The client already has logic to handle this. Servers can throw 300-class re= sponses back for INVITEs whenever they want. So the development cost is alr= eady built into every SIP terminal in the world. There is no additional sof= tware burden. In terms of CPU burden... An average large network server has to handle sev= eral thousand or several tens of thousands of transactions per second. Your= average terminal probably has to handle several dozen a day. Let's aim hig= h and ballpark it around 0.001 transactions per second. You honestly think that moving some small portion of processing from the th= ing doing 10,000 TPS to the thing doing 0.001 TPS is going in the wrong dir= ection? Or it could be that I completely missed your point, since both of these int= erpretations of "burden" make your assertion nonsense. Would you like to cl= arify your statement? /a From pkyzivat@cisco.com Tue Mar 2 13:29:40 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9D623A8CBE for ; Tue, 2 Mar 2010 13:29:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 GSuDg7FjfvT7 for ; Tue, 2 Mar 2010 13:29:39 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id A023D3A8CA6 for ; Tue, 2 Mar 2010 13:29:39 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOsRjUtAZnwM/2dsb2JhbACbBHOnAphMhHsEgxc X-IronPort-AV: E=Sophos;i="4.49,569,1262563200"; d="scan'208";a="89986685" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 02 Mar 2010 21:29:40 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o22LTe9Q006731; Tue, 2 Mar 2010 21:29:40 GMT Message-ID: <4B8D8343.3050100@cisco.com> Date: Tue, 02 Mar 2010 16:29:39 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4B8C486A.5060400@nostrum.com> <4B8D1FE3.1050107@nostrum.com> <9ae56b1e1003020701t731ca950s1c6968256399ebc3@mail.gmail.com> <4B8D6B58.1070406@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 21:29:40 -0000 Christer Holmberg wrote: > Hi, > > It sure is an interesting idea. But, apart from the fact that it would give the UAC total control on which UAS(s) to contact, when and in which order to contact them, would it bring much advantage from using parallel forking, perhaps together with feature tags in order to "control" the forking? It provides the UAC with the opportunity for a richer UI with more control for the end user. And it provides a way to do parallel forking without the early media issues. In a way its also a "poor man's presence". But as long as it isn't mandatory, UACs will still have to deal with all the troublesome forking issues too. It might be better to really use presence instead. The big problem I see with that is that typically people will only provide presence data to a limited number of their buddies, whereas you potentially want this for all callers. That could perhaps be dealt with by giving the presence server a "public presence" policy for what you are willing to disclose to anybody, and perhaps couple that with a restriction to just polling rather than a long term subscription. Thanks, Paul > Regards, > > Christer > > > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: 2. maaliskuuta 2010 21:48 > To: Hans Erik van Elburg > Cc: Christer Holmberg; SIPCORE > Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? > > On 3/2/10 09:01, Mar 2, Hans Erik van Elburg wrote: >> You mean bypassing all the RFC3261 forking logic in the proxy >> responsible for the domain and pushing back that burden to the UAC? > > Burden? > > The client already has logic to handle this. Servers can throw 300-class responses back for INVITEs whenever they want. So the development cost is already built into every SIP terminal in the world. There is no additional software burden. > > In terms of CPU burden... An average large network server has to handle several thousand or several tens of thousands of transactions per second. Your average terminal probably has to handle several dozen a day. Let's aim high and ballpark it around 0.001 transactions per second. > > You honestly think that moving some small portion of processing from the thing doing 10,000 TPS to the thing doing 0.001 TPS is going in the wrong direction? > > Or it could be that I completely missed your point, since both of these interpretations of "burden" make your assertion nonsense. Would you like to clarify your statement? > > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Tue Mar 2 13:29:59 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E91CA3A8991 for ; Tue, 2 Mar 2010 13:29:59 -0800 (PST) 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=[AWL=0.000, 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 TWGdTznF8JRz for ; Tue, 2 Mar 2010 13:29:59 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id AAD323A883C for ; Tue, 2 Mar 2010 13:29:58 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-3a-4b8d8356b495 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 98.8B.31641.6538D8B4; Tue, 2 Mar 2010 22:29:58 +0100 (CET) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0247.eemea.ericsson.se (153.88.115.93) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 2 Mar 2010 22:29:58 +0100 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.139]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Tue, 2 Mar 2010 22:29:57 +0100 From: Christer Holmberg To: 'Paul Kyzivat' , "Kevin P. Fleming" Date: Tue, 2 Mar 2010 22:29:56 +0100 Thread-Topic: [sipcore] Comments on draft-ieft-sipcore-reinvite-01 Thread-Index: Acq6MguQFDqnOitHQtOov3cS5+yoIAAG6d+Q Message-ID: References: <4B8D460E.3040205@digium.com> <4B8D4A90.30508@cisco.com> <4B8D4CA0.6090904@digium.com> <4B8D51D8.6090501@cisco.com> In-Reply-To: <4B8D51D8.6090501@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Comments on draft-ieft-sipcore-reinvite-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 21:30:00 -0000 Hi, If you use different ports, and you use ICE, I guess that means that you ne= ed to perform new ICE procedures for that port before you can start using i= t. Regards, Christer=20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Paul Kyzivat Sent: 2. maaliskuuta 2010 19:59 To: Kevin P. Fleming Cc: sipcore@ietf.org Subject: Re: [sipcore] Comments on draft-ieft-sipcore-reinvite-01 OK. I agree this falls into the category of a "logical necessity" that coul= d be well handled by a BCP. Thanks, Paul Kevin P. Fleming wrote: > Paul Kyzivat wrote: >=20 >> I don't see where there was a problem there. The alternate scenario=20 >> is >> >> - A & B negotiate a voice stream >> - A is receiving voice media >> - A sends reinvite to B with offer of t.38 >> - A continues to receive voice media in accord with >> session in effect prior to the reinvite >> - B sends 2xx accepting the change >> - B sends t.38 media >> - A receives t.38 media and infers change was accepted >> - A receives the 2xx >> - session continues with t.38. >> >> What is significant above is that A must be prepared to receive=20 >> *either* voice or t.38 on that port for some period of time. If it=20 >> can't tolerate that, then it had better use a different port. >> >> What am I missing? >=20 > That is in fact the issue, and the problem we see in the field is that=20 > because there is no such thing as a protocol number at the UDP level,=20 > and T.38 doesn't use RTP for transport, there is no reliable way to=20 > discriminate an incoming packet to determine whether it is RTP=20 > carrying > G.711 PCMU audio or UDPTL carrying a T.38 IFP. At best you can attempt=20 > to completely decode it as both forms, and then try to decide what you=20 > think it is, but it could very easily be the case that the first 'n' > bytes of a UDPTL frame when interpreted as an RTP header contain a=20 > valid payload number for the existing audio session in the right=20 > location, and then there's really no way the endpoint can know for sure. >=20 > This really falls into the 'best practices' area I suppose, and we'll=20 > certainly consider including a recommendation of this type in the SIP=20 > Forum work we are doing, but it seems that given the RFC3261 language=20 > about a change being 'executed' as soon as the offerer receives media=20 > using the 'new parameters', implementors should be cautioned (if not=20 > strongly warned) about sending a re-INVITE that would not allow them=20 > to determine whether the new parameters are being used or not. If the=20 > UAC and UAS can't explicitly indicate to each other that the new=20 > parameters are in use because of this problem, then implicit behavior=20 > will result, and the endpoints will get out of sync. This can be=20 > completely avoided with very little effort on the part of the=20 > implementor, though, which was my goal in raising this issue. >=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Tue Mar 2 13:34:28 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 618C428C16F for ; Tue, 2 Mar 2010 13:34:28 -0800 (PST) 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=[AWL=0.000, 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 69j0+pdHfwfp for ; Tue, 2 Mar 2010 13:34:27 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 272E328C12B for ; Tue, 2 Mar 2010 13:34:26 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-65-4b8d8462a016 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 31.BB.31641.2648D8B4; Tue, 2 Mar 2010 22:34:26 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.139]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 2 Mar 2010 22:34:26 +0100 From: Christer Holmberg To: 'Paul Kyzivat' Date: Tue, 2 Mar 2010 22:34:26 +0100 Thread-Topic: [sipcore] OPTIONS 3xx: To fork or not to fork? Thread-Index: Acq6T3lO7MQ2URD3TXewAR+pXCIr7gAACtuQ Message-ID: References: <4B8C486A.5060400@nostrum.com> <4B8D1FE3.1050107@nostrum.com> <9ae56b1e1003020701t731ca950s1c6968256399ebc3@mail.gmail.com> <4B8D6B58.1070406@nostrum.com> <4B8D8343.3050100@cisco.com> In-Reply-To: <4B8D8343.3050100@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 21:34:28 -0000 Hi,=20 >>It sure is an interesting idea. But, apart from the fact that it would gi= ve the UAC total control on which UAS(s) to contact, when and in which orde= r to contact them, would it bring much advantage from=20 >>using parallel forking, perhaps together with feature tags in order to "c= ontrol" the forking?=20 > >It provides the UAC with the opportunity for a richer UI with more control= for the end user. And it provides a way to do parallel forking without the= early media issues. Perhaps, but then you will also need to take charging/serivce aspects etc i= nto account. Without a correlation mechanism, I guess all these "parallel f= orks" from the UAC would be seen as separate calls. >In a way its also a "poor man's presence". > >But as long as it isn't mandatory, UACs will still have to deal with all t= he troublesome forking issues too. Again, I think using serial forking would solve lots of problems :) >It might be better to really use presence instead. The big problem I see w= ith that is that typically people will only provide presence data to a limi= ted number of their buddies, whereas you potentially=20 >want this for all callers. That could perhaps be dealt with by giving the = presence server a "public presence" policy for what you are willing to disc= lose to anybody, and perhaps couple that with a=20 >restriction to just polling rather than a long term subscription. Would presence work with PSTN gateways? Regards, Christer > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: 2. maaliskuuta 2010 21:48 > To: Hans Erik van Elburg > Cc: Christer Holmberg; SIPCORE > Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? >=20 > On 3/2/10 09:01, Mar 2, Hans Erik van Elburg wrote: >> You mean bypassing all the RFC3261 forking logic in the proxy=20 >> responsible for the domain and pushing back that burden to the UAC? >=20 > Burden? >=20 > The client already has logic to handle this. Servers can throw 300-class = responses back for INVITEs whenever they want. So the development cost is a= lready built into every SIP terminal in the world. There is no additional s= oftware burden. >=20 > In terms of CPU burden... An average large network server has to handle s= everal thousand or several tens of thousands of transactions per second. Yo= ur average terminal probably has to handle several dozen a day. Let's aim h= igh and ballpark it around 0.001 transactions per second. >=20 > You honestly think that moving some small portion of processing from the = thing doing 10,000 TPS to the thing doing 0.001 TPS is going in the wrong d= irection? >=20 > Or it could be that I completely missed your point, since both of these i= nterpretations of "burden" make your assertion nonsense. Would you like to = clarify your statement? >=20 > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From pkyzivat@cisco.com Tue Mar 2 14:00:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02EFE3A8CE8 for ; Tue, 2 Mar 2010 14:00:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 2c00ES+8CLcl for ; Tue, 2 Mar 2010 14:00:51 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B0CFB3A8839 for ; Tue, 2 Mar 2010 14:00:50 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAYZjUtAZnwM/2dsb2JhbACbCXOmdYprCI1WgmMIghAEgxc X-IronPort-AV: E=Sophos;i="4.49,569,1262563200"; d="scan'208";a="89990563" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 02 Mar 2010 22:00:51 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o22M0pgs015999; Tue, 2 Mar 2010 22:00:51 GMT Message-ID: <4B8D8A93.4040509@cisco.com> Date: Tue, 02 Mar 2010 17:00:51 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4B8C486A.5060400@nostrum.com> <4B8D1FE3.1050107@nostrum.com> <9ae56b1e1003020701t731ca950s1c6968256399ebc3@mail.gmail.com> <4B8D6B58.1070406@nostrum.com> <4B8D8343.3050100@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 22:00:52 -0000 Christer Holmberg wrote: > Hi, > >>> It sure is an interesting idea. But, apart from the fact that it would give the UAC total control on which UAS(s) to contact, when and in which order to contact them, would it bring much advantage from >>> using parallel forking, perhaps together with feature tags in order to "control" the forking? >> It provides the UAC with the opportunity for a richer UI with more control for the end user. And it provides a way to do parallel forking without the early media issues. > > Perhaps, but then you will also need to take charging/serivce aspects etc into account. Without a correlation mechanism, I guess all these "parallel forks" from the UAC would be seen as separate calls. Yes. But it doesn't change the reality of the situation. Assuming only one of the forks answers, the others are just "failed" call attempts that AFAIK are not normally charged. >> In a way its also a "poor man's presence". >> >> But as long as it isn't mandatory, UACs will still have to deal with all the troublesome forking issues too. > > Again, I think using serial forking would solve lots of problems :) Sure, but its not always what you want. Its quite reasonable that you would want your office phone and your cell phone to ring in parallel so you are perceived as being equally responsive regardless of where you are. >> It might be better to really use presence instead. The big problem I see with that is that typically people will only provide presence data to a limited number of their buddies, whereas you potentially >> want this for all callers. That could perhaps be dealt with by giving the presence server a "public presence" policy for what you are willing to disclose to anybody, and perhaps couple that with a >> restriction to just polling rather than a long term subscription. > > Would presence work with PSTN gateways? In principle a PSTN gateway could support presence subscriptions (easier if they are just polling calls). But in the end it doesn't have much information to offer. Typically there won't be multiple contacts. So failing to support presence in this case just means falling back to a basic call. Thanks, Paul > Regards, > > Christer > > > > > >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: 2. maaliskuuta 2010 21:48 >> To: Hans Erik van Elburg >> Cc: Christer Holmberg; SIPCORE >> Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? >> >> On 3/2/10 09:01, Mar 2, Hans Erik van Elburg wrote: >>> You mean bypassing all the RFC3261 forking logic in the proxy >>> responsible for the domain and pushing back that burden to the UAC? >> Burden? >> >> The client already has logic to handle this. Servers can throw 300-class responses back for INVITEs whenever they want. So the development cost is already built into every SIP terminal in the world. There is no additional software burden. >> >> In terms of CPU burden... An average large network server has to handle several thousand or several tens of thousands of transactions per second. Your average terminal probably has to handle several dozen a day. Let's aim high and ballpark it around 0.001 transactions per second. >> >> You honestly think that moving some small portion of processing from the thing doing 10,000 TPS to the thing doing 0.001 TPS is going in the wrong direction? >> >> Or it could be that I completely missed your point, since both of these interpretations of "burden" make your assertion nonsense. Would you like to clarify your statement? >> >> /a >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > From ietf.hanserik@gmail.com Tue Mar 2 14:47:50 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5AD028C28A for ; Tue, 2 Mar 2010 14:47:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 CgHQAeoE5yni for ; Tue, 2 Mar 2010 14:47:49 -0800 (PST) Received: from mail-ew0-f215.google.com (mail-ew0-f215.google.com [209.85.219.215]) by core3.amsl.com (Postfix) with ESMTP id 75AA828C161 for ; Tue, 2 Mar 2010 14:47:49 -0800 (PST) Received: by ewy7 with SMTP id 7so577257ewy.29 for ; Tue, 02 Mar 2010 14:47:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=7wmj+A2nVTWxqk2tmdAD94b9PfzdHuodsz88qFiToRY=; b=SNxUt5qIYW4FOcfrZckXlqonu/wBzvrGSIIq5wQ/5eMUiPHYSoSr9/FrcssNLRvbF0 BIZs7hnv/OKNb2Qj0oW3hsSPybgmWE10oF+bX9+YWd6k+VHCV/eLiRe7f2OEPqPJKE1T RGhUe0bpFUkEUq7U7mREZzMXvsyR2IJDgPZI8= 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; b=tnVwVMxZXH+z5mlNmMnooX6J9CTl2MtBPVXlWXyEVIDIkN/20D7GPuc9JMYBXBiGAH 9z+31/VG1WWe5K5wAElDYfUokpo6fQbUPyR+pAgE3wL2ST+z4SMRTkByeNjGU6cSA6Hh yMYJXy1VJUZj1EDFfDgdfnvqdk0XsT8y7Wtik= MIME-Version: 1.0 Received: by 10.213.41.84 with SMTP id n20mr1582966ebe.19.1267570065593; Tue, 02 Mar 2010 14:47:45 -0800 (PST) In-Reply-To: <4B8D6B58.1070406@nostrum.com> References: <4B8C486A.5060400@nostrum.com> <4B8D1FE3.1050107@nostrum.com> <9ae56b1e1003020701t731ca950s1c6968256399ebc3@mail.gmail.com> <4B8D6B58.1070406@nostrum.com> Date: Tue, 2 Mar 2010 23:47:45 +0100 Message-ID: <9ae56b1e1003021447u65c04b24i9e8cc3c65b0cc23e@mail.gmail.com> From: Hans Erik van Elburg To: Adam Roach Content-Type: multipart/alternative; boundary=001485e9a5ad7cd75e0480d92756 Cc: SIPCORE Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 22:47:50 -0000 --001485e9a5ad7cd75e0480d92756 Content-Type: text/plain; charset=ISO-8859-1 Burden as in handling the forking process. Didn't ment to overload that with lots of negative meaning. I thought the first part was more interesting. Where every forking proxy becomes a redirect server. There are also other consequences, where youre home proxy will always have the same way of handling youre contacts q-values. UAC's come in a lot of different flavors, they will all behave slightly different and most probably some will misbehave. So the UAS's owner loose some predictability about how incoming calls will be handled. No consistent experience, hard to explain. Also users will want to have services or policies be executed on their behalf on their home proxy, how does such approach impact that. Does such model mean anything to call setup delays, considering lets say scenarios where there are several intermediary proxies interconnecting some corporate voip clouds. Where the 3xx approach is very elegant in some cases, to say as a general BCP that any forking proxy should send 3xx also for INVITEs in any forking case seems in that respect over the top. /Hans Erik van Elburg On Tue, Mar 2, 2010 at 8:47 PM, Adam Roach wrote: > On 3/2/10 09:01, Mar 2, Hans Erik van Elburg wrote: > >> You mean bypassing all the RFC3261 forking logic in the proxy responsible >> for the domain and pushing back that burden to the UAC? >> > > Burden? > > The client already has logic to handle this. Servers can throw 300-class > responses back for INVITEs whenever they want. So the development cost is > already built into every SIP terminal in the world. There is no additional > software burden. > > In terms of CPU burden... An average large network server has to handle > several thousand or several tens of thousands of transactions per second. > Your average terminal probably has to handle several dozen a day. Let's aim > high and ballpark it around 0.001 transactions per second. > > You honestly think that moving some small portion of processing from the > thing doing 10,000 TPS to the thing doing 0.001 TPS is going in the wrong > direction? > > Or it could be that I completely missed your point, since both of these > interpretations of "burden" make your assertion nonsense. Would you like to > clarify your statement? > > /a > --001485e9a5ad7cd75e0480d92756 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Burden as in handling the forking process. Didn't ment to overload that= with lots of negative meaning.

I thought the first part was more in= teresting. Where every forking proxy becomes a redirect server.

There are also other consequences, where youre home proxy will always have = the same way of handling youre contacts q-values. UAC's come in a lot o= f different flavors, they will all behave slightly different and most proba= bly some will misbehave. So the UAS's owner loose some predictability a= bout how incoming calls will be handled. No consistent experience, hard to = explain.

Also users will want to have services or policies be executed on their = behalf on their home proxy, how does such approach impact that.

Does= such model mean anything to call setup delays, considering lets say scenar= ios where there are several intermediary proxies interconnecting some corpo= rate voip clouds.

Where the 3xx approach is very elegant in some cases, to say as a gener= al BCP that any forking proxy should send 3xx also for INVITEs in any forki= ng case seems in that respect over the top.=A0

/Hans = Erik van Elburg

On Tue, Mar 2, 2010 at 8:47 PM, Adam Roach <= span dir=3D"ltr"><adam@nostrum.com> wrote:
On 3/2/10 09:01, Mar 2, Hans Erik van Elburg wrote:
You mean bypassing all the RFC3261 forking logic in the proxy responsible f= or the domain and pushing back that burden to the UAC?

Burden?

The client already has logic to handle this. Servers can throw 300-class re= sponses back for INVITEs whenever they want. So the development cost is alr= eady built into every SIP terminal in the world. There is no additional sof= tware burden.

In terms of CPU burden... An average large network server has to handle sev= eral thousand or several tens of thousands of transactions per second. Your= average terminal probably has to handle several dozen a day. Let's aim= high and ballpark it around 0.001 transactions per second.

You honestly think that moving some small portion of processing from the th= ing doing 10,000 TPS to the thing doing 0.001 TPS is going in the wrong dir= ection?

Or it could be that I completely missed your point, since both of these int= erpretations of "burden" make your assertion nonsense. Would you = like to clarify your statement?

/a

--001485e9a5ad7cd75e0480d92756-- From adam@nostrum.com Tue Mar 2 14:54:24 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C33028C1C1 for ; Tue, 2 Mar 2010 14:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] 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 8ENB6n4ptipE for ; Tue, 2 Mar 2010 14:54:24 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 8C3AC3A7A68 for ; Tue, 2 Mar 2010 14:54:23 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o22MsMdk044886 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Mar 2010 16:54:22 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B8D971E.9030505@nostrum.com> Date: Tue, 02 Mar 2010 16:54:22 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Subject: [sipcore] 3265bis Open Issue: Allow-Events X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 22:54:24 -0000 [as a participant] In Stockholm, we had a discussion of the open issues in the 3265bis One of the topics that we discussed was how we handle advertising support for specific templates. The high-level exchange is captured in the meeting notes: http://www.ietf.org/proceedings/75/minutes/sipcore.html#Open%20Issue:%20Allow-Events%20and%20Templates The high level conclusion from that conversation -- really, a dialog between me and Robert -- is that the relatively slow pace of template package development (only one in 8 years) makes support for template event packages amenable to probing (as opposed to advertising). This message is a call for consensus around this point. If you agree with the proposal, please chime in and say so. Of course, if you think we need to do something different, send an email with a counter-proposal as well. Thanks. /a From adam@nostrum.com Tue Mar 2 15:22:57 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C823F28C0DC for ; Tue, 2 Mar 2010 15:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] 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 F0FrWbbiFDl2 for ; Tue, 2 Mar 2010 15:22:54 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 01F7E3A6884 for ; Tue, 2 Mar 2010 15:22:52 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o22NMooT046948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 2 Mar 2010 17:22:50 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B8D9DCA.4030807@nostrum.com> Date: Tue, 02 Mar 2010 17:22:50 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Subject: [sipcore] 3265 Open Issue: 202 Response Code X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 23:22:57 -0000 [as a participant] In Stockholm, we had a discussion of the open issues in the 3265bis One of the topics that we discussed was the utility of the 202 response code in RFC 3265. A summary of the conversation can be found in the minutes: http://www.ietf.org/proceedings/75/minutes/sipcore.html#Open%20Issue:%20The%20Fate%20of%20202 There was no clear agreement in that conversation, and several participants seemed to hold very nuanced opinions on the topic. In order to drive conversation on the topic, I will propose the following text as a starting point. The key change is in Section 8.3.1, which I propose to be updated as follows: For historical purposes, the 202 (Accepted) response code is added to the "Success" header field definition. This document does not specify the use of the 202 response code in conjunction with the SUBSCRIBE or NOTIFY methods. Previous versions of the SIP Events Framework assigned specific semantics to the 202 response code. Implementations conformant with this specification MUST treat an incoming 202 response as identical to a 200 response, and MUST NOT generate 202 response codes to SUBSCRIBE or NOTIFY messages. That is the change in policy that I am proposing. Several other changes in the document follow from this change; I list them below. In section 4.1.2.1, the third paragraph will be truncated after the word "immedately." In its revised form, it will simply read: This SUBSCRIBE request will be confirmed with a final response. 200- class responses indicate that the subscription has been accepted, and that a NOTIFY will be sent immediately. In section 4.2.1.1, the 6th and 7th paragraphs (both starting wht "If the notifier...") will be combined into a single paragraph reading: Once the notifier determines that it has enough information to create the subscription (i.e., it understands the event package, the subscription pertains to a known resource, and there are no other barriers to creating the subscription), it creates the subscription and a dialog, and returns a 200 (OK) response. In section 4.2.1.3, the fifth paragraph will replace "202 Accept" with "200 OK", with the final result being: If the notifier owner is interactively queried to determine whether a subscription is allowed, a 200 (OK) response is returned immediately. Note that a NOTIFY message is still formed and sent under these circumstances, as described in the previous section. In section 5.4.6, the final sentance of the final paragraph will be removed, resulting in the following text: Information in this section includes details of how to authenticate subscribers and authorization issues for the package. The first paragraph of section 6.2 will be updated to read: The mere act of returning certain 4xx and 6xx responses to SUBSCRIBE requests may, under certain circumstances, create privacy concerns by revealing sensitive policy information. In these cases, the notifier SHOULD always return a 200 (OK) response. While the subsequent NOTIFY message may not convey true state, it MUST appear to contain a potentially correct piece of data from the point of view of the subscriber, indistinguishable from a valid response. Information about whether a user is authorized to subscribe to the requested state is never conveyed back to the original user under these circumstances. /a From adam@nostrum.com Tue Mar 2 15:47:36 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 079EF3A8B0A for ; Tue, 2 Mar 2010 15:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] 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 CcZMG0WdjpJh for ; Tue, 2 Mar 2010 15:47:35 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 00E4628C0DC for ; Tue, 2 Mar 2010 15:47:34 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o22NlVg3048722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Mar 2010 17:47:32 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B8DA393.1050306@nostrum.com> Date: Tue, 02 Mar 2010 17:47:31 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: Oscar Novo Subject: [sipcore] Agenda Requests? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Mar 2010 23:47:36 -0000 [as chair] If you wish to request agenda time for the SIPCORE face-to-face meeting, please let Oscar by this upcoming Friday, March 5th. Please be certain to copy me and Gonzalo on your requests. So far, we have one request (no associated draft) to discuss issues related to the OPTIONS method. /a From keith.drage@alcatel-lucent.com Tue Mar 2 18:01:26 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9D0828C218 for ; Tue, 2 Mar 2010 18:01:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[AWL=4.402, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 cFEH4o2snkf1 for ; Tue, 2 Mar 2010 18:01:25 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id F3B4F3A8CC1 for ; Tue, 2 Mar 2010 18:01:20 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o2321KUD028914 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 3 Mar 2010 03:01:20 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Wed, 3 Mar 2010 03:01:20 +0100 From: "DRAGE, Keith (Keith)" To: Adam Roach , SIPCORE Date: Wed, 3 Mar 2010 03:01:19 +0100 Thread-Topic: [sipcore] 3265 Open Issue: 202 Response Code Thread-Index: Acq6X4PJRJhMN7pkSCye1gHPcmxpYgAEqyMA Message-ID: References: <4B8D9DCA.4030807@nostrum.com> In-Reply-To: <4B8D9DCA.4030807@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Subject: Re: [sipcore] 3265 Open Issue: 202 Response Code X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 02:01:26 -0000 Rather than change for change sake, what problem are we actually trying to = fix here. The meeting notes refer to HERFP but that is hardly enlightening. regards Keith=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach > Sent: Tuesday, March 02, 2010 11:23 PM > To: SIPCORE > Subject: [sipcore] 3265 Open Issue: 202 Response Code >=20 > [as a participant] >=20 > In Stockholm, we had a discussion of the open issues in the=20 > 3265bis One of the topics that we discussed was the utility=20 > of the 202 response code in RFC 3265. A summary of the=20 > conversation can be found in the minutes: >=20 > http://www.ietf.org/proceedings/75/minutes/sipcore.html#Open%2 > 0Issue:%20The%20Fate%20of%20202 >=20 > There was no clear agreement in that conversation, and=20 > several participants seemed to hold very nuanced opinions on=20 > the topic. >=20 > In order to drive conversation on the topic, I will propose=20 > the following text as a starting point. >=20 > The key change is in Section 8.3.1, which I propose to be updated as > follows: >=20 > For historical purposes, the 202 (Accepted) response code is > added to the "Success" header field definition. >=20 > This document does not specify the use of the 202 response code > in conjunction with the SUBSCRIBE or NOTIFY methods. Previous > versions of the SIP Events Framework assigned specific semantics > to the 202 response code. Implementations conformant with this > specification MUST treat an incoming 202 response as identical > to a 200 response, and MUST NOT generate 202 response codes to > SUBSCRIBE or NOTIFY messages. >=20 > That is the change in policy that I am proposing. Several=20 > other changes in the document follow from this change; I list=20 > them below. >=20 > In section 4.1.2.1, the third paragraph will be truncated=20 > after the word "immedately." In its revised form, it will simply read: >=20 > This SUBSCRIBE request will be confirmed with a final response. > 200- class responses indicate that the subscription has been > accepted, and that a NOTIFY will be sent immediately. >=20 > In section 4.2.1.1, the 6th and 7th paragraphs (both starting=20 > wht "If the notifier...") will be combined into a single=20 > paragraph reading: >=20 > Once the notifier determines that it has enough information to > create the subscription (i.e., it understands the event package, > the subscription pertains to a known resource, and there are no > other barriers to creating the subscription), it creates the > subscription and a dialog, and returns a 200 (OK) response. >=20 > In section 4.2.1.3, the fifth paragraph will replace "202 Accept" > with "200 OK", with the final result being: >=20 > If the notifier owner is interactively queried to determine > whether a subscription is allowed, a 200 (OK) response is returned > immediately. Note that a NOTIFY message is still formed and > sent under these circumstances, as described in the previous > section. >=20 > In section 5.4.6, the final sentance of the final paragraph=20 > will be removed, resulting in the following text: >=20 > Information in this section includes details of how to=20 > authenticate > subscribers and authorization issues for the package. >=20 > The first paragraph of section 6.2 will be updated to read: >=20 > The mere act of returning certain 4xx and 6xx responses to > SUBSCRIBE requests may, under certain circumstances, create > privacy concerns by revealing sensitive policy information. In > these cases, the notifier SHOULD always return a 200 (OK)=20 > response. > While the subsequent NOTIFY message may not convey true state, > it MUST appear to contain a potentially correct piece of data > from the point of view of the subscriber, indistinguishable from > a valid response. Information about whether a user is authorized > to subscribe to the requested state is never conveyed back to > the original user under these circumstances. >=20 >=20 > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From christer.holmberg@ericsson.com Tue Mar 2 21:42:28 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2537028C210 for ; Tue, 2 Mar 2010 21:42:28 -0800 (PST) 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 AbMFV484jfLY for ; Tue, 2 Mar 2010 21:42:26 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 059163A8C22 for ; Tue, 2 Mar 2010 21:42:25 -0800 (PST) X-AuditID: c1b4fb3d-b7c72ae00000040e-b7-4b8df6c13f50 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 68.78.01038.1C6FD8B4; Wed, 3 Mar 2010 06:42:25 +0100 (CET) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0247.eemea.ericsson.se (153.88.115.93) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 3 Mar 2010 06:42:25 +0100 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.216]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Wed, 3 Mar 2010 06:42:24 +0100 From: Christer Holmberg To: Adam Roach , SIPCORE Date: Wed, 3 Mar 2010 06:42:24 +0100 Thread-Topic: [sipcore] 3265 Open Issue: 202 Response Code Thread-Index: Acq6X1C0ts3B8G74Q7yA0WieCG85RwAMumHw Message-ID: References: <4B8D9DCA.4030807@nostrum.com> In-Reply-To: <4B8D9DCA.4030807@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] 3265 Open Issue: 202 Response Code X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 05:42:28 -0000 Hi, I think this is a little related to one issue/question a raised a while ago= , related to the new meaning of 200/202 for SUBSCRIBE. I assume the 200/202 response would cease the re-transmission of the SUBSCR= IBE request, but what is the *state* after 200/202 has been received and be= fore the first NOTIFY has been received?=20 If I remember correctly, dialogs won't be established until the NOTIFY requ= ests arrive, so is there some "pre-dialog" state between the SUB 200/202 an= d the first NOTIFY? Or, is there a subscription dialog usage already after = 200/202, eventhough it's not "used" for anything until the NOTIFY comes? And, for how long will the UAC wait for the first NOTIFY, in case it for wh= atever reason does not arrive immedialtely?=20 So, if the SUB 200/202 response doesn't do anything else than cease the SUB= re-transmission, maybe 202 would be more appropriate then 200? It's not a = suggestion at this point - just some loud thinking :) Regards, Christer ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Adam= Roach [adam@nostrum.com] Sent: Wednesday, March 03, 2010 1:22 AM To: SIPCORE Subject: [sipcore] 3265 Open Issue: 202 Response Code [as a participant] In Stockholm, we had a discussion of the open issues in the 3265bis One of the topics that we discussed was the utility of the 202 response code in RFC 3265. A summary of the conversation can be found in the minutes: http://www.ietf.org/proceedings/75/minutes/sipcore.html#Open%20Issue:%20The= %20Fate%20of%20202 There was no clear agreement in that conversation, and several participants seemed to hold very nuanced opinions on the topic. In order to drive conversation on the topic, I will propose the following text as a starting point. The key change is in Section 8.3.1, which I propose to be updated as follows: For historical purposes, the 202 (Accepted) response code is added to the "Success" header field definition. This document does not specify the use of the 202 response code in conjunction with the SUBSCRIBE or NOTIFY methods. Previous versions of the SIP Events Framework assigned specific semantics to the 202 response code. Implementations conformant with this specification MUST treat an incoming 202 response as identical to a 200 response, and MUST NOT generate 202 response codes to SUBSCRIBE or NOTIFY messages. That is the change in policy that I am proposing. Several other changes in the document follow from this change; I list them below. In section 4.1.2.1, the third paragraph will be truncated after the word "immedately." In its revised form, it will simply read: This SUBSCRIBE request will be confirmed with a final response. 200- class responses indicate that the subscription has been accepted, and that a NOTIFY will be sent immediately. In section 4.2.1.1, the 6th and 7th paragraphs (both starting wht "If the notifier...") will be combined into a single paragraph reading: Once the notifier determines that it has enough information to create the subscription (i.e., it understands the event package, the subscription pertains to a known resource, and there are no other barriers to creating the subscription), it creates the subscription and a dialog, and returns a 200 (OK) response. In section 4.2.1.3, the fifth paragraph will replace "202 Accept" with "200 OK", with the final result being: If the notifier owner is interactively queried to determine whether a subscription is allowed, a 200 (OK) response is returned immediately. Note that a NOTIFY message is still formed and sent under these circumstances, as described in the previous section. In section 5.4.6, the final sentance of the final paragraph will be removed, resulting in the following text: Information in this section includes details of how to authenticate subscribers and authorization issues for the package. The first paragraph of section 6.2 will be updated to read: The mere act of returning certain 4xx and 6xx responses to SUBSCRIBE requests may, under certain circumstances, create privacy concerns by revealing sensitive policy information. In these cases, the notifier SHOULD always return a 200 (OK) response. While the subsequent NOTIFY message may not convey true state, it MUST appear to contain a potentially correct piece of data from the point of view of the subscriber, indistinguishable from a valid response. Information about whether a user is authorized to subscribe to the requested state is never conveyed back to the original user under these circumstances. /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore= From christer.holmberg@ericsson.com Tue Mar 2 21:52:09 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEA7328C210 for ; Tue, 2 Mar 2010 21:52:09 -0800 (PST) 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=[AWL=0.000, 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 BAbDWBVQpaKR for ; Tue, 2 Mar 2010 21:52:09 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id A94533A8C37 for ; Tue, 2 Mar 2010 21:52:08 -0800 (PST) X-AuditID: c1b4fb3d-b7c72ae00000040e-9b-4b8df90853ed Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 55.09.01038.809FD8B4; Wed, 3 Mar 2010 06:52:08 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.216]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 3 Mar 2010 06:52:08 +0100 From: Christer Holmberg To: Paul Kyzivat Date: Wed, 3 Mar 2010 06:52:07 +0100 Thread-Topic: [sipcore] OPTIONS 3xx: To fork or not to fork? Thread-Index: Acq6U9QvLYWBiTk+QC+EHmX2+gPbzAAQJqTe Message-ID: References: <4B8C486A.5060400@nostrum.com> <4B8D1FE3.1050107@nostrum.com> <9ae56b1e1003020701t731ca950s1c6968256399ebc3@mail.gmail.com> <4B8D6B58.1070406@nostrum.com> <4B8D8343.3050100@cisco.com> , <4B8D8A93.4040509@cisco.com> In-Reply-To: <4B8D8A93.4040509@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 05:52:09 -0000 Hi, >>>> It sure is an interesting idea. But, apart from the fact that it would= give the UAC total control on which UAS(s) to contact, when and in which o= rder to contact them, would it bring much advantage from >>>> using parallel forking, perhaps together with feature tags in order to= "control" the forking? >>>It provides the UAC with the opportunity for a richer UI with more contr= ol for the end user. And it provides a way to do parallel forking without t= he early media issues. >> >>Perhaps, but then you will also need to take charging/serivce aspects etc= into account. Without a correlation mechanism, I guess all these "parallel= forks" from the UAC would be seen as separate calls. > >Yes. But it doesn't change the reality of the situation. Assuming only one= of the forks answers, the others are just "failed" call attempt that AFAIK= are not normally charged. True. But, there could be network services etc which are triggered for each= INVITE, which might not be the desired behavior, etc etc etc. I am just sa= ying the potential impacts would need to be studied. One could say that all this is already allowed, but I doubt many (if any) U= ACs would start sending multiple new INVITEs if it received a 3xx response = to the previous INVITE. >>>In a way its also a "poor man's presence". >>> >>>But as long as it isn't mandatory, UACs will still have to deal with all= the troublesome forking issues too. >> >>Again, I think using serial forking would solve lots of problems :) > >Sure, but its not always what you want. >Its quite reasonable that you would want your office phone and your cell >phone to ring in parallel so you are perceived as being equally >responsive regardless of where you are. Sure. It would be good if the forking proxy, in the case of parallel forkin= g, could tell the UAS(s) to not send early media. Regards, Christer >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: 2. maaliskuuta 2010 21:48 >> To: Hans Erik van Elburg >> Cc: Christer Holmberg; SIPCORE >> Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? >> >> On 3/2/10 09:01, Mar 2, Hans Erik van Elburg wrote: >>> You mean bypassing all the RFC3261 forking logic in the proxy >>> responsible for the domain and pushing back that burden to the UAC? >> Burden? >> >> The client already has logic to handle this. Servers can throw 300-class= responses back for INVITEs whenever they want. So the development cost is = already built into every SIP terminal in the world. There is no additional = software burden. >> >> In terms of CPU burden... An average large network server has to handle = several thousand or several tens of thousands of transactions per second. Y= our average terminal probably has to handle several dozen a day. Let's aim = high and ballpark it around 0.001 transactions per second. >> >> You honestly think that moving some small portion of processing from the= thing doing 10,000 TPS to the thing doing 0.001 TPS is going in the wrong = direction? >> >> Or it could be that I completely missed your point, since both of these = interpretations of "burden" make your assertion nonsense. Would you like to= clarify your statement? >> >> /a >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >= From dean.willis@softarmor.com Tue Mar 2 23:11:12 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 058113A88E2 for ; Tue, 2 Mar 2010 23:11:12 -0800 (PST) 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=[AWL=0.000, 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 1zcLq9Xp129Q for ; Tue, 2 Mar 2010 23:11:09 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 47AFD3A88DB for ; Tue, 2 Mar 2010 23:11:09 -0800 (PST) Received: from [192.168.2.102] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o237B7hG031072 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Mar 2010 01:11:08 -0600 Message-Id: <21160004-C309-4944-ACE1-C0275DDBF15C@softarmor.com> From: Dean Willis To: Adam Roach In-Reply-To: <4B8D6B58.1070406@nostrum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 3 Mar 2010 01:11:01 -0600 References: <4B8C486A.5060400@nostrum.com> <4B8D1FE3.1050107@nostrum.com> <9ae56b1e1003020701t731ca950s1c6968256399ebc3@mail.gmail.com> <4B8D6B58.1070406@nostrum.com> X-Mailer: Apple Mail (2.936) Cc: SIPCORE Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 07:11:12 -0000 On Mar 2, 2010, at 1:47 PM, Adam Roach wrote: > On 3/2/10 09:01, Mar 2, Hans Erik van Elburg wrote: >> You mean bypassing all the RFC3261 forking logic in the proxy >> responsible for the domain and pushing back that burden to the UAC? > > Burden? > > The client already has logic to handle this. Servers can throw 300- > class responses back for INVITEs whenever they want. So the > development cost is already built into every SIP terminal in the > world. There is no additional software burden. > > In terms of CPU burden... An average large network server has to > handle several thousand or several tens of thousands of transactions > per second. Your average terminal probably has to handle several > dozen a day. Let's aim high and ballpark it around 0.001 > transactions per second. > > You honestly think that moving some small portion of processing from > the thing doing 10,000 TPS to the thing doing 0.001 TPS is going in > the wrong direction? > > Or it could be that I completely missed your point, since both of > these interpretations of "burden" make your assertion nonsense. > Would you like to clarify your statement? > Well, somebody has to deal with the burden of resolving all those early-media streams and figuring out which one to render to the user. This is a hard problem, so whoever gets doing it is going to have to devote some resources to doing it right. On the other hand, it's arguably impossible for a proxy to do it right, so giving the additional state to the UAC needed for it to come up with a reasonable solution might not be an unreasonable burden. -- Dean From dean.willis@softarmor.com Tue Mar 2 23:16:41 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF85D28C13A for ; Tue, 2 Mar 2010 23:16:41 -0800 (PST) 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=[AWL=0.000, 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 xxqjeXVa34Q6 for ; Tue, 2 Mar 2010 23:16:40 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id ED70D28C240 for ; Tue, 2 Mar 2010 23:16:37 -0800 (PST) Received: from [192.168.2.102] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o237GXh2031142 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Mar 2010 01:16:34 -0600 Message-Id: From: Dean Willis To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 3 Mar 2010 01:16:28 -0600 References: <4B8C486A.5060400@nostrum.com> <4B8D1FE3.1050107@nostrum.com> <9ae56b1e1003020701t731ca950s1c6968256399ebc3@mail.gmail.com> <4B8D6B58.1070406@nostrum.com> X-Mailer: Apple Mail (2.936) Cc: SIPCORE Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 07:16:41 -0000 On Mar 2, 2010, at 3:10 PM, Christer Holmberg wrote: > > Hi, > > It sure is an interesting idea. But, apart from the fact that it > would give the UAC total control on which UAS(s) to contact, when > and in which order to contact them, would it bring much advantage > from using parallel forking, perhaps together with feature tags in > order to "control" the forking? Since it gives the UAC a separate O/A cycle for each media set, it at least makes it possible for the UA to correlate received media with a specific UAS. This would appear to make automated handling of the media channels in the UAC much more feasible; for example, the UAC respond with media saying "Press 1 if you're REALLY answering this call", then only connect the media flow to the user if a "1" is heard in response. This is what everything that parallel-forks through PSTN gateways pretty much has to do to work right. -- Dean From dean.willis@softarmor.com Tue Mar 2 23:19:20 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25F5128C240 for ; Tue, 2 Mar 2010 23:19:17 -0800 (PST) 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=[AWL=0.000, 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 d9a9s1TJp+1l for ; Tue, 2 Mar 2010 23:19:09 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 4547E28C236 for ; Tue, 2 Mar 2010 23:19:09 -0800 (PST) Received: from [192.168.2.102] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o237J289031165 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Mar 2010 01:19:04 -0600 Message-Id: <5C42FED0-35AE-4CB3-98C1-44C9D37683EF@softarmor.com> From: Dean Willis To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 3 Mar 2010 01:18:56 -0600 References: <4B8C486A.5060400@nostrum.com> <4B8D1FE3.1050107@nostrum.com> <9ae56b1e1003020701t731ca950s1c6968256399ebc3@mail.gmail.com> <4B8D6B58.1070406@nostrum.com> <4B8D8343.3050100@cisco.com> X-Mailer: Apple Mail (2.936) Cc: SIPCORE Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 07:19:20 -0000 On Mar 2, 2010, at 3:34 PM, Christer Holmberg wrote: > > Hi, > >>> It sure is an interesting idea. But, apart from the fact that it >>> would give the UAC total control on which UAS(s) to contact, when >>> and in which order to contact them, would it bring much advantage >>> from >>> using parallel forking, perhaps together with feature tags in >>> order to "control" the forking? >> >> It provides the UAC with the opportunity for a richer UI with more >> control for the end user. And it provides a way to do parallel >> forking without the early media issues. > > Perhaps, but then you will also need to take charging/serivce > aspects etc into account. Without a correlation mechanism, I guess > all these "parallel forks" from the UAC would be seen as separate > calls. They are, aren't they? If the carrier chooses not to bill for them separately, that's up to the carrier. > >> In a way its also a "poor man's presence". >> >> But as long as it isn't mandatory, UACs will still have to deal >> with all the troublesome forking issues too. > > Again, I think using serial forking would solve lots of problems :) > Explain how serial forking resolves the "PSTN-fork that went to voice mail" scenario? >> It might be better to really use presence instead. The big problem >> I see with that is that typically people will only provide presence >> data to a limited number of their buddies, whereas you potentially >> want this for all callers. That could perhaps be dealt with by >> giving the presence server a "public presence" policy for what you >> are willing to disclose to anybody, and perhaps couple that with a >> restriction to just polling rather than a long term subscription. > > Would presence work with PSTN gateways? Nope. -- Dean From dean.willis@softarmor.com Tue Mar 2 23:22:39 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5443A28C236 for ; Tue, 2 Mar 2010 23:22:35 -0800 (PST) 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=[AWL=0.000, 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 krKuMrF6ZmIQ for ; Tue, 2 Mar 2010 23:22:33 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 0195128C212 for ; Tue, 2 Mar 2010 23:22:31 -0800 (PST) Received: from [192.168.2.102] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o237MSS3031218 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Mar 2010 01:22:29 -0600 Message-Id: <192ABC51-3B3D-4231-98BE-D049390D340C@softarmor.com> From: Dean Willis To: Paul Kyzivat In-Reply-To: <4B8D8A93.4040509@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 3 Mar 2010 01:22:22 -0600 References: <4B8C486A.5060400@nostrum.com> <4B8D1FE3.1050107@nostrum.com> <9ae56b1e1003020701t731ca950s1c6968256399ebc3@mail.gmail.com> <4B8D6B58.1070406@nostrum.com> <4B8D8343.3050100@cisco.com> <4B8D8A93.4040509@cisco.com> X-Mailer: Apple Mail (2.936) Cc: SIPCORE Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 07:22:39 -0000 On Mar 2, 2010, at 4:00 PM, Paul Kyzivat wrote: > > > Christer Holmberg wrote: >> Hi, >>>> It sure is an interesting idea. But, apart from the fact that it >>>> would give the UAC total control on which UAS(s) to contact, when >>>> and in which order to contact them, would it bring much advantage >>>> from using parallel forking, perhaps together with feature tags >>>> in order to "control" the forking? >>> It provides the UAC with the opportunity for a richer UI with more >>> control for the end user. And it provides a way to do parallel >>> forking without the early media issues. >> Perhaps, but then you will also need to take charging/serivce >> aspects etc into account. Without a correlation mechanism, I guess >> all these "parallel forks" from the UAC would be seen as separate >> calls. > > Yes. But it doesn't change the reality of the situation. Assuming > only one of the forks answers, the others are just "failed" call > attempts that AFAIK are not normally charged. But what happens when multiple of them are "answered", either with early media or a real session? > In principle a PSTN gateway could support presence subscriptions > (easier if they are just polling calls). But in the end it doesn't > have much information to offer. Typically there won't be multiple > contacts. One of my inbound phone numbers forks to as many as 6 different phone numbers. All of those phone numbers have their own voice mail system, but if the incoming call is not answered by "a human", the system is smart enough to route the call to a special voice-mail system for the DID number. There have been systems with this functionality for years; it just doesn't work with proxy-forking in SIP. -- Dean From dean.willis@softarmor.com Tue Mar 2 23:25:08 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 225273A7C68 for ; Tue, 2 Mar 2010 23:25:08 -0800 (PST) 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=[AWL=0.000, 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 pkorGQIHEMsu for ; Tue, 2 Mar 2010 23:25:06 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 2D61F28C223 for ; Tue, 2 Mar 2010 23:25:06 -0800 (PST) Received: from [192.168.2.102] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o237P4Iw031240 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 3 Mar 2010 01:25:05 -0600 Message-Id: <21F06E40-A672-4497-92D2-B2F66A743A00@softarmor.com> From: Dean Willis To: Hans Erik van Elburg In-Reply-To: <9ae56b1e1003021447u65c04b24i9e8cc3c65b0cc23e@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 3 Mar 2010 01:24:58 -0600 References: <4B8C486A.5060400@nostrum.com> <4B8D1FE3.1050107@nostrum.com> <9ae56b1e1003020701t731ca950s1c6968256399ebc3@mail.gmail.com> <4B8D6B58.1070406@nostrum.com> <9ae56b1e1003021447u65c04b24i9e8cc3c65b0cc23e@mail.gmail.com> X-Mailer: Apple Mail (2.936) Cc: SIPCORE Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 07:25:08 -0000 On Mar 2, 2010, at 4:47 PM, Hans Erik van Elburg wrote: > Burden as in handling the forking process. Didn't ment to overload > that with lots of negative meaning. > > I thought the first part was more interesting. Where every forking > proxy becomes a redirect server. > > There are also other consequences, where youre home proxy will > always have the same way of handling youre contacts q-values. UAC's > come in a lot of different flavors, they will all behave slightly > different and most probably some will misbehave. So the UAS's owner > loose some predictability about how incoming calls will be handled. > No consistent experience, hard to explain. > > Also users will want to have services or policies be executed on > their behalf on their home proxy, how does such approach impact that. Then the home proxy has to act as a B2BUA and do the expansion into multiple connected calls itself. > > Does such model mean anything to call setup delays, considering lets > say scenarios where there are several intermediary proxies > interconnecting some corporate voip clouds. > > Where the 3xx approach is very elegant in some cases, to say as a > general BCP that any forking proxy should send 3xx also for INVITEs > in any forking case seems in that respect over the top. There are non-gateway scenarios where parallel forking actually works. We don't find them very often. -- Dean From christer.holmberg@ericsson.com Wed Mar 3 00:05:33 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8905C28C21C for ; Wed, 3 Mar 2010 00:05:33 -0800 (PST) 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 qEPLrqFUsJ+D for ; Wed, 3 Mar 2010 00:05:32 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 4446F3A8819 for ; Wed, 3 Mar 2010 00:05:32 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-45-4b8e184cc999 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 3D.AD.31641.C481E8B4; Wed, 3 Mar 2010 09:05:32 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.216]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 3 Mar 2010 09:05:32 +0100 From: Christer Holmberg To: Dean Willis Date: Wed, 3 Mar 2010 09:05:30 +0100 Thread-Topic: INVITE 3xx [was OPTIONS 3xx: To fork or not to fork?] Thread-Index: Acq6oXdZ48o9hU4LQgyK5J1NObYVhQABQadw Message-ID: References: <4B8C486A.5060400@nostrum.com> <4B8D1FE3.1050107@nostrum.com> <9ae56b1e1003020701t731ca950s1c6968256399ebc3@mail.gmail.com> <4B8D6B58.1070406@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: [sipcore] INVITE 3xx [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 08:05:33 -0000 =20 Hi, I've changed the subject. >>It sure is an interesting idea. But, apart from the fact that it would=20 >>give the UAC total control on which UAS(s) to contact, when and in=20 >>which order to contact them, would it bring much advantage=20 >>from using parallel forking, perhaps together with feature tags in order = to=20 >>"control" the forking? >=20 >Since it gives the UAC a separate O/A cycle for each media=20 >set, it at least makes it possible for the UA to correlate=20 >received media with a specific UAS. This would appear to make=20 >automated handling of the media channels in the UAC much more=20 >feasible; for example, the UAC respond with media saying=20 >"Press 1 if you're REALLY answering this call", then only=20 >connect the media flow to the user if a "1" is heard in=20 >response. This is what everything that parallel-forks through=20 >PSTN gateways pretty much has to do to work right. I think that such call selection can also be done by an B2BUA in the networ= k. Keep in mind that even if only one specific media stream is played to the u= ser behind the UAC, the fact that multiple media streams are sent towards t= he UAC can cause resource issues. So, in my opinion the best thing is to tr= y to only send the media stream towards the UAC that will be played to the = user. >>>>It sure is an interesting idea. But, apart from the fact that it=20 >>>>would give the UAC total control on which UAS(s) to contact, when=20 >>>>and in which order to contact them, would it bring much advantage=20 >>>>from using parallel forking, perhaps together with feature tags in=20 >>>>order to "control" the forking? >>> >>>It provides the UAC with the opportunity for a richer UI with more=20 >>>control for the end user. And it provides a way to do parallel=20 >>>forking without the early media issues. >> >>Perhaps, but then you will also need to take charging/serivce aspects=20 >>etc into account. Without a correlation mechanism, I guess all these=20 >>"parallel forks" from the UAC would be seen as separate calls. > >They are, aren't they? If the carrier chooses not to bill for them separat= ely, that's up to the carrier. Yes, but how does the carrier do that? Also, applying the same service (e.g. some kind of anouncement) to all thos= e "calls" is not very optimized usage of service resources. >>>In a way its also a "poor man's presence". >>> >>>But as long as it isn't mandatory, UACs will still have to deal =20 >>>with all the troublesome forking issues too. >> >>Again, I think using serial forking would solve lots of problems :) > > >Explain how serial forking resolves the "PSTN-fork that went to voice mail= " scenario? Could you explain that scenario? :) One would also need to take into account the trust issue related with INVIT= E 3xx. What if the new INVITE is sent to some expensive service number? Yes= , in some phones you may allow the user to actually decided whether to trig= ger a new INVITE, but it won't always work. Regards, Christer= From ietf.hanserik@gmail.com Wed Mar 3 00:43:14 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9B043A89C7 for ; Wed, 3 Mar 2010 00:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 dBxpoJaLn2v9 for ; Wed, 3 Mar 2010 00:43:14 -0800 (PST) Received: from mail-ew0-f215.google.com (mail-ew0-f215.google.com [209.85.219.215]) by core3.amsl.com (Postfix) with ESMTP id A46EA3A89C3 for ; Wed, 3 Mar 2010 00:43:13 -0800 (PST) Received: by ewy7 with SMTP id 7so733579ewy.29 for ; Wed, 03 Mar 2010 00:43:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=klrSGnGIseKYU8Y01lT4aq0zIkjTQQlHZyUVTMoJqTQ=; b=fKf++t9RHb7WfuL/uGCuQggwkR1hkvsJgmUkMwDgPT8oBs9O432anafPKpDsM9nweE Q67Wlaez460hZnT3Tl3VFpZj+1x8Q02pkd7F9HU3wpD7YZu+UnbXrI0XeCZBMKVTa4ru /SS5SDWQmIBh0+Tbyl59Q3VdxmCuZhZ/8beUs= 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; b=E0pbOgLUSeJqRiuFv2ZC6OautgHBOHM6XcIal87sc2qdqAPieb5hAPTzMTt+LZlRAr GpQdOhyHLis34z6+SRooZ7+j+Pgi/Uzuw69I8eD2oMHDFFbFsXyHKrBYQAVQqNKmejCG Sl31v157CfM7iTy8+RrvzTojPBn28nGPWNv7M= MIME-Version: 1.0 Received: by 10.213.96.203 with SMTP id i11mr5440537ebn.9.1267605775889; Wed, 03 Mar 2010 00:42:55 -0800 (PST) In-Reply-To: References: <4B8C486A.5060400@nostrum.com> <4B8D1FE3.1050107@nostrum.com> <9ae56b1e1003020701t731ca950s1c6968256399ebc3@mail.gmail.com> <4B8D6B58.1070406@nostrum.com> Date: Wed, 3 Mar 2010 09:42:55 +0100 Message-ID: <9ae56b1e1003030042m3a6de8f6x7f13afa7725b1ff4@mail.gmail.com> From: Hans Erik van Elburg To: Christer Holmberg Content-Type: multipart/alternative; boundary=001636c5971ffcb6f90480e1779f Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 08:43:14 -0000 --001636c5971ffcb6f90480e1779f Content-Type: text/plain; charset=ISO-8859-1 Forking in essence is a service provided by a downstream proxy (serving domein B.com) to a user that has multiple devices registered to this proxy. This service (served to him by his own domain) will allow him to receive calls at any of his devices. To push the responsibility for providing this service of a B.com user to another domain lets say A.com, is to say the least problematic. Even if it solves some issues like those related to early media and HERFP, it introduces lots of other issues. /Hans Erik van Elburg --001636c5971ffcb6f90480e1779f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Forking in essence=A0 is a service provided by a downstream proxy (serving = domein B.com) to a user that has multiple devices registered to this proxy.= This service (served to him by his own domain) will allow him to receive c= alls at any of his devices.

To push the responsibility for providing=A0 this service of a B.com use= r to another domain lets say A.com, is to say the least problematic. Even i= f it solves some issues like those related to early media and HERFP, it int= roduces lots of other issues.

/Hans Erik van Elburg

--001636c5971ffcb6f90480e1779f-- From john.elwell@siemens-enterprise.com Wed Mar 3 01:37:10 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AD913A67FB for ; Wed, 3 Mar 2010 01:37:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 lA0V7JV6V4DF for ; Wed, 3 Mar 2010 01:37:09 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id EF07A3A8B66 for ; Wed, 3 Mar 2010 01:37:08 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1074636; Wed, 3 Mar 2010 10:37:09 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 4E39D23F028E; Wed, 3 Mar 2010 10:37:09 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 3 Mar 2010 10:37:09 +0100 From: "Elwell, John" To: Christer Holmberg , 'Dean Willis' Date: Wed, 3 Mar 2010 10:37:08 +0100 Thread-Topic: [sipcore] OPTIONS 3xx: To fork or not to fork? Thread-Index: Acq6GnCg+CZ8xeU2T1G7wVf/ompLDAAL6t+AABqYWVA= Message-ID: References: <3656743157.951988183@softarmor.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 09:37:10 -0000 Serial forking with early media depends on support for PRACK and UPDATE, wh= ich are not mandatory items for UAs and therefore will not always be availa= ble. John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 02 March 2010 20:57 > To: 'Dean Willis' > Cc: sipcore@ietf.org > Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? >=20 >=20 > Hi,=20 >=20 > >>>I would like to see #2 as a BCP. Not just for OPTIONS, but for all=20 > >>>cases that a proxy/registrar might fork an inbound request. > >> > >>Just to clarify, I guess you don't include dialog establsihment=20 > >>requests (INVITE, SUBSCRIBE)? They should always be=20 > forwarded/forked=20 > >>even if addressed to the AOR for which the registrar is=20 > responseible. > > > >I think he really meant ALL REQUESTS. Replace forked-up=20 > behavior with more predictable redirection. When you really=20 > need downstream-node forking, you probably need to do it in a=20 > B28UA to handle all the=20 > >possible responses, including media-path responses. Look at=20 > how Google Voice handles forking for an example. We have=20 > known for years that forking does not play well with PSTN=20 > gateways and early media,=20 > >but have persistently failed to deal with that problem. >=20 > I think serial forking can normally be handled pretty well,=20 > when it comes to early media etc. >=20 > The problem is generally parallel forking. >=20 > Regards, >=20 > Christer >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From john.elwell@siemens-enterprise.com Wed Mar 3 01:40:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB2E03A899A for ; Wed, 3 Mar 2010 01:40:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=0.214, 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 fYsj7HyDqUDJ for ; Wed, 3 Mar 2010 01:40:51 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 8BDE53A8A5C for ; Wed, 3 Mar 2010 01:40:51 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1074911; Wed, 3 Mar 2010 10:40:52 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 5227523F0298; Wed, 3 Mar 2010 10:40:52 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 3 Mar 2010 10:40:52 +0100 From: "Elwell, John" To: Dean Willis , Hans Erik van Elburg Date: Wed, 3 Mar 2010 10:40:51 +0100 Thread-Topic: [sipcore] OPTIONS 3xx: To fork or not to fork? Thread-Index: Acq6oq4slx6WgyHbRFKTOqAZZw4nPwAD7pqg Message-ID: References: <4B8C486A.5060400@nostrum.com> <4B8D1FE3.1050107@nostrum.com> <9ae56b1e1003020701t731ca950s1c6968256399ebc3@mail.gmail.com> <4B8D6B58.1070406@nostrum.com> <9ae56b1e1003021447u65c04b24i9e8cc3c65b0cc23e@mail.gmail.com> <21F06E40-A672-4497-92D2-B2F66A743A00@softarmor.com> In-Reply-To: <21F06E40-A672-4497-92D2-B2F66A743A00@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIPCORE Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 09:40:52 -0000 I would like to expand on this issue a little. Suppose I have at my home pr= oxy a policy whereby calls go to B1 and B2 in parallel, and after T seconds= of no answer calls instead go to B3 (voicemail, perhaps). There is no way = that the proxy could convey that policy in a 3xx response to the UAC. To ma= ke this policy (or similar policies) work, the proxy would need to manufact= urer temporary contact URIs that map to B1 and B2 and send these back in a = 302. It would then need to hope that the UAC does indeed establish new requ= ests in parallel to the two temporary contacts for B1 and B2. The proxy wou= ld need to treat the two requests as related and if both are unanswered aft= er T seconds, reject one with a 4xx and the other with a 302 (this time wit= h a third temporary contact URI mapped to B3). So policy CAN be met by the = proxy, although with dependence on the UAC doing the right thing. Elsewhere in this thread, somebody mentioned charging. The fact is that cal= ls might cross a domain that charges (e.g., for international calls via a s= erver provider into an enterprise that has a proxy that makes use of 302 re= sponses to achieve forking). Since only one of the calls should normally be= answered (or if a second is answered it should be cleared very quickly), c= harging based on duration after answer should not be a big issue. However, = if a domain charges for call establishment attempts, it could be a problem.= In this example, the domain handling the international leg would not be aw= are that the multiple calls are really part of the same call. I don't know = whether this is an issue in practice or not. John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Dean Willis > Sent: 03 March 2010 07:25 > To: Hans Erik van Elburg > Cc: SIPCORE > Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? >=20 >=20 > On Mar 2, 2010, at 4:47 PM, Hans Erik van Elburg wrote: >=20 > > Burden as in handling the forking process. Didn't ment to overload =20 > > that with lots of negative meaning. > > > > I thought the first part was more interesting. Where every forking =20 > > proxy becomes a redirect server. > > > > There are also other consequences, where youre home proxy will =20 > > always have the same way of handling youre contacts=20 > q-values. UAC's =20 > > come in a lot of different flavors, they will all behave slightly =20 > > different and most probably some will misbehave. So the=20 > UAS's owner =20 > > loose some predictability about how incoming calls will be=20 > handled. =20 > > No consistent experience, hard to explain. > > > > Also users will want to have services or policies be executed on =20 > > their behalf on their home proxy, how does such approach=20 > impact that. >=20 > Then the home proxy has to act as a B2BUA and do the expansion into =20 > multiple connected calls itself. >=20 > > > > Does such model mean anything to call setup delays,=20 > considering lets =20 > > say scenarios where there are several intermediary proxies =20 > > interconnecting some corporate voip clouds. > > > > Where the 3xx approach is very elegant in some cases, to say as a =20 > > general BCP that any forking proxy should send 3xx also for=20 > INVITEs =20 > > in any forking case seems in that respect over the top. >=20 > There are non-gateway scenarios where parallel forking=20 > actually works. =20 > We don't find them very often. >=20 > -- > Dean > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From christer.holmberg@ericsson.com Wed Mar 3 02:51:10 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 910293A8522 for ; Wed, 3 Mar 2010 02:51:10 -0800 (PST) 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 gPxMItUeXKD9 for ; Wed, 3 Mar 2010 02:51:09 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 888173A8282 for ; Wed, 3 Mar 2010 02:51:09 -0800 (PST) X-AuditID: c1b4fb3d-b7c72ae00000040e-ac-4b8e3f1d64cd Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 02.31.01038.D1F3E8B4; Wed, 3 Mar 2010 11:51:09 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.216]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 3 Mar 2010 11:51:09 +0100 From: Christer Holmberg To: "Elwell, John" , 'Dean Willis' Date: Wed, 3 Mar 2010 11:51:08 +0100 Thread-Topic: INVITE 3xx [was OPTIONS 3xx: To fork or not to fork?] Thread-Index: Acq6GnCg+CZ8xeU2T1G7wVf/ompLDAAL6t+AABqYWVAAAq4AYA== Message-ID: References: <3656743157.951988183@softarmor.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: [sipcore] INVITE 3xx [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 10:51:10 -0000 =20 Hi, >Serial forking with early media depends on support for PRACK=20 >and UPDATE, which are not mandatory items for UAs and=20 >therefore will not always be available. Well, that depends on how it is implemented, and if you want to give the UA= C control of the early media. But, even if the UAC is not able to control early media, serial forking wil= l at least ensure a single early media stream at a certain time. Regards, Christer > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > > Sent: 02 March 2010 20:57 > > To: 'Dean Willis' > > Cc: sipcore@ietf.org > > Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? > >=20 > >=20 > > Hi, > >=20 > > >>>I would like to see #2 as a BCP. Not just for OPTIONS,=20 > but for all=20 > > >>>cases that a proxy/registrar might fork an inbound request. > > >> > > >>Just to clarify, I guess you don't include dialog establsihment=20 > > >>requests (INVITE, SUBSCRIBE)? They should always be > > forwarded/forked > > >>even if addressed to the AOR for which the registrar is > > responseible. > > > > > >I think he really meant ALL REQUESTS. Replace forked-up > > behavior with more predictable redirection. When you really need=20 > > downstream-node forking, you probably need to do it in a B28UA to=20 > > handle all the > > >possible responses, including media-path responses. Look at > > how Google Voice handles forking for an example. We have known for=20 > > years that forking does not play well with PSTN gateways and early=20 > > media, > > >but have persistently failed to deal with that problem. > >=20 > > I think serial forking can normally be handled pretty well, when it=20 > > comes to early media etc. > >=20 > > The problem is generally parallel forking. > >=20 > > Regards, > >=20 > > Christer > >=20 > >=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > = From christer.holmberg@ericsson.com Wed Mar 3 02:57:10 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F10228C314 for ; Wed, 3 Mar 2010 02:57:10 -0800 (PST) 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=[AWL=0.000, 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 gccnudWHqJ3U for ; Wed, 3 Mar 2010 02:57:09 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id C118A28C325 for ; Wed, 3 Mar 2010 02:57:08 -0800 (PST) X-AuditID: c1b4fb3d-b7c72ae00000040e-44-4b8e4084944f Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id A7.02.01038.4804E8B4; Wed, 3 Mar 2010 11:57:09 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.216]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 3 Mar 2010 11:56:39 +0100 From: Christer Holmberg To: "Elwell, John" , Dean Willis , Hans Erik van Elburg Date: Wed, 3 Mar 2010 11:56:37 +0100 Thread-Topic: INVITE 3xx [was OPTIONS 3xx: To fork or not to fork?] Thread-Index: Acq6oq4slx6WgyHbRFKTOqAZZw4nPwAD7pqgAANFutA= Message-ID: References: <4B8C486A.5060400@nostrum.com> <4B8D1FE3.1050107@nostrum.com> <9ae56b1e1003020701t731ca950s1c6968256399ebc3@mail.gmail.com> <4B8D6B58.1070406@nostrum.com> <9ae56b1e1003021447u65c04b24i9e8cc3c65b0cc23e@mail.gmail.com> <21F06E40-A672-4497-92D2-B2F66A743A00@softarmor.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: [sipcore] INVITE 3xx [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 10:57:10 -0000 =20 Hi, >I would like to expand on this issue a little. Suppose I have=20 >at my home proxy a policy whereby calls go to B1 and B2 in=20 >parallel, and after T seconds of no answer calls instead go=20 >to B3 (voicemail, perhaps). There is no way that the proxy=20 >could convey that policy in a 3xx response to the UAC. To=20 >make this policy (or similar policies) work, the proxy would=20 >need to manufacturer temporary contact URIs that map to B1=20 >and B2 and send these back in a 302. It would then need to=20 >hope that the UAC does indeed establish new requests in=20 >parallel to the two temporary contacts for B1 and B2. The=20 >proxy would need to treat the two requests as related and if=20 >both are unanswered after T seconds, reject one with a 4xx=20 >and the other with a 302 (this time with a third temporary=20 >contact URI mapped to B3). So policy CAN be met by the proxy,=20 >although with dependence on the UAC doing the right thing. >=20 >Elsewhere in this thread, somebody mentioned charging. The=20 >fact is that calls might cross a domain that charges (e.g.,=20 >for international calls via a server provider into an=20 >enterprise that has a proxy that makes use of 302 responses=20 >to achieve forking). Since only one of the calls should=20 >normally be answered (or if a second is answered it should be=20 >cleared very quickly), charging based on duration after=20 >answer should not be a big issue. However, if a domain=20 >charges for call establishment attempts, it could be a=20 >problem. In this example, the domain handling the=20 >international leg would not be aware that the multiple calls=20 >are really part of the same call. I don't know whether this=20 >is an issue in practice or not. I am the one who mentioned charging. Maybe charging as such is not a big problem. I am more concerned about how = network services are affected. In your example above, where B1 sends 4xx and B2 sends 302, the forking pro= xy needs to know that the calls are related. Maybe some correlation header = field can be used for that, or maybe it can somehow be embedded into the te= mporary contact URI, but the correlation still needs to be there. Regards, Christer > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Dean Willis > > Sent: 03 March 2010 07:25 > > To: Hans Erik van Elburg > > Cc: SIPCORE > > Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? > >=20 > >=20 > > On Mar 2, 2010, at 4:47 PM, Hans Erik van Elburg wrote: > >=20 > > > Burden as in handling the forking process. Didn't ment to=20 > overload=20 > > > that with lots of negative meaning. > > > > > > I thought the first part was more interesting. Where=20 > every forking=20 > > > proxy becomes a redirect server. > > > > > > There are also other consequences, where youre home proxy will=20 > > > always have the same way of handling youre contacts > > q-values. UAC's > > > come in a lot of different flavors, they will all behave slightly=20 > > > different and most probably some will misbehave. So the > > UAS's owner > > > loose some predictability about how incoming calls will be > > handled. =20 > > > No consistent experience, hard to explain. > > > > > > Also users will want to have services or policies be executed on=20 > > > their behalf on their home proxy, how does such approach > > impact that. > >=20 > > Then the home proxy has to act as a B2BUA and do the=20 > expansion into=20 > > multiple connected calls itself. > >=20 > > > > > > Does such model mean anything to call setup delays, > > considering lets > > > say scenarios where there are several intermediary proxies=20 > > > interconnecting some corporate voip clouds. > > > > > > Where the 3xx approach is very elegant in some cases, to say as a=20 > > > general BCP that any forking proxy should send 3xx also for > > INVITEs > > > in any forking case seems in that respect over the top. > >=20 > > There are non-gateway scenarios where parallel forking=20 > actually works. > > We don't find them very often. > >=20 > > -- > > Dean > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From kpfleming@digium.com Wed Mar 3 04:25:08 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56D8228C350 for ; Wed, 3 Mar 2010 04:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.56 X-Spam-Level: X-Spam-Status: No, score=-106.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 KEpZRcew7rye for ; Wed, 3 Mar 2010 04:25:06 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id B1F4428C34D for ; Wed, 3 Mar 2010 04:25:06 -0800 (PST) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1NmndQ-0004VW-3T; Wed, 03 Mar 2010 06:25:04 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id F360A1A2009; Wed, 3 Mar 2010 06:25:03 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaOFgL3v0PeF; Wed, 3 Mar 2010 06:25:03 -0600 (CST) Received: from [172.19.1.105] (173-24-204-40.client.mchsi.com [173.24.204.40]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 22619D8003; Wed, 3 Mar 2010 06:25:03 -0600 (CST) Message-ID: <4B8E551E.3080309@digium.com> Date: Wed, 03 Mar 2010 06:25:02 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Christer Holmberg References: <4B8D460E.3040205@digium.com> <4B8D4A90.30508@cisco.com> <4B8D4CA0.6090904@digium.com> <4B8D51D8.6090501@cisco.com> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Comments on draft-ieft-sipcore-reinvite-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 12:25:08 -0000 Christer Holmberg wrote: > If you use different ports, and you use ICE, I guess that means that you need to perform new ICE procedures for that port before you can start using it. That would be true, yes. On the SIP Forum mailing list when I brought this up there were comments about 'using the same port will keep the NAT mapping open if there is one', but that's only true if both endpoints use the same port for the replaced media stream. I suppose that the real cause of this issue is UDPTL itself, and the fact that it's not possible to easily discriminate between UDPTL and RTP. If the T.38 media stream was in audio/t38 mode (and thus using RTP for transport), as long as the payload number chosen was not one of the possible options for the previous media stream, discrimination of the incoming packets would be trivial. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org From kpfleming@digium.com Wed Mar 3 07:25:58 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E81428C102 for ; Wed, 3 Mar 2010 07:25:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.573 X-Spam-Level: X-Spam-Status: No, score=-106.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 Db1mVd3YWdJn for ; Wed, 3 Mar 2010 07:25:57 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id EAB2C3A8A71 for ; Wed, 3 Mar 2010 07:25:56 -0800 (PST) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1NmqSQ-0006Gu-FI; Wed, 03 Mar 2010 09:25:54 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 6DB701A2009; Wed, 3 Mar 2010 09:25:54 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+xyqcOZfXaY; Wed, 3 Mar 2010 09:25:54 -0600 (CST) Received: from [172.19.1.105] (173-24-204-40.client.mchsi.com [173.24.204.40]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id AA405D8003; Wed, 3 Mar 2010 09:25:53 -0600 (CST) Message-ID: <4B8E7F80.90801@digium.com> Date: Wed, 03 Mar 2010 09:25:52 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Christer Holmberg References: <4B8D460E.3040205@digium.com> <4B8D4A90.30508@cisco.com> <4B8D4CA0.6090904@digium.com> <4B8D51D8.6090501@cisco.com> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Comments on draft-ieft-sipcore-reinvite-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 15:25:58 -0000 Christer Holmberg wrote: > If you use different ports, and you use ICE, I guess that means that you need to perform new ICE procedures for that port before you can start using it. While hashing over this I came up with another scenario where the 'media exchanged using new parameters' trigger is not sufficient to actually know that an offerer's changes have been executed, so I'd like to propose an alternative way of describing this problem that may also make it more appropriate for inclusion in this draft. As a degenerate case of the 'port number did not change' scenario, imagine that an endpoint is currently exchanging audio media using the iLBC codec over RTP, which requires usage of a dynamic payload number since iLBC does not have an assigned payload number. Later, it wants to switch to Speex, which also does not have an assigned payload number, so it sends a re-INVITE with an offer that uses the same port number *and* payload number, but provides an rtpmap from that payload number to Speex instead of iLBC. Again in this scenario the offerer cannot safely use 'media exchanged using the new parameters' as a trigger for 'changes have been executed' because in-flight RTP packets will have that payload number already. I understand this is a contrived scenario, but it does not seem that far outside the bounds of what implementors tend to do :-) So, I'd like to propose this sort of language instead: An offerer in a re-INVITE transaction is allowed by RFC3261 to treat its offered changes as 'executed' based on *either* receiving a non-error response to its offer *or* determining that media has been exchanged using the new session parameters. However, if the offer's session parameters do not differ sufficiently from the previous session state to allow this determination to be made conclusively, the offerer should not use media exchange as the threshold for execution of the changes, and should instead use only the reception of a non-error response as the trigger. This affords the answerer the opportunity to provide an error response to the offer if desired without the two endpoints getting out of sync in their understanding of the session state. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org From adam@nostrum.com Wed Mar 3 08:07:34 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E64CC3A8B23 for ; Wed, 3 Mar 2010 08:07:34 -0800 (PST) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 6NcHzhuIzu-T for ; Wed, 3 Mar 2010 08:07:33 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id E5D5C3A8A92 for ; Wed, 3 Mar 2010 08:07:32 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o23G7UDw024430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 Mar 2010 10:07:31 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B8E8942.5080105@nostrum.com> Date: Wed, 03 Mar 2010 10:07:30 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: SIPCORE Content-Type: multipart/alternative; boundary="------------060701090909020007020308" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] Fwd: request for help in developing a tool that may be helpful to WG chairs X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 16:07:35 -0000 This is a multi-part message in MIME format. --------------060701090909020007020308 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [as chair] SIPCORE participants: Please consider filling out the survey cited below. Thanks. /a -------- Original Message -------- Subject: request for help in developing a tool that may be helpful to WG chairs Date: Wed, 3 Mar 2010 10:36:19 -0500 (EST) From: sob@harvard.edu (Scott O. Bradner) To: wgchairs@ietf.org IETF working group chairs; We are developing an open-source tool for monitoring the status and progress of conflicts in on-line working groups (WG). The tool works by analyzing the WG mailing list. When developed, this tool should be helpful to WG chairs trying to understand the status of WG discussions (how close to consensus is the WG, what is the distribution of participation, etc). As part of the development process we have been using a prototype tool to analyze IETF WG mailing list archives to determine the amount of conflict and how effective this conflict is being (has been) resolved. As the first step, we need to understand the relationship between the conflicts in a working group and the structure of the communication network in that group. While having conflicts is not necessarily a bad thing for a working group effort, some conflicts can escalate into disasters. We are interested in finding the communication patterns related to the evolution of group conflicts. Results from this study will provide the base for the development of the tool that helps working group chairs to decide when to intervene with an internal conflict before it becomes irreversibly negative as well as being a tool that may help determine where there is consensus on a particular topic. We would like your help in understanding the level of conflicts within your working groups and how the conflicts affect productivity and group members' perception on the working group. It will be greatly appreciated if you could ask your WG members to anonymously fill a short survey at https://spreadsheets.google.com/viewform?hl=en&formkey=dExTbEU5QmRncnhFbjhQUVR4bzBGMEE6MA Thank you! Best Regards, Bin Zhu, Mark Gaynor, Scott Bradner, and Jialun Qin --------------060701090909020007020308 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit [as chair]

SIPCORE participants:

Please consider filling out the survey cited below. Thanks.

/a

-------- Original Message --------
Subject: request for help in developing a tool that may be helpful to WG chairs
Date: Wed, 3 Mar 2010 10:36:19 -0500 (EST)
From: sob@harvard.edu (Scott O. Bradner)
To: wgchairs@ietf.org 


IETF working group chairs;

We are developing an open-source tool for monitoring the status and
progress of conflicts in on-line working groups (WG).  The tool works by
analyzing the WG mailing list.  When developed, this tool should be
helpful to WG chairs trying to understand the status of WG discussions
(how close to consensus is the WG, what is the distribution of
participation, etc).

As part of the development process we have been using a prototype tool
to analyze IETF WG mailing list archives to determine the amount of
conflict and how effective this conflict is being (has been) resolved.
As the first step, we need to understand the relationship between the
conflicts in a working group and the structure of the communication
network in that group. While having conflicts is not necessarily a bad
thing for a working group effort, some conflicts can escalate into
disasters. We are interested in finding the communication patterns
related to the evolution of group conflicts. Results from this study
will provide the base for the development of the tool that helps working
group chairs to decide when to intervene with an internal conflict
before it becomes irreversibly negative as well as being a tool that may
help determine where there is consensus on a particular topic.

We would like your help in understanding the level of conflicts within
your working groups and how the conflicts affect productivity and group
members' perception on the working group. It will be greatly appreciated
if you could ask your WG members to anonymously fill a short survey at 

https://spreadsheets.google.com/viewform?hl=en&formkey=dExTbEU5QmRncnhFbjhQUVR4bzBGMEE6MA

Thank you!

Best Regards, 

Bin Zhu, Mark Gaynor, Scott Bradner, and Jialun Qin
--------------060701090909020007020308-- From pkyzivat@cisco.com Wed Mar 3 09:41:56 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02F2628C1C8 for ; Wed, 3 Mar 2010 09:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.43 X-Spam-Level: X-Spam-Status: No, score=-10.43 tagged_above=-999 required=5 tests=[AWL=0.169, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 6K-DzmIULxxr for ; Wed, 3 Mar 2010 09:41:54 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id AE5FC28C163 for ; Wed, 3 Mar 2010 09:41:54 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAK4ujktAZnwN/2dsb2JhbACbBnOoPphYhHwEgxc X-IronPort-AV: E=Sophos;i="4.49,574,1262563200"; d="scan'208";a="90200297" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 03 Mar 2010 17:41:55 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o23Hft3W002394; Wed, 3 Mar 2010 17:41:55 GMT Message-ID: <4B8E9F60.2020106@cisco.com> Date: Wed, 03 Mar 2010 12:41:52 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Kevin P. Fleming" References: <4B8D460E.3040205@digium.com> <4B8D4A90.30508@cisco.com> <4B8D4CA0.6090904@digium.com> <4B8D51D8.6090501@cisco.com> <4B8E7F80.90801@digium.com> In-Reply-To: <4B8E7F80.90801@digium.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Comments on draft-ieft-sipcore-reinvite-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 17:41:56 -0000 Kevin, Once a payload number has been bound to a codec in a session, it isn't supposed to be used for anything else in that session. (I'll have to hunt to find the text that says that, but its somewhere.) However it turns out that this is another one of those things that can be broken by 3pcc. So a robust implementation should be prepared to cope with this if it happens - to the extent that there is sufficient information to cope. E.g. if a payload number that was once mentioned has not been in use for awhile, a robust implementation ought to be capable of supporting its subsequent use for a different codec. Anyway, when this is just UA-UA, a conforming implementation will not get into the situation you describe. Thanks, Paul Kevin P. Fleming wrote: > Christer Holmberg wrote: > >> If you use different ports, and you use ICE, I guess that means that you need to perform new ICE procedures for that port before you can start using it. > > While hashing over this I came up with another scenario where the 'media > exchanged using new parameters' trigger is not sufficient to actually > know that an offerer's changes have been executed, so I'd like to > propose an alternative way of describing this problem that may also make > it more appropriate for inclusion in this draft. > > As a degenerate case of the 'port number did not change' scenario, > imagine that an endpoint is currently exchanging audio media using the > iLBC codec over RTP, which requires usage of a dynamic payload number > since iLBC does not have an assigned payload number. Later, it wants to > switch to Speex, which also does not have an assigned payload number, so > it sends a re-INVITE with an offer that uses the same port number *and* > payload number, but provides an rtpmap from that payload number to Speex > instead of iLBC. Again in this scenario the offerer cannot safely use > 'media exchanged using the new parameters' as a trigger for 'changes > have been executed' because in-flight RTP packets will have that payload > number already. I understand this is a contrived scenario, but it does > not seem that far outside the bounds of what implementors tend to do :-) > > So, I'd like to propose this sort of language instead: > > An offerer in a re-INVITE transaction is allowed by RFC3261 to treat its > offered changes as 'executed' based on *either* receiving a non-error > response to its offer *or* determining that media has been exchanged > using the new session parameters. However, if the offer's session > parameters do not differ sufficiently from the previous session state to > allow this determination to be made conclusively, the offerer should not > use media exchange as the threshold for execution of the changes, and > should instead use only the reception of a non-error response as the > trigger. This affords the answerer the opportunity to provide an error > response to the offer if desired without the two endpoints getting out > of sync in their understanding of the session state. > From pkyzivat@cisco.com Wed Mar 3 09:50:01 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 872C028C1B7 for ; Wed, 3 Mar 2010 09:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.447 X-Spam-Level: X-Spam-Status: No, score=-10.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 dRidzse2filq for ; Wed, 3 Mar 2010 09:50:00 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id BF73E28C18D for ; Wed, 3 Mar 2010 09:49:56 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFMwjktAZnwM/2dsb2JhbACbBnOoQ5hYhHwEgxc X-IronPort-AV: E=Sophos;i="4.49,574,1262563200"; d="scan'208";a="304776385" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by sj-iport-1.cisco.com with ESMTP; 03 Mar 2010 17:49:58 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o23HnvC7026446; Wed, 3 Mar 2010 17:49:57 GMT Message-ID: <4B8EA142.3000107@cisco.com> Date: Wed, 03 Mar 2010 12:49:54 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Hans Erik van Elburg References: <4B8C486A.5060400@nostrum.com> <4B8D1FE3.1050107@nostrum.com> <9ae56b1e1003020701t731ca950s1c6968256399ebc3@mail.gmail.com> <4B8D6B58.1070406@nostrum.com> <9ae56b1e1003030042m3a6de8f6x7f13afa7725b1ff4@mail.gmail.com> In-Reply-To: <9ae56b1e1003030042m3a6de8f6x7f13afa7725b1ff4@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 17:50:01 -0000 Hans Erik van Elburg wrote: > Forking in essence is a service provided by a downstream proxy (serving > domein B.com) to a user that has multiple devices registered to this > proxy. This service (served to him by his own domain) will allow him to > receive calls at any of his devices. > > To push the responsibility for providing this service of a B.com user > to another domain lets say A.com, is to say the least problematic. Even > if it solves some issues like those related to early media and HERFP, it > introduces lots of other issues. Forking downstream doesn't relieve the upstream device of burden, it simply makes it be a different burden. If the downstream server wants to take this on, a B2BUA could be a better choice. And regardless of whether user B views this as a service to him, user A may also regard it as a service to him to see the multiple contacts and be able to choose among them. Thanks, Paul From ietf.hanserik@gmail.com Wed Mar 3 10:06:16 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B96F83A8B99 for ; Wed, 3 Mar 2010 10:06:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 dBi2HBemddnf for ; Wed, 3 Mar 2010 10:06:15 -0800 (PST) Received: from mail-ew0-f215.google.com (mail-ew0-f215.google.com [209.85.219.215]) by core3.amsl.com (Postfix) with ESMTP id 5F3373A87DE for ; Wed, 3 Mar 2010 10:06:15 -0800 (PST) Received: by ewy7 with SMTP id 7so1117410ewy.29 for ; Wed, 03 Mar 2010 10:06:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=GYOilDyCW9o1wX78Jbw43rlqszD0/C/LbSBG1q5y6hE=; b=JY7hY0lHsf5HvB0iQd4A+K70h9sYxhG5SjAwA86jnjXyeyf/K4EoJtETji3XfJAhlj oTh3g9S0QdGZ3sToBZpTsS5rnnSOfH0vFonXNbotVDOSskY0ukrPtu/obo1HKoLyQNts f8jae74VkLYiLOG9c7TDBjVoiPCnQpCbgU9s8= 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; b=vPDZe8p4EAZfC4zIpXdzrolV9kSXD/QLFD2FV3/cc5v0iJcFU1KmKQI7WJ3jntkNxz 5AVY8wRe1nqqRNQHooKaFjlf8/3JmMrDVOKeqQ0XVwCcccJwQ/zO/2x569mLLC4Rywdi 4HvbpGd8/2Mf0j5uNQ8ToCsiok22gB8+XBD9E= MIME-Version: 1.0 Received: by 10.213.96.68 with SMTP id g4mr2494379ebn.77.1267639571389; Wed, 03 Mar 2010 10:06:11 -0800 (PST) In-Reply-To: <4B8EA142.3000107@cisco.com> References: <4B8D1FE3.1050107@nostrum.com> <9ae56b1e1003020701t731ca950s1c6968256399ebc3@mail.gmail.com> <4B8D6B58.1070406@nostrum.com> <9ae56b1e1003030042m3a6de8f6x7f13afa7725b1ff4@mail.gmail.com> <4B8EA142.3000107@cisco.com> Date: Wed, 3 Mar 2010 19:06:11 +0100 Message-ID: <9ae56b1e1003031006n6b3fa5adoeb2921a5baed7513@mail.gmail.com> From: Hans Erik van Elburg To: Paul Kyzivat Content-Type: multipart/alternative; boundary=00504502c6e55b1c9d0480e95677 Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 18:06:17 -0000 --00504502c6e55b1c9d0480e95677 Content-Type: text/plain; charset=ISO-8859-1 Demonstrating the point that a simple BCP saying "though shalt always send 3xx in all INVITE forking cases" is not appropriate. More inline... /Hans Erik van Elburg On Wed, Mar 3, 2010 at 6:49 PM, Paul Kyzivat wrote: > > > Hans Erik van Elburg wrote: > >> Forking in essence is a service provided by a downstream proxy (serving >> domein B.com) to a user that has multiple devices registered to this proxy. >> This service (served to him by his own domain) will allow him to receive >> calls at any of his devices. >> >> To push the responsibility for providing this service of a B.com user to >> another domain lets say A.com, is to say the least problematic. Even if it >> solves some issues like those related to early media and HERFP, it >> introduces lots of other issues. >> > > Forking downstream doesn't relieve the upstream device of burden, it simply > makes it be a different burden. > > Agree. > If the downstream server wants to take this on, a B2BUA could be a better > choice. > > Maybe. > And regardless of whether user B views this as a service to him, user A may > also regard it as a service to him to see the multiple contacts and be able > to choose among them. > > Well it is hard to see how B's forking proxy's behaviour for INVITEs can be seen as a service to A. Also INVITE does not express A's wish to see B's contacts, but a wish of A's UA to establish a session with whatever UA that B registered. Of course A may want to know B's multiple contacts, but if you phrase it like that it is indeed more of a presence use case and you would not use INVITE for that. --00504502c6e55b1c9d0480e95677 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Demonstrating the point that a simple BCP saying "though shalt always = send 3xx in all INVITE forking cases" is not appropriate.

More = inline...

/Hans Erik van Elburg

On Wed, Mar 3, 2010 at 6:49 PM, Paul Kyzivat= <pkyzivat@cisco= .com> wrote:


Hans Erik van Elburg wrote:
Forking in essence =A0is a service provided by a downstream proxy (serving = domein B.com) to a user that has multiple devices registered to this proxy.= This service (served to him by his own domain) will allow him to receive c= alls at any of his devices.

To push the responsibility for providing =A0this service of a B.com user to= another domain lets say A.com, is to say the least problematic. Even if it= solves some issues like those related to early media and HERFP, it introdu= ces lots of other issues.

Forking downstream doesn't relieve the upstream device of burden, it si= mply makes it be a different burden.

Agree.
=A0
If the downstream server wants to take this on, a B2BUA could be a better c= hoice.

Maybe.
=A0
And regardless of whether user B views this as a service to him, user A may= also regard it as a service to him to see the multiple contacts and be abl= e to choose among them.

Well it is hard to see how B's forking proxy'= s behaviour for INVITEs can be seen as a service to A. Also INVITE does not= express A's wish to see B's contacts, but a wish of A's UA to = establish a session with whatever UA that B registered.

Of course A may want to know B's multiple contacts, but if you phra= se it like that it is indeed more of a presence use case and you would not = use INVITE for that.
=A0

--00504502c6e55b1c9d0480e95677-- From christer.holmberg@ericsson.com Wed Mar 3 12:03:18 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D92D28C4AD for ; Wed, 3 Mar 2010 12:03:18 -0800 (PST) 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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 0Xt0YPQAFf2F for ; Wed, 3 Mar 2010 12:03:16 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id ABCC628C45A for ; Wed, 3 Mar 2010 12:03:02 -0800 (PST) X-AuditID: c1b4fb3d-b7c72ae00000040e-9f-4b8ec076baf7 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id C2.83.01038.670CE8B4; Wed, 3 Mar 2010 21:03:02 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.216]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 3 Mar 2010 21:03:02 +0100 From: Christer Holmberg To: 'Hans Erik van Elburg' , Paul Kyzivat Date: Wed, 3 Mar 2010 21:03:00 +0100 Thread-Topic: [sipcore] INVITE 3xx [was OPTIONS 3xx: To fork or not to fork?] Thread-Index: Acq6/Egur0+m+xymTDGsNHhrq+7q/wAD8X2Q Message-ID: References: <4B8D1FE3.1050107@nostrum.com> <9ae56b1e1003020701t731ca950s1c6968256399ebc3@mail.gmail.com> <4B8D6B58.1070406@nostrum.com> <9ae56b1e1003030042m3a6de8f6x7f13afa7725b1ff4@mail.gmail.com> <4B8EA142.3000107@cisco.com> <9ae56b1e1003031006n6b3fa5adoeb2921a5baed7513@mail.gmail.com> In-Reply-To: <9ae56b1e1003031006n6b3fa5adoeb2921a5baed7513@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FF84A09F50A6DC48ACB6714F4666CC745C1102CCC4ESESSCMS0354e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 20:03:18 -0000 --_000_FF84A09F50A6DC48ACB6714F4666CC745C1102CCC4ESESSCMS0354e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I am not sure a BCP can say "SHALL" about anything... Also, I don't think we could mandate such behavior. Too many things would g= et messed up. Do I see "SIP 3.0" on Dean's lips? ;) Regards, Christer ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] Sent: 3. maaliskuuta 2010 20:06 To: Paul Kyzivat Cc: Christer Holmberg; SIPCORE Subject: Re: [sipcore] INVITE 3xx [was OPTIONS 3xx: To fork or not to fork?= ] Demonstrating the point that a simple BCP saying "though shalt always send = 3xx in all INVITE forking cases" is not appropriate. More inline... /Hans Erik van Elburg On Wed, Mar 3, 2010 at 6:49 PM, Paul Kyzivat > wrote: Hans Erik van Elburg wrote: Forking in essence is a service provided by a downstream proxy (serving do= mein B.com) to a user that has multiple devices registered to this proxy. T= his service (served to him by his own domain) will allow him to receive cal= ls at any of his devices. To push the responsibility for providing this service of a B.com user to a= nother domain lets say A.com, is to say the least problematic. Even if it s= olves some issues like those related to early media and HERFP, it introduce= s lots of other issues. Forking downstream doesn't relieve the upstream device of burden, it simply= makes it be a different burden. Agree. If the downstream server wants to take this on, a B2BUA could be a better c= hoice. Maybe. And regardless of whether user B views this as a service to him, user A may= also regard it as a service to him to see the multiple contacts and be abl= e to choose among them. Well it is hard to see how B's forking proxy's behaviour for INVITEs can be= seen as a service to A. Also INVITE does not express A's wish to see B's c= ontacts, but a wish of A's UA to establish a session with whatever UA that = B registered. Of course A may want to know B's multiple contacts, but if you phrase it li= ke that it is indeed more of a presence use case and you would not use INVI= TE for that. --_000_FF84A09F50A6DC48ACB6714F4666CC745C1102CCC4ESESSCMS0354e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I am not sure a BCP can say "SHALL" about anythi= ng...=20
 
Also, I don't think we could mandate such behavi= or. Too=20 many things would get messed up.
 
Do I see "SIP 3.0" on Dean's lips?=20 ;)
 
Regards,
 
Christer
 
 

From: Hans Erik van Elburg=20 [mailto:ietf.hanserik@gmail.com]
Sent: 3. maaliskuuta 2010=20 20:06
To: Paul Kyzivat
Cc: Christer Holmberg;=20 SIPCORE
Subject: Re: [sipcore] INVITE 3xx [was OPTIONS 3xx: To fo= rk or=20 not to fork?]

Demonstrating the point that a simple BCP saying "though shalt a= lways=20 send 3xx in all INVITE forking cases" is not appropriate.

More=20 inline...

/Hans Erik van Elburg

On Wed, Mar 3, 2010 at 6:49 PM, Paul Kyzivat <pkyzivat@cisco.com> wrote:=


Hans Erik van Elburg wrote:
Forking=20 in essence  is a service provided by a downstream proxy (serving d= omein=20 B.com) to a user that has multiple devices registered to this proxy. Th= is=20 service (served to him by his own domain) will allow him to receive cal= ls at=20 any of his devices.

To push the responsibility for providing=20  this service of a B.com user to another domain lets say A.com, is= to=20 say the least problematic. Even if it solves some issues like those rel= ated=20 to early media and HERFP, it introduces lots of other=20 issues.

Forking downstream doesn't relieve the= =20 upstream device of burden, it simply makes it be a different=20 burden.

Agree.
 
If=20 the downstream server wants to take this on, a B2BUA could be a better=20 choice.

Maybe.
 
And=20 regardless of whether user B views this as a service to him, user A may a= lso=20 regard it as a service to him to see the multiple contacts and be able to= =20 choose among them.

Well it is hard to see how B's forking proxy's behaviour for INVITEs c= an be=20 seen as a service to A. Also INVITE does not express A's wish to see B's=20 contacts, but a wish of A's UA to establish a session with whatever UA that= B=20 registered.

Of course A may want to know B's multiple contacts, but = if=20 you phrase it like that it is indeed more of a presence use case and you wo= uld=20 not use INVITE for that.
 

--_000_FF84A09F50A6DC48ACB6714F4666CC745C1102CCC4ESESSCMS0354e_-- From kpfleming@digium.com Wed Mar 3 12:54:12 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D2283A8C77 for ; Wed, 3 Mar 2010 12:54:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] 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 yoU0yKOVP7nn for ; Wed, 3 Mar 2010 12:54:11 -0800 (PST) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id 1E1733A82F0 for ; Wed, 3 Mar 2010 12:54:08 -0800 (PST) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1Nmva2-00036t-N7; Wed, 03 Mar 2010 14:54:06 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id A1237D8004; Wed, 3 Mar 2010 14:54:06 -0600 (CST) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vze6iI2UyWmN; Wed, 3 Mar 2010 14:54:06 -0600 (CST) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 58DE7D8003; Wed, 3 Mar 2010 14:54:06 -0600 (CST) Message-ID: <4B8ECC6D.6040500@digium.com> Date: Wed, 03 Mar 2010 14:54:05 -0600 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Paul Kyzivat References: <4B8D460E.3040205@digium.com> <4B8D4A90.30508@cisco.com> <4B8D4CA0.6090904@digium.com> <4B8D51D8.6090501@cisco.com> <4B8E7F80.90801@digium.com> <4B8E9F60.2020106@cisco.com> In-Reply-To: <4B8E9F60.2020106@cisco.com> X-Enigmail-Version: 0.95.7 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Comments on draft-ieft-sipcore-reinvite-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2010 20:54:12 -0000 Paul Kyzivat wrote: > Once a payload number has been bound to a codec in a session, it isn't > supposed to be used for anything else in that session. (I'll have to > hunt to find the text that says that, but its somewhere.) OK, that makes complete sense. > However it turns out that this is another one of those things that can > be broken by 3pcc. So a robust implementation should be prepared to cope > with this if it happens - to the extent that there is sufficient > information to cope. E.g. if a payload number that was once mentioned > has not been in use for awhile, a robust implementation ought to be > capable of supporting its subsequent use for a different codec. > > Anyway, when this is just UA-UA, a conforming implementation will not > get into the situation you describe. That does help then. Thanks for the information. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org From gonzalo.camarillo@ericsson.com Wed Mar 3 23:49:41 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D13E3A86DC for ; Wed, 3 Mar 2010 23:49:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 FmYYCSSdnRYs for ; Wed, 3 Mar 2010 23:49:40 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 3E5233A7C68 for ; Wed, 3 Mar 2010 23:49:37 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-39-4b8f66116a49 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 12.FC.31641.1166F8B4; Thu, 4 Mar 2010 08:49:37 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Mar 2010 08:49:37 +0100 Received: from [131.160.126.152] ([131.160.126.152]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Mar 2010 08:49:37 +0100 Message-ID: <4B8F6611.7010201@ericsson.com> Date: Thu, 04 Mar 2010 09:49:37 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Kevin P. Fleming" References: <4B8D460E.3040205@digium.com> In-Reply-To: <4B8D460E.3040205@digium.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Mar 2010 07:49:37.0520 (UTC) FILETIME=[3D26D700:01CABB6F] X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Comments on draft-ieft-sipcore-reinvite-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 07:49:41 -0000 Hi Kevin, > Editorial comments: > > Section 1: > > "There has been some confusion among implentors regarding how a UAS" > > ... should be 'implementors'. Fixed. > Section 3.7: > > SDP4 is improperly formatted. Fixed. Thanks, Gonzalo From gonzalo.camarillo@ericsson.com Thu Mar 4 00:01:41 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A42F03A8C3A for ; Thu, 4 Mar 2010 00:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 8DJoLQ5R8YiA for ; Thu, 4 Mar 2010 00:01:40 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 9EB703A8B0A for ; Thu, 4 Mar 2010 00:01:40 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-2d-4b8f68e5d4d1 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 4C.6E.31641.5E86F8B4; Thu, 4 Mar 2010 09:01:41 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Mar 2010 09:01:40 +0100 Received: from [131.160.126.152] ([131.160.126.152]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Mar 2010 09:01:40 +0100 Message-ID: <4B8F68E4.20408@ericsson.com> Date: Thu, 04 Mar 2010 10:01:40 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Kevin P. Fleming" References: <4B8D460E.3040205@digium.com> <4B8D4A90.30508@cisco.com> <4B8D4CA0.6090904@digium.com> <4B8D51D8.6090501@cisco.com> <4B8E7F80.90801@digium.com> <4B8E9F60.2020106@cisco.com> <4B8ECC6D.6040500@digium.com> In-Reply-To: <4B8ECC6D.6040500@digium.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Mar 2010 08:01:40.0084 (UTC) FILETIME=[EBD55B40:01CABB70] X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Comments on draft-ieft-sipcore-reinvite-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 08:01:41 -0000 Hi, yes, what Paul indicates is documented in Section 8.3.2 of RFC 3264: http://tools.ietf.org/html/rfc3264#section-8.3.2 "However, in the case of RTP, the mapping from a particular dynamic payload type number to a particular codec within that media stream MUST NOT change for the duration of a session." Cheers, Gonzalo Kevin P. Fleming wrote: > Paul Kyzivat wrote: > >> Once a payload number has been bound to a codec in a session, it isn't >> supposed to be used for anything else in that session. (I'll have to >> hunt to find the text that says that, but its somewhere.) > > OK, that makes complete sense. > >> However it turns out that this is another one of those things that can >> be broken by 3pcc. So a robust implementation should be prepared to cope >> with this if it happens - to the extent that there is sufficient >> information to cope. E.g. if a payload number that was once mentioned >> has not been in use for awhile, a robust implementation ought to be >> capable of supporting its subsequent use for a different codec. >> >> Anyway, when this is just UA-UA, a conforming implementation will not >> get into the situation you describe. > > That does help then. Thanks for the information. > From gonzalo.camarillo@ericsson.com Thu Mar 4 00:29:29 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99BF33A7D53 for ; Thu, 4 Mar 2010 00:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 OpvxqMW8gdxQ for ; Thu, 4 Mar 2010 00:29:28 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id A0DDD3A7977 for ; Thu, 4 Mar 2010 00:29:27 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-56-4b8f6f67875a Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 90.12.31641.76F6F8B4; Thu, 4 Mar 2010 09:29:28 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Mar 2010 09:29:27 +0100 Received: from [131.160.126.152] ([131.160.126.152]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Mar 2010 09:29:26 +0100 Message-ID: <4B8F6F66.7030301@ericsson.com> Date: Thu, 04 Mar 2010 10:29:26 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Kevin P. Fleming" References: <4B8D460E.3040205@digium.com> <4B8D4A90.30508@cisco.com> <4B8D4CA0.6090904@digium.com> <4B8D51D8.6090501@cisco.com> <4B8E7F80.90801@digium.com> In-Reply-To: <4B8E7F80.90801@digium.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Mar 2010 08:29:26.0729 (UTC) FILETIME=[CD3B3390:01CABB74] X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Comments on draft-ieft-sipcore-reinvite-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 08:29:29 -0000 Hi Kevin, Section 8.3.3 of RFC 3264 describes when it makes sense to reuse an m line when changing the media type: http://tools.ietf.org/html/rfc3264#section-8.3.3 "It is RECOMMENDED that the media type be changed (as opposed to adding a new stream), when the same logical data is being conveyed, but just in a different media format." In any case, what you describe are scenarios where the UA will not notice it has received media using the new parameters until it actually decodes the media in order to play it out. That is fine. When the UA finally notices the new parameters, it will consider the changes to have been executed. Note that the text in the draft talks about new media "having been" exchanged. It does not talk about UAs "assuming" new media has been exchanged. If the UA does not know for sure new media has been exchanged, it does not do anything. In order to address your comment and make this process clearer, I will add the following paragraph after the third paragraph of Section 3.3 Normally, a UA receiving media can easily detect when the new parameters for the media stream are used (e.g,. media is received on a new port). However, in some scenarios the UA will have to process incoming media packets in order to detect whether they use the old or the new parameters. Thanks for your comments, Gonzalo Kevin P. Fleming wrote: > Christer Holmberg wrote: > >> If you use different ports, and you use ICE, I guess that means >> that you need to perform new ICE procedures for that port before >> you can start using it. > > While hashing over this I came up with another scenario where the > 'media exchanged using new parameters' trigger is not sufficient to > actually know that an offerer's changes have been executed, so I'd > like to propose an alternative way of describing this problem that > may also make it more appropriate for inclusion in this draft. > > As a degenerate case of the 'port number did not change' scenario, > imagine that an endpoint is currently exchanging audio media using > the iLBC codec over RTP, which requires usage of a dynamic payload > number since iLBC does not have an assigned payload number. Later, it > wants to switch to Speex, which also does not have an assigned > payload number, so it sends a re-INVITE with an offer that uses the > same port number *and* payload number, but provides an rtpmap from > that payload number to Speex instead of iLBC. Again in this scenario > the offerer cannot safely use 'media exchanged using the new > parameters' as a trigger for 'changes have been executed' because > in-flight RTP packets will have that payload number already. I > understand this is a contrived scenario, but it does not seem that > far outside the bounds of what implementors tend to do :-) > > So, I'd like to propose this sort of language instead: > > An offerer in a re-INVITE transaction is allowed by RFC3261 to treat > its offered changes as 'executed' based on *either* receiving a > non-error response to its offer *or* determining that media has been > exchanged using the new session parameters. However, if the offer's > session parameters do not differ sufficiently from the previous > session state to allow this determination to be made conclusively, > the offerer should not use media exchange as the threshold for > execution of the changes, and should instead use only the reception > of a non-error response as the trigger. This affords the answerer the > opportunity to provide an error response to the offer if desired > without the two endpoints getting out of sync in their understanding > of the session state. > From gonzalo.camarillo@ericsson.com Thu Mar 4 01:00:47 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CC5F3A7B45 for ; Thu, 4 Mar 2010 01:00:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.199 X-Spam-Level: X-Spam-Status: No, score=-102.199 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, J_CHICKENPOX_12=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 KgSYE6CmN3-Y for ; Thu, 4 Mar 2010 01:00:46 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 1566F3A77D0 for ; Thu, 4 Mar 2010 01:00:45 -0800 (PST) X-AuditID: c1b4fb3d-b7c72ae00000040e-d3-4b8f76bd3ac8 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 9A.DF.01038.DB67F8B4; Thu, 4 Mar 2010 10:00:45 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Mar 2010 10:00:45 +0100 Received: from [131.160.126.152] ([131.160.126.152]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Mar 2010 10:00:45 +0100 Message-ID: <4B8F76B3.5010304@ericsson.com> Date: Thu, 04 Mar 2010 11:00:35 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Elwell, John" References: In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Mar 2010 09:00:45.0114 (UTC) FILETIME=[2CD601A0:01CABB79] X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] WGLC comments on draft-ietf-sipcore-reinvite-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 09:00:47 -0000 Hi John, thanks for your comments. Answers inline: Elwell, John wrote: > I read this document again and didn't find anything to prevent it progressing (although I would not claim to have done a thorough review). > > Minor comments and nits: > > - Section 1: > "A UAC willing to > act the offerer" > Change "act" to "act as". Fixed. > - Section 2: Where "UAC" and "UAS" expanded, it would probably be worth stating that the terms are used with respect to INVITE and re-INVITE transactions only. Other transactions within an INVITE or re-INVITE transaction can be in the reverse direction and the roles are reversed. I have added the following paragraph: "Note that the terms UAC and UAS apply to a transaction, not to a dialog. For example, the UAC of a re-INVITE transaction can be the UAS of an UPDATE transaction within the re-INVITE." > > - Section 3.1: > "SDP4: > m=audio 31000 RTP/AVP 0 > c=IN IP4 192.0.2.5 > m=video 0 RTP/AVP 31 > c=IN IP4 192.0.2.2" > It seems unreasonable to include in an answer, below a rejected m-line, a c-line echoing the c-line in the offer. Fixed. > - In the last example in 3.1, it should perhaps be pointed out that SDP5 (in the UPDATE request) is an offer. Also the contents of SDP6 (SDP answer) should perhaps also be shown for completeness. I have clarified SDP5 is an offer and added SDP6. > > - In section 3.3: > "During a session establishment, the UAS can wait for > using the media parameters until " > Change "wait for" to "wait before" (or alternatively "delay"). I have used "wait before". > - In section 3.7: > "The proxy relays the UPDATE request (9) to UA1. The UPDATE request > (9) arrives at UA1 before the 4xx response (7) that had been > previously sent. UA2 accepts the changes in the UPDATE request and > returns a 200 (OK) response (10) to it ." > I think the last sentence should begin "UA1 accepts the changes..." Fixed. > - " SDP4: m=audio 20000 RTP/AVP 0 a=sendonly m=video 30002 RTP/AVP 31 > a=inactive" > Line breaks missing (c.f., the other examples). Fixed. > > - In section 4.4: > "In this document, reliable provisional responses are > those that use the mechanism defined in RFC 3262 [RFC3262] on any > other SIP-based mechanism that may be specified in the future." > Change "on" to "or". Fixed. > > - Change "If instead sending" to "If instead of sending" Fixed. Thanks! Gonzalo From john.elwell@siemens-enterprise.com Thu Mar 4 01:58:44 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D3CC3A8746 for ; Thu, 4 Mar 2010 01:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.432 X-Spam-Level: X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[AWL=0.167, 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 udv6fi48muSq for ; Thu, 4 Mar 2010 01:58:43 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id ED1553A873B for ; Thu, 4 Mar 2010 01:58:42 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1090862; Thu, 4 Mar 2010 10:58:42 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 9CCF923F028E; Thu, 4 Mar 2010 10:58:42 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 4 Mar 2010 10:58:42 +0100 From: "Elwell, John" To: Gonzalo Camarillo Date: Thu, 4 Mar 2010 10:58:41 +0100 Thread-Topic: [sipcore] WGLC comments on draft-ietf-sipcore-reinvite-01 Thread-Index: Acq7eS3HHD14JVcnTjW7D2tdwasxPQABxNBw Message-ID: References: <4B8F76B3.5010304@ericsson.com> In-Reply-To: <4B8F76B3.5010304@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] WGLC comments on draft-ietf-sipcore-reinvite-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 09:58:44 -0000 Gonzalo, Thanks - I still have a concern, see below.=20 > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 > Sent: 04 March 2010 09:01 > To: Elwell, John > Cc: sipcore@ietf.org > Subject: Re: [sipcore] WGLC comments on draft-ietf-sipcore-reinvite-01 >=20 > Hi John, >=20 > thanks for your comments. Answers inline: >=20 > Elwell, John wrote: > > I read this document again and didn't find anything to=20 > prevent it progressing (although I would not claim to have=20 > done a thorough review). > >=20 > > Minor comments and nits: > >=20 > > - Section 1: > > "A UAC willing to > > act the offerer" > > Change "act" to "act as". >=20 > Fixed. >=20 > > - Section 2: Where "UAC" and "UAS" expanded, it would=20 > probably be worth stating that the terms are used with=20 > respect to INVITE and re-INVITE transactions only. Other=20 > transactions within an INVITE or re-INVITE transaction can be=20 > in the reverse direction and the roles are reversed. >=20 > I have added the following paragraph: >=20 > "Note that the terms UAC and UAS apply to a transaction, not to a > dialog. For example, the UAC of a re-INVITE transaction can be the UAS > of an UPDATE transaction within the re-INVITE." [JRE] I got the impression that the terms UAC and UAS were always used with= respect to the re-INVITE transaction, even though there might also be an U= PDATE transaction in the reverse direction. For example, if I look at figur= e 3, the entire left hand column is labelled "UAC", even though that entity= is the UAS for the received UPDATE request ((6). I was looking for text mo= re along the lines of: "Note that the terms UAC and UAS are used with respect to an INVITE or re-I= NVITE transaction, and do not necessarily reflect the role of the UA concer= ned with respect to any other transaction, such as an UPDATE transaction oc= curring during the INVITE transaction." John From gonzalo.camarillo@ericsson.com Thu Mar 4 02:34:59 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B58928C0CE for ; Thu, 4 Mar 2010 02:34:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 S83orG5Jx7+N for ; Thu, 4 Mar 2010 02:34:58 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id E96E63A874B for ; Thu, 4 Mar 2010 02:34:57 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-72-4b8f8cd291dc Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 88.74.31641.2DC8F8B4; Thu, 4 Mar 2010 11:34:58 +0100 (CET) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Mar 2010 11:34:58 +0100 Received: from [131.160.126.152] ([131.160.126.152]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Mar 2010 11:34:58 +0100 Message-ID: <4B8F8CD1.4020006@ericsson.com> Date: Thu, 04 Mar 2010 12:34:57 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "Elwell, John" References: <4B8F76B3.5010304@ericsson.com> In-Reply-To: X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Mar 2010 10:34:58.0121 (UTC) FILETIME=[564A6B90:01CABB86] X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] WGLC comments on draft-ietf-sipcore-reinvite-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 10:34:59 -0000 Hi John, I have added your text (I replaced "during" with "within"). Thanks, Gonzalo Elwell, John wrote: > Gonzalo, > > Thanks - I still have a concern, see below. > >> -----Original Message----- >> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >> Sent: 04 March 2010 09:01 >> To: Elwell, John >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] WGLC comments on draft-ietf-sipcore-reinvite-01 >> >> Hi John, >> >> thanks for your comments. Answers inline: >> >> Elwell, John wrote: >>> I read this document again and didn't find anything to >> prevent it progressing (although I would not claim to have >> done a thorough review). >>> Minor comments and nits: >>> >>> - Section 1: >>> "A UAC willing to >>> act the offerer" >>> Change "act" to "act as". >> Fixed. >> >>> - Section 2: Where "UAC" and "UAS" expanded, it would >> probably be worth stating that the terms are used with >> respect to INVITE and re-INVITE transactions only. Other >> transactions within an INVITE or re-INVITE transaction can be >> in the reverse direction and the roles are reversed. >> >> I have added the following paragraph: >> >> "Note that the terms UAC and UAS apply to a transaction, not to a >> dialog. For example, the UAC of a re-INVITE transaction can be the UAS >> of an UPDATE transaction within the re-INVITE." > [JRE] I got the impression that the terms UAC and UAS were always used with respect to the re-INVITE transaction, even though there might also be an UPDATE transaction in the reverse direction. For example, if I look at figure 3, the entire left hand column is labelled "UAC", even though that entity is the UAS for the received UPDATE request ((6). I was looking for text more along the lines of: > "Note that the terms UAC and UAS are used with respect to an INVITE or re-INVITE transaction, and do not necessarily reflect the role of the UA concerned with respect to any other transaction, such as an UPDATE transaction occurring during the INVITE transaction." > > John From gonzalo.camarillo@ericsson.com Thu Mar 4 02:42:55 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF8663A88B1 for ; Thu, 4 Mar 2010 02:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.063 X-Spam-Level: X-Spam-Status: No, score=-103.063 tagged_above=-999 required=5 tests=[AWL=0.536, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 fVlfGRGxIvL9 for ; Thu, 4 Mar 2010 02:42:55 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id EEC733A879D for ; Thu, 4 Mar 2010 02:42:54 -0800 (PST) X-AuditID: c1b4fb3d-b7c72ae00000040e-9f-4b8f8eaf05fe Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 82.8E.01038.FAE8F8B4; Thu, 4 Mar 2010 11:42:55 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Mar 2010 11:42:55 +0100 Received: from [131.160.126.152] ([131.160.126.152]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Mar 2010 11:42:55 +0100 Message-ID: <4B8F8EAE.6050501@ericsson.com> Date: Thu, 04 Mar 2010 12:42:54 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: SIPCORE X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Mar 2010 10:42:55.0060 (UTC) FILETIME=[72918940:01CABB87] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] New version of draft-ietf-sipcore-reinvite-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 10:42:56 -0000 Folks, I have just submitted a new revision of the following draft: http://www.ietf.org/id/draft-ietf-sipcore-reinvite-02.txt This revision includes all the WGLC comments received so far. Note that the WGLC will end on Monday (March 8th). Cheers, Gonzalo From root@core3.amsl.com Thu Mar 4 02:45:02 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 425123A88BA; Thu, 4 Mar 2010 02:45:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100304104502.425123A88BA@core3.amsl.com> Date: Thu, 4 Mar 2010 02:45:02 -0800 (PST) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 10:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Re-INVITE and Target-refresh Request Handling in the Session Initiation Protocol (SIP) Author(s) : G. Camarillo, et al. Filename : draft-ietf-sipcore-reinvite-02.txt Pages : 24 Date : 2010-03-04 In this document, we clarify the handling of re-INVITEs in SIP. We clarify in which situations a UAS (User Agent Server) should generate a success response and in which situations a UAS should generate an error response to a re-INVITE. Additionally, we clarify issues related to target-refresh requests. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-reinvite-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-reinvite-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-04024042.I-D@ietf.org> --NextPart-- From gonzalo.camarillo@ericsson.com Thu Mar 4 07:13:27 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3236328C0F2 for ; Thu, 4 Mar 2010 07:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.106 X-Spam-Level: X-Spam-Status: No, score=-103.106 tagged_above=-999 required=5 tests=[AWL=0.493, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 k4bjJJ7NGW6y for ; Thu, 4 Mar 2010 07:13:23 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 7704C3A8D55 for ; Thu, 4 Mar 2010 07:13:22 -0800 (PST) X-AuditID: c1b4fb3d-b7c72ae00000040e-49-4b8fce12e660 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id A3.6F.01038.21ECF8B4; Thu, 4 Mar 2010 16:13:22 +0100 (CET) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Mar 2010 16:13:22 +0100 Received: from [131.160.126.145] ([131.160.126.145]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Mar 2010 16:13:22 +0100 Message-ID: <4B8FCE11.5050708@ericsson.com> Date: Thu, 04 Mar 2010 17:13:21 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: SIPCORE References: <4B8F8EAE.6050501@ericsson.com> In-Reply-To: <4B8F8EAE.6050501@ericsson.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Mar 2010 15:13:22.0362 (UTC) FILETIME=[3ACB51A0:01CABBAD] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] New version of draft-ietf-sipcore-reinvite-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 15:13:27 -0000 Hi, John noticed a markup-related error in 02. Thanks for the follow up, John! I have fixed it in a new revision of the draft: http://www.ietf.org/id/draft-ietf-sipcore-reinvite-03.txt Sorry for the confusion. Cheers, Gonzalo Gonzalo Camarillo wrote: > Folks, > > I have just submitted a new revision of the following draft: > > http://www.ietf.org/id/draft-ietf-sipcore-reinvite-02.txt > > This revision includes all the WGLC comments received so far. Note that > the WGLC will end on Monday (March 8th). > > Cheers, > > Gonzalo > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From root@core3.amsl.com Thu Mar 4 07:15:02 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 35F3E28C12D; Thu, 4 Mar 2010 07:15:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100304151502.35F3E28C12D@core3.amsl.com> Date: Thu, 4 Mar 2010 07:15:02 -0800 (PST) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-03.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 15:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Re-INVITE and Target-refresh Request Handling in the Session Initiation Protocol (SIP) Author(s) : G. Camarillo, et al. Filename : draft-ietf-sipcore-reinvite-03.txt Pages : 24 Date : 2010-03-04 In this document, we clarify the handling of re-INVITEs in SIP. We clarify in which situations a UAS (User Agent Server) should generate a success response and in which situations a UAS should generate an error response to a re-INVITE. Additionally, we clarify issues related to target-refresh requests. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-reinvite-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-reinvite-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-04071114.I-D@ietf.org> --NextPart-- From dean.willis@softarmor.com Thu Mar 4 08:51:51 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E37AA28C105 for ; Thu, 4 Mar 2010 08:51:51 -0800 (PST) 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=[AWL=0.000, 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 HcCqhVxzVYE1 for ; Thu, 4 Mar 2010 08:51:51 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 1078B28C0F2 for ; Thu, 4 Mar 2010 08:51:50 -0800 (PST) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o24Gpitd013700 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 4 Mar 2010 10:51:45 -0600 Message-Id: From: Dean Willis To: Hans Erik van Elburg In-Reply-To: <9ae56b1e1003030042m3a6de8f6x7f13afa7725b1ff4@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 4 Mar 2010 10:51:37 -0600 References: <4B8C486A.5060400@nostrum.com> <4B8D1FE3.1050107@nostrum.com> <9ae56b1e1003020701t731ca950s1c6968256399ebc3@mail.gmail.com> <4B8D6B58.1070406@nostrum.com> <9ae56b1e1003030042m3a6de8f6x7f13afa7725b1ff4@mail.gmail.com> X-Mailer: Apple Mail (2.936) Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 16:51:52 -0000 On Mar 3, 2010, at 2:42 AM, Hans Erik van Elburg wrote: > Forking in essence is a service provided by a downstream proxy > (serving domein B.com) to a user that has multiple devices > registered to this proxy. This service (served to him by his own > domain) will allow him to receive calls at any of his devices. That's how it works in theory. In practice, it doesn't work all that well, as some of user B's devices are going to be either PSTN phones, or nodes that implement their own voicemail service. In other words, they're going to send back a media flow, either before or after a 200 OK. A forking proxy cannot reconcile this; it requires a UA, either a B2BUA as Christer suggests, or all the way back to the originating user. And if the media streams are a result of a forking proxy, then the UA lacks sufficient information for sorting it out. In other words, either fork in a B2BUA and be prepared to deal with the media, or send a 3XX. > > To push the responsibility for providing this service of a B.com > user to another domain lets say A.com, is to say the least > problematic. Even if it solves some issues like those related to > early media and HERFP, it introduces lots of other issues. However, those other issues are arguably tractable, in that at least the UA now has the information needed to do something intelligent rather than just failing. And "just failing" is what happens now to forked calls where multiple legs have early or late media. -- Dean From dean.willis@softarmor.com Thu Mar 4 08:53:02 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F6CF3A8D88 for ; Thu, 4 Mar 2010 08:53:02 -0800 (PST) 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=[AWL=0.000, 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 rYVMACz871Hd for ; Thu, 4 Mar 2010 08:53:01 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id EAA6F3A8D94 for ; Thu, 4 Mar 2010 08:52:41 -0800 (PST) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o24Gpite013700 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 4 Mar 2010 10:52:39 -0600 Message-Id: <39520A38-1762-4D61-9338-133803404E6C@softarmor.com> From: Dean Willis To: "Elwell, John" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 4 Mar 2010 10:52:38 -0600 References: <3656743157.951988183@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: "sipcore@ietf.org" Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 16:53:02 -0000 On Mar 3, 2010, at 3:37 AM, Elwell, John wrote: > Serial forking with early media depends on support for PRACK and > UPDATE, which are not mandatory items for UAs and therefore will not > always be available. > As always, I think early media was just a really bad idea. But we always dance away from trying to fix the problem. -- Dean From dean.willis@softarmor.com Thu Mar 4 08:59:22 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00DC43A8D84 for ; Thu, 4 Mar 2010 08:59:22 -0800 (PST) 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=[AWL=0.000, 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 QllI5omqPFga for ; Thu, 4 Mar 2010 08:59:21 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 1AEAF3A8D63 for ; Thu, 4 Mar 2010 08:59:21 -0800 (PST) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o24GxKr8013794 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 4 Mar 2010 10:59:21 -0600 Message-Id: From: Dean Willis To: "Elwell, John" In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 4 Mar 2010 10:59:14 -0600 References: <4B8C486A.5060400@nostrum.com> <4B8D1FE3.1050107@nostrum.com> <9ae56b1e1003020701t731ca950s1c6968256399ebc3@mail.gmail.com> <4B8D6B58.1070406@nostrum.com> <9ae56b1e1003021447u65c04b24i9e8cc3c65b0cc23e@mail.gmail.com> <21F06E40-A672-4497-92D2-B2F66A743A00@softarmor.com> X-Mailer: Apple Mail (2.936) Cc: SIPCORE Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 16:59:22 -0000 On Mar 3, 2010, at 3:40 AM, Elwell, John wrote: > I would like to expand on this issue a little. Suppose I have at my > home proxy a policy whereby calls go to B1 and B2 in parallel, and > after T seconds of no answer calls instead go to B3 (voicemail, > perhaps). There is no way that the proxy could convey that policy in > a 3xx response to the UAC. To make this policy (or similar policies) > work, the proxy would need to manufacturer temporary contact URIs > that map to B1 and B2 and send these back in a 302. It would then > need to hope that the UAC does indeed establish new requests in > parallel to the two temporary contacts for B1 and B2. The proxy > would need to treat the two requests as related and if both are > unanswered after T seconds, reject one with a 4xx and the other with > a 302 (this time with a third temporary contact URI mapped to B3). > So policy CAN be met by the proxy, although with dependence on the > UAC doing the right thing. So here, we either need your home proxy to be a home B2BUA (After all, what happens when B1 and B2 both send back early media, or both get answered by a bot?), OR we need a richer 302 response that conveys "Try these two destinations in parallel, and if neither replies in X seconds, try this third destination). Either is tractable. Admittedly, the second requires extending the specification of a 302 response, but we have the capacity to do this. A few standardized parameters would work fine, with no backward compatibility issues for older nodes that don't understand the parameters. Much could be done with q-values. > > Elsewhere in this thread, somebody mentioned charging. The fact is > that calls might cross a domain that charges (e.g., for > international calls via a server provider into an enterprise that > has a proxy that makes use of 302 responses to achieve forking). > Since only one of the calls should normally be answered (or if a > second is answered it should be cleared very quickly), charging > based on duration after answer should not be a big issue. However, > if a domain charges for call establishment attempts, it could be a > problem. In this example, the domain handling the international leg > would not be aware that the multiple calls are really part of the > same call. I don't know whether this is an issue in practice or not. The real question is "who gets charged, and are they surprised by it?" If the "home proxy" is forwarding the call to a toll destination, then either the "home proxy" needs to get charged for the toll (making it more B2BUA is), or the originating user needs to get charged for it, in which case the originating user needs to know about the toll destination (requiring a 302). Having your home proxy do conventional SIP forking just doesn't work here. -- Dean From gsalguei@cisco.com Thu Mar 4 09:04:22 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D43793A8D79 for ; Thu, 4 Mar 2010 09:04:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 s6UoIZ+k0mmQ for ; Thu, 4 Mar 2010 09:04:22 -0800 (PST) Received: from av-tac-rtp.cisco.com (hen.cisco.com [64.102.19.198]) by core3.amsl.com (Postfix) with ESMTP id 099AA3A8D9A for ; Thu, 4 Mar 2010 09:04:21 -0800 (PST) X-TACSUNS: Virus Scanned Received: from rooster.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o24H4N5b013898; Thu, 4 Mar 2010 12:04:23 -0500 (EST) Received: from dhcp-172-18-251-86.cisco.com (dhcp-172-18-251-86.cisco.com [172.18.251.86]) by rooster.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id o24H4MMP007763; Thu, 4 Mar 2010 12:04:23 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Gonzalo Salgueiro In-Reply-To: <39520A38-1762-4D61-9338-133803404E6C@softarmor.com> Date: Thu, 4 Mar 2010 12:04:22 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <6D9053F5-5D95-4290-95AF-4E600DA64C6A@cisco.com> References: <3656743157.951988183@softarmor.com> <39520A38-1762-4D61-9338-133803404E6C@softarmor.com> To: Dean Willis X-Mailer: Apple Mail (2.1077) Cc: "sipcore@ietf.org" , Gonzalo Salgueiro Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 17:04:22 -0000 emphatic +1 to Dean's wise comment G On Mar 4, 2010, at 11:52 AM, Dean Willis wrote: >=20 > On Mar 3, 2010, at 3:37 AM, Elwell, John wrote: >=20 >> Serial forking with early media depends on support for PRACK and = UPDATE, which are not mandatory items for UAs and therefore will not = always be available. >>=20 >=20 > As always, I think early media was just a really bad idea. But we = always dance away from trying to fix the problem. >=20 > -- > Dean > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From dean.willis@softarmor.com Thu Mar 4 09:04:49 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFB513A8D9B for ; Thu, 4 Mar 2010 09:04:49 -0800 (PST) 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=[AWL=0.000, 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 ozMv4yA+4uDo for ; Thu, 4 Mar 2010 09:04:49 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id D3C713A8D9A for ; Thu, 4 Mar 2010 09:04:48 -0800 (PST) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o24H4jnA013878 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 4 Mar 2010 11:04:47 -0600 Message-Id: <39982944-B924-4308-B8B0-3CC06D97CD96@softarmor.com> From: Dean Willis To: Paul Kyzivat In-Reply-To: <4B8C0E68.3050802@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 4 Mar 2010 11:04:40 -0600 References: <4B7E9EAD.20201@cisco.com> <4B85B02E.6000500@cisco.com> <747A6506A991724FB09B129B79D5FEB61480306949@EXMBXCLUS01.citservers.local> <4B86AAEF.9000108@cisco.com> <747A6506A991724FB09B129B79D5FEB61480306CD4@EXMBXCLUS01.citservers.local> <4B86D597.6060009@cisco.com> <747A6506A991724FB09B129B79D5FEB614803AA992@EXMBXCLUS01.citservers.local> <4B8C0E68.3050802@cisco.com> X-Mailer: Apple Mail (2.936) Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: What does it mean? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 17:04:49 -0000 On Mar 1, 2010, at 12:58 PM, Paul Kyzivat wrote: > IMO, if the request has a to-tag, then the UAS should treat it as an > in-dialog request not associated with any particular usage. If there > is no matching dialog, then it should return a 481 response. > I haven't thought this thru: Is there any chance of this being used to fish for existing dialogs? If not, then your position seems reasonable. -- Dean From pkyzivat@cisco.com Thu Mar 4 09:50:26 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A0453A8B86 for ; Thu, 4 Mar 2010 09:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 lFZRXLxBK1Y2 for ; Thu, 4 Mar 2010 09:50:25 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 04C963A8DE8 for ; Thu, 4 Mar 2010 09:50:24 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFyBj0tAZnwM/2dsb2JhbACbP3OfdJhfhHwEgxc X-IronPort-AV: E=Sophos;i="4.49,582,1262563200"; d="scan'208";a="90599517" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 04 Mar 2010 17:50:26 +0000 Received: from [10.86.249.191] (bxb-vpn3-447.cisco.com [10.86.249.191]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o24HoQMp002006; Thu, 4 Mar 2010 17:50:26 GMT Message-ID: <4B8FF2DE.6000709@cisco.com> Date: Thu, 04 Mar 2010 12:50:22 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dean Willis References: <4B8C486A.5060400@nostrum.com> <4B8D1FE3.1050107@nostrum.com> <9ae56b1e1003020701t731ca950s1c6968256399ebc3@mail.gmail.com> <4B8D6B58.1070406@nostrum.com> <9ae56b1e1003021447u65c04b24i9e8cc3c65b0cc23e@mail.gmail.com> <21F06E40-A672-4497-92D2-B2F66A743A00@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] OPTIONS 3xx: To fork or not to fork? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 17:50:26 -0000 inline Dean Willis wrote: > > On Mar 3, 2010, at 3:40 AM, Elwell, John wrote: > >> I would like to expand on this issue a little. Suppose I have at my >> home proxy a policy whereby calls go to B1 and B2 in parallel, and >> after T seconds of no answer calls instead go to B3 (voicemail, >> perhaps). There is no way that the proxy could convey that policy in a >> 3xx response to the UAC. To make this policy (or similar policies) >> work, the proxy would need to manufacturer temporary contact URIs that >> map to B1 and B2 and send these back in a 302. It would then need to >> hope that the UAC does indeed establish new requests in parallel to >> the two temporary contacts for B1 and B2. The proxy would need to >> treat the two requests as related and if both are unanswered after T >> seconds, reject one with a 4xx and the other with a 302 (this time >> with a third temporary contact URI mapped to B3). So policy CAN be met >> by the proxy, although with dependence on the UAC doing the right thing. > > So here, we either need your home proxy to be a home B2BUA (After all, > what happens when B1 and B2 both send back early media, or both get > answered by a bot?), OR we need a richer 302 response that conveys "Try > these two destinations in parallel, and if neither replies in X seconds, > try this third destination). > > Either is tractable. Admittedly, the second requires extending the > specification of a 302 response, but we have the capacity to do this. A > few standardized parameters would work fine, with no backward > compatibility issues for older nodes that don't understand the > parameters. Much could be done with q-values. This capability is (arguably) already there: provide two contacts with equal q-values, and the third with a smaller q-value. Thanks, Paul From pkyzivat@cisco.com Thu Mar 4 11:32:44 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53AD03A8C9A for ; Thu, 4 Mar 2010 11:32:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 DbWPVPoVAT0P for ; Thu, 4 Mar 2010 11:32:43 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 8E58A3A8E3F for ; Thu, 4 Mar 2010 11:32:40 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMiZj0tAZnwM/2dsb2JhbACbPXOfbJhjgkcXgh4EgxeLUg X-IronPort-AV: E=Sophos;i="4.49,582,1262563200"; d="scan'208";a="95981721" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by sj-iport-4.cisco.com with ESMTP; 04 Mar 2010 19:32:42 +0000 Received: from [10.86.249.191] (bxb-vpn3-447.cisco.com [10.86.249.191]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o24JWfcG007182; Thu, 4 Mar 2010 19:32:41 GMT Message-ID: <4B900ADA.9000804@cisco.com> Date: Thu, 04 Mar 2010 14:32:42 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dean Willis References: <4B7E9EAD.20201@cisco.com> <4B85B02E.6000500@cisco.com> <747A6506A991724FB09B129B79D5FEB61480306949@EXMBXCLUS01.citservers.local> <4B86AAEF.9000108@cisco.com> <747A6506A991724FB09B129B79D5FEB61480306CD4@EXMBXCLUS01.citservers.local> <4B86D597.6060009@cisco.com> <747A6506A991724FB09B129B79D5FEB614803AA992@EXMBXCLUS01.citservers.local> <4B8C0E68.3050802@cisco.com> <39982944-B924-4308-B8B0-3CC06D97CD96@softarmor.com> In-Reply-To: <39982944-B924-4308-B8B0-3CC06D97CD96@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] OPTIONS: What does it mean? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 19:32:44 -0000 Dean Willis wrote: > > On Mar 1, 2010, at 12:58 PM, Paul Kyzivat wrote: > >> IMO, if the request has a to-tag, then the UAS should treat it as an >> in-dialog request not associated with any particular usage. If there >> is no matching dialog, then it should return a 481 response. >> > > I haven't thought this thru: Is there any chance of this being used to > fish for existing dialogs? If not, then your position seems reasonable. There is a *possibility* of using it that way. But I don't think that is a very practical approach to anything. If you don't already have access to the dialog info, but suspect there is a dialog and want to discover it, the namespace of dialog ids is *very* large. Trying to guess and verify this way would be very expensive. And, if you thought this was useful, and we blocked use of OPTIONS for this, you could simply switch to some other message - e.g. UPDATE. Thanks, Paul From christer.holmberg@ericsson.com Thu Mar 4 12:58:01 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 677943A8E51 for ; Thu, 4 Mar 2010 12:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 s9503ErcgSzp for ; Thu, 4 Mar 2010 12:58:00 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id A69EE3A8E4B for ; Thu, 4 Mar 2010 12:57:59 -0800 (PST) X-AuditID: c1b4fb3d-b7c72ae00000040e-06-4b901ed82ea0 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id E1.43.01038.8DE109B4; Thu, 4 Mar 2010 21:58:00 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.216]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 4 Mar 2010 21:58:00 +0100 From: Christer Holmberg To: Dean Willis , "Elwell, John" Date: Thu, 4 Mar 2010 21:57:59 +0100 Thread-Topic: INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] Thread-Index: AQHKu8za+r+IWiVmekyKq4+FfwBQpA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2010 20:58:01 -0000 Hi, I thought we already had the annual thread on solving early media, but I gu= ess it doesn't hurt to discuss it a little more often ;) >>Serial forking with early media depends on support for PRACK and UPDATE,= which are not mandatory items for UAs and therefore will not always be ava= ilable. > >As always, I think early media was just a really bad idea. But we always d= ance away from trying to fix the problem. > >>I would like to expand on this issue a little. Suppose I have at my >>home proxy a policy whereby calls go to B1 and B2 in parallel, and >>after T seconds of no answer calls instead go to B3 (voicemail, >>perhaps). There is no way that the proxy could convey that policy in >>a 3xx response to the UAC. To make this policy (or similar policies) >>work, the proxy would need to manufacturer temporary contact URIs >>that map to B1 and B2 and send these back in a 302. It would then >>need to hope that the UAC does indeed establish new requests in >>parallel to the two temporary contacts for B1 and B2. The proxy >>would need to treat the two requests as related and if both are >>unanswered after T seconds, reject one with a 4xx and the other with >>a 302 (this time with a third temporary contact URI mapped to B3). >>So policy CAN be met by the proxy, although with dependence on the >>UAC doing the right thing. > >So here, we either need your home proxy to be a home B2BUA (After all, >what happens when B1 and B2 both send back early media, or both get >answered by a bot?), OR we need a richer 302 response that conveys >"Try these two destinations in parallel, and if neither replies in X >seconds, try this third destination). But, the UAC still doesn't know whether B1 and B2 would send early media. >Either is tractable. Admittedly, the second requires extending the >specification of a 302 response, but we have the capacity to do this. >A few standardized parameters would work fine, with no backward >compatibility issues for older nodes that don't understand the >parameters. Much could be done with q-values. Much could also have been done by alloing P-Early-Media:inactive in the INV= ITE request, and then indicating to the UAC for which early dialog early media has been "allowed"= . The UAC can then change that by sending a PRACK/UPDATE Also, there could be a feature tag which UAS(s) use during registration to = indicate whether they support sending of early media or not. I don't think that SIP UAs will send early media that often. PSTN gateways = can do it.=20 Appplication servers can also do it, but they are most likely located "in f= ront of" the forking proxy. And, if they would send a 3xx response, the 3xx= from the forking proxy would most likely be rejected by the UAC (since it = already received a final response from the AS). So, the application servers= could instead create a separate early dialog with the UAC, but that early = dialog (and possible announcements etc that goes with it) would then be ter= minated in an unwanted manner by the 3xx from the forking proxy. >> Elsewhere in this thread, somebody mentioned charging. The fact is >> that calls might cross a domain that charges (e.g., for >> international calls via a server provider into an enterprise that >> has a proxy that makes use of 302 responses to achieve forking). >> Since only one of the calls should normally be answered (or if a >> second is answered it should be cleared very quickly), charging >> based on duration after answer should not be a big issue. However, >> if a domain charges for call establishment attempts, it could be a >> problem. In this example, the domain handling the international leg >> would not be aware that the multiple calls are really part of the >> same call. I don't know whether this is an issue in practice or not. > >The real question is "who gets charged, and are they surprised by it?" > >If the "home proxy" is forwarding the call to a toll destination, then >either the "home proxy" needs to get charged for the toll (making it >more B2BUA is), or the originating user needs to get charged for it, >in which case the originating user needs to know about the toll >destination (requiring a 302). That assumes that the forking proxy has information about whether a contact= is associated with a toll number, and that the calling device is able to p= resent that information to the caller. There is a service called Advice Of Charge. I believe it contains a feature= to not allow certain calls to take place if the calling user can't be info= rmed about it, but I don't remember the details. Regards, Christer= From christer.holmberg@ericsson.com Fri Mar 5 00:00:57 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6A4D28C1E6 for ; Fri, 5 Mar 2010 00:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[AWL=-0.022, 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 86Ni0oFjo7FV for ; Fri, 5 Mar 2010 00:00:57 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id BDB7128C15D for ; Fri, 5 Mar 2010 00:00:56 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-db-4b90ba39ff01 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id F9.BD.31641.93AB09B4; Fri, 5 Mar 2010 09:00:57 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.1.216]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 5 Mar 2010 09:00:57 +0100 From: Christer Holmberg To: SIPCORE Date: Fri, 5 Mar 2010 09:00:56 +0100 Thread-Topic: OPTIONS 3xx: Contact filtering? Thread-Index: Acq7wzB+avda9121TqaSLDSESXUXKgAdYgnQ Message-ID: References: <4B8C486A.5060400@nostrum.com> <4B8D1FE3.1050107@nostrum.com> <9ae56b1e1003020701t731ca950s1c6968256399ebc3@mail.gmail.com> <4B8D6B58.1070406@nostrum.com> <9ae56b1e1003021447u65c04b24i9e8cc3c65b0cc23e@mail.gmail.com> <21F06E40-A672-4497-92D2-B2F66A743A00@softarmor.com> <4B8FF2DE.6000709@cisco.com> In-Reply-To: <4B8FF2DE.6000709@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] OPTIONS 3xx: Contact filtering? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 08:00:58 -0000 Hi, Paul suggested that a UAC would use the Request-Disposition header to indic= ate whether forking proxy should proxy (using the "proxy" R-D value) the OP= TIONS request, or send a 3xx response (using the "redirect" R-D value). Now, assuming "redirect" is used, the question is: If the request also contains an Accept-Contact/Reject-Contact header field,= would the proxy in the 3xx response only include contacts which matches th= e A-C/R-C criterias (in the same way as the proxy would only fork towards U= AS(s) that matches the criterias)? I can't find any text in 3841 whichs indicates that A-C is not applicable w= hen "R-D:redirect" is used. I think that would be a good feature. Regards, Christer From pkyzivat@cisco.com Fri Mar 5 05:11:45 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEF423A8B66 for ; Fri, 5 Mar 2010 05:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 Ifw-60uiECDW for ; Fri, 5 Mar 2010 05:11:45 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 770863A8F8C for ; Fri, 5 Mar 2010 05:11:44 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHyRkEtAZnwM/2dsb2JhbACbRXOcfZhehH0Egxc X-IronPort-AV: E=Sophos;i="4.49,587,1262563200"; d="scan'208";a="90809234" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 05 Mar 2010 13:11:45 +0000 Received: from [10.86.249.191] (bxb-vpn3-447.cisco.com [10.86.249.191]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o25DBkwI024638; Fri, 5 Mar 2010 13:11:46 GMT Message-ID: <4B910312.1000904@cisco.com> Date: Fri, 05 Mar 2010 08:11:46 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4B8C486A.5060400@nostrum.com> <4B8D1FE3.1050107@nostrum.com> <9ae56b1e1003020701t731ca950s1c6968256399ebc3@mail.gmail.com> <4B8D6B58.1070406@nostrum.com> <9ae56b1e1003021447u65c04b24i9e8cc3c65b0cc23e@mail.gmail.com> <21F06E40-A672-4497-92D2-B2F66A743A00@softarmor.com> <4B8FF2DE.6000709@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] OPTIONS 3xx: Contact filtering? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 13:11:46 -0000 Yes, I would certainly expect that A-C would apply to selecting the contacts returned in the 3xx response. Thanks, Paul Christer Holmberg wrote: > Hi, > > Paul suggested that a UAC would use the Request-Disposition header to indicate whether forking proxy should proxy (using the "proxy" R-D value) the OPTIONS request, or send a 3xx response (using the "redirect" R-D value). > > Now, assuming "redirect" is used, the question is: > > If the request also contains an Accept-Contact/Reject-Contact header field, would the proxy in the 3xx response only include contacts which matches the A-C/R-C criterias (in the same way as the proxy would only fork towards UAS(s) that matches the criterias)? > > I can't find any text in 3841 whichs indicates that A-C is not applicable when "R-D:redirect" is used. > > I think that would be a good feature. > > Regards, > > Christer > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From dean.willis@softarmor.com Fri Mar 5 13:19:42 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8F5B28C37B for ; Fri, 5 Mar 2010 13:19:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 tzzQQCOfFwoZ for ; Fri, 5 Mar 2010 13:19:40 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 73FE428C34D for ; Fri, 5 Mar 2010 13:19:40 -0800 (PST) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o25LJcgN026807 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 5 Mar 2010 15:19:40 -0600 Message-Id: From: Dean Willis To: Christer Holmberg In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-11--393518732 Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 5 Mar 2010 15:19:33 -0600 References: X-Mailer: Apple Mail (2.936) Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 21:19:43 -0000 --Apple-Mail-11--393518732 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Mar 4, 2010, at 2:57 PM, Christer Holmberg wrote: >> >>> I would like to expand on this issue a little. Suppose I have at my >>> home proxy a policy whereby calls go to B1 and B2 in parallel, and >>> after T seconds of no answer calls instead go to B3 (voicemail, >>> perhaps). There is no way that the proxy could convey that policy in >>> a 3xx response to the UAC. To make this policy (or similar policies) >>> work, the proxy would need to manufacturer temporary contact URIs >>> that map to B1 and B2 and send these back in a 302. It would then >>> need to hope that the UAC does indeed establish new requests in >>> parallel to the two temporary contacts for B1 and B2. The proxy >>> would need to treat the two requests as related and if both are >>> unanswered after T seconds, reject one with a 4xx and the other with >>> a 302 (this time with a third temporary contact URI mapped to B3). >>> So policy CAN be met by the proxy, although with dependence on the >>> UAC doing the right thing. >> >> So here, we either need your home proxy to be a home B2BUA (After >> all, >> what happens when B1 and B2 both send back early media, or both get >> answered by a bot?), OR we need a richer 302 response that conveys >> "Try these two destinations in parallel, and if neither replies in X >> seconds, try this third destination). > > But, the UAC still doesn't know whether B1 and B2 would send early > media. By offering different ports to B1 and B2 (especially with the media-to- signaling coupling extensions that have been proposed) UAC at least knows which one of B1 and B2 each stream is coming from. -- dean --Apple-Mail-11--393518732 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Mar 4, 2010, = at 2:57 PM, Christer Holmberg wrote:

I would like to expand on this = issue a little. Suppose I have at = my
home proxy a policy whereby calls go to B1 and B2 in = parallel, and
after T seconds of no answer = calls instead go to B3 = (voicemail,
perhaps). There is no way that = the proxy could convey that policy = in
a 3xx response to the UAC. To make this policy (or similar = policies)
work, the proxy would need to = manufacturer temporary contact = URIs
that map to B1 and B2 and send these back in a 302. It = would then
need to hope that the UAC does = indeed establish new requests = in
parallel to the two temporary contacts for B1 and B2. The = proxy
would need to treat the two requests as related and if = both are
unanswered after T seconds, = reject one with a 4xx and the other = with
a 302 (this time with a third temporary contact URI mapped = to B3).
So policy CAN be met by the proxy, although with = dependence on the
UAC doing the right = thing.

So here, we = either need your home proxy to be a home B2BUA (After = all,
what happens when B1 and = B2 both send back early media, or both get
answered by a bot?), OR we need a richer 302 response that = conveys
"Try these two = destinations in parallel, and if neither replies in = X
seconds, try this third = destination).

But, the UAC still doesn't know = whether B1 and B2 would send early = media.

By offering different = ports to B1 and B2 (especially with the media-to-signaling coupling = extensions that have been proposed) UAC at least knows which one of B1 = and B2 each stream is coming = from.


--
dean= --Apple-Mail-11--393518732-- From christer.holmberg@ericsson.com Fri Mar 5 14:36:05 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51E8A28C3C0 for ; Fri, 5 Mar 2010 14:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.67 X-Spam-Level: X-Spam-Status: No, score=-0.67 tagged_above=-999 required=5 tests=[AWL=-1.970, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899] 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 NGvi2m2iJnyV for ; Fri, 5 Mar 2010 14:36:03 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 1C6DA28C133 for ; Fri, 5 Mar 2010 14:36:02 -0800 (PST) X-AuditID: c1b4fb39-b7c2dae000007b99-29-4b9187535c9f Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 20.27.31641.357819B4; Fri, 5 Mar 2010 23:36:03 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([153.88.115.165]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 5 Mar 2010 23:36:03 +0100 From: Christer Holmberg To: 'Dean Willis' Date: Fri, 5 Mar 2010 23:36:02 +0100 Thread-Topic: INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] Thread-Index: Acq8qZKqBIGWGPe4Qvq5JsWvJoT2AwACVE+A Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 22:36:05 -0000 Hi, =09 > I would like to expand on this issue a little. Suppose I have at my =09 > home proxy a policy whereby calls go to B1 and B2 in parallel, and > after T seconds of no answer calls instead go to B3 (voicemail, > perhaps). There is no way that the proxy could convey that policy in > a 3xx response to the UAC. To make this policy (or similar policies) > work, the proxy would need to manufacturer temporary contact URIs > that map to B1 and B2 and send these back in a 302. It would then > need to hope that the UAC does indeed establish new requests in > parallel to the two temporary contacts for B1 and B2. The proxy > would need to treat the two requests as related and if both are > unanswered after T seconds, reject one with a 4xx and the other with > a 302 (this time with a third temporary contact URI mapped to B3). > So policy CAN be met by the proxy, although with dependence on the > UAC doing the right thing. > =09 > > So here, we either need your home proxy to be a home B2BUA (After all, > what happens when B1 and B2 both send back early media, or both get > answered by a bot?), OR we need a richer 302 response that conveys > "Try these two destinations in parallel, and if neither replies in X > seconds, try this third destination). > =09 > But, the UAC still doesn't know whether B1 and B2 would send early media. >=09 >By offering different ports to B1 and B2 (especially with the media-to-sig= naling coupling extensions that have been proposed) UAC at least knows whic= h one of B1 and B2 each stream is coming from. Yes. But, there are other mechanisms to solve that, and it still doesn't so= lve the fundamental problem: the UAC can receive multiple media streams ass= ociated with multiple early dialogs. Also, in bandwidth sensitive access networks there is only limited bandwidt= h, normally calculated based on the need for media associated with one earl= y dialog. Even if the UAC is able to select and play only one stream to the= user, the voice quality will suffer due to too little bandwidth. Regards, Christer From pkyzivat@cisco.com Fri Mar 5 15:04:13 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 421DB28C3D4 for ; Fri, 5 Mar 2010 15:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.497 X-Spam-Level: X-Spam-Status: No, score=-8.497 tagged_above=-999 required=5 tests=[AWL=-1.797, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, RCVD_IN_DNSWL_HI=-8] 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 y95ndUZdEA+K for ; Fri, 5 Mar 2010 15:04:12 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 1126B28C16E for ; Fri, 5 Mar 2010 15:04:11 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAK4ckUtAZnwN/2dsb2JhbACbSXOdcphihHcEgxc X-IronPort-AV: E=Sophos;i="4.49,589,1262563200"; d="scan'208";a="90946742" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 05 Mar 2010 23:04:14 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o25N4D6W000292; Fri, 5 Mar 2010 23:04:14 GMT Message-ID: <4B918DED.6090108@cisco.com> Date: Fri, 05 Mar 2010 18:04:13 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 23:04:13 -0000 If you want parallel forking, even if done by the UAC, there is no good solution to this problem. The parallel early media is going to be generated and something must happen to it. The only question is which of the bad solutions you prefer. For instance, you may have one stream asking you to enter an access code, another playing an out-of-service tone, and a third sending no media which will eventually pick up with a real person. What would you *like* for the caller to hear? Thanks, Paul Christer Holmberg wrote: > Hi, > > >> I would like to expand on this issue a little. Suppose I have at my >> home proxy a policy whereby calls go to B1 and B2 in parallel, and >> after T seconds of no answer calls instead go to B3 (voicemail, >> perhaps). There is no way that the proxy could convey that policy in >> a 3xx response to the UAC. To make this policy (or similar policies) >> work, the proxy would need to manufacturer temporary contact URIs >> that map to B1 and B2 and send these back in a 302. It would then >> need to hope that the UAC does indeed establish new requests in >> parallel to the two temporary contacts for B1 and B2. The proxy >> would need to treat the two requests as related and if both are >> unanswered after T seconds, reject one with a 4xx and the other with >> a 302 (this time with a third temporary contact URI mapped to B3). >> So policy CAN be met by the proxy, although with dependence on the >> UAC doing the right thing. >> >> >> So here, we either need your home proxy to be a home B2BUA (After all, >> what happens when B1 and B2 both send back early media, or both get >> answered by a bot?), OR we need a richer 302 response that conveys >> "Try these two destinations in parallel, and if neither replies in X >> seconds, try this third destination). >> >> But, the UAC still doesn't know whether B1 and B2 would send early media. >> >> By offering different ports to B1 and B2 (especially with the media-to-signaling coupling extensions that have been proposed) UAC at least knows which one of B1 and B2 each stream is coming from. > > Yes. But, there are other mechanisms to solve that, and it still doesn't solve the fundamental problem: the UAC can receive multiple media streams associated with multiple early dialogs. > > Also, in bandwidth sensitive access networks there is only limited bandwidth, normally calculated based on the need for media associated with one early dialog. Even if the UAC is able to select and play only one stream to the user, the voice quality will suffer due to too little bandwidth. > > Regards, > > Christer > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Fri Mar 5 15:15:48 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CBC73A743D for ; Fri, 5 Mar 2010 15:15:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.092 X-Spam-Level: X-Spam-Status: No, score=-1.092 tagged_above=-999 required=5 tests=[AWL=-1.391, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, RCVD_IN_DNSWL_LOW=-1] 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 rLeaqxDRXAKD for ; Fri, 5 Mar 2010 15:15:47 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 1D0CD28C3E4 for ; Fri, 5 Mar 2010 15:15:46 -0800 (PST) X-AuditID: c1b4fb3d-b7c72ae00000040e-88-4b9190a490fc Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 41.0E.01038.4A0919B4; Sat, 6 Mar 2010 00:15:48 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([153.88.115.165]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Sat, 6 Mar 2010 00:15:47 +0100 From: Christer Holmberg To: 'Paul Kyzivat' Date: Sat, 6 Mar 2010 00:15:47 +0100 Thread-Topic: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] Thread-Index: Acq8uC3qxtsqqAcLTtuwCSrhJudn5gAATIfA Message-ID: References: <4B918DED.6090108@cisco.com> In-Reply-To: <4B918DED.6090108@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 23:15:48 -0000 Hi, >If you want parallel forking, even if done by the UAC, there is no good so= lution to this problem. The parallel early media is going to be generated a= nd something must happen to it. The only question is=20 >which of the bad solutions you prefer. > >For instance, you may have one stream asking you to enter an access code, = another playing an out-of-service tone, and a third sending no media which = will eventually pick up with a real person. What would=20 >you *like* for the caller to hear? For this reasons you have B2BUAs, application servers, gating nodes etc, th= at at least TRY to deal with the problem, to ensure that whatever the user = eventually hears, at least the quality will be good. Regards, Christer Christer Holmberg wrote: > Hi, > =09 >=20 >> I would like to expand on this issue a little. Suppose I have at my = =09 >> home proxy a policy whereby calls go to B1 and B2 in parallel, and >> after T seconds of no answer calls instead go to B3 (voicemail, >> perhaps). There is no way that the proxy could convey that policy in >> a 3xx response to the UAC. To make this policy (or similar policies) >> work, the proxy would need to manufacturer temporary contact URIs >> that map to B1 and B2 and send these back in a 302. It would then >> need to hope that the UAC does indeed establish new requests in >> parallel to the two temporary contacts for B1 and B2. The proxy >> would need to treat the two requests as related and if both are >> unanswered after T seconds, reject one with a 4xx and the other with >> a 302 (this time with a third temporary contact URI mapped to B3). >> So policy CAN be met by the proxy, although with dependence on the >> UAC doing the right thing. >> =09 >> >> So here, we either need your home proxy to be a home B2BUA (After all, >> what happens when B1 and B2 both send back early media, or both get >> answered by a bot?), OR we need a richer 302 response that conveys >> "Try these two destinations in parallel, and if neither replies in X >> seconds, try this third destination). >> =09 >> But, the UAC still doesn't know whether B1 and B2 would send early medi= a. >> =09 >> By offering different ports to B1 and B2 (especially with the media-to-s= ignaling coupling extensions that have been proposed) UAC at least knows wh= ich one of B1 and B2 each stream is coming from. >=20 > Yes. But, there are other mechanisms to solve that, and it still doesn't = solve the fundamental problem: the UAC can receive multiple media streams a= ssociated with multiple early dialogs. >=20 > Also, in bandwidth sensitive access networks there is only limited bandwi= dth, normally calculated based on the need for media associated with one ea= rly dialog. Even if the UAC is able to select and play only one stream to t= he user, the voice quality will suffer due to too little bandwidth. >=20 > Regards, >=20 > Christer > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From pkyzivat@cisco.com Fri Mar 5 15:30:33 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3871128C3FE for ; Fri, 5 Mar 2010 15:30:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.359 X-Spam-Level: X-Spam-Status: No, score=-8.359 tagged_above=-999 required=5 tests=[AWL=-1.659, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, RCVD_IN_DNSWL_HI=-8] 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 erKgJCHNUFnh for ; Fri, 5 Mar 2010 15:30:28 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 8083328C3FC for ; Fri, 5 Mar 2010 15:30:26 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJUikUtAZnwN/2dsb2JhbACbSnOddphghHcEgxc X-IronPort-AV: E=Sophos;i="4.49,590,1262563200"; d="scan'208";a="90816378" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 05 Mar 2010 23:30:28 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o25NUSko006454; Fri, 5 Mar 2010 23:30:28 GMT Message-ID: <4B919413.60506@cisco.com> Date: Fri, 05 Mar 2010 18:30:27 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4B918DED.6090108@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Mar 2010 23:30:34 -0000 Christer Holmberg wrote: > Hi, > >> If you want parallel forking, even if done by the UAC, there is no good solution to this problem. The parallel early media is going to be generated and something must happen to it. The only question is >> which of the bad solutions you prefer. >> >> For instance, you may have one stream asking you to enter an access code, another playing an out-of-service tone, and a third sending no media which will eventually pick up with a real person. What would >> you *like* for the caller to hear? > > For this reasons you have B2BUAs, application servers, gating nodes etc, that at least TRY to deal with the problem, to ensure that whatever the user eventually hears, at least the quality will be good. For what that's worth! You get a good quality rendering of that out-of-service tone, and so hang up even though the call was ringing elsewhere, but without any ringback. I guess we just have to "let a 1000 flowers bloom" on this one. Paul > Regards, > > Christer > > > > Christer Holmberg wrote: >> Hi, >> >> >>> I would like to expand on this issue a little. Suppose I have at my >>> home proxy a policy whereby calls go to B1 and B2 in parallel, and >>> after T seconds of no answer calls instead go to B3 (voicemail, >>> perhaps). There is no way that the proxy could convey that policy in >>> a 3xx response to the UAC. To make this policy (or similar policies) >>> work, the proxy would need to manufacturer temporary contact URIs >>> that map to B1 and B2 and send these back in a 302. It would then >>> need to hope that the UAC does indeed establish new requests in >>> parallel to the two temporary contacts for B1 and B2. The proxy >>> would need to treat the two requests as related and if both are >>> unanswered after T seconds, reject one with a 4xx and the other with >>> a 302 (this time with a third temporary contact URI mapped to B3). >>> So policy CAN be met by the proxy, although with dependence on the >>> UAC doing the right thing. >>> >>> >>> So here, we either need your home proxy to be a home B2BUA (After all, >>> what happens when B1 and B2 both send back early media, or both get >>> answered by a bot?), OR we need a richer 302 response that conveys >>> "Try these two destinations in parallel, and if neither replies in X >>> seconds, try this third destination). >>> >>> But, the UAC still doesn't know whether B1 and B2 would send early media. >>> >>> By offering different ports to B1 and B2 (especially with the media-to-signaling coupling extensions that have been proposed) UAC at least knows which one of B1 and B2 each stream is coming from. >> Yes. But, there are other mechanisms to solve that, and it still doesn't solve the fundamental problem: the UAC can receive multiple media streams associated with multiple early dialogs. >> >> Also, in bandwidth sensitive access networks there is only limited bandwidth, normally calculated based on the need for media associated with one early dialog. Even if the UAC is able to select and play only one stream to the user, the voice quality will suffer due to too little bandwidth. >> >> Regards, >> >> Christer >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > From christer.holmberg@ericsson.com Sat Mar 6 01:10:14 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7221128C14E for ; Sat, 6 Mar 2010 01:10:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.038 X-Spam-Level: X-Spam-Status: No, score=-1.038 tagged_above=-999 required=5 tests=[AWL=-1.338, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, RCVD_IN_DNSWL_LOW=-1] 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 MPX9aiXrruXL for ; Sat, 6 Mar 2010 01:10:12 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id CFEA028C15D for ; Sat, 6 Mar 2010 01:10:09 -0800 (PST) X-AuditID: c1b4fb3d-b7c72ae00000040e-88-4b921bf26af8 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id EA.4D.01038.2FB129B4; Sat, 6 Mar 2010 10:10:10 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([153.88.115.165]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sat, 6 Mar 2010 10:10:10 +0100 From: Christer Holmberg To: Paul Kyzivat Date: Sat, 6 Mar 2010 10:10:09 +0100 Thread-Topic: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] Thread-Index: Acq8u9hgIPVdyDIVRISuA6SOpseMTAAT4vHu Message-ID: References: <4B918DED.6090108@cisco.com> , <4B919413.60506@cisco.com> In-Reply-To: <4B919413.60506@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Mar 2010 09:10:15 -0000 Hi, >>>If you want parallel forking, even if done by the UAC, there is no good = solution to this problem. The=20 >>>parallel early media is going to be generated and something must happen = to it. The only question is >>>which of the bad solutions you prefer. >>> >>>For instance, you may have one stream asking you to enter an access code= , another playing an out-of- >>>service tone, and a third sending no media which will eventually pick up= with a real person. What would >>>you *like* for the caller to hear? >> >>For this reasons you have B2BUAs, application servers, gating nodes etc, = that at least TRY to deal with the=20 >>problem, to ensure that whatever the user eventually hears, at least the = quality will be good. > >For what that's worth! You get a good quality rendering of that >out-of-service tone, and so hang up even though the call was ringing >elsewhere, but without any ringback. > >I guess we just have to "let a 1000 flowers bloom" on this one. As I've said before, I don't think there is a very big risk that the "wrong= " early media would be presented to you. Leaving PSTN interworking aside, most early media (at least the one of real= importance) will be generated by application servers/B2BUAs in the network= , and they will normally be able to control the media pretty well. A SIP UA= might generate something, but unless it's a Henry Sinnreich device (where = all the services are implemented in the end device :) I don't think UAs wil= l normally send service related announcement etc. Of course, if you have application servers sending media both in the origin= ating and terminating network, there need to be some policy procedures on w= hich media has higher priority etc. Regards, Christer > Christer Holmberg wrote: >> Hi, >> >> >>> I would like to expand on this issue a little. Supp= ose I have at my >>> home proxy a policy whereby calls go to B1 and B2 i= n parallel, and >>> after T seconds of no answer calls instead go to B3= (voicemail, >>> perhaps). There is no way that the proxy could conv= ey that policy in >>> a 3xx response to the UAC. To make this policy (or = similar policies) >>> work, the proxy would need to manufacturer temporar= y contact URIs >>> that map to B1 and B2 and send these back in a 302.= It would then >>> need to hope that the UAC does indeed establish new= requests in >>> parallel to the two temporary contacts for B1 and B= 2. The proxy >>> would need to treat the two requests as related and= if both are >>> unanswered after T seconds, reject one with a 4xx a= nd the other with >>> a 302 (this time with a third temporary contact URI= mapped to B3). >>> So policy CAN be met by the proxy, although with de= pendence on the >>> UAC doing the right thing. >>> >>> >>> So here, we either need your home proxy to be a home B2BUA = (After all, >>> what happens when B1 and B2 both send back early media, or = both get >>> answered by a bot?), OR we need a richer 302 response that = conveys >>> "Try these two destinations in parallel, and if neither rep= lies in X >>> seconds, try this third destination). >>> >>> But, the UAC still doesn't know whether B1 and B2 would send early = media. >>> >>> By offering different ports to B1 and B2 (especially with the media-to-= signaling coupling extensions that have been proposed) UAC at least knows w= hich one of B1 and B2 each stream is coming from. >> Yes. But, there are other mechanisms to solve that, and it still doesn't= solve the fundamental problem: the UAC can receive multiple media streams = associated with multiple early dialogs. >> >> Also, in bandwidth sensitive access networks there is only limited bandw= idth, normally calculated based on the need for media associated with one e= arly dialog. Even if the UAC is able to select and play only one stream to = the user, the voice quality will suffer due to too little bandwidth. >> >> Regards, >> >> Christer >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >= From dean.willis@softarmor.com Sat Mar 6 10:13:30 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADD023A9105 for ; Sat, 6 Mar 2010 10:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 eLT9gtqB9sKl for ; Sat, 6 Mar 2010 10:13:24 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 64F3A3A90FE for ; Sat, 6 Mar 2010 10:13:23 -0800 (PST) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o26IDLAt001592 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 6 Mar 2010 12:13:22 -0600 Message-Id: <21B07BA5-AC86-4580-BD95-687F11FF3364@softarmor.com> From: Dean Willis To: Paul Kyzivat In-Reply-To: <4B918DED.6090108@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sat, 6 Mar 2010 12:13:15 -0600 References: <4B918DED.6090108@cisco.com> X-Mailer: Apple Mail (2.936) Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Mar 2010 18:13:30 -0000 On Mar 5, 2010, at 5:04 PM, Paul Kyzivat wrote: > If you want parallel forking, even if done by the UAC, there is no > good solution to this problem. The parallel early media is going to > be generated and something must happen to it. The only question is > which of the bad solutions you prefer. > > For instance, you may have one stream asking you to enter an access > code, another playing an out-of-service tone, and a third sending no > media which will eventually pick up with a real person. What would > you *like* for the caller to hear? > I at least want the caller to be able to correlate a media flow with a signaling leg so they know which one is which. -- Dean From pkyzivat@cisco.com Sun Mar 7 08:47:37 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C291A3A8D29 for ; Sun, 7 Mar 2010 08:47:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.649 X-Spam-Level: X-Spam-Status: No, score=-8.649 tagged_above=-999 required=5 tests=[AWL=-1.950, BAYES_00=-2.599, FB_CIALIS_LEO3=3.899, RCVD_IN_DNSWL_HI=-8] 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 iIAIhvzPs4sr for ; Sun, 7 Mar 2010 08:47:36 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id C5A2E3A88F3 for ; Sun, 7 Mar 2010 08:47:36 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAZok0tAZnwN/2dsb2JhbACbRHOgRJdCglSCJASDFw X-IronPort-AV: E=Sophos;i="4.49,598,1262563200"; d="scan'208";a="162024025" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by sj-iport-5.cisco.com with ESMTP; 07 Mar 2010 16:47:35 +0000 Received: from [10.86.242.189] (che-vpn-cluster-2-189.cisco.com [10.86.242.189]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o27GlYOI016050; Sun, 7 Mar 2010 16:47:34 GMT Message-ID: <4B93D8A6.1040105@cisco.com> Date: Sun, 07 Mar 2010 11:47:34 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Christer Holmberg References: <4B918DED.6090108@cisco.com> , <4B919413.60506@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2010 16:47:37 -0000 Christer Holmberg wrote: > Hi, > >>>> If you want parallel forking, even if done by the UAC, there is no good solution to this problem. The >>>> parallel early media is going to be generated and something must happen to it. The only question is >>>> which of the bad solutions you prefer. >>>> >>>> For instance, you may have one stream asking you to enter an access code, another playing an out-of- >>>> service tone, and a third sending no media which will eventually pick up with a real person. What would >>>> you *like* for the caller to hear? >>> For this reasons you have B2BUAs, application servers, gating nodes etc, that at least TRY to deal with the >>> problem, to ensure that whatever the user eventually hears, at least the quality will be good. >> For what that's worth! You get a good quality rendering of that >> out-of-service tone, and so hang up even though the call was ringing >> elsewhere, but without any ringback. >> >> I guess we just have to "let a 1000 flowers bloom" on this one. > > As I've said before, I don't think there is a very big risk that the "wrong" early media would be presented to you. > Leaving PSTN interworking aside, most early media (at least the one of real importance) will be generated by application servers/B2BUAs in the network, and they will normally be able to control the media pretty well. A SIP UA might generate something, but unless it's a Henry Sinnreich device (where all the services are implemented in the end device :) I don't think UAs will normally send service related announcement etc. I gather you are arguing that there just aren't many calls with early media. But "leaving PSTN interworking aside" isn't really fair, since there is so much of that. For instance there could be a lot of the google service that simply forks calls to multiple PSTN lines. And don't most pstn calls have in-band ringback? That would get multiple early media, though if its just ringback it doesn't matter if you play it or not. But if one of those becomes defective and starts playing out of service messages then it does matter which one you play. > Of course, if you have application servers sending media both in the originating and terminating network, there need to be some policy procedures on which media has higher priority etc. Policy doesn't help a lot. It content, not policy, that determines which is important to hear. Perhaps the best we can do is discourage the use of early media for anything important. Thanks, Paul > Regards, > > Christer > > > > > > >> Christer Holmberg wrote: >>> Hi, >>> >>> >>>> I would like to expand on this issue a little. Suppose I have at my >>>> home proxy a policy whereby calls go to B1 and B2 in parallel, and >>>> after T seconds of no answer calls instead go to B3 (voicemail, >>>> perhaps). There is no way that the proxy could convey that policy in >>>> a 3xx response to the UAC. To make this policy (or similar policies) >>>> work, the proxy would need to manufacturer temporary contact URIs >>>> that map to B1 and B2 and send these back in a 302. It would then >>>> need to hope that the UAC does indeed establish new requests in >>>> parallel to the two temporary contacts for B1 and B2. The proxy >>>> would need to treat the two requests as related and if both are >>>> unanswered after T seconds, reject one with a 4xx and the other with >>>> a 302 (this time with a third temporary contact URI mapped to B3). >>>> So policy CAN be met by the proxy, although with dependence on the >>>> UAC doing the right thing. >>>> >>>> >>>> So here, we either need your home proxy to be a home B2BUA (After all, >>>> what happens when B1 and B2 both send back early media, or both get >>>> answered by a bot?), OR we need a richer 302 response that conveys >>>> "Try these two destinations in parallel, and if neither replies in X >>>> seconds, try this third destination). >>>> >>>> But, the UAC still doesn't know whether B1 and B2 would send early media. >>>> >>>> By offering different ports to B1 and B2 (especially with the media-to-signaling coupling extensions that have been proposed) UAC at least knows which one of B1 and B2 each stream is coming from. >>> Yes. But, there are other mechanisms to solve that, and it still doesn't solve the fundamental problem: the UAC can receive multiple media streams associated with multiple early dialogs. >>> >>> Also, in bandwidth sensitive access networks there is only limited bandwidth, normally calculated based on the need for media associated with one early dialog. Even if the UAC is able to select and play only one stream to the user, the voice quality will suffer due to too little bandwidth. >>> >>> Regards, >>> >>> Christer >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> From gilad@voxisoft.com Sun Mar 7 13:41:13 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 173C628C1DC for ; Sun, 7 Mar 2010 13:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] 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 lHFmIW3yZRli for ; Sun, 7 Mar 2010 13:41:12 -0800 (PST) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by core3.amsl.com (Postfix) with ESMTP id EAEE13A91B0 for ; Sun, 7 Mar 2010 13:41:11 -0800 (PST) Received: by fg-out-1718.google.com with SMTP id 22so777544fge.13 for ; Sun, 07 Mar 2010 13:41:12 -0800 (PST) Received: by 10.87.66.24 with SMTP id t24mr5357424fgk.75.1267998072051; Sun, 07 Mar 2010 13:41:12 -0800 (PST) Received: from vxp1 (bzq-79-176-44-3.red.bezeqint.net [79.176.44.3]) by mx.google.com with ESMTPS id 16sm2501636fxm.7.2010.03.07.13.41.08 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 07 Mar 2010 13:41:10 -0800 (PST) From: "Gilad Shaham" To: "'Paul Kyzivat'" , "'Christer Holmberg'" References: <4B918DED.6090108@cisco.com> , <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> In-Reply-To: <4B93D8A6.1040105@cisco.com> Date: Sun, 7 Mar 2010 23:41:07 +0200 Message-ID: <001a01cabe3e$e7033f80$b509be80$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq+FenT+WaAWEcGQIK4X4SS4GhOGQAJmKsw Content-Language: en-us Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0015_01CABE4F.89F1A7D0" Cc: 'SIPCORE' Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2010 21:41:13 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0015_01CABE4F.89F1A7D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > Perhaps the best we can do is discourage the use of early media for > anything important. > I'm not sure this scenario is that common, but if it is something of interest, perhaps it's possible to add a header/parameter conveying the nature of the media stream (ringback, service message, voice, etc.). This is similar to the content-disposition handling parameter, but more informative than "optional" and "required". This way, a B2BUA would be able to choose the stream to forward and even without a B2BUA, an endpoint receiving several streams would know which stream to play back to the user. ------=_NextPart_000_0015_01CABE4F.89F1A7D0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWTzCCBpgw ggWAoAMCAQICAwDUFjANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTA5MTIyMTE2MzYzMVoXDTEwMTIyMjIwMDQ0MFowgZAxIDAeBgNVBA0TFzExNzAxMC1BTVdX YVlCNDRTWXAybkRIMR4wHAYDVQQKExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxKTAnBgNVBAMTIFN0 YXJ0Q29tIEZyZWUgQ2VydGlmaWNhdGUgTWVtYmVyMSEwHwYJKoZIhvcNAQkBFhJnaWxhZEB2b3hp c29mdC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHtKrui8JEVNwxbg2PU/lQ GlxUnKyurwEhD7ENqPC4ipG8XL1XFx0ITxEXOcs0qboGQnGOtUpXIX81m2RMaRQWpwiAL22Vn4xq 9FM2aeMBI2IprfcL4xnbc2h9A9ysBoYdo1kfvGfaFfwlgxjw7irxGgyIFaYZ1QohKBWTWtfCd2tW 8qasUVTNs9BkuBR6/3U3KKaagc25d5q+Q9dPR4ocjUE0B3uSclxADF3qhCEzfOEjVYNZET7odKz1 Z/HLk+GHJxmnfJcZmVwV1RiqwmpDWF/Xln6UVuFFE6fWYccbt2z3uTHfCUyTw/u58W0pgEmR5Eqp 4cOLugqPWDrm/QMbAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFHSjlL7/4MZ5jDj1Rjr/cfv0V4GzMB8G A1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB0GA1UdEQQWMBSBEmdpbGFkQHZveGlzb2Z0 LmNvbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGBtTcBAgEwggEgMC4GCCsGAQUFBwIBFiJo dHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENv bSBMdGQuMAMCAQEagZFMaW1pdGVkIExpYWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0 YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2 YWlsYWJsZSBhdCBodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFow K6ApoCeGJWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwK6ApoCeGJWh0dHA6 Ly9jcmwuc3RhcnRzc2wuY29tL2NydHUxLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYB BQUHMAGGLWh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MxL2NsaWVudC9jYTBCBggr BgEFBQcwAoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMS5jbGllbnQu Y2EuY3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF AAOCAQEAdnaEHlWRqjSubUjWXHSyH21RCF2RKysR6qOyV4Mzyj3g67px8uPAqFdvYtceXqVG+eCX iW5PA1yJgi6UGzWjW8ItU1o/ETJmK31ZVq1jnruiBshrF4aOk3+VoA/hb7UhIfAhSZ6qcAyU+r74 5jZl+BvxfAR2lIMb7t5VUZuk4eDfOIlb1gQiDe550eauFRmdFjFOFyfBSpYkF9z6VKN26ASi4YGs vITuffcrqP8NKFXLVGXMLccmBR54PdejsVHbpdSCDUSGzhZfJgDQqNh9mREsz6O2UQGVBgRu1HBW KUY0F6ehifGmOWnsMWey6zmZA+qUq+Im6gewd2GwvxDBajCCB8kwggWxoAMCAQICAQEwDQYJKoZI hvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsT IlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYzNlowfTEL MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdp dGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4n5V7tTOQ 8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZZ7bEBn0K nnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N3gs7Skuf wiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqouaarg0kd 5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ96qryr92 /W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHsDOvSjejq nHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B7hIQDcYy fxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/kLfjkdLd 78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8novgdujbv8m MJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIwggJOMAwG A1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD0EGu8jBk BgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDAr oCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1UdIASCAVQw ggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFydGNv bS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL2lu dGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwgKFN0YXJ0 Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVn YWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQ b2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMBEG CWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs2hBOOBxe 36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmRHVGrgnt+ 1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdEw5Aa3jip PKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3Tmh2a82VQ 9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxyweSxFEyDRS J80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98iWX1jkNU DqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIousNE4mIgSh hyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkEGkcJ5g8B ViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2IgyudWS2Xq /mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMIIH4jCCBcqgAwIBAgIBDTANBgkq hkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0MjEwMTU0WhcNMTIxMDIyMjEwMTU0WjCB jDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBE aWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJp bWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8SD+rqvyNH4QrvnEIaFHxOhESip7vMz39S cLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qbLtsjjJbi6sL7Ls/f/X9ftTyhxvxWkf8K W37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1slBhyWwaQPEPPZRsWoTb7q8hmgv6Nv3Hg 9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5rcVjGcIWZ2v/43Yksq60jExipA4l5uv9 /+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwIDAQABo4IDWzCCA1cwDAYDVR0TBAUwAwEB /zALBgNVHQ8EBAMCAaYwHQYDVR0OBBYEFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMIGoBgNVHSMEgaAw gZ2AFE4L7xqkQFulF2mHMMo0aEPQQa7yoYGBpH8wfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx KTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5ggEBMAkGA1UdEgQCMAAw PQYIKwYBBQUHAQEEMTAvMC0GCCsGAQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNj YS5jcnQwYAYDVR0fBFkwVzAsoCqgKIYmaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3Nmc2NhLWNy bC5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDCCAV0GA1UdIASC AVQwggFQMIIBTAYLKwYBBAGBtTcBAQQwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5zdGFy dGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20ub3Jn L2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwgKFN0 YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlvbiAq TGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRm MBEGCWCGSAGG+EIBAQQEAwIABzBQBglghkgBhvhCAQ0EQxZBU3RhcnRDb20gQ2xhc3MgMSBQcmlt YXJ5IEludGVybWVkaWF0ZSBGcmVlIFNTTCBFbWFpbCBDZXJ0aWZpY2F0ZXMwDQYJKoZIhvcNAQEF BQADggIBAKqa4eBbjM4dG/wdxiwwIKC3kyb98QK2zREovyn/xzDP/4H/Bc8FFDTgoJR+nX2Li0EP 3U7TsjG+CaIi90+8YlShADpkPrfm/8SzjGtJtfM6EaluJOhpcqMr3OyzK3aYGJP5RIeZ6vLT3fQa DZsIooXl6YSFR/0HpU4FJDc0wuyFaZmFbCrjTp8RNYyRWTTX6mWSv+TraOwuj3zrrddSpgUEi2Wq wM9G/5o4IXQbGHx7oXTvL6zrw9IOYO3QOKZDgFNhHeKUgqMAUiLcg/+WhcGe+Y4umKuxghtwaYsg D/bLfIfop3NC/u5JqwDCWizAJruhmbOV4LG859MFCb2w/YeY55zDPVGmQ3MZdriwdOKrhlFjOjYi hmm28UHOvND2G3kK0LvnuieLqjQMc6GuUcZAQOWv96pW4BfbiQXpAqibMMeb0PZISa7PFEzGiBc2 xAuVRkM4kB9/+iieA1D/OTiRJwsf6rkoVgOsN9fCw522tzOmuVfiqDS4bFYv00sX/dFGwasHUUf3 DsLhpDSYdejb74SKjtuqLDIOuAm2bA1axA6+7kjFeNIngSU6OPSMre+xAjoc/6coaMGthFD+mimr /i/8F8wDwdyzas7oxkdCtaW8hVir8mJnbp4CbckllDMPkeQ6qQNmxSDhOeqX1jyx2cTi/vPq+/Ty xV/stlehMYID2DCCA9QCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBM dGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQD Ey9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDANQWMAkG BSsOAwIaBQCgggIYMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEw MDMwNzIxNDAxNVowIwYJKoZIhvcNAQkEMRYEFJ8sJ4irM+weNlSoiZL6t2ZjOaWzMGcGCSqGSIb3 DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO AwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIGlBgkrBgEEAYI3EAQxgZcw gZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1 cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAx IFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDANQWMIGnBgsqhkiG9w0BCRACCzGBl6CB lDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEg UHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMA1BYwDQYJKoZIhvcNAQEBBQAEggEAintw 1fpLdv71U7FJ49lAK7+LsWuasltG2Qh+9p+k0mIl5jQ8Zw9Fz7KxjCCEQZtg9LPrU4GuVLO3lNAP ea7XpA4/PkASSK7xXvnR2Ybo8iYO3K7zSKp5MZE7tPn9LcECBx45Ae1x18cHlCe8MZHjTHwymtDQ eKlWjJnJzhZeq3ua8LEopsHQCF9/trLE8xWLzIoTIrn11lyWcSzzk7YSgBkSY1LgN2KuW8mPpO9f EUkuCRyxyIm1fa3/c4WpkFpjOS54uY04efxoPCCM+C8N5OEh7WpHISyDO3N74I+JcHkfR0wFWwFw HfendZJ1C+N0GVJWl+V43ExzdIGIXJfTpQAAAAAAAA== ------=_NextPart_000_0015_01CABE4F.89F1A7D0-- From gao.yang2@zte.com.cn Sun Mar 7 16:47:45 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA1773A67F3 for ; Sun, 7 Mar 2010 16:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.349 X-Spam-Level: X-Spam-Status: No, score=-100.349 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] 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 oTBh0IHl+U7O for ; Sun, 7 Mar 2010 16:47:45 -0800 (PST) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 85FF13A676A for ; Sun, 7 Mar 2010 16:47:44 -0800 (PST) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 469071727820181; Mon, 8 Mar 2010 08:18:49 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 64572.3202798452; Mon, 8 Mar 2010 08:47:41 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id o280leAX025453; Mon, 8 Mar 2010 08:47:40 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: Oscar Novo MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 8 Mar 2010 08:46:09 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-03-08 08:47:37, Serialize complete at 2010-03-08 08:47:37 Content-Type: multipart/alternative; boundary="=_alternative 00045A4F482576E0_=" X-MAIL: mse1.zte.com.cn o280leAX025453 Cc: sipcore@ietf.org Subject: [sipcore] Hi Oscar, I can not get mails from sipcore maillist(other lists are OK) from 2 March. Could you help me to fix it? Thanks. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 00:47:45 -0000 This is a multipart message in MIME format. --=_alternative 00045A4F482576E0_= Content-Type: text/plain; charset="US-ASCII" =================================== Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn =================================== -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00045A4F482576E0_= Content-Type: text/html; charset="US-ASCII"
===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
===================================
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00045A4F482576E0_=-- From gao.yang2@zte.com.cn Sun Mar 7 17:23:23 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 902ED3A67B5 for ; Sun, 7 Mar 2010 17:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.793 X-Spam-Level: X-Spam-Status: No, score=-100.793 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_71=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] 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 RgL7N+6aEpYh for ; Sun, 7 Mar 2010 17:23:21 -0800 (PST) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 997CC3A67C2 for ; Sun, 7 Mar 2010 17:23:20 -0800 (PST) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 469071727820181; Mon, 8 Mar 2010 08:54:27 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 84131.3533455949; Mon, 8 Mar 2010 09:21:42 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id o281MJ0Y047109; Mon, 8 Mar 2010 09:22:20 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: sipcore@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 8 Mar 2010 09:20:50 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-03-08 09:22:17, Serialize complete at 2010-03-08 09:22:17 Content-Type: multipart/alternative; boundary="=_alternative 0007870E482576E0_=" X-MAIL: mse1.zte.com.cn o281MJ0Y047109 Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] //copy from the sipcore Discussion Archive X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 01:23:23 -0000 This is a multipart message in MIME format. --=_alternative 0007870E482576E0_= Content-Type: text/plain; charset="US-ASCII" Hi, Sorry for copy the mail from archive(I can not recv sipcore mails these days). inlines. Thanks, Gao From: Paul Kyzivat To: Christer Holmberg Cc: SIPCORE Date: Sun, 07 Mar 2010 11:47:34 -0500 In-reply-to: References: <4B918DED.6090108 at cisco.com> , <4B919413.60506 at cisco.com> Christer Holmberg wrote: Hi, If you want parallel forking, even if done by the UAC, there is no good solution to this problem. The parallel early media is going to be generated and something must happen to it. The only question is which of the bad solutions you prefer. For instance, you may have one stream asking you to enter an access code, another playing an out-of- service tone, and a third sending no media which will eventually pick up with a real person. What would you *like* for the caller to hear? For this reasons you have B2BUAs, application servers, gating nodes etc, that at least TRY to deal with the problem, to ensure that whatever the user eventually hears, at least the quality will be good. For what that's worth! You get a good quality rendering of that out-of-service tone, and so hang up even though the call was ringing elsewhere, but without any ringback. I guess we just have to "let a 1000 flowers bloom" on this one. As I've said before, I don't think there is a very big risk that the "wrong" early media would be presented to you. Leaving PSTN interworking aside, most early media (at least the one of real importance) will be generated by application servers/B2BUAs in the network, and they will normally be able to control the media pretty well. A SIP UA might generate something, but unless it's a Henry Sinnreich device (where all the services are implemented in the end device :) I don't think UAs will normally send service related announcement etc. I gather you are arguing that there just aren't many calls with early media. But "leaving PSTN interworking aside" isn't really fair, since there is so much of that. For instance there could be a lot of the google service that simply forks calls to multiple PSTN lines. And don't most pstn calls have in-band ringback? That would get multiple early media, though if its just ringback it doesn't matter if you play it or not. But if one of those becomes defective and starts playing out of service messages then it does matter which one you play. [Gao] I agree. The forking proxy/AS have no way to know the contents of early media currently. So, it is not proper to judge which one is more important and do filter things. Of course, if you have application servers sending media both in the originating and terminating network, there need to be some policy procedures on which media has higher priority etc. Policy doesn't help a lot. It content, not policy, that determines which is important to hear. [Gao] Yes. Perhaps the best we can do is discourage the use of early media for anything important. [Gao] As many operating equipment/network has used early media for someting important as DTMF number collecting or code collecting, discourage the usage may cause interworking and compatible problem. =================================== Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn =================================== -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 0007870E482576E0_= Content-Type: text/html; charset="US-ASCII"
Hi,

Sorry for copy the mail from archive(I can not recv sipcore mails these days).

inlines.

Thanks,

Gao

From: Paul Kyzivat <pkyzivat at cisco.com>
To: Christer Holmberg <christer.holmberg at ericsson.com>
Cc: SIPCORE <sipcore at ietf.org>
Date: Sun, 07 Mar 2010 11:47:34 -0500
In-reply-to: <FF84A09F50A6DC48ACB6714F4666CC745C10EE4166 at ESESSCMS0354.eemea.ericsson.se>
References: <FF84A09F50A6DC48ACB6714F4666CC745C10EE415F at ESESSCMS0354.eemea.ericsson.se> <AEA0E9BF-8B6A-4AAA-81B6-A7C68F6B7309 at softarmor.com> <FF84A09F50A6DC48ACB6714F4666CC745C1102CCCD at ESESSCMS0354.eemea.ericsson.se> <4B918DED.6090108 at cisco.com> <FF84A09F50A6DC48ACB6714F4666CC745C1102CCD1 at ESESSCMS0354.eemea.ericsson.se>, <4B919413.60506 at cisco.com> <FF84A09F50A6DC48ACB6714F4666CC745C10EE4166 at ESESSCMS0354.eemea.ericsson.se>

Christer Holmberg wrote:

Hi,


If you want parallel forking, even if done by the UAC, there is no good solution to this problem. The parallel early media is going to be generated and something must happen to it. The only question is
which of the bad solutions you prefer.

For instance, you may have one stream asking you to enter an access code, another playing an out-of-
service tone, and a third sending no media which will eventually pick up with a real person. What would
you *like* for the caller to hear?

For this reasons you have B2BUAs, application servers, gating nodes etc, that at least TRY to deal with the problem, to ensure that whatever the user eventually hears, at least the quality will be good.
For what that's worth! You get a good quality rendering of that
out-of-service tone, and so hang up even though the call was ringing
elsewhere, but without any ringback.

I guess we just have to "let a 1000 flowers bloom" on this one.


As I've said before, I don't think there is a very big risk that the "wrong" early media would be presented to you.




Leaving PSTN interworking aside, most early media (at least the one of real importance) will be generated by application servers/B2BUAs in the network, and they will normally be able to control the media pretty well. A SIP UA might generate something, but unless it's a Henry Sinnreich device (where all the services are implemented in the end device :) I don't think UAs will normally send service related announcement etc.



I gather you are arguing that there just aren't many calls with early media. But "leaving PSTN interworking aside" isn't really fair, since there is so much of that. For instance there could be a lot of the google service that simply forks calls to multiple PSTN lines. And don't most pstn calls have in-band ringback? That would get multiple early media, though if its just ringback it doesn't matter if you play it or not. But if one of those becomes defective and starts playing out of service messages then it does matter which one you play.

[Gao] I agree. The forking proxy/AS have no way to know the contents of early media currently. So, it is not proper to judge which one is more important and do filter things.

Of course, if you have application servers sending media both in the originating and terminating network, there need to be some policy procedures on which media has higher priority etc.



Policy doesn't help a lot. It content, not policy, that determines which is important to hear.

[Gao] Yes.

Perhaps the best we can do is discourage the use of early media for anything important.

[Gao] As many operating equipment/network has used early media for someting important as DTMF number collecting or code collecting, discourage the usage may cause interworking and compatible problem.


===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
===================================
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 0007870E482576E0_=-- From gao.yang2@zte.com.cn Sun Mar 7 18:30:41 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5F343A683E for ; Sun, 7 Mar 2010 18:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.116 X-Spam-Level: X-Spam-Status: No, score=-100.116 tagged_above=-999 required=5 tests=[AWL=-0.678, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_53=0.6, J_CHICKENPOX_57=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] 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 bwwf-ZsqKh6S for ; Sun, 7 Mar 2010 18:30:40 -0800 (PST) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 60E4A3A6846 for ; Sun, 7 Mar 2010 18:30:33 -0800 (PST) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 469071727820181; Mon, 8 Mar 2010 10:01:12 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 84131.6004501076; Mon, 8 Mar 2010 10:28:54 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o282URDn086436; Mon, 8 Mar 2010 10:30:27 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: sipcore@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 8 Mar 2010 10:28:54 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-03-08 10:30:21, Serialize complete at 2010-03-08 10:30:21 Content-Type: multipart/alternative; boundary="=_alternative 000DC253482576E0_=" X-MAIL: mse2.zte.com.cn o282URDn086436 Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 02:30:41 -0000 This is a multipart message in MIME format. --=_alternative 000DC253482576E0_= Content-Type: text/plain; charset="US-ASCII" I'd like to talk about how our equipment handle this issue(I still think the early media issue of forking is exist). Logically, we define two logical point(can be in one physical equipment): 1. Caller's Gateway, such as MGCF(of IMS) for PSTN. 2. Forking Equipment. As Forking Equipment has no way to know the contents of early media. So it is not proper for the Forking Equipment to do any filter of early medias. So, we make the Forking Equipment transfer all early medias in different dialogs to the caller direction. The Caller's Gateway is the equipment familiar with caller's capability and its preference. So, if caller can accept multiple early medias, the Caller's Gateway just render the all; if caller can only afford one early media, the Caller's Gateway just send one early media(Usually, our Caller's Gateway send its own ringing backtone, insteand of choosing one). In fact, if some early medias are used as collecting DTMF for call re-dispatch or code, the Caller's Gateway may still discard them and cause problem. While caller's capability may cause more basic problem of forking, such as caller can only afford three forking dialog, but it is the fourth one has real call answer. Such problems caused by UAC's capability can only be handled as best effort, IMO. Thanks, Gao =================================== Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn =================================== -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 000DC253482576E0_= Content-Type: text/html; charset="US-ASCII"
I'd like to talk about how our equipment handle this issue(I still think the early media issue of forking is exist).

Logically, we define two logical point(can be in one physical equipment):
1. Caller's Gateway, such as MGCF(of IMS) for PSTN.
2. Forking Equipment.

As Forking Equipment has no way to know the contents of early media. So it is not proper for the Forking Equipment to do any filter of early medias. So, we make the Forking Equipment transfer all early medias in different dialogs to the caller direction.

The Caller's Gateway is the equipment familiar with caller's capability and its preference. So, if caller can accept multiple early medias, the Caller's Gateway just render the all; if caller can only afford one early media, the Caller's Gateway just send one early media(Usually, our Caller's Gateway send its own ringing backtone, insteand of choosing one).

In fact, if some early medias are used as collecting DTMF for call re-dispatch or code, the Caller's Gateway may still discard them and cause problem. While caller's capability may cause more basic problem of forking, such as caller can only afford three forking dialog, but it is the fourth one has real call answer. Such problems caused by UAC's capability can only be handled as best effort, IMO.

Thanks,

Gao
 
===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
===================================
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 000DC253482576E0_=-- From gao.yang2@zte.com.cn Sun Mar 7 18:32:30 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EDA23A6853 for ; Sun, 7 Mar 2010 18:32:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.094 X-Spam-Level: X-Spam-Status: No, score=-96.094 tagged_above=-999 required=5 tests=[AWL=1.541, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] 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 DydT76EBsFUX for ; Sun, 7 Mar 2010 18:32:29 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 3166B3A6847 for ; Sun, 7 Mar 2010 18:32:29 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 111641727820181; Mon, 8 Mar 2010 09:54:04 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 64572.3517442228; Mon, 8 Mar 2010 10:32:27 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o282WAIU087944; Mon, 8 Mar 2010 10:32:10 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: Oscar Novo MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 8 Mar 2010 10:30:38 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-03-08 10:32:04, Serialize complete at 2010-03-08 10:32:04 Content-Type: multipart/alternative; boundary="=_alternative 000DEB17482576E0_=" X-MAIL: mse2.zte.com.cn o282WAIU087944 Cc: sipcore@ietf.org Subject: [sipcore] I can send but can not recv. Maybe this information is useful for diagnose. //Hi Oscar, I can not get mails from sipcore maillist(other lists are OK) from 2 March. Could you help me to fix it? Thanks. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 02:32:30 -0000 This is a multipart message in MIME format. --=_alternative 000DEB17482576E0_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiBaaXAgICAgOiAyMTAwMTINCiBU ZWwgICAgOiA4NzIxMQ0KIFRlbDIgICA6KCs4NiktMDI1LTUyODc3MjExDQogZV9tYWlsIDogZ2Fv LnlhbmcyQHp0ZS5jb20uY24NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQot LS0tLSDXqreiyMsgR2FvWWFuZzE0MDE5Ny91c2VyL3p0ZV9sdGQgyrG85CAyMDEwLTAzLTA4IDEw OjMwIC0tLS0tDQoNCkdhb1lhbmcxNDAxOTcvdXNlci96dGVfbHRkIA0KMjAxMC0wMy0wOCAwODo0 Ng0KDQrK1bz+yMsNCk9zY2FyIE5vdm8gPE9zY2FyLk5vdm9AZXJpY3Nzb24uY29tPg0Ks63LzQ0K c2lwY29yZUBpZXRmLm9yZw0K1vfM4g0KSGkgT3NjYXIsIEkgY2FuIG5vdCBnZXQgbWFpbHMgZnJv bSBzaXBjb3JlIG1haWxsaXN0KG90aGVyIGxpc3RzIGFyZSBPSykgDQpmcm9tIDIgTWFyY2guIENv dWxkIHlvdSBoZWxwIG1lIHRvIGZpeCBpdD8gVGhhbmtzLg0KDQoNCg0KDQoNCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DQogWmlwICAgIDogMjEwMDEyDQogVGVsICAgIDogODcy MTENCiBUZWwyICAgOigrODYpLTAyNS01Mjg3NzIxMQ0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUu Y29tLmNuDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5m b3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRo aXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4g VGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVk IGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJt aXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBv dGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUg Y29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2 aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Ig b2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0 aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nh bm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 000DEB17482576E0_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PGJyPg0KIFppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQogVGVs ICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0KIFRlbDIgJm5ic3A7IDooKzg2KS0wMjUtNTI4Nzcy MTE8YnI+DQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PTwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgY29sb3I9Izgw MDA4MCBmYWNlPSJzYW5zLXNlcmlmIj4tLS0tLSDXqreiyMsgR2FvWWFuZzE0MDE5Ny91c2VyL3p0 ZV9sdGQNCsqxvOQgMjAxMC0wMy0wOCAxMDozMCAtLS0tLTwvZm9udD4NCjxicj4NCjx0YWJsZSB3 aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MjYlPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj48Yj5HYW9ZYW5nMTQwMTk3L3VzZXIvenRlX2x0ZDwvYj4NCjwvZm9u dD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEwLTAzLTA4IDA4OjQ2PC9m b250Pg0KPHRkIHdpZHRoPTczJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K 1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPk9z Y2FyIE5vdm8gJmx0O09zY2FyLk5vdm9AZXJpY3Nzb24uY29tJmd0OzwvZm9udD4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+c2lwY29yZUBpZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBh bGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rp dj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+SGkgT3NjYXIsIEkgY2FuIG5v dCBnZXQgbWFpbHMgZnJvbSBzaXBjb3JlDQptYWlsbGlzdChvdGhlciBsaXN0cyBhcmUgT0spIGZy b20gMiBNYXJjaC4gQ291bGQgeW91IGhlbHAgbWUgdG8gZml4IGl0Pw0KVGhhbmtzLjwvZm9udD48 L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJs ZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCiBaaXAgJm5ic3A7ICZu YnNwOzogMjEwMDEyPGJyPg0KIFRlbCAmbmJzcDsgJm5ic3A7OiA4NzIxMTxicj4NCiBUZWwyICZu YnNwOyA6KCs4NiktMDI1LTUyODc3MjExPGJyPg0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29t LmNuPGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L2ZvbnQ+DQo8YnI+ PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZu YnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlz Jm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNw O3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWls Jm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lw aWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7 dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3Qm bmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVu dHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhl cnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3Ry YW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5i c3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1 c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZu YnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7 SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwm bmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7 b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2 aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDth cmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRl ci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJz cDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5i c3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 000DEB17482576E0_=-- From root@core3.amsl.com Sun Mar 7 19:30:01 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 911D73A6880; Sun, 7 Mar 2010 19:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100308033001.911D73A6880@core3.amsl.com> Date: Sun, 7 Mar 2010 19:30:01 -0800 (PST) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-invfix-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 03:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Correct transaction handling for 2xx responses to Session Initiation Protocol (SIP) INVITE requests Author(s) : R. Sparks, T. Zourzouvillys Filename : draft-ietf-sipcore-invfix-01.txt Pages : 20 Date : 2010-03-07 This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address an error in the specified handling of success (2xx class) responses to INVITE requests. Elements following RFC 3261 exactly will misidentify retransmissions of the request as a new, unassociated, request. The correction involves modifying the INVITE transaction state machines. The correction also changes the way responses that cannot be matched to an existing transaction are handled to address a security risk. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-invfix-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-invfix-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-07191557.I-D@ietf.org> --NextPart-- From pkyzivat@cisco.com Mon Mar 8 06:37:50 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD3E33A69B7 for ; Mon, 8 Mar 2010 06:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.241 X-Spam-Level: X-Spam-Status: No, score=-10.241 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 1Lp9RA66WF1o for ; Mon, 8 Mar 2010 06:37:49 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id A1BD43A6997 for ; Mon, 8 Mar 2010 06:37:49 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABOblEtAZnwM/2dsb2JhbACbKHOhZ5d5hHgEgxc X-IronPort-AV: E=Sophos;i="4.49,602,1262563200"; d="scan'208";a="91264616" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 08 Mar 2010 14:37:53 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o28EbrBB005587; Mon, 8 Mar 2010 14:37:53 GMT Message-ID: <4B950BC0.5090601@cisco.com> Date: Mon, 08 Mar 2010 09:37:52 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Gilad Shaham References: <4B918DED.6090108@cisco.com> , <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <001a01cabe3e$e7033f80$b509be80$@com> In-Reply-To: <001a01cabe3e$e7033f80$b509be80$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'SIPCORE' Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 14:37:50 -0000 Gilad Shaham wrote: > Paul Kyzivat wrote: >> Perhaps the best we can do is discourage the use of early media for >> anything important. >> > > I'm not sure this scenario is that common, but if it is something of > interest, perhaps it's possible to add a header/parameter conveying the > nature of the media stream (ringback, service message, voice, etc.). This is > similar to the content-disposition handling parameter, but more informative > than "optional" and "required". This way, a B2BUA would be able to choose > the stream to forward and even without a B2BUA, an endpoint receiving > several streams would know which stream to play back to the user. I guess this would be something like the Reason header, or maybe it would really be the Reason header, though it would take some changes to allow it for that. Another possibility for this is Alert-Info. The response code, possibly augmented with the Reason header, would work for things like out of service that are going to cause the call to fail. However the callee has to have confidence that the caller will be properly informed of the case. The Alert-Info containing a URN can potentially work for common things that aren't going to cause the call to fail. But that isn't sufficient if there is variable information to convey to the caller, unless it is done with with a URI that can be dereferenced and rendered. The latter would be an alternative if we could convince UAs to render such things. My impression is that there is reluctance to do so, though it really isn't much different from rendering an early media string. But none of this will help with many pstn interop cases where the reason isn't known except through the content of the media. Thanks, Paul From dean.willis@softarmor.com Mon Mar 8 07:44:53 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACB103A69C2 for ; Mon, 8 Mar 2010 07:44:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 Xa9xuZt5Bxty for ; Mon, 8 Mar 2010 07:44:52 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 9BD063A6904 for ; Mon, 8 Mar 2010 07:44:52 -0800 (PST) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o28Firk8019158 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 8 Mar 2010 09:44:55 -0600 Message-Id: <0BD9B443-C89F-4D16-819D-C35D74BAFD1B@softarmor.com> From: Dean Willis To: Paul Kyzivat In-Reply-To: <4B950BC0.5090601@cisco.com> Content-Type: multipart/alternative; boundary=Apple-Mail-14--154407389 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 8 Mar 2010 09:44:44 -0600 References: <4B918DED.6090108@cisco.com> , <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <001a01cabe3e$e7033f80$b509be80$@com> <4B950BC0.5090601@cisco.com> X-Mailer: Apple Mail (2.936) Cc: 'SIPCORE' , Gilad Shaham Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 15:44:53 -0000 --Apple-Mail-14--154407389 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Mar 8, 2010, at 8:37 AM, Paul Kyzivat wrote: > > > Gilad Shaham wrote: >> Paul Kyzivat wrote: >>> Perhaps the best we can do is discourage the use of early media for >>> anything important. >>> >> I'm not sure this scenario is that common, but if it is something of >> interest, perhaps it's possible to add a header/parameter conveying >> the >> nature of the media stream (ringback, service message, voice, >> etc.). This is >> similar to the content-disposition handling parameter, but more >> informative >> than "optional" and "required". This way, a B2BUA would be able to >> choose >> the stream to forward and even without a B2BUA, an endpoint receiving >> several streams would know which stream to play back to the user. > > I guess this would be something like the Reason header, or maybe it > would really be the Reason header, though it would take some changes > to allow it for that. Another possibility for this is Alert-Info. Nut at the moment, we have UAs sending back media that have sent no SIP messages yet. So there's no place to add a Reason header. The only thing that's under the UAC's control is the offer, and AFAIK the only thing the UAC can do to differentiate early media streams is somehow assure that a different offer (with a different listening port) is used for each offer. The UAC cannot do this if the offer is forked by a proxy. > ... > But none of this will help with many pstn interop cases where the > reason isn't known except through the content of the media. And even worse: assuming that the UAC has the ability to play-out all the potentially interesting media streams, there's no way for the UAC or the user thereof to CANCEL any leg and thereby "stop" early media with today's model. That's because one offer is used for all the early- media. So for a UA that's really smart and can do some level of analysis within the media path (like say "Press 1 if you want to accept this call" and then wait for a tone, or perhaps do speech-recognition), there's still no ability for it to clean up the early media by signaling until the early media becomes a regular media session. People claim to be worried about the media bandwidth impact of doing a 302 back to the UA and having it do the forking, but the simple fact is that at least in this scenario the UA can control the result, whereas with proxy parallel forking, the UA potentially gets hammered with multiple parallel early media streams and has no way to do anything about it. -- Dean --Apple-Mail-14--154407389 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Mar 8, 2010, = at 8:37 AM, Paul Kyzivat wrote:



Gilad Shaham wrote:
Paul Kyzivat wrote:
Perhaps the best we can do is = discourage the use of early media = for
anything = important.

I'm = not sure this scenario is that common, but if it is something = of
interest, perhaps it's = possible to add a header/parameter conveying = the
nature of the media stream = (ringback, service message, voice, etc.). This = is
similar to the = content-disposition handling parameter, but more = informative
than "optional" = and "required". This way, a B2BUA would be able to = choose
the stream to forward = and even without a B2BUA, an endpoint = receiving
several streams = would know which stream to play back to the user.

I = guess this would be something like the Reason header, or maybe it would = really be the Reason header, though it would take some changes to allow = it for that. Another possibility for this is = Alert-Info.

Nut at the moment, = we have UAs sending back media that have sent no SIP messages yet. So = there's no place to add a  Reason = header.

The only thing that's under the UAC's = control is the offer, and AFAIK the only thing the UAC can do to = differentiate early media streams is somehow assure that a different = offer (with a different listening port) is used for each offer. The UAC = cannot do this if the offer is forked by a = proxy.

...

But none of this will help with many pstn interop = cases where the reason isn't known except through the content of the = media.

And even worse: = assuming that the UAC has the ability to play-out all the potentially = interesting media streams, there's no way for the UAC or the user = thereof to CANCEL any leg and thereby "stop" early media with today's = model. That's because one offer is used for all the = early-media.

So for a UA that's really smart = and can do some level of analysis within the media path (like say "Press = 1 if you want to accept this call" and then wait for a tone, or perhaps = do speech-recognition), there's still no ability for it to clean up the = early media by signaling until the early media becomes a regular media = session.

People claim to be worried about the = media bandwidth impact of doing a 302 back to the UA and having it do = the forking, but the simple fact is that at least in this scenario the = UA can control the result, whereas with proxy parallel forking, the UA = potentially gets hammered with multiple parallel early media streams and = has no way to do anything about = it.

--
Dean



= --Apple-Mail-14--154407389-- From pkyzivat@cisco.com Mon Mar 8 09:20:46 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C32D3A6A5E for ; Mon, 8 Mar 2010 09:20:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.262 X-Spam-Level: X-Spam-Status: No, score=-10.262 tagged_above=-999 required=5 tests=[AWL=0.337, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 GxVRw+vmb7UZ for ; Mon, 8 Mar 2010 09:20:37 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id BC6733A6ABF for ; Mon, 8 Mar 2010 09:20:23 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAbBlEtAZnwN/2dsb2JhbACbKHOiEZgYhHgEgxc X-IronPort-AV: E=Sophos;i="4.49,603,1262563200"; d="scan'208";a="493427251" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by sj-iport-6.cisco.com with ESMTP; 08 Mar 2010 17:20:26 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o28HKQ1L014629; Mon, 8 Mar 2010 17:20:26 GMT Message-ID: <4B9531DA.7050002@cisco.com> Date: Mon, 08 Mar 2010 12:20:26 -0500 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dean Willis References: <4B918DED.6090108@cisco.com> , <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <001a01cabe3e$e7033f80$b509be80$@com> <4B950BC0.5090601@cisco.com> <0BD9B443-C89F-4D16-819D-C35D74BAFD1B@softarmor.com> In-Reply-To: <0BD9B443-C89F-4D16-819D-C35D74BAFD1B@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'SIPCORE' , Gilad Shaham Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 17:20:46 -0000 Dean Willis wrote: > > On Mar 8, 2010, at 8:37 AM, Paul Kyzivat wrote: > >> >> >> Gilad Shaham wrote: >>> Paul Kyzivat wrote: >>>> Perhaps the best we can do is discourage the use of early media for >>>> anything important. >>>> >>> I'm not sure this scenario is that common, but if it is something of >>> interest, perhaps it's possible to add a header/parameter conveying the >>> nature of the media stream (ringback, service message, voice, etc.). >>> This is >>> similar to the content-disposition handling parameter, but more >>> informative >>> than "optional" and "required". This way, a B2BUA would be able to choose >>> the stream to forward and even without a B2BUA, an endpoint receiving >>> several streams would know which stream to play back to the user. >> >> I guess this would be something like the Reason header, or maybe it >> would really be the Reason header, though it would take some changes >> to allow it for that. Another possibility for this is Alert-Info. > > Nut at the moment, we have UAs sending back media that have sent no SIP > messages yet. So there's no place to add a Reason header. I wasn't thinking of discriminating the early media streams, but rather finding ways to eliminate them while retaining their intent. > The only thing that's under the UAC's control is the offer, and AFAIK > the only thing the UAC can do to differentiate early media streams is > somehow assure that a different offer (with a different listening port) > is used for each offer. The UAC cannot do this if the offer is forked by > a proxy. > >> ... > >> But none of this will help with many pstn interop cases where the >> reason isn't known except through the content of the media. > > And even worse: assuming that the UAC has the ability to play-out all > the potentially interesting media streams, there's no way for the UAC or > the user thereof to CANCEL any leg and thereby "stop" early media with > today's model. That's because one offer is used for all the early-media. Several years ago Rohan proposed a model where the UAC did another O/A with each early dialog to move its media to a distinct port. That way it could then associate the signaling with a particular media stream. Seems cumbersome, but maybe it will take something like that to solve the problem. > So for a UA that's really smart and can do some level of analysis within > the media path (like say "Press 1 if you want to accept this call" and > then wait for a tone, or perhaps do speech-recognition), there's still > no ability for it to clean up the early media by signaling until the > early media becomes a regular media session. > > People claim to be worried about the media bandwidth impact of doing a > 302 back to the UA and having it do the forking, but the simple fact is > that at least in this scenario the UA can control the result, whereas > with proxy parallel forking, the UA potentially gets hammered with > multiple parallel early media streams and has no way to do anything > about it. Yes. The cost and difficulty of the UAC handling the forking seems no worse that the extra O/As I mention above. But even if you have each early dialog associated with a known distinct media session, the problem of deciding which of them to render remains and has no obvious solution. Possibly it only works well with a UA that has a sophisticated UI that can show you the multiple sessions and let you flip between them. Thanks, Paul From gilad@voxisoft.com Mon Mar 8 09:47:36 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 845673A6B1C for ; Mon, 8 Mar 2010 09:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 cHUMRQIQJazo for ; Mon, 8 Mar 2010 09:47:35 -0800 (PST) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 90A943A68B2 for ; Mon, 8 Mar 2010 09:47:27 -0800 (PST) Received: by fxm5 with SMTP id 5so279072fxm.29 for ; Mon, 08 Mar 2010 09:47:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.87.70.31 with SMTP id x31mr3131011fgk.19.1268070448098; Mon, 08 Mar 2010 09:47:28 -0800 (PST) X-Originating-IP: [109.64.6.171] In-Reply-To: <4B9531DA.7050002@cisco.com> References: <4B918DED.6090108@cisco.com> <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <001a01cabe3e$e7033f80$b509be80$@com> <4B950BC0.5090601@cisco.com> <0BD9B443-C89F-4D16-819D-C35D74BAFD1B@softarmor.com> <4B9531DA.7050002@cisco.com> From: Gilad Shaham Date: Mon, 8 Mar 2010 19:47:08 +0200 Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001485f872ba9bf3d904814da813 Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 17:47:36 -0000 --001485f872ba9bf3d904814da813 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Mar 8, 2010 at 7:20 PM, Paul Kyzivat wrote: > > > Dean Willis wrote: > >> >> On Mar 8, 2010, at 8:37 AM, Paul Kyzivat wrote: >> >> >>> >>> Gilad Shaham wrote: >>> >>>> Paul Kyzivat wrote: >>>> >>>>> Perhaps the best we can do is discourage the use of early media for >>>>> anything important. >>>>> >>>>> I'm not sure this scenario is that common, but if it is something of >>>> interest, perhaps it's possible to add a header/parameter conveying the >>>> nature of the media stream (ringback, service message, voice, etc.). >>>> This is >>>> similar to the content-disposition handling parameter, but more >>>> informative >>>> than "optional" and "required". This way, a B2BUA would be able to >>>> choose >>>> the stream to forward and even without a B2BUA, an endpoint receiving >>>> several streams would know which stream to play back to the user. >>>> >>> >>> I guess this would be something like the Reason header, or maybe it would >>> really be the Reason header, though it would take some changes to allow it >>> for that. Another possibility for this is Alert-Info. >>> >> >> Nut at the moment, we have UAs sending back media that have sent no SIP >> messages yet. So there's no place to add a Reason header. >> > > I wasn't thinking of discriminating the early media streams, but rather > finding ways to eliminate them while retaining their intent. > >> The only thing that's under the UAC's control is the offer, and AFAIK the >> only thing the UAC can do to differentiate early media streams is somehow >> assure that a different offer (with a different listening port) is used for >> each offer. The UAC cannot do this if the offer is forked by a proxy. >> >> ... >>> >> >> But none of this will help with many pstn interop cases where the reason >>> isn't known except through the content of the media. >>> >> >> And even worse: assuming that the UAC has the ability to play-out all the >> potentially interesting media streams, there's no way for the UAC or the >> user thereof to CANCEL any leg and thereby "stop" early media with today's >> model. That's because one offer is used for all the early-media. >> > > Several years ago Rohan proposed a model where the UAC did another O/A with > each early dialog to move its media to a distinct port. That way it could > then associate the signaling with a particular media stream. Seems > cumbersome, but maybe it will take something like that to solve the problem. > > Perhaps a less cumbersome way to utilize the offer-answer is to send an offer without actually allocating the port and only choose a port on each dialog that indicates early media. this way the initiating UA has full control and is not overwhelmed with several incoming streams. This of course has a disadvantage if the call is answered very quickly (perhaps automatically) which may require an additional UPDATE to hear something. > > So for a UA that's really smart and can do some level of analysis within >> the media path (like say "Press 1 if you want to accept this call" and then >> wait for a tone, or perhaps do speech-recognition), there's still no ability >> for it to clean up the early media by signaling until the early media >> becomes a regular media session. >> >> People claim to be worried about the media bandwidth impact of doing a 302 >> back to the UA and having it do the forking, but the simple fact is that at >> least in this scenario the UA can control the result, whereas with proxy >> parallel forking, the UA potentially gets hammered with multiple parallel >> early media streams and has no way to do anything about it. >> > > Yes. The cost and difficulty of the UAC handling the forking seems no worse > that the extra O/As I mention above. > > But even if you have each early dialog associated with a known distinct > media session, the problem of deciding which of them to render remains and > has no obvious solution. > > Possibly it only works well with a UA that has a sophisticated UI that can > show you the multiple sessions and let you flip between them. > > If we are relying on speech recognition or even tone detection, it sounds very unlikely to become widely accepted. It's also very confusing for a person to choose between those sessions and it doesn't make much sense for the user to flip between them, unless the device could actually tell the user there is something of great importance on that stream. Once again, it means the other endpoints should indicate something about their early media and as you said, PSTN is not covered by this option. Still, maybe it's possible to leave PSTN as-is and concentrate on end-to-end SIP. Gilad --001485f872ba9bf3d904814da813 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Mar 8, 2010 at 7:20= PM, Paul Kyzivat <pkyzivat@cisco.com> wrote:


Dean Willis wrote:

On Mar 8, 2010, at 8:37 AM, Paul Kyzivat wrote:



Gilad Shaham wrote:
Paul Kyzivat wrote:
Perhaps the best we can do is discourage the use of early media for
anything important.

I'm not sure this scenario is that common, but if it is something of interest, perhaps it's possible to add a header/parameter conveying the=
nature of the media stream (ringback, service message, voice, etc.). This i= s
similar to the content-disposition handling parameter, but more informative=
than "optional" and "required". This way, a B2BUA would= be able to choose
the stream to forward and even without a B2BUA, an endpoint receiving
several streams would know which stream to play back to the user.

I guess this would be something like the Reason header, or maybe it would r= eally be the Reason header, though it would take some changes to allow it f= or that. Another possibility for this is Alert-Info.

Nut at the moment, we have UAs sending back media that have sent no SIP mes= sages yet. So there's no place to add a =A0Reason header.

I wasn't thinking of discriminating the early media streams, but rather= finding ways to eliminate them while retaining their intent.

The only thing that's under the UAC's control is the offer, and AFA= IK the only thing the UAC can do to differentiate early media streams is so= mehow assure that a different offer (with a different listening port) is us= ed for each offer. The UAC cannot do this if the offer is forked by a proxy= .

...

But none of this will help with many pstn interop cases where the reason is= n't known except through the content of the media.

And even worse: assuming that the UAC has the ability to play-out all the p= otentially interesting media streams, there's no way for the UAC or the= user thereof to CANCEL any leg and thereby "stop" early media wi= th today's model. That's because one offer is used for all the earl= y-media.

Several years ago Rohan proposed a model where the UAC did another O/A with= each early dialog to move its media to a distinct port. That way it could = then associate the signaling with a particular media stream. Seems cumberso= me, but maybe it will take something like that to solve the problem.


Perhaps a less cumbersome way to utilize the offer-answer is to send an offer without actually allocating the port and only choose a port on each dialog that indicates early media. this way the initiating UA has full control and is not overwhelmed with several incoming streams. This of course has a disadvantage if the call is answered very quickly (perhaps automatically) which may require an additional UPDATE to hear something.
=A0=A0
<= div class=3D"im">
So for a UA that's really smart and can do some level of analysis withi= n the media path (like say "Press 1 if you want to accept this call&qu= ot; and then wait for a tone, or perhaps do speech-recognition), there'= s still no ability for it to clean up the early media by signaling until th= e early media becomes a regular media session.

People claim to be worried about the media bandwidth impact of doing a 302 = back to the UA and having it do the forking, but the simple fact is that at= least in this scenario the UA can control the result, whereas with proxy p= arallel forking, the UA potentially gets hammered with multiple parallel ea= rly media streams and has no way to do anything about it.

Yes. The cost and difficulty of the UAC handling the forking seems no worse= that the extra O/As I mention above.

But even if you have each early dialog associated with a known distinct med= ia session, the problem of deciding which of them to render remains and has= no obvious solution.

Possibly it only works well with a UA that has a sophisticated UI that can = show you the multiple sessions and let you flip between them.

If we are relying on speech recognition or even tone = detection, it sounds very unlikely to become widely accepted. It's also very confusing for a person to choose between those sessions and it doesn't = make much sense for the user to flip between them, unless the device could actually tell the user there is something of great importance on that stream.

Once again, it means the other endpoints should indicate something about their early media and as you said= , PSTN is not covered by this option. Still, maybe it's possible to leave PSTN as= -is and concentrate on end-to-end SIP.

=A0
Gilad
--001485f872ba9bf3d904814da813-- From dean.willis@softarmor.com Mon Mar 8 13:31:14 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 033CB3A68E7 for ; Mon, 8 Mar 2010 13:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 H0FltWcFay1h for ; Mon, 8 Mar 2010 13:31:13 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 4AB193A69F9 for ; Mon, 8 Mar 2010 13:31:12 -0800 (PST) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o28LVCmK022666 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 8 Mar 2010 15:31:14 -0600 Message-Id: <50DAE276-5E08-4760-9FCC-035BEFF2C470@softarmor.com> From: Dean Willis To: Paul Kyzivat In-Reply-To: <4B9531DA.7050002@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 8 Mar 2010 15:31:06 -0600 References: <4B918DED.6090108@cisco.com> , <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <001a01cabe3e$e7033f80$b509be80$@com> <4B950BC0.5090601@cisco.com> <0BD9B443-C89F-4D16-819D-C35D74BAFD1B@softarmor.com> <4B9531DA.7050002@cisco.com> X-Mailer: Apple Mail (2.936) Cc: 'SIPCORE' , Gilad Shaham Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 21:31:14 -0000 On Mar 8, 2010, at 11:20 AM, Paul Kyzivat wrote: > > I wasn't thinking of discriminating the early media streams, but > rather finding ways to eliminate them while retaining their intent. That would be cool. Requires a business model change at PSTN gateways, which IMHO should go to 200 OK (and a fully-connected dialog) before/ while starting the IAM or equivalent on the PSTN side. But too many yerkaloids want to bill on 200OK. But for non-gateway nodes, we could certainly do something along the lines of a 1xx header or specific cause-codes as different 1XX response types. > > Several years ago Rohan proposed a model where the UAC did another O/ > A with each early dialog to move its media to a distinct port. That > way it could then associate the signaling with a particular media > stream. Seems cumbersome, but maybe it will take something like that > to solve the problem. Only works once the UAS sends back a 1xx of some sort. Some nodes just send media. For gateways, we therefore have to differentiate in the OFFER as seen by the UAS, which means sending a different offer to each UAS, which means NO FORKING! Or maybe we could do yet-another BCP on gateways to require early- dialog before media cut-through. This might be worth exploring. Of course, this requires updating all the gateways before it can be relied on, or at least probing for compliant gateways with a Require. -- Dean From dean.willis@softarmor.com Mon Mar 8 13:37:28 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 976093A69E0 for ; Mon, 8 Mar 2010 13:37:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 Q-msErd32hb1 for ; Mon, 8 Mar 2010 13:37:27 -0800 (PST) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 8047C3A69DE for ; Mon, 8 Mar 2010 13:37:27 -0800 (PST) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o28La2i2022741 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 8 Mar 2010 15:36:04 -0600 Message-Id: From: Dean Willis To: Gilad Shaham In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-16--133334879 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 8 Mar 2010 15:35:57 -0600 References: <4B918DED.6090108@cisco.com> <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <001a01cabe3e$e7033f80$b509be80$@com> <4B950BC0.5090601@cisco.com> <0BD9B443-C89F-4D16-819D-C35D74BAFD1B@softarmor.com> <4B9531DA.7050002@cisco.com> X-Mailer: Apple Mail (2.936) Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 21:37:28 -0000 --Apple-Mail-16--133334879 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Mar 8, 2010, at 11:47 AM, Gilad Shaham wrote: > > Perhaps a less cumbersome way to utilize the offer-answer is to send > an offer without actually allocating the port and only choose a port > on each dialog that indicates early media. this way the initiating > UA has full control and is not overwhelmed with several incoming > streams. This of course has a disadvantage if the call is answered > very quickly (perhaps automatically) which may require an additional > UPDATE to hear something. So you're saying send an offerless INVITE and use early-dialogs to negotiate O/A with the UAS(gateway) acting as the offering node? That might work. > ... > If we are relying on speech recognition or even tone detection, it > sounds very unlikely to become widely accepted. It's also very > confusing for a person to choose between those sessions and it > doesn't make much sense for the user to flip between them, unless > the device could actually tell the user there is something of great > importance on that stream. I'm rather thinking more that a UA can engage in an "Are you there" challenge-response with the far end to see if there's something worth talking to. Or the UA could record the media on each leg and play it back to the user later for diagnostic purposes. > Once again, it means the other endpoints should indicate something > about their early media and as you said, PSTN is not covered by this > option. Still, maybe it's possible to leave PSTN as-is and > concentrate on end-to-end SIP. Maybe. If gateways at least did "early session" with an answer in 1xx, along with some sort of SDP-to-RTP binding token (along the lines of the crypto one's we've discussed) we could make it work. -- dean --Apple-Mail-16--133334879 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Mar 8, 2010, = at 11:47 AM, Gilad Shaham wrote:

 Perhaps a less = cumbersome way to utilize the offer-answer is to send an offer without = actually allocating the port and only choose a port on each dialog that = indicates early media. this way the initiating UA has full control and = is not overwhelmed with several incoming streams. This of course has a = disadvantage if the call is answered very quickly (perhaps = automatically) which may require an additional UPDATE to hear = something.
=

So you're = saying send an offerless INVITE and use early-dialogs to negotiate O/A = with the UAS(gateway)  acting as the offering node? That might = work.

...

If = we are relying on speech recognition or even tone detection, it sounds = very unlikely to become widely accepted. It's also very confusing for a = person to choose between those sessions and it doesn't make much sense = for the user to flip between them, unless the device could actually tell = the user there is something of great importance on that = stream.

I'm rather = thinking more that a UA can engage in an "Are you there" = challenge-response with the far end to see if there's something worth = talking to.

Or the UA could record the media on = each leg and play it back to the user later for diagnostic = purposes.

Once again, it means the = other endpoints should indicate something about their early media and as = you said, PSTN is not covered by this option. Still, maybe it's possible = to leave PSTN as-is and concentrate on end-to-end = SIP.

Maybe. If gateways = at least did "early session" with an answer in 1xx,  along with = some sort of SDP-to-RTP binding token (along the lines of the crypto = one's we've discussed) we could make it = work.

--
dean
= --Apple-Mail-16--133334879-- From adam@nostrum.com Mon Mar 8 13:49:00 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45E863A69CA for ; Mon, 8 Mar 2010 13:49:00 -0800 (PST) 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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 1HBYaBvCe8+n for ; Mon, 8 Mar 2010 13:48:58 -0800 (PST) Received: from nostrum.com (shaman.nostrum.com [72.232.179.90]) by core3.amsl.com (Postfix) with ESMTP id 7C9D43A69E2 for ; Mon, 8 Mar 2010 13:48:54 -0800 (PST) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o28LmhhN090642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Mar 2010 15:48:43 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B9570BB.3030807@nostrum.com> Date: Mon, 08 Mar 2010 15:48:43 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: SIPCORE Content-Type: multipart/alternative; boundary="------------090206000003090805050102" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "Oscar Novo \(JO/LMF\)" Subject: [sipcore] Administrivia: Trying to reach ZTE.com.cn subscribers X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2010 21:49:00 -0000 This is a multi-part message in MIME format. --------------090206000003090805050102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [as chair] For some reason, ZTE.com.cn is blocking mail sent from the SIPCORE mailing list to several email accounts. They have also blocked my attempts to contact the affected participants to try to resolve the issue. If anyone can contact any of the following individuals, please ask them to get in touch with me using an alternate email service (that is, an email service other than ZTE.com.cn): * gao.yang2@zte.com.cn * wang.libo@zte.com.cn * yan.chengan@zte.com.cn * yu.xutao@zte.com.cn * zhou.peng2@zte.com.cn Thanks, and sorry for the noise. /a --------------090206000003090805050102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit [as chair]

For some reason, ZTE.com.cn is blocking mail sent from the SIPCORE mailing list to several email accounts. They have also blocked my attempts to contact the affected participants to try to resolve the issue. If anyone can contact any of the following individuals, please ask them to get in touch with me using an alternate email service (that is, an email service other than ZTE.com.cn):


Thanks, and sorry for the noise.

/a
--------------090206000003090805050102-- From richard@shockey.us Tue Mar 9 18:10:15 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 201333A6AF4 for ; Tue, 9 Mar 2010 18:10:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.323 X-Spam-Level: X-Spam-Status: No, score=-2.323 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 BD7xJvV8nJqz for ; Tue, 9 Mar 2010 18:10:09 -0800 (PST) Received: from outbound-mail-360.bluehost.com (outbound-mail-360.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id B68B93A6359 for ; Tue, 9 Mar 2010 18:10:05 -0800 (PST) Received: (qmail 22409 invoked by uid 0); 10 Mar 2010 01:43:28 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 10 Mar 2010 01:43:28 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=TMIvnGFTYSC4Z1sIj03DmxyWwWErZrKXmtIh2T1wdCnGjRWTF2V8UEqC4vOmyizGhVEPbgDhHcZ2r2BPtZ65E6/R/9OIGJh2JBpFfOsLhKbNG6WtA/CUZmk/XB/HQ2tI; Received: from pool-173-66-69-79.washdc.fios.verizon.net ([173.66.69.79] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1NpAxM-0002WA-Ag; Tue, 09 Mar 2010 18:43:28 -0700 From: "Richard Shockey" To: , , "'MARTINI'" Date: Tue, 9 Mar 2010 20:43:25 -0500 Message-ID: <028201cabff3$13cc1360$3b643a20$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0283_01CABFC9.2AF60B60" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq/uZOrLwXMolSnQeyPKU4g86oIkg== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.79 authed with richard@shockey.us} Subject: [sipcore] SIP Forum Luncheon at IETF 77 Monday 11:30 13:00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2010 02:10:15 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0283_01CABFC9.2AF60B60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The SIP Forum is going to hold a open meeting for the RAI community during IETF 77. The purpose of this meeting is remind the SIP community of what the SIP Forum is doing and discuss relevant technical issues that relate to IETF WG's. The agenda for this luncheon will be to review current activities in the SIP Forum and seek additional technical input from the RAI community on mutual concerns. As many of you know the SIP Forum is the principal sponsor of the SIPit interoperability events and currently has 4 Task groups operating. BTW registration for SIPit 26 will be open soon. Our principal technical initiatives are: 1. SIP Connect 1.1 which is developing an enhanced profile of IETF Standards for PBX to SSP interoperability. As part of that work the IETF MARTINI WG was formed to redefine the so called Implicit registration procedure in SIP. 2. FAX over SIP is investigating the interoperability of SIP in T.38 networks with a goal of possible recommendations to the relevant SDO's on how fax can work better. 3. Client User Agent Configuration which has a pending Recommendation on how CUA devices could auto streamline the locating, retrieving and maintaining of configuration-related information for SIP User Agents 4. SIP in the SmartGrid. This is a Special Interest Group that is evaluating the appropriateness of using SIP as a protocol for a number of Smart Grid areas, including the Home Area Network (HAN), Utilities' Operational Network, and PEV (Plug-In Vehicle) deployments. Information on the SIP Forum is available at http//www.sipforum.org If you are interested in attending this event we have set up a Doodle Poll to indicate your interest. Seating is somewhat limited ( 150 Maximum) lunch will be provided. Location .. Monday 11:30 13:00 the Laguna room and its located on the 4th floor of the Anaheim Hilton The link to the poll is: http://www.doodle.com/hde57nbpcdykzqfz Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 skype: rshockey101 LinkedIn : http://www.linkedin.com/in/rshockey101 ------=_NextPart_000_0283_01CABFC9.2AF60B60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

The SIP Forum is going to hold a open meeting for = the RAI community during IETF 77. The purpose of this meeting is remind the SIP community of what the SIP Forum is doing and discuss relevant technical = issues that relate to IETF WG’s. The agenda for this luncheon will be to = review current activities in the SIP Forum and seek additional technical input = from the RAI community on mutual concerns.

 

As many of you know the SIP Forum is the principal = sponsor of the SIPit interoperability events and currently has 4 Task groups = operating.

 

BTW registration for SIPit 26 will be open = soon.

 

Our principal technical initiatives = are:

 

1.      SIP Connect 1.1 which is developing an enhanced  profile of IETF Standards for PBX to SSP interoperability. As part = of that work the IETF MARTINI WG was formed to redefine the so called = Implicit registration procedure in SIP.

2.      FAX over SIP is investigating the = interoperability of SIP in T.38 networks with a goal of possible recommendations to the = relevant SDO’s on how fax can work better.

3.      Client User Agent Configuration which has a = pending Recommendation on how CUA devices could auto streamline the locating, retrieving and maintaining of configuration-related information for SIP = User Agents

4.      SIP in the SmartGrid. This is a Special Interest = Group that is evaluating the appropriateness of using SIP as a protocol for a = number of Smart Grid areas, including the Home Area Network (HAN), Utilities' Operational Network, and PEV (Plug-In Vehicle) = deployments.

 

Information on the SIP Forum is available at =

 

http//www.sipforum.org

 

If you are interested in attending this event we = have set up a Doodle Poll to indicate your interest. Seating is somewhat limited ( = 150 Maximum) lunch will be provided.

 

Location .. Monday 11:30 13:00 the Laguna room and its = located on the 4th floor of the Anaheim Hilton

The link to the poll = is:

http://www.doodle.com/hde57nbpcdykzqfz

 

Richard = Shockey
Shockey Consulting
Chairman of the Board of Directors SIP Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>= ;
skype: rshockey101
LinkedIn : http://www.linkedin.com/i= n/rshockey101

 

------=_NextPart_000_0283_01CABFC9.2AF60B60-- From rjsparks@nostrum.com Fri Mar 12 07:57:04 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB1CC3A6CDC; Fri, 12 Mar 2010 07:57:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] 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 TrFHdFbCiPb7; Fri, 12 Mar 2010 07:57:04 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 582AF3A6A2B; Fri, 12 Mar 2010 07:42:54 -0800 (PST) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o2CFgwJw013316 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Mar 2010 09:42:58 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Robert Sparks In-Reply-To: Date: Fri, 12 Mar 2010 09:42:58 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <204C0846-1479-4795-88F2-903A4BDD5837@cisco.com> To: siprec@ietf.org, SIPCORE , codec@ietf.org, DISPATCH list , ecrit@ietf.org, XMPP , rai@ietf.org X-Mailer: Apple Mail (2.1077) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] RAI WG chair changes X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: rai@ietf.org List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Mar 2010 15:57:04 -0000 WIth the upcoming IESG and IAB changes, we need to make=20 a bunch of chair changes. After the end of the IETF 77 the chairs=20 for the following WGs will be: SIPREC=20 Brian Rosen John Elwell SIPCORE Adam Roach Paul Kyzivat CODEC Michael Knappe Jonathan Rosenberg Cullen Jennings DISPATCH Mary Barnes Cullen Jennings ECRIT=20 Richard Barnes Marc Linsner XMPP Joe Hildebrand Ben Campbell To help with continuity of the IETF77 meeting, we are going to add the = new chairs now,=20 and not remove any existing chairs until after the meeting.=20 We would like to express many thinks for all the work all these chairs = have done and continue to do.=20 Thanks,=20 Cullen, Gonzalo, & Robert From ranjit@motorola.com Fri Mar 12 21:27:27 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C6BF3A6834; Fri, 12 Mar 2010 21:27:27 -0800 (PST) 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=[AWL=-0.000, 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 0KIAXcvxl03v; Fri, 12 Mar 2010 21:27:26 -0800 (PST) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id 21B5C3A694A; Fri, 12 Mar 2010 21:27:18 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-2.tower-55.messagelabs.com!1268458043!40364755!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 29324 invoked from network); 13 Mar 2010 05:27:23 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-2.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 13 Mar 2010 05:27:23 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id o2D5RN12026589; Fri, 12 Mar 2010 22:27:23 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id o2D5RNrE003499; Fri, 12 Mar 2010 23:27:23 -0600 (CST) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id o2D5RLZX003496; Fri, 12 Mar 2010 23:27:22 -0600 (CST) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAC26D.CE17FB13" Date: Sat, 13 Mar 2010 13:26:58 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A3BE70F@ZMY16EXM66.ds.mot.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: Query on draft-ietf-sipcore-info-events-07 thread-index: AcrCbc1fOC+kPgM7SvG/qQEEcug40Q== From: "Avasarala Ranjit-A20990" To: X-CFilter-Loop: Reflected Cc: sipcore@ietf.org Subject: [sipcore] Query on draft-ietf-sipcore-info-events-07 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2010 05:27:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAC26D.CE17FB13 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all Are there any registered INFO packages and can the regular SIP event packages based on RFC 3265 be used with INFO mechanism? Thanks Regards Ranjit ------_=_NextPart_001_01CAC26D.CE17FB13 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Query on draft-ietf-sipcore-info-events-07

Hi all

Are there any registered INFO packages = and can the regular SIP event packages based on RFC 3265 be used with = INFO mechanism?

Thanks

Regards
Ranjit

------_=_NextPart_001_01CAC26D.CE17FB13-- From adam@nostrum.com Sat Mar 13 14:53:06 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FE8B3A6A94 for ; Sat, 13 Mar 2010 14:53:06 -0800 (PST) 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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 5D5ntkLvOp6Y for ; Sat, 13 Mar 2010 14:53:03 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 91E3A3A6A1A for ; Sat, 13 Mar 2010 14:53:02 -0800 (PST) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o2DMr6Qi052813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 13 Mar 2010 16:53:07 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4B9C1752.1000905@nostrum.com> Date: Sat, 13 Mar 2010 16:53:06 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: Avasarala Ranjit-A20990 References: <750BBC72E178114F9DC4872EBFF29A5B0A3BE70F@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A3BE70F@ZMY16EXM66.ds.mot.com> Content-Type: multipart/alternative; boundary="------------040702090002090702030606" Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org Subject: Re: [sipcore] Query on draft-ietf-sipcore-info-events-07 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2010 22:53:06 -0000 This is a multi-part message in MIME format. --------------040702090002090702030606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Please don't cross-post to dispatch and sipcore. On 3/12/10 23:26, Mar 12, Avasarala Ranjit-A20990 wrote: > > Are there any registered INFO packages > Not yet. > and can the regular SIP event packages based on RFC 3265 be used with > INFO mechanism? > Absolutely not. No. Never. Under no circumstances. Nein, ???, ????, Non, Nej. They are _completely_ different things. Really, if this is somehow unclear in the INFO draft, we need to pull it from publication request and work on it some more. It would be the worst possible outcome if implementors were led to believe that 3265 packages could be used with INFO. Where did you get the impression that this might be okay? /a --------------040702090002090702030606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Please don't cross-post to dispatch and sipcore.

On 3/12/10 23:26, Mar 12, Avasarala Ranjit-A20990 wrote:
Query on draft-ietf-sipcore-info-events-07

Are there any registered INFO packages


Not yet.

and can the regular SIP event packages based on RFC 3265 be used with INFO mechanism?


Absolutely not. No. Never. Under no circumstances. Nein, Нет, नहीं, Non, Nej. They are _completely_ different things.

Really, if this is somehow unclear in the INFO draft, we need to pull it from publication request and work on it some more. It would be the worst possible outcome if implementors were led to believe that 3265 packages could be used with INFO. Where did you get the impression that this might be okay?

/a
--------------040702090002090702030606-- From ranjit@motorola.com Sun Mar 14 00:04:12 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 896893A683E for ; Sun, 14 Mar 2010 00:04:12 -0800 (PST) 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=[AWL=-0.000, 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 hIHeYskYpTol for ; Sun, 14 Mar 2010 00:04:11 -0800 (PST) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id 4FD703A683A for ; Sun, 14 Mar 2010 00:04:11 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-11.tower-55.messagelabs.com!1268553856!37592769!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 11599 invoked from network); 14 Mar 2010 08:04:16 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-11.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Mar 2010 08:04:16 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id o2E84GcH026190 for ; Sun, 14 Mar 2010 01:04:16 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id o2E84Geu013665 for ; Sun, 14 Mar 2010 03:04:16 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id o2E84EGs013654 for ; Sun, 14 Mar 2010 03:04:15 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CAC34C.E2C6C213" Date: Sun, 14 Mar 2010 16:03:50 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A3BE74E@ZMY16EXM66.ds.mot.com> In-Reply-To: <4B9C1752.1000905@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [sipcore] Query on draft-ietf-sipcore-info-events-07 thread-index: AcrC//mUv8+z/3J8TiOGYO8J3gDrcwAS5pMg References: <750BBC72E178114F9DC4872EBFF29A5B0A3BE70F@ZMY16EXM66.ds.mot.com> <4B9C1752.1000905@nostrum.com> From: "Avasarala Ranjit-A20990" To: "Adam Roach" X-CFilter-Loop: Reflected Cc: sipcore@ietf.org Subject: Re: [sipcore] Query on draft-ietf-sipcore-info-events-07 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Mar 2010 08:04:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CAC34C.E2C6C213 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWRhbQ0KIA0KRnJvbSB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIGluZm8gZHJhZnQtaWV0 Zi1zaXBjb3JlLWluZm8tZXZlbnRzLTA3LCB0aGUgc2VjdGlvbiA0ICJJbmZvIFBhY2thZ2VzIiBk b2VzIG5vdCB0YWxrIGFib3V0IHRoZSBraW5kIG9mIHBhY2thZ2VzIGFuZCB0aGVpciBmb3JtYXQu IA0KIA0KVGhvdWdoIHRoZSBzZWN0aW9uIDcuNC4xLjIgIHRhbGtzIHRoYXQgdXNlIG9mIFNVQlND UklCRSAvIE5PVElGWSBiYXNlZCBvbiAzMjY1IGFzIGFuIGFsdGVybmF0ZSBtZWNoYW5pc20sIGl0 IGlzIG5vdCBjbGVhciB3aGF0IHNob3VsZCBiZSB0aGUgZm9ybWF0IG9mIGEgdHlwaWNhbCBJTkZP IHBhY2thZ2UuIA0KIA0KQWxzbyBmdXJ0aGVyIFNlY3Rpb24gNy40LjEuMyBtZW50aW9ucyB0aGUg dXNhZ2Ugb2YgU0lQIE1FU1NBR0UgbWV0aG9kLiBTbyBkb2VzIHRoaXMgbWVhbiBJIGNhbiB1c2Ug TUVTU0FHRSBtZXRob2QgYXMgYW4gYWx0ZXJuYXRpdmUgdG8gSU5GTz8gDQogDQpUaGFua3MNClJl Z2FyZHMgDQpSYW5qaXQgDQogDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoN CkZyb206IEFkYW0gUm9hY2ggW21haWx0bzphZGFtQG5vc3RydW0uY29tXSANClNlbnQ6IFN1bmRh eSwgTWFyY2ggMTQsIDIwMTAgNDoyMyBBTQ0KVG86IEF2YXNhcmFsYSBSYW5qaXQtQTIwOTkwDQpD Yzogc2lwY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBRdWVyeSBvbiBkcmFm dC1pZXRmLXNpcGNvcmUtaW5mby1ldmVudHMtMDcNCg0KDQpQbGVhc2UgZG9uJ3QgY3Jvc3MtcG9z dCB0byBkaXNwYXRjaCBhbmQgc2lwY29yZS4NCg0KT24gMy8xMi8xMCAyMzoyNiwgTWFyIDEyLCBB dmFzYXJhbGEgUmFuaml0LUEyMDk5MCB3cm90ZTogDQoNCglBcmUgdGhlcmUgYW55IHJlZ2lzdGVy ZWQgSU5GTyBwYWNrYWdlcw0KDQoNCk5vdCB5ZXQuDQoNCg0KDQoJYW5kIGNhbiB0aGUgcmVndWxh ciBTSVAgZXZlbnQgcGFja2FnZXMgYmFzZWQgb24gUkZDIDMyNjUgYmUgdXNlZCB3aXRoIElORk8g bWVjaGFuaXNtPw0KDQoNCkFic29sdXRlbHkgbm90LiBOby4gTmV2ZXIuIFVuZGVyIG5vIGNpcmN1 bXN0YW5jZXMuIE5laW4sINCd0LXRgiwg4KSo4KS54KWA4KSCLCBOb24sIE5lai4gVGhleSBhcmUg X2NvbXBsZXRlbHlfIGRpZmZlcmVudCB0aGluZ3MuDQoNClJlYWxseSwgaWYgdGhpcyBpcyBzb21l aG93IHVuY2xlYXIgaW4gdGhlIElORk8gZHJhZnQsIHdlIG5lZWQgdG8gcHVsbCBpdCBmcm9tIHB1 YmxpY2F0aW9uIHJlcXVlc3QgYW5kIHdvcmsgb24gaXQgc29tZSBtb3JlLiBJdCB3b3VsZCBiZSB0 aGUgd29yc3QgcG9zc2libGUgb3V0Y29tZSBpZiBpbXBsZW1lbnRvcnMgd2VyZSBsZWQgdG8gYmVs aWV2ZSB0aGF0IDMyNjUgcGFja2FnZXMgY291bGQgYmUgdXNlZCB3aXRoIElORk8uIFdoZXJlIGRp ZCB5b3UgZ2V0IHRoZSBpbXByZXNzaW9uIHRoYXQgdGhpcyBtaWdodCBiZSBva2F5Pw0KDQovYQ0K DQo= ------_=_NextPart_001_01CAC34C.E2C6C213 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPjxUSVRMRT5RdWVyeSBvbiBkcmFmdC1pZXRmLXNpcGNvcmUt aW5mby1ldmVudHMtMDc8L1RJVExFPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuNTUxMiIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFkgdGV4dD0jMDAwMDAw IGJnQ29sb3I9I2ZmZmZmZj4NCjxESVYgZGlyPWx0ciBhbGlnbj1sZWZ0PjxTUEFOIGNsYXNzPTQ3 OTMwNTQwNy0xNDAzMjAxMD48Rk9OVCBmYWNlPUFyaWFsIA0KY29sb3I9IzAwMDBmZiBzaXplPTI+ SGkgQWRhbTwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BB TiBjbGFzcz00NzkzMDU0MDctMTQwMzIwMTA+PEZPTlQgZmFjZT1BcmlhbCANCmNvbG9yPSMwMDAw ZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249 bGVmdD48U1BBTiBjbGFzcz00NzkzMDU0MDctMTQwMzIwMTA+PEZPTlQgc2l6ZT0yPjxGT05UIA0K ZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmPkZyb20gdGhlIGxhdGVzdCB2ZXJzaW9uIG9mIHRoZSBp bmZvIA0KZHJhZnQtaWV0Zi1zaXBjb3JlLWluZm8tZXZlbnRzLTA3LCB0aGUgc2VjdGlvbiA0ICJJ bmZvIFBhY2thZ2VzIiBkb2VzIG5vdCB0YWxrIA0KYWJvdXQgdGhlIGtpbmQgb2YgcGFja2FnZXMg YW5kIHRoZWlyIGZvcm1hdC4gPC9GT05UPjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1s dHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz00NzkzMDU0MDctMTQwMzIwMTA+PEZPTlQgc2l6ZT0y PjxGT05UIA0KZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPiZu YnNwOzwvRElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NDc5MzA1NDA3 LTE0MDMyMDEwPjxGT05UIHNpemU9Mj48Rk9OVCANCmZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZj5U aG91Z2ggdGhlIHNlY3Rpb24gNy40LjEuMiZuYnNwOyB0YWxrcyB0aGF0IHVzZSBvZiANClNVQlND UklCRSAvIE5PVElGWSBiYXNlZCBvbiAzMjY1IGFzIGFuIGFsdGVybmF0ZSBtZWNoYW5pc20sIGl0 IGlzIG5vdCBjbGVhciB3aGF0IA0Kc2hvdWxkIGJlIHRoZSBmb3JtYXQgb2YgYSB0eXBpY2FsIElO Rk8gcGFja2FnZS4gPC9GT05UPjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxp Z249bGVmdD48U1BBTiBjbGFzcz00NzkzMDU0MDctMTQwMzIwMTA+PEZPTlQgc2l6ZT0yPjxGT05U IA0KZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmPjwvRk9OVD48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwv RElWPg0KPERJViBkaXI9bHRyIGFsaWduPWxlZnQ+PFNQQU4gY2xhc3M9NDc5MzA1NDA3LTE0MDMy MDEwPjxGT05UIHNpemU9Mj48Rk9OVCANCmZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZj5BbHNvIGZ1 cnRoZXIgU2VjdGlvbiA3LjQuMS4zIG1lbnRpb25zIHRoZSB1c2FnZSBvZiBTSVAgDQpNRVNTQUdF IG1ldGhvZC4gU28gZG9lcyB0aGlzIG1lYW4gSSBjYW4gdXNlIE1FU1NBR0UgbWV0aG9kIGFzIGFu IGFsdGVybmF0aXZlIHRvIA0KSU5GTz8gPC9GT05UPjwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElW IGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz00NzkzMDU0MDctMTQwMzIwMTA+PEZPTlQg ZmFjZT1BcmlhbCANCmNvbG9yPSMwMDAwZmYgc2l6ZT0yPjwvRk9OVD48L1NQQU4+Jm5ic3A7PC9E SVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBjbGFzcz00NzkzMDU0MDctMTQwMzIw MTA+PEZPTlQgZmFjZT1BcmlhbCANCmNvbG9yPSMwMDAwZmYgc2l6ZT0yPlRoYW5rczwvRk9OVD48 L1NQQU4+PC9ESVY+DQo8RElWIGRpcj1sdHIgYWxpZ249bGVmdD48U1BBTiBsYW5nPWVuLXVzPjxG T05UIGZhY2U9QXJpYWwgDQpzaXplPTI+UmVnYXJkczwvRk9OVD48L1NQQU4+IDxCUj48U1BBTiBs YW5nPWVuLXVzPjxGT05UIGZhY2U9QXJpYWwgDQpzaXplPTI+UmFuaml0PC9GT05UPjwvU1BBTj4g PC9ESVY+DQo8RElWPiZuYnNwOzwvRElWPjxCUj4NCjxESVYgY2xhc3M9T3V0bG9va01lc3NhZ2VI ZWFkZXIgbGFuZz1lbi11cyBkaXI9bHRyIGFsaWduPWxlZnQ+DQo8SFIgdGFiSW5kZXg9LTE+DQo8 Rk9OVCBmYWNlPVRhaG9tYSBzaXplPTI+PEI+RnJvbTo8L0I+IEFkYW0gUm9hY2ggW21haWx0bzph ZGFtQG5vc3RydW0uY29tXSANCjxCUj48Qj5TZW50OjwvQj4gU3VuZGF5LCBNYXJjaCAxNCwgMjAx MCA0OjIzIEFNPEJSPjxCPlRvOjwvQj4gQXZhc2FyYWxhIA0KUmFuaml0LUEyMDk5MDxCUj48Qj5D Yzo8L0I+IHNpcGNvcmVAaWV0Zi5vcmc8QlI+PEI+U3ViamVjdDo8L0I+IFJlOiBbc2lwY29yZV0g DQpRdWVyeSBvbiBkcmFmdC1pZXRmLXNpcGNvcmUtaW5mby1ldmVudHMtMDc8QlI+PC9GT05UPjxC Uj48L0RJVj4NCjxESVY+PC9ESVY+PFNQQU4gY2xhc3M9c2hvcnRfdGV4dCBpZD1yZXN1bHRfYm94 PjxTUEFOIHRpdGxlPU5vIA0Kc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IHJnYigyNTUsMjU1LDI1 NSkiPlBsZWFzZSBkb24ndCBjcm9zcy1wb3N0IHRvIGRpc3BhdGNoIA0KYW5kIHNpcGNvcmUuPC9T UEFOPjwvU1BBTj48QlI+PEJSPk9uIDMvMTIvMTAgMjM6MjYsIE1hciAxMiwgQXZhc2FyYWxhIA0K UmFuaml0LUEyMDk5MCB3cm90ZTogDQo8QkxPQ0tRVU9URSANCmNpdGU9bWlkOjc1MEJCQzcyRTE3 ODExNEY5REM0ODcyRUJGRjI5QTVCMEEzQkU3MEZAWk1ZMTZFWE02Ni5kcy5tb3QuY29tIA0KdHlw ZT0iY2l0ZSI+DQogIDxNRVRBIGNvbnRlbnQ9Ik1TIEV4Y2hhbmdlIFNlcnZlciB2ZXJzaW9uIDYu NS43NjU0LjEyIiBuYW1lPUdlbmVyYXRvcj48IS0tIENvbnZlcnRlZCBmcm9tIHRleHQvcnRmIGZv cm1hdCAtLT4NCiAgPFA+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+QXJlIHRoZXJlIGFueSByZWdp c3RlcmVkIElORk8gDQpwYWNrYWdlczwvRk9OVD48L1A+PC9CTE9DS1FVT1RFPjxCUj5Ob3QgeWV0 LjxCUj48QlI+DQo8QkxPQ0tRVU9URSANCmNpdGU9bWlkOjc1MEJCQzcyRTE3ODExNEY5REM0ODcy RUJGRjI5QTVCMEEzQkU3MEZAWk1ZMTZFWE02Ni5kcy5tb3QuY29tIA0KdHlwZT0iY2l0ZSI+DQog IDxQPjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPmFuZCBjYW4gdGhlIHJlZ3VsYXIgU0lQIGV2ZW50 IHBhY2thZ2VzIGJhc2VkIG9uIFJGQyANCiAgMzI2NSBiZSB1c2VkIHdpdGggSU5GTyBtZWNoYW5p c20/PC9GT05UPjwvUD48L0JMT0NLUVVPVEU+PEJSPkFic29sdXRlbHkgbm90LiBOby4gDQpOZXZl ci4gVW5kZXIgbm8gY2lyY3Vtc3RhbmNlcy4gTmVpbiwgPFNQQU4gY2xhc3M9c2hvcnRfdGV4dCBp ZD1yZXN1bHRfYm94PjxTUEFOIA0KdGl0bGU9Tm8gc3R5bGU9IkJBQ0tHUk9VTkQtQ09MT1I6IHJn YigyNTUsMjU1LDI1NSkiPtCd0LXRgjwvU1BBTj48L1NQQU4+LCA8U1BBTiANCmNsYXNzPXNob3J0 X3RleHQgaWQ9cmVzdWx0X2JveD48U1BBTiB0aXRsZT1ObyANCnN0eWxlPSJCQUNLR1JPVU5ELUNP TE9SOiByZ2IoMjU1LDI1NSwyNTUpIj7gpKjgpLngpYDgpII8L1NQQU4+PC9TUEFOPiwgTm9uLCA8 U1BBTiANCmNsYXNzPXNob3J0X3RleHQgaWQ9cmVzdWx0X2JveD48U1BBTiB0aXRsZT1ObyANCnN0 eWxlPSJCQUNLR1JPVU5ELUNPTE9SOiByZ2IoMjU1LDI1NSwyNTUpIj5OZWouIFRoZXkgYXJlIF9j b21wbGV0ZWx5XyBkaWZmZXJlbnQgDQp0aGluZ3MuPEJSPjxCUj5SZWFsbHksIGlmIHRoaXMgaXMg c29tZWhvdyB1bmNsZWFyIGluIHRoZSBJTkZPIGRyYWZ0LCB3ZSBuZWVkIHRvIA0KcHVsbCBpdCBm cm9tIHB1YmxpY2F0aW9uIHJlcXVlc3QgYW5kIHdvcmsgb24gaXQgc29tZSBtb3JlLiBJdCB3b3Vs ZCBiZSB0aGUgd29yc3QgDQpwb3NzaWJsZSBvdXRjb21lIGlmIGltcGxlbWVudG9ycyB3ZXJlIGxl ZCB0byBiZWxpZXZlIHRoYXQgMzI2NSBwYWNrYWdlcyBjb3VsZCBiZSANCnVzZWQgd2l0aCBJTkZP LiBXaGVyZSBkaWQgeW91IGdldCB0aGUgaW1wcmVzc2lvbiB0aGF0IHRoaXMgbWlnaHQgYmUgDQpv a2F5PzxCUj48L1NQQU4+PC9TUEFOPjxCUj4vYTxCUj48L0JPRFk+PC9IVE1MPg0K ------_=_NextPart_001_01CAC34C.E2C6C213-- From eburger@standardstrack.com Sun Mar 14 10:28:10 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 998433A6982 for ; Sun, 14 Mar 2010 10:28:10 -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=[AWL=0.001, 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 jmdATl-LI3f4 for ; Sun, 14 Mar 2010 10:28:09 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 423BD3A68A6 for ; Sun, 14 Mar 2010 10:26:45 -0700 (PDT) Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.105]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1NqraS-0000R6-Ea; Sun, 14 Mar 2010 10:26:48 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=utf-8 From: Eric Burger In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A3BE74E@ZMY16EXM66.ds.mot.com> Date: Sun, 14 Mar 2010 13:26:48 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <750BBC72E178114F9DC4872EBFF29A5B0A3BE70F@ZMY16EXM66.ds.mot.com> <4B9C1752.1000905@nostrum.com> <750BBC72E178114F9DC4872EBFF29A5B0A3BE74E@ZMY16EXM66.ds.mot.com> To: Avasarala Ranjit-A20990 X-Mailer: Apple Mail (2.1077) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: SIPCORE SIPCORE Subject: Re: [sipcore] Query on draft-ietf-sipcore-info-events-07 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Mar 2010 17:28:10 -0000 The point of Section 7.4 is there is often a far superior method of = doing user-user signaling besides INFO. For example, if you want to send = DTMF digits, use KPML (he says modestly). There is absolutely NO correspondence between an Info Package and an = Event Package. Moreover, if someone tried to register such, my guess is = they would not get the requisite Specification Required level needed to = register a package. On Mar 14, 2010, at 4:03 AM, Avasarala Ranjit-A20990 wrote: > Hi Adam > =20 > =46rom the latest version of the info = draft-ietf-sipcore-info-events-07, the section 4 "Info Packages" does = not talk about the kind of packages and their format. > =20 > Though the section 7.4.1.2 talks that use of SUBSCRIBE / NOTIFY based = on 3265 as an alternate mechanism, it is not clear what should be the = format of a typical INFO package. > =20 > Also further Section 7.4.1.3 mentions the usage of SIP MESSAGE method. = So does this mean I can use MESSAGE method as an alternative to INFO? > =20 > Thanks > Regards=20 > Ranjit > =20 >=20 > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: Sunday, March 14, 2010 4:23 AM > To: Avasarala Ranjit-A20990 > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Query on draft-ietf-sipcore-info-events-07 >=20 > Please don't cross-post to dispatch and sipcore. >=20 > On 3/12/10 23:26, Mar 12, Avasarala Ranjit-A20990 wrote: >> Are there any registered INFO packages >>=20 >=20 > Not yet. >=20 >> and can the regular SIP event packages based on RFC 3265 be used with = INFO mechanism? >>=20 >=20 > Absolutely not. No. Never. Under no circumstances. Nein, =D0=9D=D0=B5=D1= =82, =E0=A4=A8=E0=A4=B9=E0=A5=80=E0=A4=82, Non, Nej. They are = _completely_ different things. >=20 > Really, if this is somehow unclear in the INFO draft, we need to pull = it from publication request and work on it some more. It would be the = worst possible outcome if implementors were led to believe that 3265 = packages could be used with INFO. Where did you get the impression that = this might be okay? >=20 > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From ranjit@motorola.com Sun Mar 14 10:36:06 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B44363A6822 for ; Sun, 14 Mar 2010 10:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.357 X-Spam-Level: X-Spam-Status: No, score=-6.357 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, 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 iTUAoj9kMQ+P for ; Sun, 14 Mar 2010 10:36:05 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id 5F3433A69DE for ; Sun, 14 Mar 2010 10:35:18 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-4.tower-55.messagelabs.com!1268588123!92122476!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [136.182.1.15] Received: (qmail 28235 invoked from network); 14 Mar 2010 17:35:24 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (136.182.1.15) by server-4.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 14 Mar 2010 17:35:24 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate5.mot.com (8.14.3/8.14.3) with ESMTP id o2EHZNU9006858 for ; Sun, 14 Mar 2010 10:35:23 -0700 (MST) Received: from az10vts04.mot.com (il27vts04.cig.mot.com [10.17.196.88]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id o2EHZMQc008890 for ; Sun, 14 Mar 2010 12:35:22 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id o2EHZ09S008831 for ; Sun, 14 Mar 2010 12:35:01 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 15 Mar 2010 01:34:36 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A3BE75A@ZMY16EXM66.ds.mot.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [sipcore] Query on draft-ietf-sipcore-info-events-07 thread-index: AcrDm5DmUuCbZBi8RsGq31BpWpFpKQAAFdog References: <750BBC72E178114F9DC4872EBFF29A5B0A3BE70F@ZMY16EXM66.ds.mot.com> <4B9C1752.1000905@nostrum.com> <750BBC72E178114F9DC4872EBFF29A5B0A3BE74E@ZMY16EXM66.ds.mot.com> From: "Avasarala Ranjit-A20990" To: "Eric Burger" X-CFilter-Loop: Reflected Cc: SIPCORE SIPCORE Subject: Re: [sipcore] Query on draft-ietf-sipcore-info-events-07 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Mar 2010 17:36:06 -0000 DQpIaSBFcmljIGFuZCBhbGwsDQoNClRoZW4gd2hhdCBpcyB0aGUgcmVhbCBwdXJwb3NlIG9mIGFu IElORk8gcGFja2FnZT8gSXMgdGhlcmUgYW55IGV4YW1wbGUgb3IgdXNlIGNhc2Ugd2hlcmUgSSB3 b3VsZCB1c2UgYW4gSU5GTyBwYWNrYWdlIG92ZXIgU0lQIE1FU1NBR0U/IEFsc28gaWYgdGhlIElO Rk8gcGFja2FnZSBpcyBnb2luZyB0byB0YWtlIHRoZSBmb3JtYXQgb2YgYW4gWE1MIGRvY3VtZW50 IChJIHRoaW5rKSwgdGhlbiBob3cgZGlmZmVyZW50IHdvdWxkIHRoYXQgYmUgZnJvbSB0aGUgcmVn dWxhciBldmVudCBwYWNrYWdlcz8NCg0KT25lIG1vcmUgcXVlcnkgSSBoYXZlIGlzIDogc2F5IGlu IGNhc2UgdGhlIFVBQyBkb2VzIG5vdCBpbmNsdWRlIHRoZSBSZWN2LUluZm8gaGVhZGVyIGluIHRo ZSBpbml0aWFsIElOVklURSByZXF1ZXN0LCB0aGVuIGNhbiBpdCBzdGlsbCB1c2UgSU5GTyB3aXRo IHBhY2thZ2Ugd2l0aCBtaWQgc2Vzc2lvbiBJTkZPIG1lc3NhZ2U/DQoNClRoYW5rcw0KDQoNClJl Z2FyZHMNClJhbmppdA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogRXJpYyBC dXJnZXIgW21haWx0bzplYnVyZ2VyQHN0YW5kYXJkc3RyYWNrLmNvbV0gDQpTZW50OiBTdW5kYXks IE1hcmNoIDE0LCAyMDEwIDEwOjU3IFBNDQpUbzogQXZhc2FyYWxhIFJhbmppdC1BMjA5OTANCkNj OiBTSVBDT1JFIFNJUENPUkUNClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gUXVlcnkgb24gZHJhZnQt aWV0Zi1zaXBjb3JlLWluZm8tZXZlbnRzLTA3DQoNClRoZSBwb2ludCBvZiBTZWN0aW9uIDcuNCBp cyB0aGVyZSBpcyBvZnRlbiBhIGZhciBzdXBlcmlvciBtZXRob2Qgb2YgZG9pbmcgdXNlci11c2Vy IHNpZ25hbGluZyBiZXNpZGVzIElORk8uIEZvciBleGFtcGxlLCBpZiB5b3Ugd2FudCB0byBzZW5k IERUTUYgZGlnaXRzLCB1c2UgS1BNTCAoaGUgc2F5cyBtb2Rlc3RseSkuDQoNClRoZXJlIGlzIGFi c29sdXRlbHkgTk8gY29ycmVzcG9uZGVuY2UgYmV0d2VlbiBhbiBJbmZvIFBhY2thZ2UgYW5kIGFu IEV2ZW50IFBhY2thZ2UuIE1vcmVvdmVyLCBpZiBzb21lb25lIHRyaWVkIHRvIHJlZ2lzdGVyIHN1 Y2gsIG15IGd1ZXNzIGlzIHRoZXkgd291bGQgbm90IGdldCB0aGUgcmVxdWlzaXRlIFNwZWNpZmlj YXRpb24gUmVxdWlyZWQgbGV2ZWwgbmVlZGVkIHRvIHJlZ2lzdGVyIGEgcGFja2FnZS4NCg0KT24g TWFyIDE0LCAyMDEwLCBhdCA0OjAzIEFNLCBBdmFzYXJhbGEgUmFuaml0LUEyMDk5MCB3cm90ZToN Cg0KPiBIaSBBZGFtDQo+ICANCj4gRnJvbSB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgdGhlIGluZm8g ZHJhZnQtaWV0Zi1zaXBjb3JlLWluZm8tZXZlbnRzLTA3LCB0aGUgc2VjdGlvbiA0ICJJbmZvIFBh Y2thZ2VzIiBkb2VzIG5vdCB0YWxrIGFib3V0IHRoZSBraW5kIG9mIHBhY2thZ2VzIGFuZCB0aGVp ciBmb3JtYXQuDQo+ICANCj4gVGhvdWdoIHRoZSBzZWN0aW9uIDcuNC4xLjIgIHRhbGtzIHRoYXQg dXNlIG9mIFNVQlNDUklCRSAvIE5PVElGWSBiYXNlZCBvbiAzMjY1IGFzIGFuIGFsdGVybmF0ZSBt ZWNoYW5pc20sIGl0IGlzIG5vdCBjbGVhciB3aGF0IHNob3VsZCBiZSB0aGUgZm9ybWF0IG9mIGEg dHlwaWNhbCBJTkZPIHBhY2thZ2UuDQo+ICANCj4gQWxzbyBmdXJ0aGVyIFNlY3Rpb24gNy40LjEu MyBtZW50aW9ucyB0aGUgdXNhZ2Ugb2YgU0lQIE1FU1NBR0UgbWV0aG9kLiBTbyBkb2VzIHRoaXMg bWVhbiBJIGNhbiB1c2UgTUVTU0FHRSBtZXRob2QgYXMgYW4gYWx0ZXJuYXRpdmUgdG8gSU5GTz8N Cj4gIA0KPiBUaGFua3MNCj4gUmVnYXJkcw0KPiBSYW5qaXQNCj4gIA0KPiANCj4gRnJvbTogQWRh bSBSb2FjaCBbbWFpbHRvOmFkYW1Abm9zdHJ1bS5jb21dDQo+IFNlbnQ6IFN1bmRheSwgTWFyY2gg MTQsIDIwMTAgNDoyMyBBTQ0KPiBUbzogQXZhc2FyYWxhIFJhbmppdC1BMjA5OTANCj4gQ2M6IHNp cGNvcmVAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtzaXBjb3JlXSBRdWVyeSBvbiBkcmFmdC1p ZXRmLXNpcGNvcmUtaW5mby1ldmVudHMtMDcNCj4gDQo+IFBsZWFzZSBkb24ndCBjcm9zcy1wb3N0 IHRvIGRpc3BhdGNoIGFuZCBzaXBjb3JlLg0KPiANCj4gT24gMy8xMi8xMCAyMzoyNiwgTWFyIDEy LCBBdmFzYXJhbGEgUmFuaml0LUEyMDk5MCB3cm90ZToNCj4+IEFyZSB0aGVyZSBhbnkgcmVnaXN0 ZXJlZCBJTkZPIHBhY2thZ2VzDQo+PiANCj4gDQo+IE5vdCB5ZXQuDQo+IA0KPj4gYW5kIGNhbiB0 aGUgcmVndWxhciBTSVAgZXZlbnQgcGFja2FnZXMgYmFzZWQgb24gUkZDIDMyNjUgYmUgdXNlZCB3 aXRoIElORk8gbWVjaGFuaXNtPw0KPj4gDQo+IA0KPiBBYnNvbHV0ZWx5IG5vdC4gTm8uIE5ldmVy LiBVbmRlciBubyBjaXJjdW1zdGFuY2VzLiBOZWluLCDQndC10YIsIOCkqOCkueClgOCkgiwgTm9u LCBOZWouIFRoZXkgYXJlIF9jb21wbGV0ZWx5XyBkaWZmZXJlbnQgdGhpbmdzLg0KPiANCj4gUmVh bGx5LCBpZiB0aGlzIGlzIHNvbWVob3cgdW5jbGVhciBpbiB0aGUgSU5GTyBkcmFmdCwgd2UgbmVl ZCB0byBwdWxsIGl0IGZyb20gcHVibGljYXRpb24gcmVxdWVzdCBhbmQgd29yayBvbiBpdCBzb21l IG1vcmUuIEl0IHdvdWxkIGJlIHRoZSB3b3JzdCBwb3NzaWJsZSBvdXRjb21lIGlmIGltcGxlbWVu dG9ycyB3ZXJlIGxlZCB0byBiZWxpZXZlIHRoYXQgMzI2NSBwYWNrYWdlcyBjb3VsZCBiZSB1c2Vk IHdpdGggSU5GTy4gV2hlcmUgZGlkIHlvdSBnZXQgdGhlIGltcHJlc3Npb24gdGhhdCB0aGlzIG1p Z2h0IGJlIG9rYXk/DQo+IA0KPiAvYQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPiBzaXBjb3JlQGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KDQo= From peter.musgrave@magorcorp.com Sun Mar 14 08:48:29 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 008A53A69C9 for ; Sun, 14 Mar 2010 08:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.487 X-Spam-Level: X-Spam-Status: No, score=-0.487 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 L0iLfrzGU+Kw for ; Sun, 14 Mar 2010 08:48:28 -0700 (PDT) Received: from mail-yx0-f180.google.com (mail-yx0-f180.google.com [209.85.210.180]) by core3.amsl.com (Postfix) with ESMTP id 8D1AA3A69E0 for ; Sun, 14 Mar 2010 08:46:49 -0700 (PDT) Received: by yxe10 with SMTP id 10so1428792yxe.29 for ; Sun, 14 Mar 2010 08:46:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.130.36 with SMTP id h36mr2825862ann.84.1268581613319; Sun, 14 Mar 2010 08:46:53 -0700 (PDT) Date: Sun, 14 Mar 2010 11:46:53 -0400 Message-ID: <8e5ec72f1003140846k313f008fk83980d92fd699351@mail.gmail.com> From: Peter Musgrave To: Gonzalo.Camarillo@ericsson.com, Christer.Holmberg@ericsson.com, gao.yang2@zte.com.cn Content-Type: multipart/alternative; boundary=0016e68de3e46e35b90481c4acdd X-Mailman-Approved-At: Sun, 14 Mar 2010 11:04:37 -0700 Cc: sipcore@ietf.org Subject: [sipcore] draft-ietf-sipcore-reinvite-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Mar 2010 15:48:29 -0000 --0016e68de3e46e35b90481c4acdd Content-Type: text/plain; charset=ISO-8859-1 Hi Gonzalo/Chris/Gao, Not sure if this is a nit - or if I am lost... In Figure 3 the 200 OK for the second INVITE (which made an offer) does not carry an answer. Is this deliberate? (I have the same issue in Figure 4 making me think perhaps I'm lost.) If yes, then I think an explanatory comment would be helpful - since I would expect a 200 with answer . Regards, Peter Musgrave --0016e68de3e46e35b90481c4acdd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Gonzalo/Chris/Gao,=A0

Not sure if this is a nit - or if I am lost...

In Figure 3 the 200 OK for the second INVITE (which made a= n offer) does not carry an answer. Is this deliberate? (I have the same iss= ue in Figure 4 making me think perhaps I'm lost.)

If yes, then I think an explanatory comment would be he= lpful - since I would expect a 200 with answer .

R= egards,=A0

Peter Musgrave
--0016e68de3e46e35b90481c4acdd-- From brett@broadsoft.com Sun Mar 14 11:16:47 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46F103A67AB for ; Sun, 14 Mar 2010 11:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.391 X-Spam-Level: X-Spam-Status: No, score=-1.391 tagged_above=-999 required=5 tests=[AWL=-1.208, BAYES_40=-0.185, HTML_MESSAGE=0.001] 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 0EyJmTnTpYSo for ; Sun, 14 Mar 2010 11:16:43 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id E9A083A6767 for ; Sun, 14 Mar 2010 11:16:42 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Sun, 14 Mar 2010 11:16:49 -0700 From: Brett Tate To: Peter Musgrave , "sipcore@ietf.org" Date: Sun, 14 Mar 2010 11:16:04 -0700 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-03 Thread-Index: AcrDoNeok8QAFn1uSPm6qEY/dVnA3gAAMM1w Message-ID: <747A6506A991724FB09B129B79D5FEB614806AF6E4@EXMBXCLUS01.citservers.local> References: <8e5ec72f1003140846k313f008fk83980d92fd699351@mail.gmail.com> In-Reply-To: <8e5ec72f1003140846k313f008fk83980d92fd699351@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_747A6506A991724FB09B129B79D5FEB614806AF6E4EXMBXCLUS01ci_" MIME-Version: 1.0 Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Mar 2010 18:16:47 -0000 --_000_747A6506A991724FB09B129B79D5FEB614806AF6E4EXMBXCLUS01ci_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It is deliberate; see RFC 3261 concerning when answer SDP needs to be withi= n INVITE's 2xx response. The 18x's were sent reliable; thus completing the= offer/answer exchange. The following is mention above both figures: "PRAC= K transactions are not shown for clarity". -brett From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Peter Musgrave Sent: Sunday, March 14, 2010 11:47 AM To: Gonzalo.Camarillo@ericsson.com; Christer.Holmberg@ericsson.com; gao.yan= g2@zte.com.cn Cc: sipcore@ietf.org Subject: [sipcore] draft-ietf-sipcore-reinvite-03 Hi Gonzalo/Chris/Gao, Not sure if this is a nit - or if I am lost... In Figure 3 the 200 OK for the second INVITE (which made an offer) does not= carry an answer. Is this deliberate? (I have the same issue in Figure 4 ma= king me think perhaps I'm lost.) If yes, then I think an explanatory comment would be helpful - since I woul= d expect a 200 with answer . Regards, Peter Musgrave --_000_747A6506A991724FB09B129B79D5FEB614806AF6E4EXMBXCLUS01ci_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It is deliberate; see RFC 3261 concerning when answer SDP ne= eds to be within INVITE’s 2xx response.  The 18x’s were sent reliable; thus completing the offer/answer exchange.  The following is mention above both figures: “PRACK transactions are not shown for cla= rity”.

 

-brett

 

From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of = Peter Musgrave
Sent: Sunday, March 14, 2010 11:47 AM
To: Gonzalo.Camarillo@ericsson.com; Christer.Holmberg@ericsson.com; gao.yang2@zte.com.cn
Cc: sipcore@ietf.org
Subject: [sipcore] draft-ietf-sipcore-reinvite-03<= /p>

 

Hi Gonzalo/Chris/Gao, 

 

Not sure if this is a nit - or if I am lost...

 

In Figure 3 the 200 OK for the second INVITE (which ma= de an offer) does not carry an answer. Is this deliberate? (I have the same issue= in Figure 4 making me think perhaps I'm lost.)

 

If yes, then I think an explanatory comment would be h= elpful - since I would expect a 200 with answer .

 

Regards, 

 

Peter Musgrave

--_000_747A6506A991724FB09B129B79D5FEB614806AF6E4EXMBXCLUS01ci_-- From eburger@standardstrack.com Sun Mar 14 17:01:50 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3548D3A683F for ; Sun, 14 Mar 2010 17:01:50 -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=[AWL=0.000, 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 Wi5PeD8Yhu6L for ; Sun, 14 Mar 2010 17:01:48 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 8EA373A6801 for ; Sun, 14 Mar 2010 17:01:48 -0700 (PDT) Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8] helo=[192.168.15.105]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Nqxki-00053x-JT; Sun, 14 Mar 2010 17:01:48 -0700 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=utf-8 From: Eric Burger In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A3BE75A@ZMY16EXM66.ds.mot.com> Date: Sun, 14 Mar 2010 20:01:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2AB9580C-6972-4E08-898E-E7E675E1DF81@standardstrack.com> References: <750BBC72E178114F9DC4872EBFF29A5B0A3BE70F@ZMY16EXM66.ds.mot.com> <4B9C1752.1000905@nostrum.com> <750BBC72E178114F9DC4872EBFF29A5B0A3BE74E@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A3BE75A@ZMY16EXM66.ds.mot.com> To: Avasarala Ranjit-A20990 X-Mailer: Apple Mail (2.1077) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: SIPCORE SIPCORE Subject: Re: [sipcore] Query on draft-ietf-sipcore-info-events-07 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 00:01:50 -0000 SOME people think session management for SUBSCRIBE/NOTIFY is too hard, = especially if the lifetime of the user-user exchange exactly matches the = lifetime of the SIP dialog. Simplicity and laziness? Ah - MESSAGE (I was thinking SUBSCRIBE). Problem is you have no way of = knowing whether the receiver wants to digest what you're sending. When you say UAC for the INVITE, I presume you mean the UAC for the = INFO, as well? If so, it is the UAS that must offer a Recv-Info header. = What the UAC offers is irrelevant, unless the UAC wants to advertise = what the UAC is willing to receive from the UAS. All of that should be = in the text. On Mar 14, 2010, at 1:34 PM, Avasarala Ranjit-A20990 wrote: >=20 > Hi Eric and all, >=20 > Then what is the real purpose of an INFO package? Is there any example = or use case where I would use an INFO package over SIP MESSAGE? Also if = the INFO package is going to take the format of an XML document (I = think), then how different would that be from the regular event = packages? >=20 > One more query I have is : say in case the UAC does not include the = Recv-Info header in the initial INVITE request, then can it still use = INFO with package with mid session INFO message? >=20 > Thanks >=20 >=20 > Regards > Ranjit >=20 > -----Original Message----- > From: Eric Burger [mailto:eburger@standardstrack.com]=20 > Sent: Sunday, March 14, 2010 10:57 PM > To: Avasarala Ranjit-A20990 > Cc: SIPCORE SIPCORE > Subject: Re: [sipcore] Query on draft-ietf-sipcore-info-events-07 >=20 > The point of Section 7.4 is there is often a far superior method of = doing user-user signaling besides INFO. For example, if you want to send = DTMF digits, use KPML (he says modestly). >=20 > There is absolutely NO correspondence between an Info Package and an = Event Package. Moreover, if someone tried to register such, my guess is = they would not get the requisite Specification Required level needed to = register a package. >=20 > On Mar 14, 2010, at 4:03 AM, Avasarala Ranjit-A20990 wrote: >=20 >> Hi Adam >>=20 >> =46rom the latest version of the info = draft-ietf-sipcore-info-events-07, the section 4 "Info Packages" does = not talk about the kind of packages and their format. >>=20 >> Though the section 7.4.1.2 talks that use of SUBSCRIBE / NOTIFY = based on 3265 as an alternate mechanism, it is not clear what should be = the format of a typical INFO package. >>=20 >> Also further Section 7.4.1.3 mentions the usage of SIP MESSAGE = method. So does this mean I can use MESSAGE method as an alternative to = INFO? >>=20 >> Thanks >> Regards >> Ranjit >>=20 >>=20 >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: Sunday, March 14, 2010 4:23 AM >> To: Avasarala Ranjit-A20990 >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] Query on draft-ietf-sipcore-info-events-07 >>=20 >> Please don't cross-post to dispatch and sipcore. >>=20 >> On 3/12/10 23:26, Mar 12, Avasarala Ranjit-A20990 wrote: >>> Are there any registered INFO packages >>>=20 >>=20 >> Not yet. >>=20 >>> and can the regular SIP event packages based on RFC 3265 be used = with INFO mechanism? >>>=20 >>=20 >> Absolutely not. No. Never. Under no circumstances. Nein, =D0=9D=D0=B5=D1= =82, =E0=A4=A8=E0=A4=B9=E0=A5=80=E0=A4=82, Non, Nej. They are = _completely_ different things. >>=20 >> Really, if this is somehow unclear in the INFO draft, we need to pull = it from publication request and work on it some more. It would be the = worst possible outcome if implementors were led to believe that 3265 = packages could be used with INFO. Where did you get the impression that = this might be okay? >>=20 >> /a >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 From nancy.greene@ericsson.com Sun Mar 14 20:10:19 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 560983A67F8 for ; Sun, 14 Mar 2010 20:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 IsaGm1xPxMEs for ; Sun, 14 Mar 2010 20:10:13 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id BEE8C3A67E3 for ; Sun, 14 Mar 2010 20:10:13 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o2F3DIXw024215 for ; Sun, 14 Mar 2010 22:13:18 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Sun, 14 Mar 2010 23:10:19 -0400 From: Nancy Greene To: "sipcore@ietf.org" Date: Sun, 14 Mar 2010 23:10:16 -0400 Thread-Topic: RFC 3263 - why require use port in Request-URI? Thread-Index: AcrD7QlstVU2IukFScuAvqzjz2Ni0w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [sipcore] RFC 3263 - why require use port in Request-URI? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 03:10:19 -0000 I have a question on section 4.2 of RFC 3263:=20 =20 Why is it that the port of the Request-URI is required to be used for an in= termediate proxy? Is the issue that it is not known whether the next hop pr= oxy is intermediate or is the actual destination in the Request-URI?=20 If so shouldn't there at least be a procedure described to use the port fro= m DNS instead of the one in the Request-URI if sending to the one in the Re= quest-URI fails? Section 4.2 from RFC 3263 (locating SIP servers): If the TARGET was not a numeric IP address, but a port is present =20 in the URI, the client performs an A or AAAA record lookup of the domain name. The result will be a list of IP addresses, each of which can be contacted at the specific port from the URI and transport protocol determined previously. Nancy =20 From ranjit@motorola.com Sun Mar 14 23:30:31 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70FA03A6A61 for ; Sun, 14 Mar 2010 23:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 nM5z7FEIhpl4 for ; Sun, 14 Mar 2010 23:30:30 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with ESMTP id 9C2423A6A4C for ; Sun, 14 Mar 2010 23:28:41 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-6.tower-55.messagelabs.com!1268634527!20309214!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 2228 invoked from network); 15 Mar 2010 06:28:47 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-6.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 15 Mar 2010 06:28:47 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id o2F6SfgB011023 for ; Sun, 14 Mar 2010 23:28:46 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id o2F6SfTb029433 for ; Mon, 15 Mar 2010 01:28:41 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id o2F6SdXQ029425 for ; Mon, 15 Mar 2010 01:28:40 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 15 Mar 2010 14:28:17 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A3BE81F@ZMY16EXM66.ds.mot.com> In-Reply-To: <2AB9580C-6972-4E08-898E-E7E675E1DF81@standardstrack.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [sipcore] Query on draft-ietf-sipcore-info-events-07 thread-index: AcrD0sGINqnD8JpiTImJyzEpuz3nuAANT+6g References: <750BBC72E178114F9DC4872EBFF29A5B0A3BE70F@ZMY16EXM66.ds.mot.com><4B9C1752.1000905@nostrum.com><750BBC72E178114F9DC4872EBFF29A5B0A3BE74E@ZMY16EXM66.ds.mot.com><750BBC72E178114F9DC4872EBFF29A5B0A3BE75A@ZMY16EXM66.ds.mot.com> <2AB9580C-6972-4E08-898E-E7E675E1DF81@standardstrack.com> From: "Avasarala Ranjit-A20990" To: "Eric Burger" X-CFilter-Loop: Reflected Cc: SIPCORE SIPCORE Subject: Re: [sipcore] Query on draft-ietf-sipcore-info-events-07 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 06:30:31 -0000 DQpPay4gU2F5IGlmIEkgd2FudCB0byB3cml0ZSBhIElORk8gcGFja2FnZSBmb3IgYSBwYXJ0aWN1 bGFyIHB1cnBvc2UsIHdoYXQgc2hvdWxkIGJlIHRoZSBmb3JtYXQgb2YgdGhhdCBwYWNrYWdlPyBT aG91bGQgaXQgYmUgYW4gWE1MIG9uZSBsaWtlIHRoZSBldmVudCBwYWNrYWdlcz8gVGhlbiB3aGF0 IHdvdWxkIGJlIHRoZSBwcm9jZWR1cmVzIGZvciB0aGF0IHBhY2thZ2UgLSBsaWtlIHRoZSBVQUMg dGhhdCBpbnRlbmRzIHRvIHNlbmQgYSBwYXJ0aWN1bGFyIHNlc3Npb24gb3IgYXBwbGljYXRpb24g bGV2ZWwgaW5mb3JtYXRpb24gZ2VuZXJhdGVzIHRoZSBjb3JyZXNwb25kaW5nIElORk8gcGFja2Fn ZSBhbmQgc2VuZHMgaXQ/DQoNCkUuZyAgVUFDIHNlbmRzIElOVklURSB0byBVQVMgd2l0aCBSZWN2 LUluZm86IGFwcC1pbmZvDQogICAgIC4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u Li4uLi4uLi4uLi4uDQogICAgIFVBQyBzZW5kcyBJTkZPIChhcHAtaW5mbyBwYWNrYWdlKQ0KDQog d2lsbCBhcHAtaW5mbyBwYWNrYWdlIGJlIHNvbWV0aGluZyBsaWtlIHRoaXMNCg0KIDx4bWwgdmVy c2lvbj0iMS4wIiA/Pg0KICAuLi4uLi4uLi4uLi4uLi4uLg0KICA8YXBwLWluZm8+DQogICAgLi4u DQogIDwvYXBwLWluZm8+DQogPC94bWw+DQoNClRoYW5rcyANCg0KDQpSZWdhcmRzDQpSYW5qaXQN Cg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNpcGNvcmUtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVyaWMg QnVyZ2VyDQpTZW50OiBNb25kYXksIE1hcmNoIDE1LCAyMDEwIDU6MzIgQU0NClRvOiBBdmFzYXJh bGEgUmFuaml0LUEyMDk5MA0KQ2M6IFNJUENPUkUgU0lQQ09SRQ0KU3ViamVjdDogUmU6IFtzaXBj b3JlXSBRdWVyeSBvbiBkcmFmdC1pZXRmLXNpcGNvcmUtaW5mby1ldmVudHMtMDcNCg0KU09NRSBw ZW9wbGUgdGhpbmsgc2Vzc2lvbiBtYW5hZ2VtZW50IGZvciBTVUJTQ1JJQkUvTk9USUZZIGlzIHRv byBoYXJkLCBlc3BlY2lhbGx5IGlmIHRoZSBsaWZldGltZSBvZiB0aGUgdXNlci11c2VyIGV4Y2hh bmdlIGV4YWN0bHkgbWF0Y2hlcyB0aGUgbGlmZXRpbWUgb2YgdGhlIFNJUCBkaWFsb2cuDQoNClNp bXBsaWNpdHkgYW5kIGxhemluZXNzPw0KDQpBaCAtIE1FU1NBR0UgKEkgd2FzIHRoaW5raW5nIFNV QlNDUklCRSkuIFByb2JsZW0gaXMgeW91IGhhdmUgbm8gd2F5IG9mIGtub3dpbmcgd2hldGhlciB0 aGUgcmVjZWl2ZXIgd2FudHMgdG8gZGlnZXN0IHdoYXQgeW91J3JlIHNlbmRpbmcuDQoNCldoZW4g eW91IHNheSBVQUMgZm9yIHRoZSBJTlZJVEUsIEkgcHJlc3VtZSB5b3UgbWVhbiB0aGUgVUFDIGZv ciB0aGUgSU5GTywgYXMgd2VsbD8gSWYgc28sIGl0IGlzIHRoZSBVQVMgdGhhdCBtdXN0IG9mZmVy IGEgUmVjdi1JbmZvIGhlYWRlci4gV2hhdCB0aGUgVUFDIG9mZmVycyBpcyBpcnJlbGV2YW50LCB1 bmxlc3MgdGhlIFVBQyB3YW50cyB0byBhZHZlcnRpc2Ugd2hhdCB0aGUgVUFDIGlzIHdpbGxpbmcg dG8gcmVjZWl2ZSBmcm9tIHRoZSBVQVMuICBBbGwgb2YgdGhhdCBzaG91bGQgYmUgaW4gdGhlIHRl eHQuDQoNCk9uIE1hciAxNCwgMjAxMCwgYXQgMTozNCBQTSwgQXZhc2FyYWxhIFJhbmppdC1BMjA5 OTAgd3JvdGU6DQoNCj4gDQo+IEhpIEVyaWMgYW5kIGFsbCwNCj4gDQo+IFRoZW4gd2hhdCBpcyB0 aGUgcmVhbCBwdXJwb3NlIG9mIGFuIElORk8gcGFja2FnZT8gSXMgdGhlcmUgYW55IGV4YW1wbGUg b3IgdXNlIGNhc2Ugd2hlcmUgSSB3b3VsZCB1c2UgYW4gSU5GTyBwYWNrYWdlIG92ZXIgU0lQIE1F U1NBR0U/IEFsc28gaWYgdGhlIElORk8gcGFja2FnZSBpcyBnb2luZyB0byB0YWtlIHRoZSBmb3Jt YXQgb2YgYW4gWE1MIGRvY3VtZW50IChJIHRoaW5rKSwgdGhlbiBob3cgZGlmZmVyZW50IHdvdWxk IHRoYXQgYmUgZnJvbSB0aGUgcmVndWxhciBldmVudCBwYWNrYWdlcz8NCj4gDQo+IE9uZSBtb3Jl IHF1ZXJ5IEkgaGF2ZSBpcyA6IHNheSBpbiBjYXNlIHRoZSBVQUMgZG9lcyBub3QgaW5jbHVkZSB0 aGUgUmVjdi1JbmZvIGhlYWRlciBpbiB0aGUgaW5pdGlhbCBJTlZJVEUgcmVxdWVzdCwgdGhlbiBj YW4gaXQgc3RpbGwgdXNlIElORk8gd2l0aCBwYWNrYWdlIHdpdGggbWlkIHNlc3Npb24gSU5GTyBt ZXNzYWdlPw0KPiANCj4gVGhhbmtzDQo+IA0KPiANCj4gUmVnYXJkcw0KPiBSYW5qaXQNCj4gDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEVyaWMgQnVyZ2VyIFttYWlsdG86 ZWJ1cmdlckBzdGFuZGFyZHN0cmFjay5jb21dDQo+IFNlbnQ6IFN1bmRheSwgTWFyY2ggMTQsIDIw MTAgMTA6NTcgUE0NCj4gVG86IEF2YXNhcmFsYSBSYW5qaXQtQTIwOTkwDQo+IENjOiBTSVBDT1JF IFNJUENPUkUNCj4gU3ViamVjdDogUmU6IFtzaXBjb3JlXSBRdWVyeSBvbiBkcmFmdC1pZXRmLXNp cGNvcmUtaW5mby1ldmVudHMtMDcNCj4gDQo+IFRoZSBwb2ludCBvZiBTZWN0aW9uIDcuNCBpcyB0 aGVyZSBpcyBvZnRlbiBhIGZhciBzdXBlcmlvciBtZXRob2Qgb2YgZG9pbmcgdXNlci11c2VyIHNp Z25hbGluZyBiZXNpZGVzIElORk8uIEZvciBleGFtcGxlLCBpZiB5b3Ugd2FudCB0byBzZW5kIERU TUYgZGlnaXRzLCB1c2UgS1BNTCAoaGUgc2F5cyBtb2Rlc3RseSkuDQo+IA0KPiBUaGVyZSBpcyBh YnNvbHV0ZWx5IE5PIGNvcnJlc3BvbmRlbmNlIGJldHdlZW4gYW4gSW5mbyBQYWNrYWdlIGFuZCBh biBFdmVudCBQYWNrYWdlLiBNb3Jlb3ZlciwgaWYgc29tZW9uZSB0cmllZCB0byByZWdpc3RlciBz dWNoLCBteSBndWVzcyBpcyB0aGV5IHdvdWxkIG5vdCBnZXQgdGhlIHJlcXVpc2l0ZSBTcGVjaWZp Y2F0aW9uIFJlcXVpcmVkIGxldmVsIG5lZWRlZCB0byByZWdpc3RlciBhIHBhY2thZ2UuDQo+IA0K PiBPbiBNYXIgMTQsIDIwMTAsIGF0IDQ6MDMgQU0sIEF2YXNhcmFsYSBSYW5qaXQtQTIwOTkwIHdy b3RlOg0KPiANCj4+IEhpIEFkYW0NCj4+IA0KPj4gRnJvbSB0aGUgbGF0ZXN0IHZlcnNpb24gb2Yg dGhlIGluZm8gZHJhZnQtaWV0Zi1zaXBjb3JlLWluZm8tZXZlbnRzLTA3LCB0aGUgc2VjdGlvbiA0 ICJJbmZvIFBhY2thZ2VzIiBkb2VzIG5vdCB0YWxrIGFib3V0IHRoZSBraW5kIG9mIHBhY2thZ2Vz IGFuZCB0aGVpciBmb3JtYXQuDQo+PiANCj4+IFRob3VnaCB0aGUgc2VjdGlvbiA3LjQuMS4yICB0 YWxrcyB0aGF0IHVzZSBvZiBTVUJTQ1JJQkUgLyBOT1RJRlkgYmFzZWQgb24gMzI2NSBhcyBhbiBh bHRlcm5hdGUgbWVjaGFuaXNtLCBpdCBpcyBub3QgY2xlYXIgd2hhdCBzaG91bGQgYmUgdGhlIGZv cm1hdCBvZiBhIHR5cGljYWwgSU5GTyBwYWNrYWdlLg0KPj4gDQo+PiBBbHNvIGZ1cnRoZXIgU2Vj dGlvbiA3LjQuMS4zIG1lbnRpb25zIHRoZSB1c2FnZSBvZiBTSVAgTUVTU0FHRSBtZXRob2QuIFNv IGRvZXMgdGhpcyBtZWFuIEkgY2FuIHVzZSBNRVNTQUdFIG1ldGhvZCBhcyBhbiBhbHRlcm5hdGl2 ZSB0byBJTkZPPw0KPj4gDQo+PiBUaGFua3MNCj4+IFJlZ2FyZHMNCj4+IFJhbmppdA0KPj4gDQo+ PiANCj4+IEZyb206IEFkYW0gUm9hY2ggW21haWx0bzphZGFtQG5vc3RydW0uY29tXQ0KPj4gU2Vu dDogU3VuZGF5LCBNYXJjaCAxNCwgMjAxMCA0OjIzIEFNDQo+PiBUbzogQXZhc2FyYWxhIFJhbmpp dC1BMjA5OTANCj4+IENjOiBzaXBjb3JlQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW3NpcGNv cmVdIFF1ZXJ5IG9uIGRyYWZ0LWlldGYtc2lwY29yZS1pbmZvLWV2ZW50cy0wNw0KPj4gDQo+PiBQ bGVhc2UgZG9uJ3QgY3Jvc3MtcG9zdCB0byBkaXNwYXRjaCBhbmQgc2lwY29yZS4NCj4+IA0KPj4g T24gMy8xMi8xMCAyMzoyNiwgTWFyIDEyLCBBdmFzYXJhbGEgUmFuaml0LUEyMDk5MCB3cm90ZToN Cj4+PiBBcmUgdGhlcmUgYW55IHJlZ2lzdGVyZWQgSU5GTyBwYWNrYWdlcw0KPj4+IA0KPj4gDQo+ PiBOb3QgeWV0Lg0KPj4gDQo+Pj4gYW5kIGNhbiB0aGUgcmVndWxhciBTSVAgZXZlbnQgcGFja2Fn ZXMgYmFzZWQgb24gUkZDIDMyNjUgYmUgdXNlZCB3aXRoIElORk8gbWVjaGFuaXNtPw0KPj4+IA0K Pj4gDQo+PiBBYnNvbHV0ZWx5IG5vdC4gTm8uIE5ldmVyLiBVbmRlciBubyBjaXJjdW1zdGFuY2Vz LiBOZWluLCDQndC10YIsIOCkqOCkueClgOCkgiwgTm9uLCBOZWouIFRoZXkgYXJlIF9jb21wbGV0 ZWx5XyBkaWZmZXJlbnQgdGhpbmdzLg0KPj4gDQo+PiBSZWFsbHksIGlmIHRoaXMgaXMgc29tZWhv dyB1bmNsZWFyIGluIHRoZSBJTkZPIGRyYWZ0LCB3ZSBuZWVkIHRvIHB1bGwgaXQgZnJvbSBwdWJs aWNhdGlvbiByZXF1ZXN0IGFuZCB3b3JrIG9uIGl0IHNvbWUgbW9yZS4gSXQgd291bGQgYmUgdGhl IHdvcnN0IHBvc3NpYmxlIG91dGNvbWUgaWYgaW1wbGVtZW50b3JzIHdlcmUgbGVkIHRvIGJlbGll dmUgdGhhdCAzMjY1IHBhY2thZ2VzIGNvdWxkIGJlIHVzZWQgd2l0aCBJTkZPLiBXaGVyZSBkaWQg eW91IGdldCB0aGUgaW1wcmVzc2lvbiB0aGF0IHRoaXMgbWlnaHQgYmUgb2theT8NCj4+IA0KPj4g L2ENCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ PiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPj4gc2lwY29yZUBpZXRmLm9yZw0KPj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo+IA0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2lwY29yZSBtYWlsaW5nIGxpc3QN CnNpcGNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2lwY29yZQ0K From pkyzivat@cisco.com Mon Mar 15 06:10:23 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF1DF3A67A4 for ; Mon, 15 Mar 2010 06:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.256 X-Spam-Level: X-Spam-Status: No, score=-10.256 tagged_above=-999 required=5 tests=[AWL=0.343, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 g0jqkJ+n9BVw for ; Mon, 15 Mar 2010 06:10:22 -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 AFFA33A6A7E for ; Mon, 15 Mar 2010 06:08:23 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKfNnUutJV2a/2dsb2JhbACacXOfHZdXhHsEhhk X-IronPort-AV: E=Sophos;i="4.49,643,1262563200"; d="scan'208";a="92859314" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 15 Mar 2010 13:08:23 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o2FD8Nvr029308; Mon, 15 Mar 2010 13:08:23 GMT Message-ID: <4B9E3147.6050601@cisco.com> Date: Mon, 15 Mar 2010 09:08:23 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Nancy Greene References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] RFC 3263 - why require use port in Request-URI? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 13:10:24 -0000 Nancy, Questions such as this should be brought to . To answer your question... The port from the URI is to be used *if* it is present in the URI. (Would you prefer to *ignore* it?) If the the port is *not* present in the URI, then the port is obtained from DNS via the SRV query. That is explained further on in the same section of the document. Thanks, Paul Nancy Greene wrote: > I have a question on section 4.2 of RFC 3263: > > Why is it that the port of the Request-URI is required to be used for an intermediate proxy? Is the issue that it is not known whether the next hop proxy is intermediate or is the actual destination in the Request-URI? > > If so shouldn't there at least be a procedure described to use the port from DNS instead of the one in the Request-URI if sending to the one in the Request-URI fails? > > Section 4.2 from RFC 3263 (locating SIP servers): > > If the TARGET was not a numeric IP address, but a port is present > in the URI, the client performs an A or AAAA record lookup of the > domain name. The result will be a list of IP addresses, each of > which can be contacted at the specific port from the URI and > transport protocol determined previously. > > Nancy > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nancy.greene@ericsson.com Mon Mar 15 06:33:08 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEC983A67A5 for ; Mon, 15 Mar 2010 06:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 2Gm59IgBpGeX for ; Mon, 15 Mar 2010 06:33:07 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id B15E23A693F for ; Mon, 15 Mar 2010 06:33:00 -0700 (PDT) Received: from eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o2FDZYSp006038; Mon, 15 Mar 2010 08:35:40 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.1.20]) by eusaamw0707.eamcs.ericsson.se ([147.117.20.32]) with mapi; Mon, 15 Mar 2010 09:32:38 -0400 From: Nancy Greene To: Paul Kyzivat Date: Mon, 15 Mar 2010 09:32:37 -0400 Thread-Topic: [sipcore] RFC 3263 - why require use port in Request-URI? Thread-Index: AcrEQLUYp94Rd/rnTSKb4aWQprPgbQAAtTlw Message-ID: References: <4B9E3147.6050601@cisco.com> In-Reply-To: <4B9E3147.6050601@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] RFC 3263 - why require use port in Request-URI? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 13:33:08 -0000 Thanks for the answer, but I'd like to know why the RFC is written the way = it is.=20 What if there is an intermediate SIP proxy between the target in the Reques= t-URI and the proxy trying to reach it? That intermediate SIP proxy does no= t allow traffic on the port mentioned in the Request-URI, so the request fa= ils to reach the target. This does not seem right. Shouldn't the RFC at th= e very least require a retry at the port that the intermediate proxy expect= s traffic on? Nancy -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: March-15-10 9:08 AM To: Nancy Greene Cc: sipcore@ietf.org Subject: Re: [sipcore] RFC 3263 - why require use port in Request-URI? Nancy, Questions such as this should be brought to . To answer your question... The port from the URI is to be used *if* it is present in the URI. (Would you prefer to *ignore* it?) If the the port is *not* present in the URI, then the port is obtained from= DNS via the SRV query. That is explained further on in the same section of= the document. Thanks, Paul Nancy Greene wrote: > I have a question on section 4.2 of RFC 3263:=20 > =20 > Why is it that the port of the Request-URI is required to be used for an = intermediate proxy? Is the issue that it is not known whether the next hop = proxy is intermediate or is the actual destination in the Request-URI?=20 >=20 > If so shouldn't there at least be a procedure described to use the port f= rom DNS instead of the one in the Request-URI if sending to the one in the = Request-URI fails? >=20 > Section 4.2 from RFC 3263 (locating SIP servers): >=20 > If the TARGET was not a numeric IP address, but a port is present = =20 > in the URI, the client performs an A or AAAA record lookup of the=20 > domain name. The result will be a list of IP addresses, each of which=20 > can be contacted at the specific port from the URI and transport=20 > protocol determined previously. >=20 > Nancy > =20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From adam@nostrum.com Mon Mar 15 07:17:03 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D01463A697C for ; Mon, 15 Mar 2010 07:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] 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 M3YyxY7AymrT for ; Mon, 15 Mar 2010 07:17:02 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 402283A6B5A for ; Mon, 15 Mar 2010 07:15:55 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o2FEFIF3028133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Mar 2010 09:15:18 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4B9E40F6.6000000@nostrum.com> Date: Mon, 15 Mar 2010 09:15:18 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: Nancy Greene References: <4B9E3147.6050601@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: "sipcore@ietf.org" Subject: Re: [sipcore] RFC 3263 - why require use port in Request-URI? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 14:17:03 -0000 [as WG chair] Nancy: Paul is correct. This is the type of question that belongs on , not the standards development mailing list. Please redirect your queries there. In practice, I believe you are confused about what section 4.2 actually says. Someone on the sip-implementors list should be able to help clarify things for you. Thanks. /a On 3/15/10 08:32, Mar 15, Nancy Greene wrote: > Thanks for the answer, but I'd like to know why the RFC is written the way it is. > > What if there is an intermediate SIP proxy between the target in the Request-URI and the proxy trying to reach it? That intermediate SIP proxy does not allow traffic on the port mentioned in the Request-URI, so the request fails to reach the target. This does not seem right. Shouldn't the RFC at the very least require a retry at the port that the intermediate proxy expects traffic on? > > Nancy > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: March-15-10 9:08 AM > To: Nancy Greene > Cc: sipcore@ietf.org > Subject: Re: [sipcore] RFC 3263 - why require use port in Request-URI? > > Nancy, > > Questions such as this should be brought to. > > To answer your question... > > The port from the URI is to be used *if* it is present in the URI. > (Would you prefer to *ignore* it?) > > If the the port is *not* present in the URI, then the port is obtained from DNS via the SRV query. That is explained further on in the same section of the document. > > Thanks, > Paul > > > Nancy Greene wrote: > >> I have a question on section 4.2 of RFC 3263: >> >> Why is it that the port of the Request-URI is required to be used for an intermediate proxy? Is the issue that it is not known whether the next hop proxy is intermediate or is the actual destination in the Request-URI? >> >> If so shouldn't there at least be a procedure described to use the port from DNS instead of the one in the Request-URI if sending to the one in the Request-URI fails? >> >> Section 4.2 from RFC 3263 (locating SIP servers): >> >> If the TARGET was not a numeric IP address, but a port is present >> in the URI, the client performs an A or AAAA record lookup of the >> domain name. The result will be a list of IP addresses, each of which >> can be contacted at the specific port from the URI and transport >> protocol determined previously. >> >> Nancy >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From wwwrun@core3.amsl.com Mon Mar 15 07:23:26 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 9DD203A6A30; Mon, 15 Mar 2010 07:23:26 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100315142326.9DD203A6A30@core3.amsl.com> Date: Mon, 15 Mar 2010 07:23:26 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] Last Call: draft-ietf-sipcore-info-events (Session Initiation Protocol (SIP) INFO Method and Package Framework) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 14:23:26 -0000 The IESG has received a request from the Session Initiation Protocol Core WG (sipcore) to consider the following document: - 'Session Initiation Protocol (SIP) INFO Method and Package Framework ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-03-29. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sipcore-info-events-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18772&rfc_flag=0 From adam@nostrum.com Mon Mar 15 07:53:40 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 752023A6969 for ; Mon, 15 Mar 2010 07:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] 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 y-FI5ZfGxj9V for ; Mon, 15 Mar 2010 07:53:39 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 512FE3A68C6 for ; Mon, 15 Mar 2010 07:53:38 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o2FErirW031031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Mar 2010 09:53:44 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4B9E49F8.8010702@nostrum.com> Date: Mon, 15 Mar 2010 09:53:44 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: Eric Burger References: <750BBC72E178114F9DC4872EBFF29A5B0A3BE70F@ZMY16EXM66.ds.mot.com> <4B9C1752.1000905@nostrum.com> <750BBC72E178114F9DC4872EBFF29A5B0A3BE74E@ZMY16EXM66.ds.mot.com> <750BBC72E178114F9DC4872EBFF29A5B0A3BE75A@ZMY16EXM66.ds.mot.com> <2AB9580C-6972-4E08-898E-E7E675E1DF81@standardstrack.com> In-Reply-To: <2AB9580C-6972-4E08-898E-E7E675E1DF81@standardstrack.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: SIPCORE SIPCORE , Avasarala Ranjit-A20990 Subject: Re: [sipcore] Query on draft-ietf-sipcore-info-events-07 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 14:53:40 -0000 On 3/14/10 19:01, Mar 14, Eric Burger wrote: > Ah - MESSAGE (I was thinking SUBSCRIBE). Problem is you have no way of knowing whether the receiver wants to digest what you're sending. > That's one problem. The key problem is that MESSAGE means something. And that something is not "here's a pile of bits, figure out what to do with them." The meaning is "here is some kind of media that you need to present to your user." For non-media payloads consumed by automata, you need something with different semantics. /a From adam@nostrum.com Mon Mar 15 08:26:38 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA43F3A6B8C for ; Mon, 15 Mar 2010 08:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] 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 8QbtDIlhBNIP for ; Mon, 15 Mar 2010 08:26:37 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 5A6633A6BC6 for ; Mon, 15 Mar 2010 08:26:35 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o2FFQeYe033522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Mar 2010 10:26:41 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4B9E51B0.3080607@nostrum.com> Date: Mon, 15 Mar 2010 10:26:40 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: Avasarala Ranjit-A20990 References: <750BBC72E178114F9DC4872EBFF29A5B0A3BE70F@ZMY16EXM66.ds.mot.com><4B9C1752.1000905@nostrum.com><750BBC72E178114F9DC4872EBFF29A5B0A3BE74E@ZMY16EXM66.ds.mot.com><750BBC72E178114F9DC4872EBFF29A5B0A3BE75A@ZMY16EXM66.ds.mot.com> <2AB9580C-6972-4E08-898E-E7E675E1DF81@standardstrack.com> <750BBC72E178114F9DC4872EBFF29A5B0A3BE81F@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A3BE81F@ZMY16EXM66.ds.mot.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: SIPCORE SIPCORE Subject: Re: [sipcore] Query on draft-ietf-sipcore-info-events-07 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 15:26:38 -0000 [as participant] On 3/15/10 01:28, Mar 15, Avasarala Ranjit-A20990 wrote: > Ok. Say if I want to write a INFO package for a particular purpose, what should be the format of that package? Should it be an XML one like the event packages? Not all event packages are XML -- see RFC 3842, for example. The format that is best suited for conveying information in a MIME body generally depends on what you're trying to convey. People seem to like XML for this kind of thing, but there is nothing preventing any appropriate data format. > Then what would be the procedures for that package If you want to publish an INFO package as part of the IETF process, you really need to step through section 7 -- and, in particular, section 7.4 -- and explain why INFO is the right tool for the task you have in mind. You need to explain why the other mechanisms designed for inter-automata communication don't suit the purpose of the application you're designing. Describe why, for example, you want to use INFO instead of SUBSCRIBE and NOTIFY. To be clear, you can define INFO packages outside the IETF process, as long as you do so in a way that can be referenced and which is effectively permanent. This would typically involve working with another SDO, although a company, organization, or individual could, in theory, publish a specification as well (as long as it met the criteria described in section 11.4 of the INFO draft). In either case, you'll need to include enough information to allow interoperable implementation. Although it's not the only way to do things, the easy way to do this would be to include the following 12 sections in your document, with contents as suggested by the corresponding parts of Section 10 of the INFO framework: 1. General 2. Overall Description 3. Applicability 4. Info Package Name 5. Info Package Parameters 6. SIP Option Tags 7. INFO Message Body Parts 8. Info Package Usage Restrictions 9. Rate of INFO Requests 10. Info Package Security Considerations 11. Implementation Details 12. Examples > - like the UAC that intends to send a particular session or application level information generates the corresponding INFO package and sends it? > > E.g UAC sends INVITE to UAS with Recv-Info: app-info > ............................................... > UAC sends INFO (app-info package) > > will app-info package be something like this > > > ................. > > ... > > > Except that it wouldn't be something as generic as "app-info." You'd need to define an info package that specified what kind of information is to be conveyed, and how the recipient processes it. Ideally, your event package name would reflect that application in some way. You'll need a formal (and complete) definition of the body syntax. If you choose to use XML, this would be something like a DTD, Schema, or Relax NG definition. If you use some other data framework (e.g., ASN.1), you'll need to define your fields using the formal definition language provided by that framework. If you're rolling your own syntax, you probably want to use something like ABNF. But I'm pretty much just repeating the guidance provided by the INFO draft itself. I would suggest a careful, detailed reading -- with special attention to sections 7 and 10 (and their respective subsections). /a From peter.musgrave@magorcorp.com Mon Mar 15 09:34:44 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD95B3A6BF2 for ; Mon, 15 Mar 2010 09:34:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.232 X-Spam-Level: X-Spam-Status: No, score=-1.232 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 fsllX0tGGWGH for ; Mon, 15 Mar 2010 09:34:43 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 0DAEB3A6C38 for ; Mon, 15 Mar 2010 09:34:36 -0700 (PDT) Received: by vws1 with SMTP id 1so250725vws.31 for ; Mon, 15 Mar 2010 09:34:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.124.136 with SMTP id u8mr3311693vcr.25.1268670881656; Mon, 15 Mar 2010 09:34:41 -0700 (PDT) Date: Mon, 15 Mar 2010 12:34:41 -0400 Message-ID: <8e5ec72f1003150934i56014485p7001ecde495869a0@mail.gmail.com> From: Peter Musgrave To: eburger@standardstrack.com, sipcore@ietf.org Content-Type: multipart/alternative; boundary=0016369208b43cf1540481d97556 Subject: [sipcore] INFO Package Candidate? RFC5168 Media Control X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 16:34:44 -0000 --0016369208b43cf1540481d97556 Content-Type: text/plain; charset=ISO-8859-1 Hi, I am finding the INFO event draft helpful (and have it in my code for my 'vendor specific' needs). Is there interest in defining an INFO package for picture fast updates for a video stream as per RFC5168? I am currently not aware of a standard mechanism to see if an endpoint will originate or accept such INFOs (although a number of implementations do). Currently I am 'guessing'. Would such a definition be done in sipcore or as part of mmusic (the originators of RFC). Regards, Peter Musgrave --0016369208b43cf1540481d97556 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,=A0

I am finding the INFO event draft helpful (and ha= ve it in my code for my 'vendor specific' needs).

Is there interest in defining an INFO package for picture fast update= s for a video stream as per RFC5168?

I am currently not aware of a standard mechanism to see= if an endpoint will originate or accept such INFOs (although a number of i= mplementations do). Currently I am 'guessing'.

Would such a definition be done in sipcore or as part of mmusic (the o= riginators of RFC).

Regards,=A0

Peter Musgrave
--0016369208b43cf1540481d97556-- From pkyzivat@cisco.com Mon Mar 15 09:41:57 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C76A03A6939 for ; Mon, 15 Mar 2010 09:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.297 X-Spam-Level: X-Spam-Status: No, score=-10.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 mLdzL2EghPEm for ; Mon, 15 Mar 2010 09:41:56 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id A384E3A67F2 for ; Mon, 15 Mar 2010 09:41:56 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPv/nUtAZnwN/2dsb2JhbACacHOiAJdshHsE X-IronPort-AV: E=Sophos;i="4.49,644,1262563200"; d="scan'208";a="92801051" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 15 Mar 2010 16:42:03 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2FGg3wF026445; Mon, 15 Mar 2010 16:42:03 GMT Message-ID: <4B9E6359.7080301@cisco.com> Date: Mon, 15 Mar 2010 12:42:01 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Peter Musgrave References: <8e5ec72f1003150934i56014485p7001ecde495869a0@mail.gmail.com> In-Reply-To: <8e5ec72f1003150934i56014485p7001ecde495869a0@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] INFO Package Candidate? RFC5168 Media Control X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 16:41:57 -0000 [I'm now quite sure what hat I'm wearing here. I don't think I have formally received by "chair" hat. I guess I would be wearing my chair hat if I had one.] sipcore would *not* be the right place to do such an info package. (Most likely it will never be the place to do *any* info package.) mmusic does sound like a plausible place to do it. But of course they would have to agree. Thanks, Paul Peter Musgrave wrote: > Hi, > > I am finding the INFO event draft helpful (and have it in my code for my > 'vendor specific' needs). > > Is there interest in defining an INFO package for picture fast updates > for a video stream as per RFC5168? > > I am currently not aware of a standard mechanism to see if an endpoint > will originate or accept such INFOs (although a number of > implementations do). Currently I am 'guessing'. > > Would such a definition be done in sipcore or as part of mmusic (the > originators of RFC). > > Regards, > > Peter Musgrave > > > ------------------------------------------------------------------------ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From adam@nostrum.com Mon Mar 15 09:45:21 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C15C13A6AA9 for ; Mon, 15 Mar 2010 09:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] 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 8HUW0iKQK2Jy for ; Mon, 15 Mar 2010 09:45:20 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 53E483A6BC0 for ; Mon, 15 Mar 2010 09:45:12 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-147-216.dsl.rcsntx.swbell.net [70.249.147.216]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o2FGjCe2039593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Mar 2010 11:45:12 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4B9E6418.6080808@nostrum.com> Date: Mon, 15 Mar 2010 11:45:12 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 MIME-Version: 1.0 To: Paul Kyzivat References: <8e5ec72f1003150934i56014485p7001ecde495869a0@mail.gmail.com> <4B9E6359.7080301@cisco.com> In-Reply-To: <4B9E6359.7080301@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.147.216 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org, Peter Musgrave Subject: Re: [sipcore] INFO Package Candidate? RFC5168 Media Control X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 16:45:21 -0000 [as chair] And, when in doubt, I'd take things to DISPATCH. That's what they're there for. /a On 3/15/10 11:42, Mar 15, Paul Kyzivat wrote: > [I'm now quite sure what hat I'm wearing here. I don't think I have > formally received by "chair" hat. I guess I would be wearing my chair > hat if I had one.] > > sipcore would *not* be the right place to do such an info package. > (Most likely it will never be the place to do *any* info package.) > > mmusic does sound like a plausible place to do it. But of course they > would have to agree. > > Thanks, > Paul > > Peter Musgrave wrote: >> Hi, >> I am finding the INFO event draft helpful (and have it in my code for >> my 'vendor specific' needs). >> >> Is there interest in defining an INFO package for picture fast >> updates for a video stream as per RFC5168? >> >> I am currently not aware of a standard mechanism to see if an >> endpoint will originate or accept such INFOs (although a number of >> implementations do). Currently I am 'guessing'. >> >> Would such a definition be done in sipcore or as part of mmusic (the >> originators of RFC). >> >> Regards, >> Peter Musgrave >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From gonzalo.camarillo@ericsson.com Mon Mar 15 10:36:30 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 242ED3A69A3 for ; Mon, 15 Mar 2010 10:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.243 X-Spam-Level: X-Spam-Status: No, score=-103.243 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 RKTUH77xXFJw for ; Mon, 15 Mar 2010 10:36:29 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id D80A43A6A7D for ; Mon, 15 Mar 2010 10:35:46 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-ba-4b9e6ff88111 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id C3.70.23532.8FF6E9B4; Mon, 15 Mar 2010 18:35:52 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Mar 2010 18:35:52 +0100 Received: from [131.160.126.193] ([131.160.126.193]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 15 Mar 2010 18:35:51 +0100 Message-ID: <4B9E6FF7.6070006@ericsson.com> Date: Mon, 15 Mar 2010 09:35:51 -0800 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Peter Musgrave References: <8e5ec72f1003140846k313f008fk83980d92fd699351@mail.gmail.com> In-Reply-To: <8e5ec72f1003140846k313f008fk83980d92fd699351@mail.gmail.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Mar 2010 17:35:51.0413 (UTC) FILETIME=[F4F83A50:01CAC465] X-Brightmail-Tracker: AAAAAA== Cc: "gao.yang2@zte.com.cn" , "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 17:36:30 -0000 Hi Peter, those 200 (OK) responses do not carry answers because of one of the main rules of the offer/answer model. That is, the UAS only provides one answer to a given offer. In the cases you are pointing to, the answer was provided in a reliable provisional response. Cheers, Gonzalo On 14/03/2010 7:46 AM, Peter Musgrave wrote: > Hi Gonzalo/Chris/Gao, > > Not sure if this is a nit - or if I am lost... > > In Figure 3 the 200 OK for the second INVITE (which made an offer) does > not carry an answer. Is this deliberate? (I have the same issue in > Figure 4 making me think perhaps I'm lost.) > > If yes, then I think an explanatory comment would be helpful - since I > would expect a 200 with answer . > > Regards, > > Peter Musgrave From keith.drage@alcatel-lucent.com Mon Mar 15 11:34:31 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 746C83A6BBD for ; Mon, 15 Mar 2010 11:34:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.067 X-Spam-Level: X-Spam-Status: No, score=-5.067 tagged_above=-999 required=5 tests=[AWL=1.182, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 b3LWH3Ohgn6b for ; Mon, 15 Mar 2010 11:34:30 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 3059A3A6B63 for ; Mon, 15 Mar 2010 11:34:28 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o2FIYVTl024252 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 15 Mar 2010 19:34:31 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 15 Mar 2010 19:34:31 +0100 From: "DRAGE, Keith (Keith)" To: Adam Roach , Paul Kyzivat Date: Mon, 15 Mar 2010 19:34:28 +0100 Thread-Topic: [sipcore] INFO Package Candidate? RFC5168 Media Control Thread-Index: AcrEXwsbjGPobNNjQYWChtX5mS319wADqfzQ Message-ID: References: <8e5ec72f1003150934i56014485p7001ecde495869a0@mail.gmail.com> <4B9E6359.7080301@cisco.com> <4B9E6418.6080808@nostrum.com> In-Reply-To: <4B9E6418.6080808@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: "sipcore@ietf.org" , Peter Musgrave Subject: Re: [sipcore] INFO Package Candidate? RFC5168 Media Control X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 18:34:31 -0000 If you want to get it in front of a WG, dispatch is probably the best place= to start. (Do remember that dispatch is using advanced deadlines on the no= rmal WG submission deadline). Remember however that you do not need a WG charter item, or a proposed stan= dard, to create an INFO package. Aside from getting some other group outsid= e IETF to put it in one of their specifications, if it is simple, you may b= e able to persuade an AD to sponsor it (as a more efficient task that sendi= ng it to a WG), or it can just be submitted as informational and wait. regards Keith=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach > Sent: Monday, March 15, 2010 4:45 PM > To: Paul Kyzivat > Cc: sipcore@ietf.org; Peter Musgrave > Subject: Re: [sipcore] INFO Package Candidate? RFC5168 Media Control >=20 > [as chair] >=20 > And, when in doubt, I'd take things to DISPATCH. That's what=20 > they're there for. >=20 > /a >=20 > On 3/15/10 11:42, Mar 15, Paul Kyzivat wrote: > > [I'm now quite sure what hat I'm wearing here. I don't think I have=20 > > formally received by "chair" hat. I guess I would be=20 > wearing my chair=20 > > hat if I had one.] > > > > sipcore would *not* be the right place to do such an info package. > > (Most likely it will never be the place to do *any* info package.) > > > > mmusic does sound like a plausible place to do it. But of=20 > course they=20 > > would have to agree. > > > > Thanks, > > Paul > > > > Peter Musgrave wrote: > >> Hi, > >> I am finding the INFO event draft helpful (and have it in=20 > my code for=20 > >> my 'vendor specific' needs). > >> > >> Is there interest in defining an INFO package for picture fast=20 > >> updates for a video stream as per RFC5168? > >> > >> I am currently not aware of a standard mechanism to see if an=20 > >> endpoint will originate or accept such INFOs (although a number of=20 > >> implementations do). Currently I am 'guessing'. > >> > >> Would such a definition be done in sipcore or as part of=20 > mmusic (the=20 > >> originators of RFC). > >> > >> Regards, > >> Peter Musgrave > >> > >> > >>=20 > --------------------------------------------------------------------- > >> --- > >> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From dean.willis@softarmor.com Mon Mar 15 16:29:37 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DF4F3A6811 for ; Mon, 15 Mar 2010 16:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.459 X-Spam-Level: X-Spam-Status: No, score=-2.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 ExvO2UJSs1xl for ; Mon, 15 Mar 2010 16:29:34 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 88EE63A6C04 for ; Mon, 15 Mar 2010 16:29:30 -0700 (PDT) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2FNTXk1029473 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 15 Mar 2010 18:29:34 -0500 Message-Id: <494EFA17-16C9-46D5-8367-E50EBF8CC641@softarmor.com> From: Dean Willis To: Gonzalo Camarillo In-Reply-To: <4B9E6FF7.6070006@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 15 Mar 2010 18:29:27 -0500 References: <8e5ec72f1003140846k313f008fk83980d92fd699351@mail.gmail.com> <4B9E6FF7.6070006@ericsson.com> X-Mailer: Apple Mail (2.936) Cc: "gao.yang2@zte.com.cn" , "sipcore@ietf.org" , Peter Musgrave Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 23:29:37 -0000 On Mar 15, 2010, at 12:35 PM, Gonzalo Camarillo wrote: > Hi Peter, > > those 200 (OK) responses do not carry answers because of one of the > main > rules of the offer/answer model. That is, the UAS only provides one > answer to a given offer. In the cases you are pointing to, the answer > was provided in a reliable provisional response. > There was, IIRC, some discussion on that, with my position being that the 200 OK SHOULD have a copy (and if present, it MUST be an identical copy!) of the answer provided in the reliable provisional response. My goal here is that this makes certain debugging scenarios easier. It also makes these hideous call flows more palatable to my brain, which along with refusing to believe in the square root of negative one also seems to have trouble with reliable provisional media and the plethora of alternative O/A sattes that can result. However, I do believe that the consensus was as Gonzalo reports. -- Dean From pkyzivat@cisco.com Mon Mar 15 16:50:25 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F3E93A6862 for ; Mon, 15 Mar 2010 16:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.319 X-Spam-Level: X-Spam-Status: No, score=-10.319 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 WzkUE28QOuzo for ; Mon, 15 Mar 2010 16:50:24 -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 3557B3A6783 for ; Mon, 15 Mar 2010 16:50:24 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMNknktAZnwN/2dsb2JhbACacHOga5gxhHsE X-IronPort-AV: E=Sophos;i="4.49,646,1262563200"; d="scan'208";a="93073112" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 15 Mar 2010 23:50:31 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2FNoVAn017848; Mon, 15 Mar 2010 23:50:31 GMT Message-ID: <4B9EC7BA.7080906@cisco.com> Date: Mon, 15 Mar 2010 19:50:18 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Dean Willis References: <8e5ec72f1003140846k313f008fk83980d92fd699351@mail.gmail.com> <4B9E6FF7.6070006@ericsson.com> <494EFA17-16C9-46D5-8367-E50EBF8CC641@softarmor.com> In-Reply-To: <494EFA17-16C9-46D5-8367-E50EBF8CC641@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "gao.yang2@zte.com.cn" , "sipcore@ietf.org" , Peter Musgrave Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2010 23:50:25 -0000 [as individual] I differ slightly from Dean on this: - if the answer has been sent in a reliable provisional, it is not required, or expected, in the 2xx. - for backward compatibility, it MAY, be *repeated* in the 2xx, but this is not advised. The reason its not advised is that its presence there can only cause grief, not good. The only valid thing you can do if you receive it is ignore it. If you *use* it (i.e. switch to it) then you are going to be in a world of hurt if there has been more than one o/a exchange before the 2xx is sent. Specifically, in that case the only SDP that is permitted to appear in the 2xx is the *first* answer, which may well differ from the *last* answer that is to be used for the session. Thanks, Paul Dean Willis wrote: > > On Mar 15, 2010, at 12:35 PM, Gonzalo Camarillo wrote: > >> Hi Peter, >> >> those 200 (OK) responses do not carry answers because of one of the main >> rules of the offer/answer model. That is, the UAS only provides one >> answer to a given offer. In the cases you are pointing to, the answer >> was provided in a reliable provisional response. >> > > There was, IIRC, some discussion on that, with my position being that > the 200 OK SHOULD have a copy (and if present, it MUST be an identical > copy!) of the answer provided in the reliable provisional response. > > My goal here is that this makes certain debugging scenarios easier. It > also makes these hideous call flows more palatable to my brain, which > along with refusing to believe in the square root of negative one also > seems to have trouble with reliable provisional media and the plethora > of alternative O/A sattes that can result. > > However, I do believe that the consensus was as Gonzalo reports. > > -- > Dean > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From alexander.milinski@nsn.com Tue Mar 16 03:19:02 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C55023A695B for ; Tue, 16 Mar 2010 03:19:02 -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 fr1+Me8jSPeU for ; Tue, 16 Mar 2010 03:19:01 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id 854AF3A6924 for ; Tue, 16 Mar 2010 03:19:01 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o2GAJ1cY013735 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Mar 2010 11:19:01 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o2GAJ0OX015083; Tue, 16 Mar 2010 11:19:00 +0100 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Mar 2010 11:18:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Mar 2010 11:18:48 +0100 Message-ID: <3F4C11BC54A36642BFB5875D599F47BD027E51E3@DEMUEXC013.nsn-intra.net> In-Reply-To: <4B9EC7BA.7080906@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-03 Thread-Index: AcrEmlT42qUcGT5sSdeP3mmRHv9gFwAVzSJg References: <8e5ec72f1003140846k313f008fk83980d92fd699351@mail.gmail.com> <4B9E6FF7.6070006@ericsson.com><494EFA17-16C9-46D5-8367-E50EBF8CC641@softarmor.com> <4B9EC7BA.7080906@cisco.com> From: "Milinski, Alexander (NSN - DE/Munich)" To: "ext Paul Kyzivat" , "Dean Willis" X-OriginalArrivalTime: 16 Mar 2010 10:18:52.0617 (UTC) FILETIME=[13C33390:01CAC4F2] Cc: gao.yang2@zte.com.cn, sipcore@ietf.org, Peter Musgrave Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 10:19:02 -0000 Hi Paul, Dean, now I am confused (though I got used to the square root of -1 being i). Which RFC explains this repetition? Moreover, how is the repeated answer distingusished from a new offer (the previous o/a has been completed before), which should be answered in the ACK? Regards, Alex > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of ext Paul Kyzivat > Sent: Tuesday, March 16, 2010 12:50 AM > To: Dean Willis > Cc: gao.yang2@zte.com.cn; sipcore@ietf.org; Peter Musgrave > Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-03 >=20 > [as individual] >=20 > I differ slightly from Dean on this: >=20 > - if the answer has been sent in a reliable provisional, > it is not required, or expected, in the 2xx. >=20 > - for backward compatibility, it MAY, be *repeated* in > the 2xx, but this is not advised. >=20 > The reason its not advised is that its presence there can only cause=20 > grief, not good. The only valid thing you can do if you receive it is=20 > ignore it. If you *use* it (i.e. switch to it) then you are=20 > going to be=20 > in a world of hurt if there has been more than one o/a=20 > exchange before=20 > the 2xx is sent. Specifically, in that case the only SDP that is=20 > permitted to appear in the 2xx is the *first* answer, which may well=20 > differ from the *last* answer that is to be used for the session. >=20 > Thanks, > Paul >=20 > Dean Willis wrote: > >=20 > > On Mar 15, 2010, at 12:35 PM, Gonzalo Camarillo wrote: > >=20 > >> Hi Peter, > >> > >> those 200 (OK) responses do not carry answers because of=20 > one of the main > >> rules of the offer/answer model. That is, the UAS only provides one > >> answer to a given offer. In the cases you are pointing to,=20 > the answer > >> was provided in a reliable provisional response. > >> > >=20 > > There was, IIRC, some discussion on that, with my position=20 > being that=20 > > the 200 OK SHOULD have a copy (and if present, it MUST be=20 > an identical=20 > > copy!) of the answer provided in the reliable provisional response. > >=20 > > My goal here is that this makes certain debugging scenarios=20 > easier. It=20 > > also makes these hideous call flows more palatable to my=20 > brain, which=20 > > along with refusing to believe in the square root of=20 > negative one also=20 > > seems to have trouble with reliable provisional media and=20 > the plethora=20 > > of alternative O/A sattes that can result. > >=20 > > However, I do believe that the consensus was as Gonzalo reports. > >=20 > > --=20 > > Dean > >=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From peter.musgrave@magorcorp.com Tue Mar 16 04:00:26 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A5FE3A6850 for ; Tue, 16 Mar 2010 04:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.729 X-Spam-Level: X-Spam-Status: No, score=-1.729 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 l7WbWGXMQXSV for ; Tue, 16 Mar 2010 04:00:25 -0700 (PDT) Received: from mail-qy0-f202.google.com (mail-qy0-f202.google.com [209.85.221.202]) by core3.amsl.com (Postfix) with ESMTP id 0EC673A683A for ; Tue, 16 Mar 2010 04:00:24 -0700 (PDT) Received: by qyk40 with SMTP id 40so3496558qyk.23 for ; Tue, 16 Mar 2010 04:00:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.1.37 with SMTP id 37mr1964610qad.325.1268737226808; Tue, 16 Mar 2010 04:00:26 -0700 (PDT) In-Reply-To: <3F4C11BC54A36642BFB5875D599F47BD027E51E3@DEMUEXC013.nsn-intra.net> References: <8e5ec72f1003140846k313f008fk83980d92fd699351@mail.gmail.com> <4B9E6FF7.6070006@ericsson.com> <494EFA17-16C9-46D5-8367-E50EBF8CC641@softarmor.com> <4B9EC7BA.7080906@cisco.com> <3F4C11BC54A36642BFB5875D599F47BD027E51E3@DEMUEXC013.nsn-intra.net> Date: Tue, 16 Mar 2010 07:00:26 -0400 Message-ID: <8e5ec72f1003160400g65d19374q2a192c3e5f10c92b@mail.gmail.com> From: Peter Musgrave To: "Milinski, Alexander (NSN - DE/Munich)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: gao.yang2@zte.com.cn, sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 11:00:26 -0000 Hi all, I would assume a new offer in a 200 OK would be distinguished by increasing the sess-verssion in the o=3D line of the SDP. I do find the issue of repeating an SDP hard to pin down - after poking into 3261 and 3262...am I looking in the right places? Peter On Tue, Mar 16, 2010 at 6:18 AM, Milinski, Alexander (NSN - DE/Munich) wrote: > Hi Paul, Dean, > > now I am confused (though I got used to the square root of -1 being i). > > Which RFC explains this repetition? > > Moreover, how is the repeated answer distingusished from a new offer > (the previous o/a has been completed before), > which should be answered in the ACK? > > Regards, > Alex > > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of ext Paul Kyzivat >> Sent: Tuesday, March 16, 2010 12:50 AM >> To: Dean Willis >> Cc: gao.yang2@zte.com.cn; sipcore@ietf.org; Peter Musgrave >> Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-03 >> >> [as individual] >> >> I differ slightly from Dean on this: >> >> - if the answer has been sent in a reliable provisional, >> =A0 =A0it is not required, or expected, in the 2xx. >> >> - for backward compatibility, it MAY, be *repeated* in >> =A0 =A0the 2xx, but this is not advised. >> >> The reason its not advised is that its presence there can only cause >> grief, not good. The only valid thing you can do if you receive it is >> ignore it. If you *use* it (i.e. switch to it) then you are >> going to be >> in a world of hurt if there has been more than one o/a >> exchange before >> the 2xx is sent. Specifically, in that case the only SDP that is >> permitted to appear in the 2xx is the *first* answer, which may well >> differ from the *last* answer that is to be used for the session. >> >> =A0 =A0 =A0 Thanks, >> =A0 =A0 =A0 Paul >> >> Dean Willis wrote: >> > >> > On Mar 15, 2010, at 12:35 PM, Gonzalo Camarillo wrote: >> > >> >> Hi Peter, >> >> >> >> those 200 (OK) responses do not carry answers because of >> one of the main >> >> rules of the offer/answer model. That is, the UAS only provides one >> >> answer to a given offer. In the cases you are pointing to, >> the answer >> >> was provided in a reliable provisional response. >> >> >> > >> > There was, IIRC, some discussion on that, with my position >> being that >> > the 200 OK SHOULD have a copy (and if present, it MUST be >> an identical >> > copy!) of the answer provided in the reliable provisional response. >> > >> > My goal here is that this makes certain debugging scenarios >> easier. It >> > also makes these hideous call flows more palatable to my >> brain, which >> > along with refusing to believe in the square root of >> negative one also >> > seems to have trouble with reliable provisional media and >> the plethora >> > of alternative O/A sattes that can result. >> > >> > However, I do believe that the consensus was as Gonzalo reports. >> > >> > -- >> > Dean >> > >> > _______________________________________________ >> > sipcore mailing list >> > sipcore@ietf.org >> > https://www.ietf.org/mailman/listinfo/sipcore >> > >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > From thomas.belling@nsn.com Tue Mar 16 05:08:35 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A8803A6A43 for ; Tue, 16 Mar 2010 05:08:35 -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 0IUZbzrAg1zj for ; Tue, 16 Mar 2010 05:08:33 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by core3.amsl.com (Postfix) with ESMTP id DAEBF3A692F for ; Tue, 16 Mar 2010 05:08:29 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o2GC8a7E005476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 Mar 2010 13:08:36 +0100 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o2GC8VbB000808; Tue, 16 Mar 2010 13:08:35 +0100 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Mar 2010 13:08:30 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Mar 2010 13:04:41 +0100 Message-ID: <744A66DF31B5B34EA8B08BBD8187A722016575BA@DEMUEXC014.nsn-intra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-03 Thread-Index: AcrE9+uiBvYoO93lQ9SgE0Ol/kTrxQACPArr References: <8e5ec72f1003140846k313f008fk83980d92fd699351@mail.gmail.com><4B9E6FF7.6070006@ericsson.com><494EFA17-16C9-46D5-8367-E50EBF8CC641@softarmor.com><4B9EC7BA.7080906@cisco.com><3F4C11BC54A36642BFB5875D599F47BD027E51E3@DEMUEXC013.nsn-intra.net> <8e5ec72f1003160400g65d19374q2a192c3e5f10c92b@mail.gmail.com> From: "Belling, Thomas (NSN - DE/Munich)" To: "ext Peter Musgrave" , "Milinski, Alexander (NSN - DE/Munich)" X-OriginalArrivalTime: 16 Mar 2010 12:08:30.0648 (UTC) FILETIME=[64931380:01CAC501] Cc: gao.yang2@zte.com.cn, sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 12:08:35 -0000 Hi Peter, Alexander =20 > I do find the issue of repeating an SDP hard to pin down - after poking into 3261 and 3262...am I looking in the right places? Please read RFC 3261, Clause 13.2.1: =20 In this specification, offers and answers can only appear in INVITE requests and responses, and ACK. The usage of offers and answers is further restricted. For the initial INVITE transaction, the rules are: o The initial offer MUST be in either an INVITE or, if not there, in the first reliable non-failure message from the UAS back to the UAC. In this specification, that is the final 2xx response. o If the initial offer is in an INVITE, the answer MUST be in a reliable non-failure message from UAS back to UAC which is correlated to that INVITE. For this specification, that is only the final 2xx response to that INVITE. That same exact answer MAY also be placed in any provisional responses sent prior to the answer. The UAC MUST treat the first session description it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE. o If the initial offer is in the first reliable non-failure message from the UAS back to UAC, the answer MUST be in the acknowledgement for that message (in this specification, ACK for a 2xx response). o After having sent or received an answer to the first offer, the UAC MAY generate subsequent offers in requests based on rules specified for that method, but only if it has received answers to any previous offers, and has not sent any offers to which it hasn't gotten an answer. o Once the UAS has sent or received an answer to the initial offer, it MUST NOT generate subsequent offers in any responses to the initial INVITE. This means that a UAS based on this specification alone can never generate subsequent offers until completion of the initial transaction. =20 Regards, Thomas =20 ________________________________ Von: sipcore-bounces@ietf.org im Auftrag von ext Peter Musgrave Gesendet: Di 16.03.2010 12:00 An: Milinski, Alexander (NSN - DE/Munich) Cc: gao.yang2@zte.com.cn; sipcore@ietf.org Betreff: Re: [sipcore] draft-ietf-sipcore-reinvite-03 Hi all, I would assume a new offer in a 200 OK would be distinguished by increasing the sess-verssion in the o=3D line of the SDP. I do find the issue of repeating an SDP hard to pin down - after poking into 3261 and 3262...am I looking in the right places? Peter On Tue, Mar 16, 2010 at 6:18 AM, Milinski, Alexander (NSN - DE/Munich) wrote: > Hi Paul, Dean, > > now I am confused (though I got used to the square root of -1 being = i). > > Which RFC explains this repetition? > > Moreover, how is the repeated answer distingusished from a new offer > (the previous o/a has been completed before), > which should be answered in the ACK? > > Regards, > Alex > > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of ext Paul Kyzivat >> Sent: Tuesday, March 16, 2010 12:50 AM >> To: Dean Willis >> Cc: gao.yang2@zte.com.cn; sipcore@ietf.org; Peter Musgrave >> Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-03 >> >> [as individual] >> >> I differ slightly from Dean on this: >> >> - if the answer has been sent in a reliable provisional, >> it is not required, or expected, in the 2xx. >> >> - for backward compatibility, it MAY, be *repeated* in >> the 2xx, but this is not advised. >> >> The reason its not advised is that its presence there can only cause >> grief, not good. The only valid thing you can do if you receive it is >> ignore it. If you *use* it (i.e. switch to it) then you are >> going to be >> in a world of hurt if there has been more than one o/a >> exchange before >> the 2xx is sent. Specifically, in that case the only SDP that is >> permitted to appear in the 2xx is the *first* answer, which may well >> differ from the *last* answer that is to be used for the session. >> >> Thanks, >> Paul >> >> Dean Willis wrote: >> > >> > On Mar 15, 2010, at 12:35 PM, Gonzalo Camarillo wrote: >> > >> >> Hi Peter, >> >> >> >> those 200 (OK) responses do not carry answers because of >> one of the main >> >> rules of the offer/answer model. That is, the UAS only provides = one >> >> answer to a given offer. In the cases you are pointing to, >> the answer >> >> was provided in a reliable provisional response. >> >> >> > >> > There was, IIRC, some discussion on that, with my position >> being that >> > the 200 OK SHOULD have a copy (and if present, it MUST be >> an identical >> > copy!) of the answer provided in the reliable provisional response. >> > >> > My goal here is that this makes certain debugging scenarios >> easier. It >> > also makes these hideous call flows more palatable to my >> brain, which >> > along with refusing to believe in the square root of >> negative one also >> > seems to have trouble with reliable provisional media and >> the plethora >> > of alternative O/A sattes that can result. >> > >> > However, I do believe that the consensus was as Gonzalo reports. >> > >> > -- >> > Dean >> > >> > _______________________________________________ >> > sipcore mailing list >> > sipcore@ietf.org >> > https://www.ietf.org/mailman/listinfo/sipcore >> > >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From peter.musgrave@magorcorp.com Tue Mar 16 05:27:06 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8896C3A6A47 for ; Tue, 16 Mar 2010 05:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 0n1lfT4+BgI7 for ; Tue, 16 Mar 2010 05:27:05 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id E56383A6907 for ; Tue, 16 Mar 2010 05:27:02 -0700 (PDT) Received: by vws13 with SMTP id 13so393407vws.31 for ; Tue, 16 Mar 2010 05:27:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.122.74 with SMTP id k10mr2281915vcr.43.1268742426484; Tue, 16 Mar 2010 05:27:06 -0700 (PDT) In-Reply-To: <744A66DF31B5B34EA8B08BBD8187A722016575BA@DEMUEXC014.nsn-intra.net> References: <8e5ec72f1003140846k313f008fk83980d92fd699351@mail.gmail.com> <4B9E6FF7.6070006@ericsson.com> <494EFA17-16C9-46D5-8367-E50EBF8CC641@softarmor.com> <4B9EC7BA.7080906@cisco.com> <3F4C11BC54A36642BFB5875D599F47BD027E51E3@DEMUEXC013.nsn-intra.net> <8e5ec72f1003160400g65d19374q2a192c3e5f10c92b@mail.gmail.com> <744A66DF31B5B34EA8B08BBD8187A722016575BA@DEMUEXC014.nsn-intra.net> Date: Tue, 16 Mar 2010 08:27:06 -0400 Message-ID: <8e5ec72f1003160527k9dfb9ebw3ca6c9803887f2dd@mail.gmail.com> From: Peter Musgrave To: "Belling, Thomas (NSN - DE/Munich)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: gao.yang2@zte.com.cn, sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 12:27:06 -0000 Hi Thomas, Thanks for the reference. I was reading that part of the spec. but could not make my mind up about whether it forbids sending a copy of the SDP in the 200 (if a reliable response had been provided). The closest I came was the statement: The UAC MUST treat the first session description it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE. Which makes me think if this does happen it MUST be ignored. So that convinces me that it's not a good idea. I just didn't see any language saying it was forbidden. Perhaps it should have been. I think what makes this something I have to think/read carefully about is the lack of examples in PRACK/3262. Apologies to all if I am belabouring the point here. Peter On Tue, Mar 16, 2010 at 8:04 AM, Belling, Thomas (NSN - DE/Munich) wrote: > Hi Peter, Alexander > >> I do find the issue of repeating an SDP hard to pin down - after > poking into 3261 and 3262...am I looking in the right places? > > Please read RFC 3261, Clause 13.2.1: > > In this specification, offers and answers > =A0 can only appear in INVITE requests and responses, and ACK. =A0The usa= ge > =A0 of offers and answers is further restricted. =A0For the initial INVIT= E > =A0 transaction, the rules are: > =A0 =A0 =A0o =A0The initial offer MUST be in either an INVITE or, if not = there, > =A0 =A0 =A0 =A0 in the first reliable non-failure message from the UAS ba= ck to > =A0 =A0 =A0 =A0 the UAC. =A0In this specification, that is the final 2xx > =A0 =A0 =A0 =A0 response. > =A0 =A0 =A0o =A0If the initial offer is in an INVITE, the answer MUST be = in a > =A0 =A0 =A0 =A0 reliable non-failure message from UAS back to UAC which i= s > =A0 =A0 =A0 =A0 correlated to that INVITE. =A0For this specification, tha= t is > =A0 =A0 =A0 =A0 only the final 2xx response to that INVITE. =A0That same = exact > =A0 =A0 =A0 =A0 answer MAY also be placed in any provisional responses se= nt > =A0 =A0 =A0 =A0 prior to the answer. =A0The UAC MUST treat the first sess= ion > =A0 =A0 =A0 =A0 description it receives as the answer, and MUST ignore an= y > =A0 =A0 =A0 =A0 session descriptions in subsequent responses to the initi= al > =A0 =A0 =A0 =A0 INVITE. > =A0 =A0 =A0o =A0If the initial offer is in the first reliable non-failure > =A0 =A0 =A0 =A0 message from the UAS back to UAC, the answer MUST be in t= he > =A0 =A0 =A0 =A0 acknowledgement for that message (in this specification, = ACK > =A0 =A0 =A0 =A0 for a 2xx response). > =A0 =A0 =A0o =A0After having sent or received an answer to the first offe= r, the > =A0 =A0 =A0 =A0 UAC MAY generate subsequent offers in requests based on r= ules > =A0 =A0 =A0 =A0 specified for that method, but only if it has received an= swers > =A0 =A0 =A0 =A0 to any previous offers, and has not sent any offers to wh= ich it > =A0 =A0 =A0 =A0 hasn't gotten an answer. > =A0 =A0 =A0o =A0Once the UAS has sent or received an answer to the initia= l > =A0 =A0 =A0 =A0 offer, it MUST NOT generate subsequent offers in any resp= onses > =A0 =A0 =A0 =A0 to the initial INVITE. =A0This means that a UAS based on = this > =A0 =A0 =A0 =A0 specification alone can never generate subsequent offers = until > =A0 =A0 =A0 =A0 completion of the initial transaction. > > Regards, Thomas From gilad@voxisoft.com Tue Mar 16 05:33:14 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 602CC3A6A4F for ; Tue, 16 Mar 2010 05:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 mWGeWa3f65ou for ; Tue, 16 Mar 2010 05:33:13 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 0952D3A6A49 for ; Tue, 16 Mar 2010 05:33:12 -0700 (PDT) Received: by fxm5 with SMTP id 5so4505775fxm.29 for ; Tue, 16 Mar 2010 05:33:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.87.62.21 with SMTP id p21mr1936165fgk.15.1268742796278; Tue, 16 Mar 2010 05:33:16 -0700 (PDT) X-Originating-IP: [80.74.109.2] In-Reply-To: <8e5ec72f1003160527k9dfb9ebw3ca6c9803887f2dd@mail.gmail.com> References: <8e5ec72f1003140846k313f008fk83980d92fd699351@mail.gmail.com> <4B9E6FF7.6070006@ericsson.com> <494EFA17-16C9-46D5-8367-E50EBF8CC641@softarmor.com> <4B9EC7BA.7080906@cisco.com> <3F4C11BC54A36642BFB5875D599F47BD027E51E3@DEMUEXC013.nsn-intra.net> <8e5ec72f1003160400g65d19374q2a192c3e5f10c92b@mail.gmail.com> <744A66DF31B5B34EA8B08BBD8187A722016575BA@DEMUEXC014.nsn-intra.net> <8e5ec72f1003160527k9dfb9ebw3ca6c9803887f2dd@mail.gmail.com> From: Gilad Shaham Date: Tue, 16 Mar 2010 14:32:56 +0200 Message-ID: To: Peter Musgrave Content-Type: multipart/alternative; boundary=001485f7cbeeaefa860481ea3334 Cc: gao.yang2@zte.com.cn, sipcore@ietf.org, "Belling, Thomas \(NSN - DE/Munich\)" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 12:33:14 -0000 --001485f7cbeeaefa860481ea3334 Content-Type: text/plain; charset=ISO-8859-1 > Which makes me think if this does happen it MUST be ignored. So that > convinces me that it's not a good idea. I just didn't see any language > saying it was forbidden. Perhaps it should have been. I think what > makes this something I have to think/read carefully about is the lack > of examples in PRACK/3262. > > If you are looking for some offer answer usages in SIP you can also refer to http://tools.ietf.org/html/draft-ietf-sipping-sip-offeranswer In general, offer-answer has in practice many interop issues, so it's best to keep your implementation as permissive as possible in terms of what you expect to receive. --001485f7cbeeaefa860481ea3334 Content-Type: text/html; charset=ISO-8859-1

Which makes me think if this does happen it MUST be ignored. So that
convinces me that it's not a good idea. I just didn't see any language
saying it was forbidden. Perhaps it should have been. I think what
makes this something I have to think/read carefully about is the lack
of examples in PRACK/3262.


If you are looking for some offer answer usages in SIP you can also refer to http://tools.ietf.org/html/draft-ietf-sipping-sip-offeranswer

In general, offer-answer has in practice many interop issues, so it's best to keep your implementation as permissive as possible in terms of what you expect to receive.

--001485f7cbeeaefa860481ea3334-- From gao.yang2@zte.com.cn Tue Mar 16 06:06:39 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E78E3A689F for ; Tue, 16 Mar 2010 06:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.312 X-Spam-Level: X-Spam-Status: No, score=-93.312 tagged_above=-999 required=5 tests=[AWL=-2.011, BAYES_05=-1.11, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] 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 d62ktkJnlmWv for ; Tue, 16 Mar 2010 06:06:38 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id F23993A6A57 for ; Tue, 16 Mar 2010 06:06:35 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 314901727820181; Tue, 16 Mar 2010 21:06:28 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 84131.5501381973; Tue, 16 Mar 2010 20:55:34 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id o2GCvmVo032424; Tue, 16 Mar 2010 20:57:48 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <8e5ec72f1003160527k9dfb9ebw3ca6c9803887f2dd@mail.gmail.com> To: Peter Musgrave MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 16 Mar 2010 20:55:58 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-03-16 20:57:36, Serialize complete at 2010-03-16 20:57:36 Content-Type: multipart/alternative; boundary="=_alternative 00471AA7482576E8_=" X-MAIL: mse1.zte.com.cn o2GCvmVo032424 Cc: sipcore@ietf.org, "Belling, Thomas \(NSN - DE/Munich\)" Subject: [sipcore] =?gb2312?b?tPC4tDogUmU6ICBkcmFmdC1pZXRmLXNpcGNvcmUtcmVp?= =?gb2312?b?bnZpdGUtMDM=?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 13:06:39 -0000 This is a multipart message in MIME format. --=_alternative 00471AA7482576E8_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNCnBsZWFzZSBzZWUgaW5saW5lcy4NCg0KVGhhbmtzLA0KDQpHYW8gDQoNCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09DQogWmlwICAgIDogMjEwMDEyDQogVGVsICAgIDog ODcyMTENCiBUZWwyICAgOigrODYpLTAyNS01Mjg3NzIxMQ0KIGVfbWFpbCA6IGdhby55YW5nMkB6 dGUuY29tLmNuDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQoNCg0KUGV0 ZXIgTXVzZ3JhdmUgPHBldGVyLm11c2dyYXZlQG1hZ29yY29ycC5jb20+IA0KMjAxMC0wMy0xNiAy MDoyNw0KDQrK1bz+yMsNCiJCZWxsaW5nLCBUaG9tYXMgKE5TTiAtIERFL011bmljaCkiIDx0aG9t YXMuYmVsbGluZ0Buc24uY29tPg0Ks63LzQ0KIk1pbGluc2tpLCBBbGV4YW5kZXIgKE5TTiAtIERF L011bmljaCkiIDxhbGV4YW5kZXIubWlsaW5za2lAbnNuLmNvbT4sIA0KZ2FvLnlhbmcyQHp0ZS5j b20uY24sIHNpcGNvcmVAaWV0Zi5vcmcNCtb3zOINClJlOiBbc2lwY29yZV0gZHJhZnQtaWV0Zi1z aXBjb3JlLXJlaW52aXRlLTAzDQoNCg0KDQoNCg0KDQpIaSBUaG9tYXMsDQoNClRoYW5rcyBmb3Ig dGhlIHJlZmVyZW5jZS4gSSB3YXMgcmVhZGluZyB0aGF0IHBhcnQgb2YgdGhlIHNwZWMuIGJ1dA0K Y291bGQgbm90IG1ha2UgbXkgbWluZCB1cCBhYm91dCB3aGV0aGVyIGl0IGZvcmJpZHMgc2VuZGlu ZyBhIGNvcHkgb2YNCnRoZSBTRFAgaW4gdGhlIDIwMCAoaWYgYSByZWxpYWJsZSByZXNwb25zZSBo YWQgYmVlbiBwcm92aWRlZCkuIA0KDQpbR2FvXSBSRkMzMjYxIGhhcyBzdWNoIGRlZmluaXRpb246 DQpvICBPbmNlIHRoZSBVQVMgaGFzIHNlbnQgb3IgcmVjZWl2ZWQgYW4gYW5zd2VyIHRvIHRoZSBp bml0aWFsDQogICAgICAgICBvZmZlciwgaXQgTVVTVCBOT1QgZ2VuZXJhdGUgc3Vic2VxdWVudCBv ZmZlcnMgaW4gYW55IHJlc3BvbnNlcw0KICAgICAgICAgdG8gdGhlIGluaXRpYWwgSU5WSVRFLiAN Cg0KSSB0aGluayB0aGlzIGlzIHRoZSBkZWZpbml0aW9uIHlvdSBhcmUgc2Vla2luZy4NCg0KLy8v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLw0K VGhlDQpjbG9zZXN0IEkgY2FtZSB3YXMgdGhlIHN0YXRlbWVudDoNCg0KVGhlIFVBQyBNVVNUIHRy ZWF0IHRoZSBmaXJzdCBzZXNzaW9uDQogICAgICAgIGRlc2NyaXB0aW9uIGl0IHJlY2VpdmVzIGFz IHRoZSBhbnN3ZXIsIGFuZCBNVVNUIGlnbm9yZSBhbnkNCiAgICAgICAgc2Vzc2lvbiBkZXNjcmlw dGlvbnMgaW4gc3Vic2VxdWVudCByZXNwb25zZXMgdG8gdGhlIGluaXRpYWwNCiAgICAgICAgSU5W SVRFLg0KDQpXaGljaCBtYWtlcyBtZSB0aGluayBpZiB0aGlzIGRvZXMgaGFwcGVuIGl0IE1VU1Qg YmUgaWdub3JlZC4gU28gdGhhdA0KY29udmluY2VzIG1lIHRoYXQgaXQncyBub3QgYSBnb29kIGlk ZWEuIEkganVzdCBkaWRuJ3Qgc2VlIGFueSBsYW5ndWFnZQ0Kc2F5aW5nIGl0IHdhcyBmb3JiaWRk ZW4uIFBlcmhhcHMgaXQgc2hvdWxkIGhhdmUgYmVlbi4gSSB0aGluayB3aGF0DQptYWtlcyB0aGlz IHNvbWV0aGluZyBJIGhhdmUgdG8gdGhpbmsvcmVhZCBjYXJlZnVsbHkgYWJvdXQgaXMgdGhlIGxh Y2sNCm9mIGV4YW1wbGVzIGluIFBSQUNLLzMyNjIuDQoNCkFwb2xvZ2llcyB0byBhbGwgaWYgSSBh bSBiZWxhYm91cmluZyB0aGUgcG9pbnQgaGVyZS4NCg0KUGV0ZXINCg0KT24gVHVlLCBNYXIgMTYs IDIwMTAgYXQgODowNCBBTSwgQmVsbGluZywgVGhvbWFzIChOU04gLSBERS9NdW5pY2gpDQo8dGhv bWFzLmJlbGxpbmdAbnNuLmNvbT4gd3JvdGU6DQo+IEhpIFBldGVyLCBBbGV4YW5kZXINCj4NCj4+ IEkgZG8gZmluZCB0aGUgaXNzdWUgb2YgcmVwZWF0aW5nIGFuIFNEUCBoYXJkIHRvIHBpbiBkb3du IC0gYWZ0ZXINCj4gcG9raW5nIGludG8gMzI2MSBhbmQgMzI2Mi4uLmFtIEkgbG9va2luZyBpbiB0 aGUgcmlnaHQgcGxhY2VzPw0KPg0KPiBQbGVhc2UgcmVhZCBSRkMgMzI2MSwgQ2xhdXNlIDEzLjIu MToNCj4NCj4gSW4gdGhpcyBzcGVjaWZpY2F0aW9uLCBvZmZlcnMgYW5kIGFuc3dlcnMNCj4gICBj YW4gb25seSBhcHBlYXIgaW4gSU5WSVRFIHJlcXVlc3RzIGFuZCByZXNwb25zZXMsIGFuZCBBQ0su ICBUaGUgdXNhZ2UNCj4gICBvZiBvZmZlcnMgYW5kIGFuc3dlcnMgaXMgZnVydGhlciByZXN0cmlj dGVkLiAgRm9yIHRoZSBpbml0aWFsIElOVklURQ0KPiAgIHRyYW5zYWN0aW9uLCB0aGUgcnVsZXMg YXJlOg0KPiAgICAgIG8gIFRoZSBpbml0aWFsIG9mZmVyIE1VU1QgYmUgaW4gZWl0aGVyIGFuIElO VklURSBvciwgaWYgbm90IHRoZXJlLA0KPiAgICAgICAgIGluIHRoZSBmaXJzdCByZWxpYWJsZSBu b24tZmFpbHVyZSBtZXNzYWdlIGZyb20gdGhlIFVBUyBiYWNrIHRvDQo+ICAgICAgICAgdGhlIFVB Qy4gIEluIHRoaXMgc3BlY2lmaWNhdGlvbiwgdGhhdCBpcyB0aGUgZmluYWwgMnh4DQo+ICAgICAg ICAgcmVzcG9uc2UuDQo+ICAgICAgbyAgSWYgdGhlIGluaXRpYWwgb2ZmZXIgaXMgaW4gYW4gSU5W SVRFLCB0aGUgYW5zd2VyIE1VU1QgYmUgaW4gYQ0KPiAgICAgICAgIHJlbGlhYmxlIG5vbi1mYWls dXJlIG1lc3NhZ2UgZnJvbSBVQVMgYmFjayB0byBVQUMgd2hpY2ggaXMNCj4gICAgICAgICBjb3Jy ZWxhdGVkIHRvIHRoYXQgSU5WSVRFLiAgRm9yIHRoaXMgc3BlY2lmaWNhdGlvbiwgdGhhdCBpcw0K PiAgICAgICAgIG9ubHkgdGhlIGZpbmFsIDJ4eCByZXNwb25zZSB0byB0aGF0IElOVklURS4gIFRo YXQgc2FtZSBleGFjdA0KPiAgICAgICAgIGFuc3dlciBNQVkgYWxzbyBiZSBwbGFjZWQgaW4gYW55 IHByb3Zpc2lvbmFsIHJlc3BvbnNlcyBzZW50DQo+ICAgICAgICAgcHJpb3IgdG8gdGhlIGFuc3dl ci4gIFRoZSBVQUMgTVVTVCB0cmVhdCB0aGUgZmlyc3Qgc2Vzc2lvbg0KPiAgICAgICAgIGRlc2Ny aXB0aW9uIGl0IHJlY2VpdmVzIGFzIHRoZSBhbnN3ZXIsIGFuZCBNVVNUIGlnbm9yZSBhbnkNCj4g ICAgICAgICBzZXNzaW9uIGRlc2NyaXB0aW9ucyBpbiBzdWJzZXF1ZW50IHJlc3BvbnNlcyB0byB0 aGUgaW5pdGlhbA0KPiAgICAgICAgIElOVklURS4NCj4gICAgICBvICBJZiB0aGUgaW5pdGlhbCBv ZmZlciBpcyBpbiB0aGUgZmlyc3QgcmVsaWFibGUgbm9uLWZhaWx1cmUNCj4gICAgICAgICBtZXNz YWdlIGZyb20gdGhlIFVBUyBiYWNrIHRvIFVBQywgdGhlIGFuc3dlciBNVVNUIGJlIGluIHRoZQ0K PiAgICAgICAgIGFja25vd2xlZGdlbWVudCBmb3IgdGhhdCBtZXNzYWdlIChpbiB0aGlzIHNwZWNp ZmljYXRpb24sIEFDSw0KPiAgICAgICAgIGZvciBhIDJ4eCByZXNwb25zZSkuDQo+ICAgICAgbyAg QWZ0ZXIgaGF2aW5nIHNlbnQgb3IgcmVjZWl2ZWQgYW4gYW5zd2VyIHRvIHRoZSBmaXJzdCBvZmZl ciwgdGhlDQo+ICAgICAgICAgVUFDIE1BWSBnZW5lcmF0ZSBzdWJzZXF1ZW50IG9mZmVycyBpbiBy ZXF1ZXN0cyBiYXNlZCBvbiBydWxlcw0KPiAgICAgICAgIHNwZWNpZmllZCBmb3IgdGhhdCBtZXRo b2QsIGJ1dCBvbmx5IGlmIGl0IGhhcyByZWNlaXZlZCBhbnN3ZXJzDQo+ICAgICAgICAgdG8gYW55 IHByZXZpb3VzIG9mZmVycywgYW5kIGhhcyBub3Qgc2VudCBhbnkgb2ZmZXJzIHRvIHdoaWNoIGl0 DQo+ICAgICAgICAgaGFzbid0IGdvdHRlbiBhbiBhbnN3ZXIuDQo+ICAgICAgbyAgT25jZSB0aGUg VUFTIGhhcyBzZW50IG9yIHJlY2VpdmVkIGFuIGFuc3dlciB0byB0aGUgaW5pdGlhbA0KPiAgICAg ICAgIG9mZmVyLCBpdCBNVVNUIE5PVCBnZW5lcmF0ZSBzdWJzZXF1ZW50IG9mZmVycyBpbiBhbnkg cmVzcG9uc2VzDQo+ICAgICAgICAgdG8gdGhlIGluaXRpYWwgSU5WSVRFLiAgVGhpcyBtZWFucyB0 aGF0IGEgVUFTIGJhc2VkIG9uIHRoaXMNCj4gICAgICAgICBzcGVjaWZpY2F0aW9uIGFsb25lIGNh biBuZXZlciBnZW5lcmF0ZSBzdWJzZXF1ZW50IG9mZmVycyB1bnRpbA0KPiAgICAgICAgIGNvbXBs ZXRpb24gb2YgdGhlIGluaXRpYWwgdHJhbnNhY3Rpb24uDQo+DQo+IFJlZ2FyZHMsIFRob21hcw0K DQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRl cidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFs LiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVj eSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMg Y29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNt aXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRo ZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVz c2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3Rp ZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4g dGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1l c3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1T cGFtIHN5c3RlbS4NCg== --=_alternative 00471AA7482576E8_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5IaSw8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5wbGVhc2Ugc2VlIGlubGluZXMuPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+VGhhbmtzLDwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPkdhbyA8L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KIFppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8 YnI+DQogVGVsICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0KIFRlbDIgJm5ic3A7IDooKzg2KS0w MjUtNTI4NzcyMTE8YnI+DQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvZm9udD4NCjxicj4NCjxicj4NCjxicj4N Cjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MjYlPjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5QZXRlciBNdXNncmF2ZSAmbHQ7cGV0ZXIubXVz Z3JhdmVAbWFnb3Jjb3JwLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+MjAxMC0wMy0xNiAyMDoyNzwvZm9udD4NCjx0ZCB3aWR0aD03MyU+DQo8 dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRk Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtCZWxsaW5nLCBUaG9tYXMgKE5T TiAtIERFL011bmljaCkmcXVvdDsNCiZsdDt0aG9tYXMuYmVsbGluZ0Buc24uY29tJmd0OzwvZm9u dD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+JnF1b3Q7TWlsaW5za2ksIEFsZXhhbmRlciAoTlNOIC0gREUvTXVuaWNo KSZxdW90Ow0KJmx0O2FsZXhhbmRlci5taWxpbnNraUBuc24uY29tJmd0OywgZ2FvLnlhbmcyQHp0 ZS5jb20uY24sIHNpcGNvcmVAaWV0Zi5vcmc8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4N CjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2Zv bnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbc2lwY29y ZV0gZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRlLTAzPC9mb250PjwvdGFibGU+DQo8YnI+DQo8 dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+ DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5IaSBUaG9tYXMsPGJyPg0KPGJyPg0K VGhhbmtzIGZvciB0aGUgcmVmZXJlbmNlLiBJIHdhcyByZWFkaW5nIHRoYXQgcGFydCBvZiB0aGUg c3BlYy4gYnV0PGJyPg0KY291bGQgbm90IG1ha2UgbXkgbWluZCB1cCBhYm91dCB3aGV0aGVyIGl0 IGZvcmJpZHMgc2VuZGluZyBhIGNvcHkgb2Y8YnI+DQp0aGUgU0RQIGluIHRoZSAyMDAgKGlmIGEg cmVsaWFibGUgcmVzcG9uc2UgaGFkIGJlZW4gcHJvdmlkZWQpLiA8L2ZvbnQ+PC90dD4NCjxicj4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPltHYW9dIFJGQzMyNjEgaGFzIHN1Y2ggZGVmaW5pdGlvbjo8 L2ZvbnQ+PC90dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPm8gJm5ic3A7 PGI+T25jZTwvYj4gdGhlIDxiPlVBUyBoYXMNCnNlbnQ8L2I+IG9yIHJlY2VpdmVkIGFuIDxiPmFu c3dlciB0byB0aGUgaW5pdGlhbDwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNv dXJpZXIgTmV3Ij48Yj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7b2ZmZXI8L2I+ LA0KaXQgPGI+TVVTVCBOT1Q8L2I+IGdlbmVyYXRlIDxiPnN1YnNlcXVlbnQgb2ZmZXJzPC9iPiBp biA8Yj5hbnkgcmVzcG9uc2VzPC9iPjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291 cmllciBOZXciPjxiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt0bw0KdGhlIGlu aXRpYWwgSU5WSVRFPC9iPi4gPC9mb250Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SSB0 aGluayB0aGlzIGlzIHRoZSBkZWZpbml0aW9uIHlvdSBhcmUgc2Vla2luZy48L2ZvbnQ+PC90dD4N Cjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPi8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy88L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPlRoZTxicj4NCmNsb3Nlc3QgSSBjYW1lIHdhcyB0aGUgc3RhdGVtZW50Ojxicj4NCjxi cj4NClRoZSBVQUMgTVVTVCB0cmVhdCB0aGUgZmlyc3Qgc2Vzc2lvbjxicj4NCiAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtkZXNjcmlwdGlvbiBpdCByZWNlaXZlcyBhcyB0aGUgYW5zd2VyLCBh bmQNCk1VU1QgaWdub3JlIGFueTxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzZXNz aW9uIGRlc2NyaXB0aW9ucyBpbiBzdWJzZXF1ZW50IHJlc3BvbnNlcw0KdG8gdGhlIGluaXRpYWw8 YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7SU5WSVRFLjxicj4NCjxicj4NCldoaWNo IG1ha2VzIG1lIHRoaW5rIGlmIHRoaXMgZG9lcyBoYXBwZW4gaXQgTVVTVCBiZSBpZ25vcmVkLiBT byB0aGF0PGJyPg0KY29udmluY2VzIG1lIHRoYXQgaXQncyBub3QgYSBnb29kIGlkZWEuIEkganVz dCBkaWRuJ3Qgc2VlIGFueSBsYW5ndWFnZTxicj4NCnNheWluZyBpdCB3YXMgZm9yYmlkZGVuLiBQ ZXJoYXBzIGl0IHNob3VsZCBoYXZlIGJlZW4uIEkgdGhpbmsgd2hhdDxicj4NCm1ha2VzIHRoaXMg c29tZXRoaW5nIEkgaGF2ZSB0byB0aGluay9yZWFkIGNhcmVmdWxseSBhYm91dCBpcyB0aGUgbGFj azxicj4NCm9mIGV4YW1wbGVzIGluIFBSQUNLLzMyNjIuPGJyPg0KPGJyPg0KQXBvbG9naWVzIHRv IGFsbCBpZiBJIGFtIGJlbGFib3VyaW5nIHRoZSBwb2ludCBoZXJlLjxicj4NCjxicj4NClBldGVy PGJyPg0KPGJyPg0KT24gVHVlLCBNYXIgMTYsIDIwMTAgYXQgODowNCBBTSwgQmVsbGluZywgVGhv bWFzIChOU04gLSBERS9NdW5pY2gpPGJyPg0KJmx0O3Rob21hcy5iZWxsaW5nQG5zbi5jb20mZ3Q7 IHdyb3RlOjxicj4NCiZndDsgSGkgUGV0ZXIsIEFsZXhhbmRlcjxicj4NCiZndDs8YnI+DQomZ3Q7 Jmd0OyBJIGRvIGZpbmQgdGhlIGlzc3VlIG9mIHJlcGVhdGluZyBhbiBTRFAgaGFyZCB0byBwaW4g ZG93biAtIGFmdGVyPGJyPg0KJmd0OyBwb2tpbmcgaW50byAzMjYxIGFuZCAzMjYyLi4uYW0gSSBs b29raW5nIGluIHRoZSByaWdodCBwbGFjZXM/PGJyPg0KJmd0Ozxicj4NCiZndDsgUGxlYXNlIHJl YWQgUkZDIDMyNjEsIENsYXVzZSAxMy4yLjE6PGJyPg0KJmd0Ozxicj4NCiZndDsgSW4gdGhpcyBz cGVjaWZpY2F0aW9uLCBvZmZlcnMgYW5kIGFuc3dlcnM8YnI+DQomZ3Q7ICZuYnNwOyBjYW4gb25s eSBhcHBlYXIgaW4gSU5WSVRFIHJlcXVlc3RzIGFuZCByZXNwb25zZXMsIGFuZCBBQ0suDQombmJz cDtUaGUgdXNhZ2U8YnI+DQomZ3Q7ICZuYnNwOyBvZiBvZmZlcnMgYW5kIGFuc3dlcnMgaXMgZnVy dGhlciByZXN0cmljdGVkLiAmbmJzcDtGb3IgdGhlDQppbml0aWFsIElOVklURTxicj4NCiZndDsg Jm5ic3A7IHRyYW5zYWN0aW9uLCB0aGUgcnVsZXMgYXJlOjxicj4NCiZndDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtvICZuYnNwO1RoZSBpbml0aWFsIG9mZmVyIE1VU1QgYmUgaW4gZWl0aGVyIGFuDQpJ TlZJVEUgb3IsIGlmIG5vdCB0aGVyZSw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBpbiB0aGUgZmlyc3QgcmVsaWFibGUgbm9uLWZhaWx1cmUgbWVzc2FnZQ0KZnJvbSB0aGUg VUFTIGJhY2sgdG88YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0aGUgVUFD LiAmbmJzcDtJbiB0aGlzIHNwZWNpZmljYXRpb24sDQp0aGF0IGlzIHRoZSBmaW5hbCAyeHg8YnI+ DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyByZXNwb25zZS48YnI+DQomZ3Q7ICZu YnNwOyAmbmJzcDsgJm5ic3A7byAmbmJzcDtJZiB0aGUgaW5pdGlhbCBvZmZlciBpcyBpbiBhbiBJ TlZJVEUsDQp0aGUgYW5zd2VyIE1VU1QgYmUgaW4gYTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IHJlbGlhYmxlIG5vbi1mYWlsdXJlIG1lc3NhZ2UgZnJvbSBVQVMNCmJhY2sg dG8gVUFDIHdoaWNoIGlzPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgY29y cmVsYXRlZCB0byB0aGF0IElOVklURS4gJm5ic3A7Rm9yIHRoaXMNCnNwZWNpZmljYXRpb24sIHRo YXQgaXM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBvbmx5IHRoZSBmaW5h bCAyeHggcmVzcG9uc2UgdG8gdGhhdCBJTlZJVEUuDQombmJzcDtUaGF0IHNhbWUgZXhhY3Q8YnI+ DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBhbnN3ZXIgTUFZIGFsc28gYmUgcGxh Y2VkIGluIGFueSBwcm92aXNpb25hbA0KcmVzcG9uc2VzIHNlbnQ8YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBwcmlvciB0byB0aGUgYW5zd2VyLiAmbmJzcDtUaGUgVUFDIE1V U1QNCnRyZWF0IHRoZSBmaXJzdCBzZXNzaW9uPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgZGVzY3JpcHRpb24gaXQgcmVjZWl2ZXMgYXMgdGhlIGFuc3dlciwNCmFuZCBNVVNU IGlnbm9yZSBhbnk8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzZXNzaW9u IGRlc2NyaXB0aW9ucyBpbiBzdWJzZXF1ZW50IHJlc3BvbnNlcw0KdG8gdGhlIGluaXRpYWw8YnI+ DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJTlZJVEUuPGJyPg0KJmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwO28gJm5ic3A7SWYgdGhlIGluaXRpYWwgb2ZmZXIgaXMgaW4gdGhlIGZp cnN0IHJlbGlhYmxlDQpub24tZmFpbHVyZTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IG1lc3NhZ2UgZnJvbSB0aGUgVUFTIGJhY2sgdG8gVUFDLCB0aGUNCmFuc3dlciBNVVNU IGJlIGluIHRoZTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGFja25vd2xl ZGdlbWVudCBmb3IgdGhhdCBtZXNzYWdlIChpbiB0aGlzDQpzcGVjaWZpY2F0aW9uLCBBQ0s8YnI+ DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBmb3IgYSAyeHggcmVzcG9uc2UpLjxi cj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtvICZuYnNwO0FmdGVyIGhhdmluZyBzZW50IG9y IHJlY2VpdmVkIGFuIGFuc3dlcg0KdG8gdGhlIGZpcnN0IG9mZmVyLCB0aGU8YnI+DQomZ3Q7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBVQUMgTUFZIGdlbmVyYXRlIHN1YnNlcXVlbnQgb2Zm ZXJzIGluDQpyZXF1ZXN0cyBiYXNlZCBvbiBydWxlczxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IHNwZWNpZmllZCBmb3IgdGhhdCBtZXRob2QsIGJ1dCBvbmx5IGlmDQppdCBo YXMgcmVjZWl2ZWQgYW5zd2Vyczxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IHRvIGFueSBwcmV2aW91cyBvZmZlcnMsIGFuZCBoYXMgbm90IHNlbnQNCmFueSBvZmZlcnMgdG8g d2hpY2ggaXQ8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBoYXNuJ3QgZ290 dGVuIGFuIGFuc3dlci48YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7byAmbmJzcDtPbmNl IHRoZSBVQVMgaGFzIHNlbnQgb3IgcmVjZWl2ZWQgYW4gYW5zd2VyDQp0byB0aGUgaW5pdGlhbDxi cj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG9mZmVyLCBpdCBNVVNUIE5PVCBn ZW5lcmF0ZSBzdWJzZXF1ZW50DQpvZmZlcnMgaW4gYW55IHJlc3BvbnNlczxicj4NCiZndDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHRvIHRoZSBpbml0aWFsIElOVklURS4gJm5ic3A7VGhp cyBtZWFucw0KdGhhdCBhIFVBUyBiYXNlZCBvbiB0aGlzPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgc3BlY2lmaWNhdGlvbiBhbG9uZSBjYW4gbmV2ZXIgZ2VuZXJhdGUNCnN1 YnNlcXVlbnQgb2ZmZXJzIHVudGlsPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgY29tcGxldGlvbiBvZiB0aGUgaW5pdGlhbCB0cmFuc2FjdGlvbi48YnI+DQomZ3Q7PGJyPg0K Jmd0OyBSZWdhcmRzLCBUaG9tYXM8YnI+DQo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48 cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5i c3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMm bmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7 dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwm bmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBp ZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0 byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZu YnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50 cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVy cy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJh bnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJz cDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3Vz ZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5i c3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJ ZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZu YnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtv cmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3Zp ZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2Fy ZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVy Lg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNw O2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJz cDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 00471AA7482576E8_=-- From pkyzivat@cisco.com Tue Mar 16 06:27:06 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2131A3A6860 for ; Tue, 16 Mar 2010 06:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.329 X-Spam-Level: X-Spam-Status: No, score=-10.329 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 FKkJNYhXylEb for ; Tue, 16 Mar 2010 06:27:05 -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 DBD403A6816 for ; Tue, 16 Mar 2010 06:27:04 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMYjn0tAZnwN/2dsb2JhbACafnOfUZhvhHwE X-IronPort-AV: E=Sophos;i="4.49,650,1262563200"; d="scan'208";a="93320281" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 16 Mar 2010 13:27:11 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2GDRAth015209; Tue, 16 Mar 2010 13:27:10 GMT Message-ID: <4B9F872E.8010101@cisco.com> Date: Tue, 16 Mar 2010 09:27:10 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Peter Musgrave References: <8e5ec72f1003140846k313f008fk83980d92fd699351@mail.gmail.com> <4B9E6FF7.6070006@ericsson.com> <494EFA17-16C9-46D5-8367-E50EBF8CC641@softarmor.com> <4B9EC7BA.7080906@cisco.com> <3F4C11BC54A36642BFB5875D599F47BD027E51E3@DEMUEXC013.nsn-intra.net> <8e5ec72f1003160400g65d19374q2a192c3e5f10c92b@mail.gmail.com> <744A66DF31B5B34EA8B08BBD8187A722016575BA@DEMUEXC014.nsn-intra.net> <8e5ec72f1003160527k9dfb9ebw3ca6c9803887f2dd@mail.gmail.com> In-Reply-To: <8e5ec72f1003160527k9dfb9ebw3ca6c9803887f2dd@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gao.yang2@zte.com.cn, sipcore@ietf.org, "Belling, Thomas \(NSN - DE/Munich\)" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 13:27:06 -0000 Peter Musgrave wrote: > Hi Thomas, > > Thanks for the reference. I was reading that part of the spec. but > could not make my mind up about whether it forbids sending a copy of > the SDP in the 200 (if a reliable response had been provided). The > closest I came was the statement: > > The UAC MUST treat the first session > description it receives as the answer, and MUST ignore any > session descriptions in subsequent responses to the initial > INVITE. > Which makes me think if this does happen it MUST be ignored. So that > convinces me that it's not a good idea. I just didn't see any language > saying it was forbidden. Perhaps it should have been. I think what > makes this something I have to think/read carefully about is the lack > of examples in PRACK/3262. The language is not very clear, and can only be discerned in total by integrating across several RFCs and making various inferences. This led to a very long email discussion/debate on the subject several years ago. That in turn led to the writing of the offeranswer draft, which attempts to capture all that. We have concluded that it is all just clarification, rather than normative changes. > Apologies to all if I am belabouring the point here. Don't feel too bad - it comes up every few months. If you haven't, please read the offeranswer draft: http://www.ietf.org/id/draft-ietf-sipping-sip-offeranswer-12.txt Thanks, Paul > Peter > > On Tue, Mar 16, 2010 at 8:04 AM, Belling, Thomas (NSN - DE/Munich) > wrote: >> Hi Peter, Alexander >> >>> I do find the issue of repeating an SDP hard to pin down - after >> poking into 3261 and 3262...am I looking in the right places? >> >> Please read RFC 3261, Clause 13.2.1: >> >> In this specification, offers and answers >> can only appear in INVITE requests and responses, and ACK. The usage >> of offers and answers is further restricted. For the initial INVITE >> transaction, the rules are: >> o The initial offer MUST be in either an INVITE or, if not there, >> in the first reliable non-failure message from the UAS back to >> the UAC. In this specification, that is the final 2xx >> response. >> o If the initial offer is in an INVITE, the answer MUST be in a >> reliable non-failure message from UAS back to UAC which is >> correlated to that INVITE. For this specification, that is >> only the final 2xx response to that INVITE. That same exact >> answer MAY also be placed in any provisional responses sent >> prior to the answer. The UAC MUST treat the first session >> description it receives as the answer, and MUST ignore any >> session descriptions in subsequent responses to the initial >> INVITE. >> o If the initial offer is in the first reliable non-failure >> message from the UAS back to UAC, the answer MUST be in the >> acknowledgement for that message (in this specification, ACK >> for a 2xx response). >> o After having sent or received an answer to the first offer, the >> UAC MAY generate subsequent offers in requests based on rules >> specified for that method, but only if it has received answers >> to any previous offers, and has not sent any offers to which it >> hasn't gotten an answer. >> o Once the UAS has sent or received an answer to the initial >> offer, it MUST NOT generate subsequent offers in any responses >> to the initial INVITE. This means that a UAS based on this >> specification alone can never generate subsequent offers until >> completion of the initial transaction. >> >> Regards, Thomas > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@cisco.com Tue Mar 16 06:30:03 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FB683A6860 for ; Tue, 16 Mar 2010 06:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.339 X-Spam-Level: X-Spam-Status: No, score=-10.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 wJWj1Zuv2cju for ; Tue, 16 Mar 2010 06:30:02 -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 8C1633A6816 for ; Tue, 16 Mar 2010 06:30:02 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAkln0tAZnwM/2dsb2JhbACafnOfaph0hHwE X-IronPort-AV: E=Sophos;i="4.49,650,1262563200"; d="scan'208";a="93321292" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 16 Mar 2010 13:30:10 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2GDUAnh015349; Tue, 16 Mar 2010 13:30:10 GMT Message-ID: <4B9F87E2.2030600@cisco.com> Date: Tue, 16 Mar 2010 09:30:10 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: Peter Musgrave References: <8e5ec72f1003140846k313f008fk83980d92fd699351@mail.gmail.com> <4B9E6FF7.6070006@ericsson.com> <494EFA17-16C9-46D5-8367-E50EBF8CC641@softarmor.com> <4B9EC7BA.7080906@cisco.com> <3F4C11BC54A36642BFB5875D599F47BD027E51E3@DEMUEXC013.nsn-intra.net> <8e5ec72f1003160400g65d19374q2a192c3e5f10c92b@mail.gmail.com> <744A66DF31B5B34EA8B08BBD8187A722016575BA@DEMUEXC014.nsn-intra.net> <8e5ec72f1003160527k9dfb9ebw3ca6c9803887f2dd@mail.gmail.com> <4B9F872E.8010101@cisco.com> In-Reply-To: <4B9F872E.8010101@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: gao.yang2@zte.com.cn, sipcore@ietf.org, "Belling, Thomas \(NSN - DE/Munich\)" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 13:30:03 -0000 Paul Kyzivat wrote: > > ... We have concluded that it is all just > clarification, rather than normative changes. I should have said more... We decided what ambiguities required normative action should be dealt with separately from the o/a draft. draft-ietf-sipcore-reinvite is a normative draft doing just that. Thanks, Paul From rjsparks@nostrum.com Tue Mar 16 09:15:51 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D703F3A6BAD for ; Tue, 16 Mar 2010 09:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 oZlJw71AUJdV for ; Tue, 16 Mar 2010 09:15:47 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 4D6DB3A6B57 for ; Tue, 16 Mar 2010 09:15:47 -0700 (PDT) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o2GGFaro048083 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 16 Mar 2010 11:15:54 -0500 (CDT) (envelope-from rjsparks@nostrum.com) From: Robert Sparks Content-Type: multipart/alternative; boundary=Apple-Mail-7-538661720 Date: Tue, 16 Mar 2010 11:15:54 -0500 References: <5A78707C-A3AF-4E3A-BE18-65817DE8B40F@nostrum.com> To: SIPCORE Message-Id: Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] Fwd: SIPit26 registration is open X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 16:15:51 -0000 --Apple-Mail-7-538661720 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Begin forwarded message: > From: Robert Sparks > Date: March 16, 2010 11:15:36 AM CDT > To: rai@ietf.org > Subject: SIPit26 registration is open >=20 > SIPit 26 will be held in Kista - the telecom valley outside Stockholm, = Sweden on May 17-21, 2010. The event is hosted by Edvina and TANDBERG = and sponsored by Ingate, Intertex and .se. >=20 > See and for details = and to register. >=20 > RjS --Apple-Mail-7-538661720 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
From: Robert Sparks = <rjsparks@nostrum.com>
Date: March 16, 2010 = 11:15:36 AM CDT
Subject: SIPit26 = registration is open

SIPit 26 will be held = in Kista - the telecom valley outside Stockholm, Sweden on May 17-21, = 2010. The event is hosted by Edvina and TANDBERG and sponsored by = Ingate, Intertex and .se.

See <http://www.sipit.net> and <http://sipit.edvina.se> for = details and to = register.

RjS

= --Apple-Mail-7-538661720-- From dean.willis@softarmor.com Tue Mar 16 13:14:23 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A1013A6900 for ; Tue, 16 Mar 2010 13:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 SbXDAxuC18yI for ; Tue, 16 Mar 2010 13:14:22 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 2F58C3A68C3 for ; Tue, 16 Mar 2010 13:14:22 -0700 (PDT) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2GKERBk006780 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 16 Mar 2010 15:14:28 -0500 Message-Id: From: Dean Willis To: "Milinski, Alexander (NSN - DE/Munich)" In-Reply-To: <3F4C11BC54A36642BFB5875D599F47BD027E51E3@DEMUEXC013.nsn-intra.net> Content-Type: multipart/alternative; boundary=Apple-Mail-12-552968282 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 16 Mar 2010 15:14:20 -0500 References: <8e5ec72f1003140846k313f008fk83980d92fd699351@mail.gmail.com> <4B9E6FF7.6070006@ericsson.com><494EFA17-16C9-46D5-8367-E50EBF8CC641@softarmor.com> <4B9EC7BA.7080906@cisco.com> <3F4C11BC54A36642BFB5875D599F47BD027E51E3@DEMUEXC013.nsn-intra.net> X-Mailer: Apple Mail (2.936) Cc: gao.yang2@zte.com.cn, sipcore@ietf.org, Peter Musgrave Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2010 20:14:23 -0000 --Apple-Mail-12-552968282 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Mar 16, 2010, at 5:18 AM, Milinski, Alexander (NSN - DE/Munich) wrote: > Hi Paul, Dean, > > now I am confused (though I got used to the square root of -1 being > i). > > Which RFC explains this repetition? None, really. We didn't do it like I wanted it. > Moreover, how is the repeated answer distingusished from a new offer > (the previous o/a has been completed before), > which should be answered in the ACK? The principle of repetition would say that you answer it again in the ACK, with an identical answer to that already sent. In other words, one is simply confirming in the "final" response that which was previously sent "provisionally". Provisional means "temporary until confirmed in a separate exchange", which means to me that there ought to be a final confirmation of the O/A executed in the provisional messages. Note that I also argued that either we should have no O/A in reliable provisional, or that reliable provisional O/A should become mandatory and exclusive; that is, that the "regular" offer/answer be discarded in favor of doing it in a reliable provisional exchange. This has some benefits when trying to grapple with the early media / early session problem in conjunction with PSTN gateways, and it's also useful for dealing with the folks who think that billing begins on 200 OK, who pretty much just annoy me. -- Dean --Apple-Mail-12-552968282 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Mar 16, 2010, = at 5:18 AM, Milinski, Alexander (NSN - DE/Munich) wrote:

Hi = Paul, Dean,

now I am confused (though I got used to the square = root of -1 being i).

Which RFC explains this repetition?

None= , really. We didn't do it like I wanted = it.


Moreover, how is = the repeated answer distingusished from a new offer
(the previous o/a = has been completed before),
which should be answered in the = ACK?

The principle of repetition = would say that you answer it again in the ACK, with an identical answer = to that already sent. In other words, one is simply confirming in the = "final" response that which was previously sent "provisionally". = Provisional means "temporary until confirmed in a separate exchange", = which means to me that there ought to be a final confirmation of the O/A = executed in the provisional messages.

Note that = I also argued that either we should have no O/A in reliable provisional, = or that reliable provisional O/A should become mandatory and exclusive; =  that is, that the "regular" offer/answer be discarded in favor of = doing it in a reliable provisional exchange. This has some benefits when = trying to grapple with the early media / early session problem in = conjunction with PSTN gateways, and it's also useful for dealing with = the folks who think that billing begins on 200 OK, who pretty much just = annoy = me.

--
Dean


= --Apple-Mail-12-552968282-- From dworley@avaya.com Tue Mar 16 18:50:05 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 823313A6BA9 for ; Tue, 16 Mar 2010 18:50:05 -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 tE9M8zazr4Fg for ; Tue, 16 Mar 2010 18:50:04 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id DFBBC3A6BAA for ; Tue, 16 Mar 2010 18:49:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.49,654,1262581200"; d="scan'208";a="180583303" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 16 Mar 2010 21:49:52 -0400 X-IronPort-AV: E=Sophos;i="4.49,654,1262581200"; d="scan'208";a="442432493" Received: from unknown (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 16 Mar 2010 21:49:50 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.214]) by DC-US1HCEX2.global.avaya.com ([2002:870b:3415::870b:3415]) with mapi; Tue, 16 Mar 2010 21:49:50 -0400 From: "WORLEY, DALE R (DALE)" To: Brett Tate , Peter Musgrave , "sipcore@ietf.org" Date: Tue, 16 Mar 2010 21:48:47 -0400 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-03 Thread-Index: AcrDoNeok8QAFn1uSPm6qEY/dVnA3gAAMM1wAHSYRIQ= Message-ID: References: <8e5ec72f1003140846k313f008fk83980d92fd699351@mail.gmail.com>, <747A6506A991724FB09B129B79D5FEB614806AF6E4@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB614806AF6E4@EXMBXCLUS01.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-03 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 01:50:05 -0000 ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Bret= t Tate [brett@broadsoft.com] Sent: Sunday, March 14, 2010 2:16 PM To: Peter Musgrave; sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-03 It is deliberate; see RFC 3261 concerning when answer SDP needs to be withi= n INVITE=92s 2xx response. The 18x=92s were sent reliable; thus completing= the offer/answer exchange. The following is mention above both figures: = =93PRACK transactions are not shown for clarity=94. _________________________________________ It might avoid confusion if that note was extended with "Note that in some = cases, the SDP answer is carried in a PRACK which is not shown." Dale From gao.yang2@zte.com.cn Tue Mar 16 21:42:49 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6304B3A6A6D; Tue, 16 Mar 2010 21:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.79 X-Spam-Level: X-Spam-Status: No, score=-92.79 tagged_above=-999 required=5 tests=[AWL=-1.730, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] 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 Pzt3RDNEyZAH; Tue, 16 Mar 2010 21:42:48 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 8853B3A6A53; Tue, 16 Mar 2010 21:42:46 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 314902001811080; Wed, 17 Mar 2010 12:42:36 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 64572.6140868949; Wed, 17 Mar 2010 12:42:49 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id o2H4grsU026913; Wed, 17 Mar 2010 12:42:54 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: Dean Willis MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 17 Mar 2010 12:41:13 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-03-17 12:42:50, Serialize complete at 2010-03-17 12:42:50 Content-Type: multipart/alternative; boundary="=_alternative 0019E267482576E9_=" X-MAIL: mse1.zte.com.cn o2H4grsU026913 Cc: sipcore-bounces@ietf.org, sipcore@ietf.org, Peter Musgrave Subject: [sipcore] =?gb2312?b?tPC4tDogUmU6ICBkcmFmdC1pZXRmLXNpcGNvcmUtcmVp?= =?gb2312?b?bnZpdGUtMDM=?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 04:42:49 -0000 This is a multipart message in MIME format. --=_alternative 0019E267482576E9_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 c2lwY29yZS1ib3VuY2VzQGlldGYub3JnINC009ogMjAxMC0wMy0xNyAwNDoxNDoyMDoNCg0KPiBP biBNYXIgMTYsIDIwMTAsIGF0IDU6MTggQU0sIE1pbGluc2tpLCBBbGV4YW5kZXIgKE5TTiAtIERF L011bmljaCkgDQp3cm90ZToNCj4gDQo+IEhpIFBhdWwsIERlYW4sDQo+IA0KPiBub3cgSSBhbSBj b25mdXNlZCAodGhvdWdoIEkgZ290IHVzZWQgdG8gdGhlIHNxdWFyZSByb290IG9mIC0xIGJlaW5n IGkpLg0KPiANCj4gV2hpY2ggUkZDIGV4cGxhaW5zIHRoaXMgcmVwZXRpdGlvbj8NCj4gDQo+IE5v bmUsIHJlYWxseS4gV2UgZGlkbid0IGRvIGl0IGxpa2UgSSB3YW50ZWQgaXQuDQo+IA0KDQo+IE1v cmVvdmVyLCBob3cgaXMgdGhlIHJlcGVhdGVkIGFuc3dlciBkaXN0aW5ndXNpc2hlZCBmcm9tIGEg bmV3IG9mZmVyDQo+ICh0aGUgcHJldmlvdXMgby9hIGhhcyBiZWVuIGNvbXBsZXRlZCBiZWZvcmUp LA0KPiB3aGljaCBzaG91bGQgYmUgYW5zd2VyZWQgaW4gdGhlIEFDSz8NCj4gDQo+IFRoZSBwcmlu Y2lwbGUgb2YgcmVwZXRpdGlvbiB3b3VsZCBzYXkgdGhhdCB5b3UgYW5zd2VyIGl0IGFnYWluIGlu IA0KPiB0aGUgQUNLLCB3aXRoIGFuIGlkZW50aWNhbCBhbnN3ZXIgdG8gdGhhdCBhbHJlYWR5IHNl bnQuIEluIG90aGVyIA0KPiB3b3Jkcywgb25lIGlzIHNpbXBseSBjb25maXJtaW5nIGluIHRoZSAi ZmluYWwiIHJlc3BvbnNlIHRoYXQgd2hpY2ggDQo+IHdhcyBwcmV2aW91c2x5IHNlbnQgInByb3Zp c2lvbmFsbHkiLiBQcm92aXNpb25hbCBtZWFucyAidGVtcG9yYXJ5IA0KPiB1bnRpbCBjb25maXJt ZWQgaW4gYSBzZXBhcmF0ZSBleGNoYW5nZSIsIHdoaWNoIG1lYW5zIHRvIG1lIHRoYXQgDQo+IHRo ZXJlIG91Z2h0IHRvIGJlIGEgZmluYWwgY29uZmlybWF0aW9uIG9mIHRoZSBPL0EgZXhlY3V0ZWQg aW4gdGhlIA0KPiBwcm92aXNpb25hbCBtZXNzYWdlcy4NCg0KW0dhb10gSGkgRGVhbiwNCkkgdGhp bmsgYXMgdGhlIFVBUyBzZW5kIHRoZSBBbnN3ZXIgaW4gb25lIHJlbGlhYmxlIHJlc3BvbnNlLCB0 aGVyZSdzIG5vIA0KbmVlZCB0byBjb3B5IHRoZSBzYW1lIEFuc3dlciBhcyB0aGUgY29uZmlybWF0 aW9uIGluIHRoZSBmaW5hbCByZXNwb25lLg0KVGhlcmUgYXJlIFVBU3MgZG8gbm90IHN1cHBvcnQg MTAwcmVsLCBzbyB0aGV5IHNlbmQgdGhlIFNEUChubyBhcyBBbnN3ZXIpIA0KaW4gMXh4IGZvciBl YXJseSBtZWRpYSB1c2FnZS4gVGhpcyBpcyB0aGUgY2FzZSBVQVMgc2hvdWxkIGNvcHkgdGhlIHNh bWUgDQpTRFAgYXMgQW5zd2VyIGluIHRoZSBmaW5hbCByZXNwb25lLiANCkFuZCBzZW5kIFNEUCBp biBhbm90aGVyIHJlbGlhYmxlIHJlc3BvbnNlIGFmdGVyIHRoZSBpbml0aWFsIE8vQSBpcyANCnZp b2xhdGlvbiBvZiBjdXJyZW50IFJGQzMyNjEncyBkZWZpbml0aW9uLiBJIGRvIG5vdCBwcmVmZXIg dGhlcmUgcnVsZXMgdG8gDQpiZSByZS1kZWZpbmVkIGV4Y2VwdCBmb3Igc3Ryb25nIHJlYXNvbnMu DQoNCj4gDQo+IE5vdGUgdGhhdCBJIGFsc28gYXJndWVkIHRoYXQgZWl0aGVyIHdlIHNob3VsZCBo YXZlIG5vIE8vQSBpbiANCj4gcmVsaWFibGUgcHJvdmlzaW9uYWwsIG9yIHRoYXQgcmVsaWFibGUg cHJvdmlzaW9uYWwgTy9BIHNob3VsZCBiZWNvbWUNCj4gbWFuZGF0b3J5IGFuZCBleGNsdXNpdmU7 ICB0aGF0IGlzLCB0aGF0IHRoZSAicmVndWxhciIgb2ZmZXIvYW5zd2VyIA0KPiBiZSBkaXNjYXJk ZWQgaW4gZmF2b3Igb2YgZG9pbmcgaXQgaW4gYSByZWxpYWJsZSBwcm92aXNpb25hbCANCj4gZXhj aGFuZ2UuIFRoaXMgaGFzIHNvbWUgYmVuZWZpdHMgd2hlbiB0cnlpbmcgdG8gZ3JhcHBsZSB3aXRo IHRoZSANCj4gZWFybHkgbWVkaWEgLyBlYXJseSBzZXNzaW9uIHByb2JsZW0gaW4gY29uanVuY3Rp b24gd2l0aCBQU1ROIA0KPiBnYXRld2F5cywgYW5kIGl0J3MgYWxzbyB1c2VmdWwgZm9yIGRlYWxp bmcgd2l0aCB0aGUgZm9sa3Mgd2hvIHRoaW5rIA0KPiB0aGF0IGJpbGxpbmcgYmVnaW5zIG9uIDIw MCBPSywgd2hvIHByZXR0eSBtdWNoIGp1c3QgYW5ub3kgbWUuDQoNCltHYW9dIEkgdGhpbmsgdGhl IGVhcmx5IG1lZGlhIHByb2JsZW0gaW4gY29uanVuY3Rpb24gd2l0aCBQU1ROIGdhdGV3YXlzIA0K Y2FuIGJlIHNvbHZlZCBieSB1c2luZyBwLWVhcmx5LW1lZGlhIGFuZCBpdHMgcG9saWN5Lg0KDQpU aGFua3MsDQoNCkdhbw0KDQo+IA0KPiAtLQ0KPiBEZWFuDQo+IA0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzaXBjb3JlIG1haWxpbmcgbGlzdA0K PiBzaXBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2lwY29yZQ0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0 aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25m aWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFp biBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMg b2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxl cyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVs eSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFy ZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxl YXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJl c3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4N ClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpU RSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 0019E267482576E9_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5zaXBjb3JlLWJvdW5jZXNAaWV0Zi5v cmcg0LTT2iAyMDEwLTAzLTE3IDA0OjE0OjIwOjxicj4NCjxicj4NCiZndDsgT24gTWFyIDE2LCAy MDEwLCBhdCA1OjE4IEFNLCBNaWxpbnNraSwgQWxleGFuZGVyIChOU04gLSBERS9NdW5pY2gpDQp3 cm90ZTo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBI aSBQYXVsLCBEZWFuLDxicj4NCiZndDsgPGJyPg0KJmd0OyBub3cgSSBhbSBjb25mdXNlZCAodGhv dWdoIEkgZ290IHVzZWQgdG8gdGhlIHNxdWFyZSByb290IG9mIC0xIGJlaW5nDQppKS48YnI+DQom Z3Q7IDxicj4NCiZndDsgV2hpY2ggUkZDIGV4cGxhaW5zIHRoaXMgcmVwZXRpdGlvbj88L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBOb25lLCByZWFsbHku IFdlIGRpZG4ndCBkbyBpdCBsaWtlIEkgd2FudGVkIGl0LjwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PiZndDsgTW9yZW92ZXIsIGhvdyBpcyB0aGUgcmVwZWF0ZWQgYW5zd2VyIGRpc3Rpbmd1c2lzaGVk DQpmcm9tIGEgbmV3IG9mZmVyPGJyPg0KJmd0OyAodGhlIHByZXZpb3VzIG8vYSBoYXMgYmVlbiBj b21wbGV0ZWQgYmVmb3JlKSw8YnI+DQomZ3Q7IHdoaWNoIHNob3VsZCBiZSBhbnN3ZXJlZCBpbiB0 aGUgQUNLPzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7 IFRoZSBwcmluY2lwbGUgb2YgcmVwZXRpdGlvbiB3b3VsZCBzYXkgdGhhdCB5b3UgYW5zd2VyIGl0 IGFnYWluIGluDQo8YnI+DQomZ3Q7IHRoZSBBQ0ssIHdpdGggYW4gaWRlbnRpY2FsIGFuc3dlciB0 byB0aGF0IGFscmVhZHkgc2VudC4gSW4gb3RoZXIgPGJyPg0KJmd0OyB3b3Jkcywgb25lIGlzIHNp bXBseSBjb25maXJtaW5nIGluIHRoZSAmcXVvdDtmaW5hbCZxdW90OyByZXNwb25zZQ0KdGhhdCB3 aGljaCA8YnI+DQomZ3Q7IHdhcyBwcmV2aW91c2x5IHNlbnQgJnF1b3Q7cHJvdmlzaW9uYWxseSZx dW90Oy4gUHJvdmlzaW9uYWwgbWVhbnMgJnF1b3Q7dGVtcG9yYXJ5DQo8YnI+DQomZ3Q7IHVudGls IGNvbmZpcm1lZCBpbiBhIHNlcGFyYXRlIGV4Y2hhbmdlJnF1b3Q7LCB3aGljaCBtZWFucyB0byBt ZSB0aGF0DQo8YnI+DQomZ3Q7IHRoZXJlIG91Z2h0IHRvIGJlIGEgZmluYWwgY29uZmlybWF0aW9u IG9mIHRoZSBPL0EgZXhlY3V0ZWQgaW4gdGhlDQo8YnI+DQomZ3Q7IHByb3Zpc2lvbmFsIG1lc3Nh Z2VzLjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+W0dhb10gSGkgRGVh biw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkkgdGhpbmsgYXMgdGhlIFVBUyBz ZW5kIHRoZSBBbnN3ZXIgaW4gb25lIHJlbGlhYmxlDQpyZXNwb25zZSwgdGhlcmUncyBubyBuZWVk IHRvIGNvcHkgdGhlIHNhbWUgQW5zd2VyIGFzIHRoZSBjb25maXJtYXRpb24gaW4NCnRoZSBmaW5h bCByZXNwb25lLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+VGhlcmUgYXJlIFVB U3MgZG8gbm90IHN1cHBvcnQgMTAwcmVsLCBzbyB0aGV5IHNlbmQNCnRoZSBTRFAobm8gYXMgQW5z d2VyKSBpbiAxeHggZm9yIGVhcmx5IG1lZGlhIHVzYWdlLiBUaGlzIGlzIHRoZSBjYXNlIFVBUw0K c2hvdWxkIGNvcHkgdGhlIHNhbWUgU0RQIGFzIEFuc3dlciBpbiB0aGUgZmluYWwgcmVzcG9uZS4g PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5BbmQgc2VuZCBTRFAgaW4gYW5vdGhl ciByZWxpYWJsZSByZXNwb25zZSBhZnRlciB0aGUNCmluaXRpYWwgTy9BIGlzIHZpb2xhdGlvbiBv ZiBjdXJyZW50IFJGQzMyNjEncyBkZWZpbml0aW9uLiBJIGRvIG5vdCBwcmVmZXINCnRoZXJlIHJ1 bGVzIHRvIGJlIHJlLWRlZmluZWQgZXhjZXB0IGZvciBzdHJvbmcgcmVhc29ucy48L2ZvbnQ+PC90 dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBOb3RlIHRoYXQg SSBhbHNvIGFyZ3VlZCB0aGF0IGVpdGhlciB3ZSBzaG91bGQgaGF2ZSBubyBPL0EgaW4gPGJyPg0K Jmd0OyByZWxpYWJsZSBwcm92aXNpb25hbCwgb3IgdGhhdCByZWxpYWJsZSBwcm92aXNpb25hbCBP L0Egc2hvdWxkIGJlY29tZTxicj4NCiZndDsgbWFuZGF0b3J5IGFuZCBleGNsdXNpdmU7ICZuYnNw O3RoYXQgaXMsIHRoYXQgdGhlICZxdW90O3JlZ3VsYXImcXVvdDsNCm9mZmVyL2Fuc3dlciA8YnI+ DQomZ3Q7IGJlIGRpc2NhcmRlZCBpbiBmYXZvciBvZiBkb2luZyBpdCBpbiBhIHJlbGlhYmxlIHBy b3Zpc2lvbmFsIDxicj4NCiZndDsgZXhjaGFuZ2UuIFRoaXMgaGFzIHNvbWUgYmVuZWZpdHMgd2hl biB0cnlpbmcgdG8gZ3JhcHBsZSB3aXRoIHRoZSA8YnI+DQomZ3Q7IGVhcmx5IG1lZGlhIC8gZWFy bHkgc2Vzc2lvbiBwcm9ibGVtIGluIGNvbmp1bmN0aW9uIHdpdGggUFNUTiA8YnI+DQomZ3Q7IGdh dGV3YXlzLCBhbmQgaXQncyBhbHNvIHVzZWZ1bCBmb3IgZGVhbGluZyB3aXRoIHRoZSBmb2xrcyB3 aG8gdGhpbmsNCjxicj4NCiZndDsgdGhhdCBiaWxsaW5nIGJlZ2lucyBvbiAyMDAgT0ssIHdobyBw cmV0dHkgbXVjaCBqdXN0IGFubm95IG1lLjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+W0dhb10gSSB0aGluayB0aGUgZWFybHkgbWVkaWEgcHJvYmxlbSBpbiBjb25qdW5j dGlvbg0Kd2l0aCBQU1ROIGdhdGV3YXlzIGNhbiBiZSBzb2x2ZWQgYnkgdXNpbmcgcC1lYXJseS1t ZWRpYSBhbmQgaXRzIHBvbGljeS48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPlRoYW5rcyw8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkdhbzwv Zm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IC0t PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IERlYW48L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgc2lwY29yZSBtYWlsaW5nIGxp c3Q8YnI+DQomZ3Q7IHNpcGNvcmVAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZTxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjxwcmU+ DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtU aGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNw O21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUm bmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNw O2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRz Jm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5i c3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7 cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5i c3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0K VGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21p dHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2Fu ZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5i c3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0 byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5i c3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7 aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdp bmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3Mm bmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5i c3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpU aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9y Jm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0Fu dGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 0019E267482576E9_=-- From dean.willis@softarmor.com Tue Mar 16 22:43:22 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 992583A6BAA; Tue, 16 Mar 2010 22:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.854 X-Spam-Level: X-Spam-Status: No, score=0.854 tagged_above=-999 required=5 tests=[AWL=-3.123, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_GB2312=1.345] 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 q0QO4LlWpu70; Tue, 16 Mar 2010 22:43:20 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 6A9383A6914; Tue, 16 Mar 2010 22:43:20 -0700 (PDT) Received: from [192.168.2.106] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2H5hRtS010705 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 17 Mar 2010 00:43:28 -0500 Message-Id: From: Dean Willis To: gao.yang2@zte.com.cn In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-22-587109391 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 17 Mar 2010 00:43:21 -0500 References: X-Mailer: Apple Mail (2.936) Cc: sipcore-bounces@ietf.org, sipcore@ietf.org, Peter Musgrave Subject: Re: [sipcore] =?gb2312?b?tPC4tDogUmU6ICBkcmFmdC1pZXRmLXNpcGNvcmUtcmVp?= =?gb2312?b?bnZpdGUtMDM=?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 05:43:22 -0000 --Apple-Mail-22-587109391 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Mar 16, 2010, at 11:41 PM, gao.yang2@zte.com.cn wrote: > > [Gao] Hi Dean, > I think as the UAS send the Answer in one reliable response, there's > no need to copy the same Answer as the confirmation in the final > respone. That was also the consensus of the working group. > There are UASs do not support 100rel, so they send the SDP(no as > Answer) in 1xx for early media usage. This is the case UAS should > copy the same SDP as Answer in the final respone. So, a reliably sent answer is a "final Answer", and an unreliably-sent answer is just being hopeful. > > And send SDP in another reliable response after the initial O/A is > violation of current RFC3261's definition. That's actually debatable; as quoted earlier in this thread, RFC 3261 is not completely clear on whether a copy of the same answer is a different answer. Certainly, CHANGING the answer is forbidden, but repeating it might not be. That's pat of why we have further drafts to clarify this. > I do not prefer there rules to be re-defined except for strong > reasons. I concur. Of course, one of the best reasons for more definition is because the rule wasn't well defined to start with. > > > > > Note that I also argued that either we should have no O/A in > > reliable provisional, or that reliable provisional O/A should become > > mandatory and exclusive; that is, that the "regular" offer/answer > > be discarded in favor of doing it in a reliable provisional > > exchange. This has some benefits when trying to grapple with the > > early media / early session problem in conjunction with PSTN > > gateways, and it's also useful for dealing with the folks who think > > that billing begins on 200 OK, who pretty much just annoy me. > > [Gao] I think the early media problem in conjunction with PSTN > gateways can be solved by using p-early-media and its policy. Not without changing the gateway billing model, I think. But I look forward to somebody writing an I-D on how this might work. -- Dean --Apple-Mail-22-587109391 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Mar 16, 2010, = at 11:41 PM, gao.yang2@zte.com.cn = wrote:


[Gao] Hi Dean, =
I think as the UAS send the Answer in one = reliable response, there's no need to copy the same Answer as the = confirmation in the final respone. =

That was also the consensus of the = working group.

There are UASs do not support 100rel, so they send the SDP(no = as Answer) in 1xx for early media usage. This is the case UAS should = copy the same SDP as Answer in the final = respone.

So, a reliably sent = answer is a "final Answer", and an unreliably-sent answer is just being = hopeful.

=
And send SDP in another reliable = response after the initial O/A is violation of current RFC3261's = definition.

That's actually = debatable; as quoted earlier in this thread, RFC 3261 is not completely = clear on whether a copy of the same answer is a different answer. = Certainly, CHANGING the answer is forbidden, but repeating it might not = be. That's pat of why we have further drafts to clarify = this.

I do not = prefer there rules to be re-defined except for strong = reasons.

I concur. Of = course, one of the best reasons for more definition is because the rule = wasn't well defined to start with.


>
> Note that I also = argued that either we should have no O/A in
> reliable = provisional, or that reliable provisional O/A should become
> = mandatory and exclusive;  that is, that the "regular" offer/answer =
> be discarded in favor of doing it in a reliable provisional =
> exchange. This has some benefits when trying to grapple with = the
> early media / early session problem in conjunction with = PSTN
> gateways, and it's also useful for dealing with the folks = who think
> that billing begins on 200 OK, who pretty much just = annoy me.

[Gao] I think the = early media problem in conjunction with PSTN gateways can be solved by = using p-early-media and its policy. =

Not without changing the gateway billing = model, I think. But I look forward to somebody writing an I-D on how = this might = work.

--
Dean

=
= --Apple-Mail-22-587109391-- From gao.yang2@zte.com.cn Wed Mar 17 02:43:10 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87DFE3A67E5 for ; Wed, 17 Mar 2010 02:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.501 X-Spam-Level: X-Spam-Status: No, score=-92.501 tagged_above=-999 required=5 tests=[AWL=-1.441, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] 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 tL0tfKZZDjk9 for ; Wed, 17 Mar 2010 02:43:09 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 646203A67FA for ; Wed, 17 Mar 2010 02:43:07 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 314901727820181; Wed, 17 Mar 2010 17:41:47 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 84131.2588901745; Wed, 17 Mar 2010 17:41:08 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id o2H9aZS4048797; Wed, 17 Mar 2010 17:36:35 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: Dean Willis MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 17 Mar 2010 17:34:48 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-03-17 17:36:26, Serialize complete at 2010-03-17 17:36:26 Content-Type: multipart/alternative; boundary="=_alternative 0034C333482576E9_=" X-MAIL: mse1.zte.com.cn o2H9aZS4048797 Cc: sipcore@ietf.org Subject: Re: [sipcore] =?gb2312?b?tPC4tDogUmU6ICBkcmFmdC1pZXRmLXNpcGNvcmUtcmVp?= =?gb2312?b?bnZpdGUtMDM=?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Mar 2010 09:43:10 -0000 This is a multipart message in MIME format. --=_alternative 0034C333482576E9_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiBaaXAgICAgOiAyMTAwMTINCiBU ZWwgICAgOiA4NzIxMQ0KIFRlbDIgICA6KCs4NiktMDI1LTUyODc3MjExDQogZV9tYWlsIDogZ2Fv LnlhbmcyQHp0ZS5jb20uY24NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoN CkRlYW4gV2lsbGlzIDxkZWFuLndpbGxpc0Bzb2Z0YXJtb3IuY29tPiDQtNPaIDIwMTAtMDMtMTcg MTM6NDM6MjE6DQoNCj4gT24gTWFyIDE2LCAyMDEwLCBhdCAxMTo0MSBQTSwgZ2FvLnlhbmcyQHp0 ZS5jb20uY24gd3JvdGU6DQo+IA0KPiANCj4gW0dhb10gSGkgRGVhbiwgDQo+IEkgdGhpbmsgYXMg dGhlIFVBUyBzZW5kIHRoZSBBbnN3ZXIgaW4gb25lIHJlbGlhYmxlIHJlc3BvbnNlLCB0aGVyZSdz DQo+IG5vIG5lZWQgdG8gY29weSB0aGUgc2FtZSBBbnN3ZXIgYXMgdGhlIGNvbmZpcm1hdGlvbiBp biB0aGUgZmluYWwgDQpyZXNwb25lLiANCj4gDQo+IFRoYXQgd2FzIGFsc28gdGhlIGNvbnNlbnN1 cyBvZiB0aGUgd29ya2luZyBncm91cC4NCj4gDQo+IFRoZXJlIGFyZSBVQVNzIGRvIG5vdCBzdXBw b3J0IDEwMHJlbCwgc28gdGhleSBzZW5kIHRoZSBTRFAobm8gYXMgDQo+IEFuc3dlcikgaW4gMXh4 IGZvciBlYXJseSBtZWRpYSB1c2FnZS4gVGhpcyBpcyB0aGUgY2FzZSBVQVMgc2hvdWxkIA0KPiBj b3B5IHRoZSBzYW1lIFNEUCBhcyBBbnN3ZXIgaW4gdGhlIGZpbmFsIHJlc3BvbmUuDQo+IA0KPiBT bywgYSByZWxpYWJseSBzZW50IGFuc3dlciBpcyBhICJmaW5hbCBBbnN3ZXIiLCBhbmQgYW4gdW5y ZWxpYWJseS0NCj4gc2VudCBhbnN3ZXIgaXMganVzdCBiZWluZyBob3BlZnVsLg0KDQpbR2FvXSBZ ZXMuIEJ1dCBJIHRoaW5rIHRoZXJlJ3MgbWVhbmluZyB0byBzZW5kIHRoZSBub24tYW5zd2VyLVNE UCBiZWZvcmUgDQp0aGUgQW5zd2VyLiBBbmQgZG9pbmcgaGFzIG5vIGNvbmZsaWN0IHdpdGggY3Vy cmVudCBSRkNzLg0KSSBqdXN0IHRoaW5rIHNlbmRpbmcgdGhlIG5vbi1hbnN3ZXItU0RQIGFmdGVy IHRoZSBBbnN3ZXIgaXMgbm90IHByb3Blci4NCg0KPiANCj4gDQo+IEFuZCBzZW5kIFNEUCBpbiBh bm90aGVyIHJlbGlhYmxlIHJlc3BvbnNlIGFmdGVyIHRoZSBpbml0aWFsIE8vQSBpcyANCj4gdmlv bGF0aW9uIG9mIGN1cnJlbnQgUkZDMzI2MSdzIGRlZmluaXRpb24uIA0KPiANCj4gVGhhdCdzIGFj dHVhbGx5IGRlYmF0YWJsZTsgYXMgcXVvdGVkIGVhcmxpZXIgaW4gdGhpcyB0aHJlYWQsIFJGQyAN Cj4gMzI2MSBpcyBub3QgY29tcGxldGVseSBjbGVhciBvbiB3aGV0aGVyIGEgY29weSBvZiB0aGUg c2FtZSBhbnN3ZXIgaXMNCj4gYSBkaWZmZXJlbnQgYW5zd2VyLiBDZXJ0YWlubHksIENIQU5HSU5H IHRoZSBhbnN3ZXIgaXMgZm9yYmlkZGVuLCBidXQNCj4gcmVwZWF0aW5nIGl0IG1pZ2h0IG5vdCBi ZS4gVGhhdCdzIHBhdCBvZiB3aHkgd2UgaGF2ZSBmdXJ0aGVyIGRyYWZ0cyANCj4gdG8gY2xhcmlm eSB0aGlzLg0KDQpbR2FvXQ0KUkZDMzI2MSBoYXMgc3VjaCBkZWZpbml0aW9uOg0KbyAgT25jZSB0 aGUgVUFTIGhhcyBzZW50IG9yIHJlY2VpdmVkIGFuIGFuc3dlciB0byB0aGUgaW5pdGlhbA0KICAg ICAgICAgb2ZmZXIsIGl0IE1VU1QgTk9UIGdlbmVyYXRlIHN1YnNlcXVlbnQgb2ZmZXJzIGluIGFu eSByZXNwb25zZXMNCiAgICAgICAgIHRvIHRoZSBpbml0aWFsIElOVklURS4gDQoNCkkgdGhpbmsg YWZ0ZXIgdGhlIGluaXRpYWwgTy9BLCBVQVMncyBTRFAgaW4gYW5vdGhlciByZWxpYWJsZSByZXNw b25zZSBpcyANCnRoZSBjYXNlLiBTbywgaXQgaXMgZm9yYmlkZGVuIHRvIHNlbmQgdGhlIG5ldyBT RFAob2ZmZXIpLg0KSW4gZmFjdCwgc29tZW9uZSBtYXkgYXJndWUgd2UgbWF5IHNheSB0aGUgU0RQ IGlzIHRoZSBzZWNvbmQgQW5zd2VyLiBUbyBiZSANCmhvbmVzdCwgSSBqdXN0ICpmZWVsKiB0aGUg U0RQIGluIGFub3RoZXIgcmVsaWFibGUgcmVzcG9uc2UgYWZ0ZXIgb25lIE8vQSANCnNob3VsZCBi ZSB0cmVhdGVkIGFzIE9mZmVyLiANCg0KPiANCj4gSSBkbyBub3QgcHJlZmVyIHRoZXJlIHJ1bGVz IHRvIGJlIHJlLWRlZmluZWQgZXhjZXB0IGZvciBzdHJvbmcgcmVhc29ucy4gDQo+IA0KPiBJIGNv bmN1ci4gT2YgY291cnNlLCBvbmUgb2YgdGhlIGJlc3QgcmVhc29ucyBmb3IgbW9yZSBkZWZpbml0 aW9uIGlzIA0KPiBiZWNhdXNlIHRoZSBydWxlIHdhc24ndCB3ZWxsIGRlZmluZWQgdG8gc3RhcnQg d2l0aC4NCg0KDQo+IA0KPiANCj4gPiANCj4gPiBOb3RlIHRoYXQgSSBhbHNvIGFyZ3VlZCB0aGF0 IGVpdGhlciB3ZSBzaG91bGQgaGF2ZSBubyBPL0EgaW4gDQo+ID4gcmVsaWFibGUgcHJvdmlzaW9u YWwsIG9yIHRoYXQgcmVsaWFibGUgcHJvdmlzaW9uYWwgTy9BIHNob3VsZCBiZWNvbWUNCj4gPiBt YW5kYXRvcnkgYW5kIGV4Y2x1c2l2ZTsgIHRoYXQgaXMsIHRoYXQgdGhlICJyZWd1bGFyIiBvZmZl ci9hbnN3ZXIgDQo+ID4gYmUgZGlzY2FyZGVkIGluIGZhdm9yIG9mIGRvaW5nIGl0IGluIGEgcmVs aWFibGUgcHJvdmlzaW9uYWwgDQo+ID4gZXhjaGFuZ2UuIFRoaXMgaGFzIHNvbWUgYmVuZWZpdHMg d2hlbiB0cnlpbmcgdG8gZ3JhcHBsZSB3aXRoIHRoZSANCj4gPiBlYXJseSBtZWRpYSAvIGVhcmx5 IHNlc3Npb24gcHJvYmxlbSBpbiBjb25qdW5jdGlvbiB3aXRoIFBTVE4gDQo+ID4gZ2F0ZXdheXMs IGFuZCBpdCdzIGFsc28gdXNlZnVsIGZvciBkZWFsaW5nIHdpdGggdGhlIGZvbGtzIHdobyB0aGlu ayANCj4gPiB0aGF0IGJpbGxpbmcgYmVnaW5zIG9uIDIwMCBPSywgd2hvIHByZXR0eSBtdWNoIGp1 c3QgYW5ub3kgbWUuIA0KPiANCj4gW0dhb10gSSB0aGluayB0aGUgZWFybHkgbWVkaWEgcHJvYmxl bSBpbiBjb25qdW5jdGlvbiB3aXRoIFBTVE4gDQo+IGdhdGV3YXlzIGNhbiBiZSBzb2x2ZWQgYnkg dXNpbmcgcC1lYXJseS1tZWRpYSBhbmQgaXRzIHBvbGljeS4gDQo+IA0KPiBOb3Qgd2l0aG91dCBj aGFuZ2luZyB0aGUgZ2F0ZXdheSBiaWxsaW5nIG1vZGVsLCBJIHRoaW5rLiBCdXQgSSBsb29rIA0K PiBmb3J3YXJkIHRvIHNvbWVib2R5IHdyaXRpbmcgYW4gSS1EIG9uIGhvdyB0aGlzIG1pZ2h0IHdv cmsuDQo+IA0KPiAtLQ0KPiBEZWFuDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3Rp Y2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9w ZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlv biBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0 byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUg Y29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5k IGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVu ZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hv bSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4g ZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZp ZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFs IHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBT cGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 0034C333482576E9_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PGJyPg0KIFppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQogVGVs ICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0KIFRlbDIgJm5ic3A7IDooKzg2KS0wMjUtNTI4Nzcy MTE8YnI+DQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQo9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PTwvZm9udD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PkRlYW4gV2lsbGlzICZsdDtkZWFuLndpbGxpc0Bzb2Z0YXJtb3IuY29tJmd0OyDQtNPaDQoyMDEw LTAzLTE3IDEzOjQzOjIxOjxicj4NCjxicj4NCiZndDsgT24gTWFyIDE2LCAyMDEwLCBhdCAxMTo0 MSBQTSwgZ2FvLnlhbmcyQHp0ZS5jb20uY24gd3JvdGU6PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBbR2FvXSBIaSBEZWFuLCA8YnI+ DQomZ3Q7IEkgdGhpbmsgYXMgdGhlIFVBUyBzZW5kIHRoZSBBbnN3ZXIgaW4gb25lIHJlbGlhYmxl IHJlc3BvbnNlLCB0aGVyZSdzPGJyPg0KJmd0OyBubyBuZWVkIHRvIGNvcHkgdGhlIHNhbWUgQW5z d2VyIGFzIHRoZSBjb25maXJtYXRpb24gaW4gdGhlIGZpbmFsIHJlc3BvbmUuDQo8L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBUaGF0IHdhcyBhbHNvIHRo ZSBjb25zZW5zdXMgb2YgdGhlIHdvcmtpbmcgZ3JvdXAuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgVGhlcmUgYXJlIFVBU3MgZG8gbm90IHN1cHBvcnQg MTAwcmVsLCBzbyB0aGV5IHNlbmQgdGhlIFNEUChubyBhcyA8YnI+DQomZ3Q7IEFuc3dlcikgaW4g MXh4IGZvciBlYXJseSBtZWRpYSB1c2FnZS4gVGhpcyBpcyB0aGUgY2FzZSBVQVMgc2hvdWxkDQo8 YnI+DQomZ3Q7IGNvcHkgdGhlIHNhbWUgU0RQIGFzIEFuc3dlciBpbiB0aGUgZmluYWwgcmVzcG9u ZS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBTbywg YSByZWxpYWJseSBzZW50IGFuc3dlciBpcyBhICZxdW90O2ZpbmFsIEFuc3dlciZxdW90OywgYW5k IGFuIHVucmVsaWFibHktPGJyPg0KJmd0OyBzZW50IGFuc3dlciBpcyBqdXN0IGJlaW5nIGhvcGVm dWwuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5bR2FvXSBZZXMuIEJ1 dCBJIHRoaW5rIHRoZXJlJ3MgbWVhbmluZyB0byBzZW5kIHRoZQ0Kbm9uLWFuc3dlci1TRFAgYmVm b3JlIHRoZSBBbnN3ZXIuIEFuZCBkb2luZyBoYXMgbm8gY29uZmxpY3Qgd2l0aCBjdXJyZW50DQpS RkNzLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SSBqdXN0IHRoaW5rIHNlbmRp bmcgdGhlIG5vbi1hbnN3ZXItU0RQIGFmdGVyIHRoZQ0KQW5zd2VyIGlzIG5vdCBwcm9wZXIuPC9m b250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgPGJy Pg0KJmd0OyBBbmQgc2VuZCBTRFAgaW4gYW5vdGhlciByZWxpYWJsZSByZXNwb25zZSBhZnRlciB0 aGUgaW5pdGlhbCBPL0EgaXMNCjxicj4NCiZndDsgdmlvbGF0aW9uIG9mIGN1cnJlbnQgUkZDMzI2 MSdzIGRlZmluaXRpb24uIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8 YnI+DQomZ3Q7IFRoYXQncyBhY3R1YWxseSBkZWJhdGFibGU7IGFzIHF1b3RlZCBlYXJsaWVyIGlu IHRoaXMgdGhyZWFkLCBSRkMgPGJyPg0KJmd0OyAzMjYxIGlzIG5vdCBjb21wbGV0ZWx5IGNsZWFy IG9uIHdoZXRoZXIgYSBjb3B5IG9mIHRoZSBzYW1lIGFuc3dlcg0KaXM8YnI+DQomZ3Q7IGEgZGlm ZmVyZW50IGFuc3dlci4gQ2VydGFpbmx5LCBDSEFOR0lORyB0aGUgYW5zd2VyIGlzIGZvcmJpZGRl biwgYnV0PGJyPg0KJmd0OyByZXBlYXRpbmcgaXQgbWlnaHQgbm90IGJlLiBUaGF0J3MgcGF0IG9m IHdoeSB3ZSBoYXZlIGZ1cnRoZXIgZHJhZnRzDQo8YnI+DQomZ3Q7IHRvIGNsYXJpZnkgdGhpcy48 L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPltHYW9dPC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5SRkMzMjYxIGhhcyBzdWNoIGRlZmluaXRpb246PC9mb250 PjwvdHQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij5vICZuYnNwOzxiPk9u Y2U8L2I+IHRoZSA8Yj5VQVMgaGFzDQpzZW50PC9iPiBvciByZWNlaXZlZCBhbiA8Yj5hbnN3ZXIg dG8gdGhlIGluaXRpYWw8L2I+PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVy IE5ldyI+PGI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO29mZmVyPC9iPiwNCml0 IDxiPk1VU1QgTk9UPC9iPiBnZW5lcmF0ZSA8Yj5zdWJzZXF1ZW50IG9mZmVyczwvYj4gaW4gPGI+ YW55IHJlc3BvbnNlczwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIg TmV3Ij48Yj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dG8NCnRoZSBpbml0aWFs IElOVklURTwvYj4uIDwvZm9udD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkkgdGhpbmsg YWZ0ZXIgdGhlIGluaXRpYWwgTy9BLCBVQVMncyBTRFAgaW4gYW5vdGhlcg0KcmVsaWFibGUgcmVz cG9uc2UgaXMgdGhlIGNhc2UuIFNvLCBpdCBpcyBmb3JiaWRkZW4gdG8gc2VuZCB0aGUgbmV3IFNE UChvZmZlcikuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5JbiBmYWN0LCBzb21l b25lIG1heSBhcmd1ZSB3ZSBtYXkgc2F5IHRoZSBTRFAgaXMgdGhlDQpzZWNvbmQgQW5zd2VyLiBU byBiZSBob25lc3QsIEkganVzdCAqZmVlbCo8Yj4gdGhlIFNEUCBpbiBhbm90aGVyIHJlbGlhYmxl DQpyZXNwb25zZSBhZnRlciBvbmUgTy9BIHNob3VsZCBiZSB0cmVhdGVkIGFzIE9mZmVyLjwvYj4g PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsg SSBkbyBub3QgcHJlZmVyIHRoZXJlIHJ1bGVzIHRvIGJlIHJlLWRlZmluZWQgZXhjZXB0IGZvciBz dHJvbmcgcmVhc29ucy4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8 YnI+DQomZ3Q7IEkgY29uY3VyLiBPZiBjb3Vyc2UsIG9uZSBvZiB0aGUgYmVzdCByZWFzb25zIGZv ciBtb3JlIGRlZmluaXRpb24gaXMNCjxicj4NCiZndDsgYmVjYXVzZSB0aGUgcnVsZSB3YXNuJ3Qg d2VsbCBkZWZpbmVkIHRvIHN0YXJ0IHdpdGguPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZn dDsgJmd0OyBOb3RlIHRoYXQgSSBhbHNvIGFyZ3VlZCB0aGF0IGVpdGhlciB3ZSBzaG91bGQgaGF2 ZSBubyBPL0EgaW4NCjxicj4NCiZndDsgJmd0OyByZWxpYWJsZSBwcm92aXNpb25hbCwgb3IgdGhh dCByZWxpYWJsZSBwcm92aXNpb25hbCBPL0Egc2hvdWxkDQpiZWNvbWU8YnI+DQomZ3Q7ICZndDsg bWFuZGF0b3J5IGFuZCBleGNsdXNpdmU7ICZuYnNwO3RoYXQgaXMsIHRoYXQgdGhlICZxdW90O3Jl Z3VsYXImcXVvdDsNCm9mZmVyL2Fuc3dlciA8YnI+DQomZ3Q7ICZndDsgYmUgZGlzY2FyZGVkIGlu IGZhdm9yIG9mIGRvaW5nIGl0IGluIGEgcmVsaWFibGUgcHJvdmlzaW9uYWwgPGJyPg0KJmd0OyAm Z3Q7IGV4Y2hhbmdlLiBUaGlzIGhhcyBzb21lIGJlbmVmaXRzIHdoZW4gdHJ5aW5nIHRvIGdyYXBw bGUgd2l0aA0KdGhlIDxicj4NCiZndDsgJmd0OyBlYXJseSBtZWRpYSAvIGVhcmx5IHNlc3Npb24g cHJvYmxlbSBpbiBjb25qdW5jdGlvbiB3aXRoIFBTVE4NCjxicj4NCiZndDsgJmd0OyBnYXRld2F5 cywgYW5kIGl0J3MgYWxzbyB1c2VmdWwgZm9yIGRlYWxpbmcgd2l0aCB0aGUgZm9sa3Mgd2hvDQp0 aGluayA8YnI+DQomZ3Q7ICZndDsgdGhhdCBiaWxsaW5nIGJlZ2lucyBvbiAyMDAgT0ssIHdobyBw cmV0dHkgbXVjaCBqdXN0IGFubm95IG1lLg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFtHYW9dIEkg dGhpbmsgdGhlIGVhcmx5IG1lZGlhIHByb2JsZW0gaW4gY29uanVuY3Rpb24gd2l0aCBQU1ROIDxi cj4NCiZndDsgZ2F0ZXdheXMgY2FuIGJlIHNvbHZlZCBieSB1c2luZyBwLWVhcmx5LW1lZGlhIGFu ZCBpdHMgcG9saWN5LiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJy Pg0KJmd0OyBOb3Qgd2l0aG91dCBjaGFuZ2luZyB0aGUgZ2F0ZXdheSBiaWxsaW5nIG1vZGVsLCBJ IHRoaW5rLiBCdXQgSSBsb29rDQo8YnI+DQomZ3Q7IGZvcndhcmQgdG8gc29tZWJvZHkgd3JpdGlu ZyBhbiBJLUQgb24gaG93IHRoaXMgbWlnaHQgd29yay48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAtLTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyBEZWFuPC9mb250PjwvdHQ+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1h dGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9u Jm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7 c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7 b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNw O2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fi b3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3Nl Y3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZu YnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJz cDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJz cDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNw O2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJz cDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNw O2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3Ro ZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5i c3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7 cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7 dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNw O2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5i c3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5i c3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7 YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVt Lg0KPC9wcmU+ --=_alternative 0034C333482576E9_=-- From richard@shockey.us Wed Mar 17 18:12:55 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E95F83A6A4C for ; Wed, 17 Mar 2010 18:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.321 X-Spam-Level: X-Spam-Status: No, score=-0.321 tagged_above=-999 required=5 tests=[AWL=-1.453, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] 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 zzoZZIIbpOqK for ; Wed, 17 Mar 2010 18:12:55 -0700 (PDT) Received: from outbound-mail-360.bluehost.com (outbound-mail-360.bluehost.com [66.147.249.254]) by core3.amsl.com (Postfix) with SMTP id 13DDF3A69DE for ; Wed, 17 Mar 2010 18:12:55 -0700 (PDT) Received: (qmail 16486 invoked by uid 0); 18 Mar 2010 01:06:26 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 18 Mar 2010 01:06:26 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=FUg0ERYPNPtRtIN2JBdEDxFDfX/3yr4SjzYJr5PppNhI6VNa2znSmf8TtOL6Dr8fQ9NE+Id8KKSPn9OUVVyWgjc0mgnjEPkCX5HXke7G4y3Th9TsEEs7xWMs91cgmqQU; Received: from pool-173-66-69-79.washdc.fios.verizon.net ([173.66.69.79] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Ns4Bu-00023X-81; Wed, 17 Mar 2010 19:06:26 -0600 From: "Richard Shockey" To: , Date: Wed, 17 Mar 2010 21:06:22 -0400 Message-ID: <013801cac637$3a7668e0$af633aa0$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0139_01CAC615.B364C8E0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acq/uZOrLwXMolSnQeyPKU4g86oIkg== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 173.66.69.79 authed with richard@shockey.us} Cc: rai@ietf.org Subject: [sipcore] Reminder Last Message: SIP Forum Luncheon at IETF 77 Monday 11:30 13:00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 01:12:56 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0139_01CAC615.B364C8E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The SIP Forum is going to hold a open meeting for the RAI community during IETF 77. The purpose of this meeting is remind the SIP community of what the SIP Forum is doing and discuss relevant technical issues that relate to IETF WG's. The agenda for this luncheon will be to review current activities in the SIP Forum and seek additional technical input from the RAI community on mutual concerns. As many of you know the SIP Forum is the principal sponsor of the SIPit interoperability events and currently has 4 Task groups operating. BTW registration for SIPit 26 will be open soon. Our principal technical initiatives are: 1. SIP Connect 1.1 which is developing an enhanced profile of IETF Standards for PBX to SSP interoperability. As part of that work the IETF MARTINI WG was formed to redefine the so called Implicit registration procedure in SIP. 2. FAX over SIP is investigating the interoperability of SIP in T.38 networks with a goal of possible recommendations to the relevant SDO's on how fax can work better. 3. Client User Agent Configuration which has a pending Recommendation on how CUA devices could auto streamline the locating, retrieving and maintaining of configuration-related information for SIP User Agents 4. SIP in the SmartGrid. This is a Special Interest Group that is evaluating the appropriateness of using SIP as a protocol for a number of Smart Grid areas, including the Home Area Network (HAN), Utilities' Operational Network, and PEV (Plug-In Vehicle) deployments. Information on the SIP Forum is available at http//www.sipforum.org If you are interested in attending this event we have set up a Doodle Poll to indicate your interest. Seating is somewhat limited ( 150 Maximum) lunch will be provided. Location .. Monday 11:30 13:00 the Laguna room and its located on the 4th floor of the Anaheim Hilton The link to the poll is: http://www.doodle.com/hde57nbpcdykzqfz Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 skype: rshockey101 LinkedIn : http://www.linkedin.com/in/rshockey101 ------=_NextPart_000_0139_01CAC615.B364C8E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

The SIP Forum is going to hold a open meeting for = the RAI community during IETF 77. The purpose of this meeting is remind the SIP community of what the SIP Forum is doing and discuss relevant technical = issues that relate to IETF WG’s. The agenda for this luncheon will be to = review current activities in the SIP Forum and seek additional technical input = from the RAI community on mutual concerns.

 

As many of you know the SIP Forum is the principal = sponsor of the SIPit interoperability events and currently has 4 Task groups = operating.

 

BTW registration for SIPit 26 will be open = soon.

 

Our principal technical initiatives = are:

 

1.      SIP Connect 1.1 which is developing an enhanced  profile of IETF Standards for PBX to SSP interoperability. As part = of that work the IETF MARTINI WG was formed to redefine the so called Implicit registration procedure in SIP.

2.      FAX over SIP is investigating the = interoperability of SIP in T.38 networks with a goal of possible recommendations to the = relevant SDO’s on how fax can work better.

3.      Client User Agent Configuration which has a = pending Recommendation on how CUA devices could auto streamline the locating, retrieving and maintaining of configuration-related information for SIP = User Agents

4.      SIP in the SmartGrid. This is a Special Interest = Group that is evaluating the appropriateness of using SIP as a protocol for a = number of Smart Grid areas, including the Home Area Network (HAN), Utilities' Operational Network, and PEV (Plug-In Vehicle) = deployments.

 

Information on the SIP Forum is available at =

 

http//www.sipforum.org

 

If you are interested in attending this event we = have set up a Doodle Poll to indicate your interest. Seating is somewhat limited ( = 150 Maximum) lunch will be provided.

 

Location .. Monday 11:30 13:00 the Laguna room and its = located on the 4th floor of the Anaheim Hilton

The link to the poll = is:

http://www.doodle.com/hde57nbpcdykzqfz

 

Richard = Shockey
Shockey Consulting
Chairman of the Board of Directors SIP Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>= ;
skype: rshockey101
LinkedIn : http://www.linkedin.com/i= n/rshockey101

 

------=_NextPart_000_0139_01CAC615.B364C8E0-- From rjsparks@nostrum.com Thu Mar 18 12:45:13 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96B103A65A6 for ; Thu, 18 Mar 2010 12:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[AWL=-0.503, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 0e2H7Gu5cDQ5 for ; Thu, 18 Mar 2010 12:45:12 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id B0CFC3A6808 for ; Thu, 18 Mar 2010 12:45:11 -0700 (PDT) Received: from [172.16.3.177] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o2IJjCSX085746 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Mar 2010 14:45:15 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-46-724019216 From: Robert Sparks In-Reply-To: <4B9C1752.1000905@nostrum.com> Date: Thu, 18 Mar 2010 14:45:11 -0500 Message-Id: <7F5A16F5-69A7-448F-B33D-11891C8C8C97@nostrum.com> References: <750BBC72E178114F9DC4872EBFF29A5B0A3BE70F@ZMY16EXM66.ds.mot.com> <4B9C1752.1000905@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1077) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org, Avasarala Ranjit-A20990 Subject: Re: [sipcore] Query on draft-ietf-sipcore-info-events-07 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2010 19:45:13 -0000 --Apple-Mail-46-724019216 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Its worth looking to see if the document text is as explicit as people = think it should be on this point. Also, I remember some discussion about whether it's ok to reuse event = package names? (Is it ok for someone to create a "dialog" event package = for instance?) The draft is silent on this at the moment - is that on purpose? RjS On Mar 13, 2010, at 4:53 PM, Adam Roach wrote: > Please don't cross-post to dispatch and sipcore. >=20 > On 3/12/10 23:26, Mar 12, Avasarala Ranjit-A20990 wrote: >>=20 >> Are there any registered INFO packages >>=20 >=20 > Not yet. >=20 >> and can the regular SIP event packages based on RFC 3265 be used with = INFO mechanism? >>=20 >=20 > Absolutely not. No. Never. Under no circumstances. Nein, =D0=9D=D0=B5=D1= =82, =E0=A4=A8=E0=A4=B9=E0=A5=80=E0=A4=82, Non, Nej. They are = _completely_ different things. >=20 > Really, if this is somehow unclear in the INFO draft, we need to pull = it from publication request and work on it some more. It would be the = worst possible outcome if implementors were led to believe that 3265 = packages could be used with INFO. Where did you get the impression that = this might be okay? >=20 > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail-46-724019216 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Its = worth looking to see if the document text is as explicit as people think = it should be on this point.

Also, I remember some = discussion about whether it's ok to reuse event package names? (Is it ok = for someone to create a "dialog" event package for = instance?)
The draft is silent on this at the moment - is that = on purpose?

RjS

On Mar = 13, 2010, at 4:53 PM, Adam Roach wrote:

Please = don't cross-post to dispatch and sipcore.

On 3/12/10 23:26, Mar 12, Avasarala Ranjit-A20990 wrote:
=20 =20 =20

Are there any registered INFO packages


Not yet.

and can the regular = SIP event packages based on RFC 3265 be used with INFO mechanism?


Absolutely not. No. Never. Under no circumstances. Nein, =D0=9D=D0=B5=D1=82, =E0=A4=A8=E0=A4=B9=E0=A5=80=E0=A4=82, Non, Nej. They = are _completely_ different things.

Really, if this is somehow unclear in the INFO draft, we need to pull it from publication request and work on it some more. It would be the worst possible outcome if implementors were led to believe that 3265 packages could be used with INFO. Where did you get the impression that this might be okay?

/a
_______________________________________________
sipcore mailing = list
sipcore@ietf.org
https://www.ietf.= org/mailman/listinfo/sipcore

= = --Apple-Mail-46-724019216-- From rjsparks@nostrum.com Fri Mar 19 11:52:18 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 184263A67F2 for ; Fri, 19 Mar 2010 11:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.944 X-Spam-Level: X-Spam-Status: No, score=0.944 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, SPF_PASS=-0.001] 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 F1AYNTJwlcf5 for ; Fri, 19 Mar 2010 11:52:16 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 83C933A67A1 for ; Fri, 19 Mar 2010 11:52:16 -0700 (PDT) Received: from 53.95.240.10.in-addr.arpa (m295636d0.tmodns.net [208.54.86.41]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o2JIqKqj090562 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Mar 2010 13:52:26 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: Robert Sparks In-Reply-To: Date: Fri, 19 Mar 2010 13:52:15 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4B8D9DCA.4030807@nostrum.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1077) Received-SPF: pass (nostrum.com: 208.54.86.41 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] 3265 Open Issue: 202 Response Code X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 18:52:18 -0000 The notes were pointing to why we ended up with 202 in the first place. = We introduced it when we figured out QAUTH wouldn't work because of the = fixed non-INVITE transaction length. Shortly after, because of HERFP, we = realized that we had to require the immediate NOTIFY from each branch. = When we added the Subscription-State header to the NOTIFY (including = it's potential value of "pending"), all utility for 202 vs 200 went = away. The problem we are trying to solve is that we have interoperability = issues with implementations trying to treat 202 and 200 as meaning = something different to the application that receives them. Because of the issues = pointed to above, they _can't_ and whenever I've found someone trying to do something differently on receipt of a 202, they really wanted to be = using Subscription-State from the NOTIFY anyhow. This has also been a honeypot for inducing bad implementation. I've seen = early implementations that would terminate a dialog if they got a 202 to the SUBSCRIBE and a NOTIFY with a state of active. I've = seen people try to build "conformance tests" that would complain if that happened. Both are not helpful behaviors. This is a rough spot (even if it is a very small one). We have a chance = to clean it up. RjS On Mar 2, 2010, at 8:01 PM, DRAGE, Keith (Keith) wrote: > Rather than change for change sake, what problem are we actually = trying to fix here. The meeting notes refer to HERFP but that is hardly = enlightening. >=20 > regards >=20 > Keith=20 >=20 >> -----Original Message----- >> From: sipcore-bounces@ietf.org=20 >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach >> Sent: Tuesday, March 02, 2010 11:23 PM >> To: SIPCORE >> Subject: [sipcore] 3265 Open Issue: 202 Response Code >>=20 >> [as a participant] >>=20 >> In Stockholm, we had a discussion of the open issues in the=20 >> 3265bis One of the topics that we discussed was the utility=20 >> of the 202 response code in RFC 3265. A summary of the=20 >> conversation can be found in the minutes: >>=20 >> http://www.ietf.org/proceedings/75/minutes/sipcore.html#Open%2 >> 0Issue:%20The%20Fate%20of%20202 >>=20 >> There was no clear agreement in that conversation, and=20 >> several participants seemed to hold very nuanced opinions on=20 >> the topic. >>=20 >> In order to drive conversation on the topic, I will propose=20 >> the following text as a starting point. >>=20 >> The key change is in Section 8.3.1, which I propose to be updated as >> follows: >>=20 >> For historical purposes, the 202 (Accepted) response code is >> added to the "Success" header field definition. >>=20 >> This document does not specify the use of the 202 response code >> in conjunction with the SUBSCRIBE or NOTIFY methods. Previous >> versions of the SIP Events Framework assigned specific semantics >> to the 202 response code. Implementations conformant with this >> specification MUST treat an incoming 202 response as identical >> to a 200 response, and MUST NOT generate 202 response codes to >> SUBSCRIBE or NOTIFY messages. >>=20 >> That is the change in policy that I am proposing. Several=20 >> other changes in the document follow from this change; I list=20 >> them below. >>=20 >> In section 4.1.2.1, the third paragraph will be truncated=20 >> after the word "immedately." In its revised form, it will simply = read: >>=20 >> This SUBSCRIBE request will be confirmed with a final response. >> 200- class responses indicate that the subscription has been >> accepted, and that a NOTIFY will be sent immediately. >>=20 >> In section 4.2.1.1, the 6th and 7th paragraphs (both starting=20 >> wht "If the notifier...") will be combined into a single=20 >> paragraph reading: >>=20 >> Once the notifier determines that it has enough information to >> create the subscription (i.e., it understands the event package, >> the subscription pertains to a known resource, and there are no >> other barriers to creating the subscription), it creates the >> subscription and a dialog, and returns a 200 (OK) response. >>=20 >> In section 4.2.1.3, the fifth paragraph will replace "202 Accept" >> with "200 OK", with the final result being: >>=20 >> If the notifier owner is interactively queried to determine >> whether a subscription is allowed, a 200 (OK) response is returned >> immediately. Note that a NOTIFY message is still formed and >> sent under these circumstances, as described in the previous >> section. >>=20 >> In section 5.4.6, the final sentance of the final paragraph=20 >> will be removed, resulting in the following text: >>=20 >> Information in this section includes details of how to=20 >> authenticate >> subscribers and authorization issues for the package. >>=20 >> The first paragraph of section 6.2 will be updated to read: >>=20 >> The mere act of returning certain 4xx and 6xx responses to >> SUBSCRIBE requests may, under certain circumstances, create >> privacy concerns by revealing sensitive policy information. In >> these cases, the notifier SHOULD always return a 200 (OK)=20 >> response. >> While the subsequent NOTIFY message may not convey true state, >> it MUST appear to contain a potentially correct piece of data >> from the point of view of the subscriber, indistinguishable from >> a valid response. Information about whether a user is authorized >> to subscribe to the requested state is never conveyed back to >> the original user under these circumstances. >>=20 >>=20 >> /a >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >>=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From dworley@avaya.com Fri Mar 19 12:35:04 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2321D3A688F for ; Fri, 19 Mar 2010 12:35:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 1RB90SUMhmi4 for ; Fri, 19 Mar 2010 12:35:03 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id B213A3A67EC for ; Fri, 19 Mar 2010 12:35:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.51,276,1267419600"; d="scan'208";a="181032013" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 19 Mar 2010 15:35:14 -0400 X-IronPort-AV: E=Sophos;i="4.51,276,1267419600"; d="scan'208";a="457027020" Received: from unknown (HELO zcars04f.nortel.com) ([47.129.242.57]) by co300216-co-erhwest-out.avaya.com with ESMTP; 19 Mar 2010 15:35:13 -0400 Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by zcars04f.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id o2JJYqF11082; Fri, 19 Mar 2010 19:34:52 GMT Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id o2JJYoh28065; Fri, 19 Mar 2010 19:34:50 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Mar 2010 15:34:49 -0400 From: "Dale Worley" To: Adam Roach In-Reply-To: <4B8D9DCA.4030807@nostrum.com> References: <4B8D9DCA.4030807@nostrum.com> Content-Type: text/plain Organization: Nortel Networks Date: Fri, 19 Mar 2010 15:34:46 -0400 Message-Id: <1269027286.3747.27.camel@khone.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Mar 2010 19:34:50.0006 (UTC) FILETIME=[3D8E1360:01CAC79B] Cc: SIPCORE Subject: Re: [sipcore] 3265 Open Issue: 202 Response Code X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Mar 2010 19:35:04 -0000 On Tue, 2010-03-02 at 17:22 -0600, Adam Roach wrote: > The key change is in Section 8.3.1, which I propose to be updated as > follows: > > For historical purposes, the 202 (Accepted) response code is > added to the "Success" header field definition. > > This document does not specify the use of the 202 response code > in conjunction with the SUBSCRIBE or NOTIFY methods. Previous > versions of the SIP Events Framework assigned specific semantics > to the 202 response code. Implementations conformant with this > specification MUST treat an incoming 202 response as identical > to a 200 response, and MUST NOT generate 202 response codes to > SUBSCRIBE or NOTIFY messages. > > That is the change in policy that I am proposing. Several other changes > in the document follow from this change; I list them below. My understanding is that the SIP convention is that all 2xx responses are considered successful and must be accepted as such by all SIP elements. If there is further semantics attached to a particular 2xx response, an element that knows those semantics may act on them. The above text suggests that a SIP element might legitimately not treat certain 2xx responses as successful in certain circumstances. I would prefer something like this: Previous versions of the SIP Events Framework assigned specific semantics to the 202 response code as a response to a SUBSCRIBE request, viz., that the SUBSCRIBE request was understood but the subscription had not yet been approved by the notifier's policy. This version merges this meaning into the semantics of the 200 response, and hence conforming implementations SHOULD respond to a SUBSCRIBE request with a 200 response rather than a 202 response in this case (like all other success cases). As is true in all circumstances where a UA receives a 2xx response that does not have specifically defined semantics, a conforming implementation that receives a 202 response MUST treat it as identical to a 200 response. You can change that "SHOULD" to "MUST", but I like it as SHOULD, as there might be special circumstances that dictate some other 2xx response. In any case, the subscriber will accept any 2xx as successful. Dale From christer.holmberg@ericsson.com Mon Mar 22 09:28:24 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 337303A691D for ; Mon, 22 Mar 2010 09:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.873 X-Spam-Level: X-Spam-Status: No, score=-1.873 tagged_above=-999 required=5 tests=[AWL=-0.404, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 9jGMZPh1tuxQ for ; Mon, 22 Mar 2010 09:28:23 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 30DC53A6902 for ; Mon, 22 Mar 2010 09:28:22 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-a8-4ba79ab75af1 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 6C.D7.23740.7BA97AB4; Mon, 22 Mar 2010 17:28:39 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Mon, 22 Mar 2010 17:28:38 +0100 From: Christer Holmberg To: 'Robert Sparks' , Adam Roach Date: Mon, 22 Mar 2010 17:28:38 +0100 Thread-Topic: [sipcore] Query on draft-ietf-sipcore-info-events-07 Thread-Index: AcrG05N2aG6EX+ehRRquvgNJQGsI2wDCKC8g Message-ID: References: <750BBC72E178114F9DC4872EBFF29A5B0A3BE70F@ZMY16EXM66.ds.mot.com> <4B9C1752.1000905@nostrum.com> <7F5A16F5-69A7-448F-B33D-11891C8C8C97@nostrum.com> In-Reply-To: <7F5A16F5-69A7-448F-B33D-11891C8C8C97@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" , Avasarala Ranjit-A20990 Subject: Re: [sipcore] Query on draft-ietf-sipcore-info-events-07 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 16:28:24 -0000 IA0KSGksDQogDQo+SXRzIHdvcnRoIGxvb2tpbmcgdG8gc2VlIGlmIHRoZSBkb2N1bWVudCB0ZXh0 IGlzIGFzIGV4cGxpY2l0IGFzIHBlb3BsZSB0aGluayBpdCBzaG91bGQgYmUgb24gDQo+dGhpcyBw b2ludC4gDQo+DQo+QWxzbywgSSByZW1lbWJlciBzb21lIGRpc2N1c3Npb24gYWJvdXQgd2hldGhl ciBpdCdzIG9rIHRvIHJldXNlIGV2ZW50IHBhY2thZ2UgbmFtZXM/IChJcyBpdCANCj5vayBmb3Ig c29tZW9uZSB0byBjcmVhdGUgYSAiZGlhbG9nIiBldmVudCBwYWNrYWdlIGZvciBpbnN0YW5jZT8p DQo+VGhlIGRyYWZ0IGlzIHNpbGVudCBvbiB0aGlzIGF0IHRoZSBtb21lbnQgLSBpcyB0aGF0IG9u IHB1cnBvc2U/DQoNCkkgc2VlIG5vIHJlYXNvbiB0byBleHBsaWNpdGx5IGZvcmJpZCBpdCwgc2lu Y2Ugd2UncmUgZGVhbGluZyB3aXRoIGRpZmZlcmVudCBuYW1lc3BhY2VzLg0KDQpCdXQsIHBlb3Bs ZSBtYXkgb2YgY291cnNlIHVzZSBjb21tb24gc2Vuc2UgYW5kIGFzayB0aGVtc2VsdmVzIHdoZXRo ZXIgaXQncyBhIHNtYXJ0IHRoaW5nIHRvIGRvLi4uDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoN Cg0KDQoNCg0KDQpPbiBNYXIgMTMsIDIwMTAsIGF0IDQ6NTMgUE0sIEFkYW0gUm9hY2ggd3JvdGU6 DQoNCg0KCVBsZWFzZSBkb24ndCBjcm9zcy1wb3N0IHRvIGRpc3BhdGNoIGFuZCBzaXBjb3JlLg0K CQ0KCU9uIDMvMTIvMTAgMjM6MjYsIE1hciAxMiwgQXZhc2FyYWxhIFJhbmppdC1BMjA5OTAgd3Jv dGU6IA0KDQoJCUFyZSB0aGVyZSBhbnkgcmVnaXN0ZXJlZCBJTkZPIHBhY2thZ2VzDQoNCg0KCU5v dCB5ZXQuDQoJDQoJDQoNCgkJYW5kIGNhbiB0aGUgcmVndWxhciBTSVAgZXZlbnQgcGFja2FnZXMg YmFzZWQgb24gUkZDIDMyNjUgYmUgdXNlZCB3aXRoIElORk8gbWVjaGFuaXNtPw0KDQoNCglBYnNv bHV0ZWx5IG5vdC4gTm8uIE5ldmVyLiBVbmRlciBubyBjaXJjdW1zdGFuY2VzLiBOZWluLCDQndC1 0YIsIOCkqOCkueClgOCkgiwgTm9uLCBOZWouIFRoZXkgYXJlIF9jb21wbGV0ZWx5XyBkaWZmZXJl bnQgdGhpbmdzLg0KCQ0KCVJlYWxseSwgaWYgdGhpcyBpcyBzb21laG93IHVuY2xlYXIgaW4gdGhl IElORk8gZHJhZnQsIHdlIG5lZWQgdG8gcHVsbCBpdCBmcm9tIHB1YmxpY2F0aW9uIHJlcXVlc3Qg YW5kIHdvcmsgb24gaXQgc29tZSBtb3JlLiBJdCB3b3VsZCBiZSB0aGUgd29yc3QgcG9zc2libGUg b3V0Y29tZSBpZiBpbXBsZW1lbnRvcnMgd2VyZSBsZWQgdG8gYmVsaWV2ZSB0aGF0IDMyNjUgcGFj a2FnZXMgY291bGQgYmUgdXNlZCB3aXRoIElORk8uIFdoZXJlIGRpZCB5b3UgZ2V0IHRoZSBpbXBy ZXNzaW9uIHRoYXQgdGhpcyBtaWdodCBiZSBva2F5Pw0KCQ0KCS9hDQoJDQoJX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCglzaXBjb3JlIG1haWxpbmcgbGlz dA0KCXNpcGNvcmVAaWV0Zi5vcmcNCglodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NpcGNvcmUNCgkNCg0KDQo= From adam@nostrum.com Mon Mar 22 10:54:37 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A21C3A69D1 for ; Mon, 22 Mar 2010 10:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.47 X-Spam-Level: X-Spam-Status: No, score=-1.47 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, SPF_PASS=-0.001] 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 z5ryTbsfDy7L for ; Mon, 22 Mar 2010 10:54:37 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 599D23A6A2C for ; Mon, 22 Mar 2010 10:54:34 -0700 (PDT) Received: from dhcp-wireless-open-abg-24-56.meeting.ietf.org (dhcp-wireless-open-abg-24-56.meeting.ietf.org [130.129.24.56]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o2MHsl5J035858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 22 Mar 2010 12:54:48 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BA7AEE7.2030705@nostrum.com> Date: Mon, 22 Mar 2010 10:54:47 -0700 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Christer Holmberg References: <750BBC72E178114F9DC4872EBFF29A5B0A3BE70F@ZMY16EXM66.ds.mot.com> <4B9C1752.1000905@nostrum.com> <7F5A16F5-69A7-448F-B33D-11891C8C8C97@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.24.56 is authenticated by a trusted mechanism) Cc: "sipcore@ietf.org" , Avasarala Ranjit-A20990 Subject: Re: [sipcore] Query on draft-ietf-sipcore-info-events-07 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2010 17:54:37 -0000 On 3/22/10 9:28 AM, Christer Holmberg wrote: > > Hi, > > >> Also, I remember some discussion about whether it's ok to reuse event package names? (Is it >> ok for someone to create a "dialog" event package for instance?) >> The draft is silent on this at the moment - is that on purpose? >> > I see no reason to explicitly forbid it, since we're dealing with different namespaces. > I agree. In fact, I believe that doing anything that implies that they're drawing from the same namespace is actually harmful: doing so can convey the incorrect impression that there might be some way to use an Event Package in INFO, or an INFO package in SUBSCRIBE. /a From christer.holmberg@ericsson.com Mon Mar 22 23:36:02 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ED303A6997 for ; Mon, 22 Mar 2010 23:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.569 X-Spam-Level: X-Spam-Status: No, score=-1.569 tagged_above=-999 required=5 tests=[DNS_FROM_OPENWHOIS=2.431, 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 dxYA4hVeFM0S for ; Mon, 22 Mar 2010 23:36:01 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 3476F3A695F for ; Mon, 22 Mar 2010 23:35:57 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-f6-4ba8615d59ed Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 0D.92.23532.D5168AB4; Tue, 23 Mar 2010 07:36:13 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 23 Mar 2010 07:36:13 +0100 From: Christer Holmberg To: SIPCORE Date: Tue, 23 Mar 2010 07:36:13 +0100 Thread-Topic: SUBSCRIBE 3xx - can it solve issues raised in 3265bis? [was INVITE 3xx and early media] Thread-Index: Acq/B5gYbGS2mSzGTiOh0LxJFIIdywLStXHw Message-ID: References: <4B918DED.6090108@cisco.com> <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <001a01cabe3e$e7033f80$b509be80$@com> <4B950BC0.5090601@cisco.com> <0BD9B443-C89F-4D16-819D-C35D74BAFD1B@softarmor.com> <4B9531DA.7050002@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] SUBSCRIBE 3xx - can it solve issues raised in 3265bis? [was INVITE 3xx and early media] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 06:36:02 -0000 Hi, Would it be possible to use the 3xx mechanism in order to solve the forking= related problems with SUB/NOT (as described in 3265bis)? The forking proxy would return a 3xx response to the SUBSCRIBE request, and= the UAC can then send individual SUBSCRIBE requests to each UAS? Regards, Christer= From adam@nostrum.com Tue Mar 23 00:13:50 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C3753A6A61 for ; Tue, 23 Mar 2010 00:13:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.43 X-Spam-Level: ** X-Spam-Status: No, score=2.43 tagged_above=-999 required=5 tests=[DNS_FROM_OPENWHOIS=2.431, SPF_PASS=-0.001] 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 yLbXEQJv1Dj3 for ; Tue, 23 Mar 2010 00:13:48 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 6468B3A68BD for ; Tue, 23 Mar 2010 00:13:46 -0700 (PDT) Received: from dhcp-wireless-open-abg-24-56.meeting.ietf.org (dhcp-wireless-open-abg-24-56.meeting.ietf.org [130.129.24.56]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o2N7Dvt3099501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 23 Mar 2010 02:13:58 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BA86A35.90707@nostrum.com> Date: Tue, 23 Mar 2010 00:13:57 -0700 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: Christer Holmberg References: <4B918DED.6090108@cisco.com> <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <001a01cabe3e$e7033f80$b509be80$@com> <4B950BC0.5090601@cisco.com> <0BD9B443-C89F-4D16-819D-C35D74BAFD1B@softarmor.com> <4B9531DA.7050002@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.24.56 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] SUBSCRIBE 3xx - can it solve issues raised in 3265bis? [was INVITE 3xx and early media] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 07:13:50 -0000 The only real way you could deploy this would be with a 'proxy-require' option tag that would have associated semantics that forbid proxies from forking. I don't think that's very tractable at this point. /a On 3/22/10 11:36 PM, Christer Holmberg wrote: > Hi, > > Would it be possible to use the 3xx mechanism in order to solve the forking related problems with SUB/NOT (as described in 3265bis)? > > The forking proxy would return a 3xx response to the SUBSCRIBE request, and the UAC can then send individual SUBSCRIBE requests to each UAS? > > Regards, > > Christer > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Tue Mar 23 00:29:04 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5CAA3A684A for ; Tue, 23 Mar 2010 00:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.219 X-Spam-Level: X-Spam-Status: No, score=-0.219 tagged_above=-999 required=5 tests=[AWL=-1.350, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 1Xrot2UrWE2p for ; Tue, 23 Mar 2010 00:29:04 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 030EA3A684C for ; Tue, 23 Mar 2010 00:28:43 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-36-4ba86db97bcb Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id EE.07.23740.9BD68AB4; Tue, 23 Mar 2010 08:28:57 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 23 Mar 2010 08:28:57 +0100 From: Christer Holmberg To: 'Adam Roach' Date: Tue, 23 Mar 2010 08:28:56 +0100 Thread-Topic: [sipcore] SUBSCRIBE 3xx - can it solve issues raised in 3265bis? [was INVITE 3xx and early media] Thread-Index: AcrKWH8mqr6bMKcETqq82tOOApdUrQAATZyA Message-ID: References: <4B918DED.6090108@cisco.com> <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <001a01cabe3e$e7033f80$b509be80$@com> <4B950BC0.5090601@cisco.com> <0BD9B443-C89F-4D16-819D-C35D74BAFD1B@softarmor.com> <4B9531DA.7050002@cisco.com> <4BA86A35.90707@nostrum.com> In-Reply-To: <4BA86A35.90707@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] SUBSCRIBE 3xx - can it solve issues raised in 3265bis? [was INVITE 3xx and early media] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 07:29:04 -0000 Hi, I don't think we can "forbid" the proxy from forking, and if it does we hav= e to live with the consequences. The proposal for OPTIONS 3xx (and, I guess it would be the same for INVITE = 3xx?) is to use the Request-Disposition to header to indicate a wish to red= irect. But, then if of course depends on whether support for R-D is impleme= nted in proxies or not. If not implemented things will work as today - with= all the consequences. Note, however, that I am not suggesting to replace 3265bis with SUB 3xx - I= was only asking whether it could be used to solve the problems described. Regards, Christer=20 -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: 23. maaliskuuta 2010 9:14 To: Christer Holmberg Cc: SIPCORE Subject: Re: [sipcore] SUBSCRIBE 3xx - can it solve issues raised in 3265bi= s? [was INVITE 3xx and early media] The only real way you could deploy this would be with a 'proxy-require'=20 option tag that would have associated semantics that forbid proxies from fo= rking. I don't think that's very tractable at this point. /a On 3/22/10 11:36 PM, Christer Holmberg wrote: > Hi, > > Would it be possible to use the 3xx mechanism in order to solve the forki= ng related problems with SUB/NOT (as described in 3265bis)? > > The forking proxy would return a 3xx response to the SUBSCRIBE request, a= nd the UAC can then send individual SUBSCRIBE requests to each UAS? > > Regards, > > Christer > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > =20 From pkyzivat@cisco.com Tue Mar 23 07:46:53 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D7573A69E8 for ; Tue, 23 Mar 2010 07:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.869 X-Spam-Level: X-Spam-Status: No, score=-6.869 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] 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 nPAjOqlArA6C for ; Tue, 23 Mar 2010 07:46:51 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 6CDA73A6B94 for ; Tue, 23 Mar 2010 07:46:50 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAM9xqEurR7H+/2dsb2JhbACbLHOiY5khhH0E X-IronPort-AV: E=Sophos;i="4.51,295,1267401600"; d="scan'208";a="310965829" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 23 Mar 2010 14:47:09 +0000 Received: from [10.21.75.143] ([10.21.75.143]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2NEl9cK011803; Tue, 23 Mar 2010 14:47:09 GMT Message-ID: <4BA8D46D.90502@cisco.com> Date: Tue, 23 Mar 2010 10:47:09 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg References: <4B918DED.6090108@cisco.com> <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <001a01cabe3e$e7033f80$b509be80$@com> <4B950BC0.5090601@cisco.com> <0BD9B443-C89F-4D16-819D-C35D74BAFD1B@softarmor.com> <4B9531DA.7050002@cisco.com> <4BA86A35.90707@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] SUBSCRIBE 3xx - can it solve issues raised in 3265bis? [was INVITE 3xx and early media] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 14:46:53 -0000 Yes, of course its possible to use R-D to request redirect, as long as you are satisfied with the possibility that it won't be honored. Thanks, Paul Christer Holmberg wrote: > Hi, > > I don't think we can "forbid" the proxy from forking, and if it does we have to live with the consequences. > > The proposal for OPTIONS 3xx (and, I guess it would be the same for INVITE 3xx?) is to use the Request-Disposition to header to indicate a wish to redirect. But, then if of course depends on whether support for R-D is implemented in proxies or not. If not implemented things will work as today - with all the consequences. > > Note, however, that I am not suggesting to replace 3265bis with SUB 3xx - I was only asking whether it could be used to solve the problems described. > > Regards, > > Christer > > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: 23. maaliskuuta 2010 9:14 > To: Christer Holmberg > Cc: SIPCORE > Subject: Re: [sipcore] SUBSCRIBE 3xx - can it solve issues raised in 3265bis? [was INVITE 3xx and early media] > > The only real way you could deploy this would be with a 'proxy-require' > option tag that would have associated semantics that forbid proxies from forking. I don't think that's very tractable at this point. > > /a > > On 3/22/10 11:36 PM, Christer Holmberg wrote: >> Hi, >> >> Would it be possible to use the 3xx mechanism in order to solve the forking related problems with SUB/NOT (as described in 3265bis)? >> >> The forking proxy would return a 3xx response to the SUBSCRIBE request, and the UAC can then send individual SUBSCRIBE requests to each UAS? >> >> Regards, >> >> Christer >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From ranjit@motorola.com Tue Mar 23 09:34:15 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F03A13A695B for ; Tue, 23 Mar 2010 09:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.869 X-Spam-Level: X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 QZvjHc26YvqX for ; Tue, 23 Mar 2010 09:34:13 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with ESMTP id 6488D3A696C for ; Tue, 23 Mar 2010 09:34:01 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: ranjit@motorola.com X-Msg-Ref: server-13.tower-119.messagelabs.com!1269362059!55292690!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [136.182.1.15] Received: (qmail 31987 invoked from network); 23 Mar 2010 16:34:19 -0000 Received: from motgate5.mot.com (HELO motgate5.mot.com) (136.182.1.15) by server-13.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Mar 2010 16:34:19 -0000 Received: from il27exr04.cig.mot.com ([10.17.196.73]) by motgate5.mot.com (8.14.3/8.14.3) with ESMTP id o2NGYI8O021949 for ; Tue, 23 Mar 2010 09:34:18 -0700 (MST) Received: from az10vts04.mot.com (il27vts04.cig.mot.com [10.17.196.88]) by il27exr04.cig.mot.com (8.13.1/Vontu) with SMTP id o2NGYI95027834 for ; Tue, 23 Mar 2010 11:34:18 -0500 (CDT) Received: from ZMY16EXM66.ds.mot.com (zmy16exm66.ap.mot.com [10.179.4.26]) by il27exr04.cig.mot.com (8.13.1/8.13.0) with ESMTP id o2NGYHVR027814 for ; Tue, 23 Mar 2010 11:34:18 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Mar 2010 00:33:57 +0800 Message-ID: <750BBC72E178114F9DC4872EBFF29A5B0A3BF450@ZMY16EXM66.ds.mot.com> In-Reply-To: <4BA7AEE7.2030705@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Query on draft-ietf-sipcore-info-events-07 thread-index: AcrJ6Mt9ekqjj/BdR9eDjUHVvXkqWQAvSa8g References: <750BBC72E178114F9DC4872EBFF29A5B0A3BE70F@ZMY16EXM66.ds.mot.com> <4B9C1752.1000905@nostrum.com><7F5A16F5-69A7-448F-B33D-11891C8C8C97@nostrum.com> <4BA7AEE7.2030705@nostrum.com> From: "Avasarala Ranjit-A20990" To: "Adam Roach" , "Christer Holmberg" X-CFilter-Loop: Reflected Cc: sipcore@ietf.org Subject: Re: [sipcore] Query on draft-ietf-sipcore-info-events-07 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 16:34:15 -0000 Hi Now since the I-D does not specify any particular format or template for an INFO package, there is a very likely chance that someone could propose an INFO package as a XML package which is quite similar to an 3265 based event package. Now how can someone prevent use of this package with SUBSCRIBE / NOTIFY? Regards Ranjit -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach Sent: Monday, March 22, 2010 11:25 PM To: Christer Holmberg Cc: sipcore@ietf.org; Avasarala Ranjit-A20990 Subject: Re: [sipcore] Query on draft-ietf-sipcore-info-events-07 On 3/22/10 9:28 AM, Christer Holmberg wrote: > > Hi, > > =20 >> Also, I remember some discussion about whether it's ok to reuse event >> package names? (Is it ok for someone to create a "dialog" event=20 >> package for instance?) The draft is silent on this at the moment - is that on purpose? >> =20 > I see no reason to explicitly forbid it, since we're dealing with different namespaces. > =20 I agree. In fact, I believe that doing anything that implies that they're drawing from the same namespace is actually harmful: doing so can convey the incorrect impression that there might be some way to use an Event Package in INFO, or an INFO package in SUBSCRIBE. /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Tue Mar 23 09:51:15 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4C8D3A6D30 for ; Tue, 23 Mar 2010 09:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.844 X-Spam-Level: X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[AWL=2.625, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 31EWbykGugDE for ; Tue, 23 Mar 2010 09:51:11 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id DD7E73A6D0B for ; Tue, 23 Mar 2010 09:50:57 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-5b-4ba8f183bf09 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id B1.4F.23532.381F8AB4; Tue, 23 Mar 2010 17:51:15 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 23 Mar 2010 17:51:14 +0100 From: Christer Holmberg To: 'Avasarala Ranjit-A20990' , Adam Roach Date: Tue, 23 Mar 2010 17:51:13 +0100 Thread-Topic: [sipcore] Query on draft-ietf-sipcore-info-events-07 Thread-Index: AcrJ6Mt9ekqjj/BdR9eDjUHVvXkqWQAvSa8gAABidRA= Message-ID: References: <750BBC72E178114F9DC4872EBFF29A5B0A3BE70F@ZMY16EXM66.ds.mot.com> <4B9C1752.1000905@nostrum.com><7F5A16F5-69A7-448F-B33D-11891C8C8C97@nostrum.com> <4BA7AEE7.2030705@nostrum.com> <750BBC72E178114F9DC4872EBFF29A5B0A3BF450@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A3BF450@ZMY16EXM66.ds.mot.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Query on draft-ietf-sipcore-info-events-07 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 16:51:15 -0000 Hi,=20 >Now since the I-D does not specify any particular format or template for a= n INFO package,=20 >there is a very likely chance that someone could propose an INFO package a= s a XML package=20 >which is quite similar to an >3265 based event package. Now how can someone prevent use of this package = with SUBSCRIBE /=20 >NOTIFY? Technically you can use the same MIME message bodies both for INFO packages= and event packages, but if you want to use the message body as part of an = event package you need to register that event package. Regards, Christer -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Adam Roach Sent: Monday, March 22, 2010 11:25 PM To: Christer Holmberg Cc: sipcore@ietf.org; Avasarala Ranjit-A20990 Subject: Re: [sipcore] Query on draft-ietf-sipcore-info-events-07 On 3/22/10 9:28 AM, Christer Holmberg wrote: > > Hi, > > =20 >> Also, I remember some discussion about whether it's ok to reuse event >> package names? (Is it ok for someone to create a "dialog" event=20 >> package for instance?) The draft is silent on this at the moment - is that on purpose? >> =20 > I see no reason to explicitly forbid it, since we're dealing with different namespaces. > =20 I agree. In fact, I believe that doing anything that implies that they're drawing fr= om the same namespace is actually harmful: doing so can convey the incorrec= t impression that there might be some way to use an Event Package in INFO, = or an INFO package in SUBSCRIBE. /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From shida@ntt-at.com Tue Mar 23 10:02:48 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECF1A3A6D5C for ; Tue, 23 Mar 2010 10:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334] 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 aVTnuspPzuVJ for ; Tue, 23 Mar 2010 10:02:48 -0700 (PDT) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [69.56.159.26]) by core3.amsl.com (Postfix) with SMTP id 8D4D73A6C17 for ; Tue, 23 Mar 2010 10:02:37 -0700 (PDT) Received: (qmail 19224 invoked from network); 23 Mar 2010 17:03:39 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway07.websitewelcome.com with SMTP; 23 Mar 2010 17:03:39 -0000 Received: from dhcp-wireless-open-abg-29-69.meeting.ietf.org ([130.129.29.69]:60942) by gator465.hostgator.com with esmtpa (Exim 4.69) (envelope-from ) id 1Nu7VA-0003x5-Fl for sipcore@ietf.org; Tue, 23 Mar 2010 12:02:48 -0500 From: Shida Schubert Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 23 Mar 2010 10:02:37 -0700 Message-Id: <62134BAB-7E62-4A27-B69B-B781611A4EAB@ntt-at.com> To: SIPCORE Mime-Version: 1.0 (Apple Message framework v1077) X-Mailer: Apple Mail (2.1077) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com Subject: [sipcore] Clarifying the voicemail use-cases in RFC4244bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 17:02:49 -0000 As a service provider we always use the last target as a target of voicemail. But in a corporate world, call can be forwarded to different user and if no one picks up, policy is usually to retarget the call to the voicemail of the original target. As different deployment has different practice and requirements, it is difficult to say "A" is the only one you need to look at to solve the voicemail problem. We can add a normative text saying if used in PBX environment to use the first target within its administrative domain and say, in non-PBX environment use the last target. But that's not much different from what Mary had on the slide.. If that's not sufficient then I guess we can add an identifier which identifies a target with the notion of "use this target for voicemail" (May be use RFC4458?). Proxy that handles the call and diverts the call to the voicemail after executing whatever policy can add this identifier. Regards Shida From mary.ietf.barnes@gmail.com Tue Mar 23 10:30:29 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71AF93A6C18 for ; Tue, 23 Mar 2010 10:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 Qtu915fB4oOe for ; Tue, 23 Mar 2010 10:30:28 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 6FAD73A6A56 for ; Tue, 23 Mar 2010 10:30:28 -0700 (PDT) Received: by pwi10 with SMTP id 10so3511778pwi.31 for ; Tue, 23 Mar 2010 10:30:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GXs82STU3rPI+/QIXKngxsbTErwIiYBXOGlyfVSVB+I=; b=YVHaX+VdBQSwGh4mLjpef60A0VJn9LZQzyCZKQhgkp89pZiRRtU6DhzweOtm8oV2p8 pGg1r/+mOteRxeqs8MtEpNswQmB6jz56LtAEHP/YxbYyNC0T415RSU36ZeWSRI1/NPfv isT75zlLxap65x9j1jSiY/TxqeA6mLr3GZ+r8= 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=YM8Npcd+Z/t/JINS2RxAnmKG+541bGWEtljbLTPoKIab2BHtnmq5sYIsQ7OEHP8bvF FEjjinTzN5vr3L43nZ7hxkrWB4LHKxJAjsY2jcq7MGbbl5hEuGWHsCCjWX7vHdUQ/exp 2a8J2VMi0bpPEDYRgg6DAhUink/PHLRSHRmN4= MIME-Version: 1.0 Received: by 10.114.11.1 with SMTP id 1mr666108wak.52.1269365445226; Tue, 23 Mar 2010 10:30:45 -0700 (PDT) In-Reply-To: <62134BAB-7E62-4A27-B69B-B781611A4EAB@ntt-at.com> References: <62134BAB-7E62-4A27-B69B-B781611A4EAB@ntt-at.com> Date: Tue, 23 Mar 2010 12:30:45 -0500 Message-ID: <184b5e71003231030j1d6067d0o43bffabfb364841f@mail.gmail.com> From: Mary Barnes To: Shida Schubert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: SIPCORE Subject: Re: [sipcore] Clarifying the voicemail use-cases in RFC4244bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 17:30:29 -0000 I'm wondering if it wouldn't be useful to show these two different voicemail scenarios and thus we might be able to have normative text or at least recommended behavior. I believe the HI headers would be populated slightly differently in these scenarios, so this should work. In looking at all the other examples, the HI information that is relevant is deterministic. Thus, we might be able to make the text stronger although I'm not convinced we can do more than a BCP level of specification. Mary. On Tue, Mar 23, 2010 at 12:02 PM, Shida Schubert wrote: > > =A0As a service provider we always use the last target as a > target of voicemail. > > =A0But in a corporate world, call can be forwarded to different > user and if no one picks up, policy is usually to retarget > the call to the voicemail of the original target. > > =A0As different deployment has different practice and > requirements, it is difficult to say "A" is the only one > you need to look at to solve the voicemail problem. > > =A0We can add a normative text saying if used in PBX > environment to use the first target within its administrative > domain and say, in non-PBX environment use the > last target. But that's not much different from what Mary > had on the slide.. > > =A0If that's not sufficient then I guess =A0we can add > an identifier which identifies a target with the notion of > =A0"use this target for voicemail" (May be use RFC4458?). > > =A0Proxy that handles the call and diverts the call to the > voicemail after executing whatever policy can add > this identifier. > > =A0Regards > =A0Shida > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From dworley@avaya.com Tue Mar 23 11:03:50 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60F033A6C17 for ; Tue, 23 Mar 2010 11:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 plAUJga7YL5T for ; Tue, 23 Mar 2010 11:03:49 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 97A093A6991 for ; Tue, 23 Mar 2010 11:03:49 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.51,296,1267419600"; d="scan'208";a="210479194" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 23 Mar 2010 14:04:08 -0400 X-IronPort-AV: E=Sophos;i="4.51,296,1267419600"; d="scan'208";a="444690212" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 23 Mar 2010 14:04:08 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.214]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Tue, 23 Mar 2010 14:04:07 -0400 From: "WORLEY, DALE R (DALE)" To: Christer Holmberg , SIPCORE Date: Tue, 23 Mar 2010 14:01:20 -0400 Thread-Topic: [sipcore] SUBSCRIBE 3xx - can it solve issues raised in 3265bis? [was INVITE 3xx and early media] Thread-Index: Acq/B5gYbGS2mSzGTiOh0LxJFIIdywLStXHwABgaaf0= Message-ID: References: <4B918DED.6090108@cisco.com> <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <001a01cabe3e$e7033f80$b509be80$@com> <4B950BC0.5090601@cisco.com> <0BD9B443-C89F-4D16-819D-C35D74BAFD1B@softarmor.com> <4B9531DA.7050002@cisco.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] SUBSCRIBE 3xx - can it solve issues raised in 3265bis? [was INVITE 3xx and early media] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 18:03:50 -0000 ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Chri= ster Holmberg [christer.holmberg@ericsson.com] Would it be possible to use the 3xx mechanism in order to solve the forking= related problems with SUB/NOT (as described in 3265bis)? The forking proxy would return a 3xx response to the SUBSCRIBE request, and= the UAC can then send individual SUBSCRIBE requests to each UAS? _______________________________________________ A UA can send SUBSCRIBE with "Request-Disposition: no-recurse", but there's= no guarantee that every proxy on the way will obey it. Dale From keith.drage@alcatel-lucent.com Tue Mar 23 12:25:28 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D4DB3A67F9 for ; Tue, 23 Mar 2010 12:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.119 X-Spam-Level: X-Spam-Status: No, score=-5.119 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, 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 X8Uwrs6z5vTE for ; Tue, 23 Mar 2010 12:25:27 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id E2EC43A6358 for ; Tue, 23 Mar 2010 12:25:26 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o2NJPfDQ031081 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 23 Mar 2010 20:25:41 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 23 Mar 2010 20:25:41 +0100 From: "DRAGE, Keith (Keith)" To: Avasarala Ranjit-A20990 , Adam Roach , Christer Holmberg Date: Tue, 23 Mar 2010 20:25:40 +0100 Thread-Topic: [sipcore] Query on draft-ietf-sipcore-info-events-07 Thread-Index: AcrJ6Mt9ekqjj/BdR9eDjUHVvXkqWQAvSa8gAAYNo6A= Message-ID: References: <750BBC72E178114F9DC4872EBFF29A5B0A3BE70F@ZMY16EXM66.ds.mot.com> <4B9C1752.1000905@nostrum.com><7F5A16F5-69A7-448F-B33D-11891C8C8C97@nostrum.com> <4BA7AEE7.2030705@nostrum.com> <750BBC72E178114F9DC4872EBFF29A5B0A3BF450@ZMY16EXM66.ds.mot.com> In-Reply-To: <750BBC72E178114F9DC4872EBFF29A5B0A3BF450@ZMY16EXM66.ds.mot.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Query on draft-ietf-sipcore-info-events-07 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 19:25:28 -0000 You cannot prevent it, because IETF are not the protocol police. However if you wish to make a claim of conformance to both the event packag= e specifications and the info package specifications, you will have to impl= ement each using an appropriately registered descriptor of the package. Pre= sumably expert review on either path will raise some issues with you trying= to do this, unless you demonstrate that what you are doing actually makes = sense, rather than just providing two ways of using the protocol to do the = same thing. regards Keith=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Avasarala Ranjit-A20990 > Sent: Tuesday, March 23, 2010 4:34 PM > To: Adam Roach; Christer Holmberg > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Query on draft-ietf-sipcore-info-events-07 >=20 > Hi >=20 > Now since the I-D does not specify any particular format or=20 > template for an INFO package, there is a very likely chance=20 > that someone could propose an INFO package as a XML package=20 > which is quite similar to an > 3265 based event package. Now how can someone prevent use of=20 > this package with SUBSCRIBE / NOTIFY? >=20 > Regards > Ranjit >=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach > Sent: Monday, March 22, 2010 11:25 PM > To: Christer Holmberg > Cc: sipcore@ietf.org; Avasarala Ranjit-A20990 > Subject: Re: [sipcore] Query on draft-ietf-sipcore-info-events-07 >=20 > On 3/22/10 9:28 AM, Christer Holmberg wrote: > > > > Hi, > > > > =20 > >> Also, I remember some discussion about whether it's ok to=20 > reuse event >=20 > >> package names? (Is it ok for someone to create a "dialog" event=20 > >> package for instance?) The draft is silent on this at the=20 > moment - is > that on purpose? > >> =20 > > I see no reason to explicitly forbid it, since we're dealing with > different namespaces. > > =20 >=20 > I agree. >=20 > In fact, I believe that doing anything that implies that=20 > they're drawing from the same namespace is actually harmful:=20 > doing so can convey the incorrect impression that there might=20 > be some way to use an Event Package in INFO, or an INFO=20 > package in SUBSCRIBE. >=20 > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From pkyzivat@cisco.com Tue Mar 23 13:36:51 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 481AD3A691F for ; Tue, 23 Mar 2010 13:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.869 X-Spam-Level: X-Spam-Status: No, score=-6.869 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] 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 zsqpCuZkifXO for ; Tue, 23 Mar 2010 13:36:50 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 532043A68C0 for ; Tue, 23 Mar 2010 13:36:50 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAM3DqEurR7H+/2dsb2JhbACbH3OlZ4phjjyEfQQ X-IronPort-AV: E=Sophos;i="4.51,296,1267401600"; d="scan'208";a="501640891" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 23 Mar 2010 20:37:09 +0000 Received: from [10.21.77.201] ([10.21.77.201]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o2NKb921022608; Tue, 23 Mar 2010 20:37:09 GMT Message-ID: <4BA92679.2080001@cisco.com> Date: Tue, 23 Mar 2010 16:37:13 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Mary Barnes References: <62134BAB-7E62-4A27-B69B-B781611A4EAB@ntt-at.com> <184b5e71003231030j1d6067d0o43bffabfb364841f@mail.gmail.com> In-Reply-To: <184b5e71003231030j1d6067d0o43bffabfb364841f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Clarifying the voicemail use-cases in RFC4244bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 20:36:51 -0000 IMO both mentioned options are broken. The proposed scenario is when Alice calls Bob, Bob forwards to Carol, and Carol forwards to VM. If Carol didn't have VM, the call would have failed back to Bob, and he might have forwarded to his VM, or he might have then forwarded the call to Dave. When Carol forwards to VM she preempts Bob's ability to make the next policy decision. The given scenarios for handling this mis the point - they don't give the control back to Bob. Instead they propose to have Carol's VM server use Bob's VM mailbox. This at best works if Bob and Carol use the same VM server, or servers that have a special relationship with one another. And they still presume that Carol's VM server knows the policy that Bob wants to use. Having all the info in HI does not solve this problem. The real problem is not one of giving Carol's VM server a list of mailboxes to choose among. The problem is to convey part of Bob's policy to Carol - namely whether to delegate the handling of call failure to Carol, or if instead Carol should simply fail the call attempt if there is no answer from Carol, and let Bob deal with that. That is all possible with Callerprefs. If implemented it would give as good or better a result in all cases, and doesn't require HI. Thanks, Paul Mary Barnes wrote: > I'm wondering if it wouldn't be useful to show these two different > voicemail scenarios and thus we might be able to have normative text > or at least recommended behavior. I believe the HI headers would be > populated slightly differently in these scenarios, so this should > work. In looking at all the other examples, the HI information that > is relevant is deterministic. Thus, we might be able to make the > text stronger although I'm not convinced we can do more than a BCP > level of specification. > > Mary. > > On Tue, Mar 23, 2010 at 12:02 PM, Shida Schubert wrote: >> As a service provider we always use the last target as a >> target of voicemail. >> >> But in a corporate world, call can be forwarded to different >> user and if no one picks up, policy is usually to retarget >> the call to the voicemail of the original target. >> >> As different deployment has different practice and >> requirements, it is difficult to say "A" is the only one >> you need to look at to solve the voicemail problem. >> >> We can add a normative text saying if used in PBX >> environment to use the first target within its administrative >> domain and say, in non-PBX environment use the >> last target. But that's not much different from what Mary >> had on the slide.. >> >> If that's not sufficient then I guess we can add >> an identifier which identifies a target with the notion of >> "use this target for voicemail" (May be use RFC4458?). >> >> Proxy that handles the call and diverts the call to the >> voicemail after executing whatever policy can add >> this identifier. >> >> Regards >> Shida >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From mary.ietf.barnes@gmail.com Tue Mar 23 14:19:07 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA1CA3A6C68 for ; Tue, 23 Mar 2010 14:19:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.169 X-Spam-Level: X-Spam-Status: No, score=-0.169 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 Q4G2dQGDl8WP for ; Tue, 23 Mar 2010 14:19:06 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 948403A6CB3 for ; Tue, 23 Mar 2010 14:18:50 -0700 (PDT) Received: by pwi10 with SMTP id 10so3679585pwi.31 for ; Tue, 23 Mar 2010 14:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9ClrstVMl6oxVEkwffX8br5tR/60gJCyLI2oisFwxMg=; b=RewcINjGBXlpkWU28ovTDALVUzBh1CyoN2vbNoZAOXAyyjnbI1oss1gcGanScRT/0y 6SZHML+xphzETwyRr4gMUa7pfl9/MFqSKjg1ZL8biHHMQ49WzcxSFYWhCucHAY329RHW FLbS5/E3ek/TZ6indUFNu2r7v/S8J7CX659+0= 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=p7uw7TCn4L3EV6FK/KJ5ZvFcg2PeJICZsRNEhfO8OYc1H2UvuGdOWq3CLTehVqxhHd Vvti/dRXvMc1iEN3UL8K8sjH8o+31CT6VgCoVPCTEbMNVN7veX4b+BpxE88yio2LW+B/ 72Pu1U6mrj3BHA/nzGNJfe6w6d8qwOZ10zXVo= MIME-Version: 1.0 Received: by 10.141.108.9 with SMTP id k9mr1850932rvm.226.1269379147253; Tue, 23 Mar 2010 14:19:07 -0700 (PDT) In-Reply-To: <4BA92679.2080001@cisco.com> References: <62134BAB-7E62-4A27-B69B-B781611A4EAB@ntt-at.com> <184b5e71003231030j1d6067d0o43bffabfb364841f@mail.gmail.com> <4BA92679.2080001@cisco.com> Date: Tue, 23 Mar 2010 16:19:07 -0500 Message-ID: <184b5e71003231419g44acf9feo56e67bb135053622@mail.gmail.com> From: Mary Barnes To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: SIPCORE Subject: Re: [sipcore] Clarifying the voicemail use-cases in RFC4244bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 21:19:07 -0000 Paul, That's one reason why we note that the call flows are examples and not prescriptive for implementing the services ;) I don't entirely agree that callerprefs is all that you need, but I will agree that trying to document some of these services as only needing History-Info is not necessarily a good idea, although many of them do just need History-Info. We had an offline discussion and were considering that the best approach would be to pull the call flows (except perhaps the first one) out into a separate document to progress as a BCP - that way we can include the use of other mechanisms and optimize the recommendations. Along with doing that, we propose to update the UAS processing and the Application consideration sections of 4244bis to have more discussion of using the new tags for services (without prescribing services per se) would hopefully resolve the concern raised by Cullen (and others) about the core document not describing how to use the header (which was the agreed approach for RFC 4244, but it seems folks realize that wasn't particularly constructive). Separating the detailed flows in this manner is also more consistent with how we've done protocol work in most of the other RAI WGs. We would of course have to determine the best home for a call flow document. Thanks, Mary. On Tue, Mar 23, 2010 at 3:37 PM, Paul Kyzivat wrote: > IMO both mentioned options are broken. The proposed scenario is when Alic= e > calls Bob, Bob forwards to Carol, and Carol forwards to VM. > > If Carol didn't have VM, the call would have failed back to Bob, and he > might have forwarded to his VM, or he might have then forwarded the call = to > Dave. When Carol forwards to VM she preempts Bob's ability to make the ne= xt > policy decision. > > The given scenarios for handling this mis the point - they don't give the > control back to Bob. Instead they propose to have Carol's VM server use > Bob's VM mailbox. This at best works if Bob and Carol use the same VM > server, or servers that have a special relationship with one another. =A0= And > they still presume that Carol's VM server knows the policy that Bob wants= to > use. > > Having all the info in HI does not solve this problem. The real problem i= s > not one of giving Carol's VM server a list of mailboxes to choose among. = The > problem is to convey part of Bob's policy to Carol - namely whether to > delegate the handling of call failure to Carol, or if instead Carol shoul= d > simply fail the call attempt if there is no answer from Carol, and let Bo= b > deal with that. > > That is all possible with Callerprefs. If implemented it would give as go= od > or better a result in all cases, and doesn't require HI. > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > > Mary Barnes wrote: >> >> I'm wondering if it wouldn't be useful to show these two different >> voicemail scenarios and thus we might be able to have normative text >> or at least recommended behavior. I believe the HI headers would be >> populated slightly differently in these scenarios, so this should >> work. =A0In looking at all the other examples, the HI information that >> is relevant is deterministic. =A0 Thus, we might be able to make the >> text stronger although I'm not convinced we can do more than a BCP >> level of specification. >> >> Mary. >> >> On Tue, Mar 23, 2010 at 12:02 PM, Shida Schubert wrot= e: >>> >>> =A0As a service provider we always use the last target as a >>> target of voicemail. >>> >>> =A0But in a corporate world, call can be forwarded to different >>> user and if no one picks up, policy is usually to retarget >>> the call to the voicemail of the original target. >>> >>> =A0As different deployment has different practice and >>> requirements, it is difficult to say "A" is the only one >>> you need to look at to solve the voicemail problem. >>> >>> =A0We can add a normative text saying if used in PBX >>> environment to use the first target within its administrative >>> domain and say, in non-PBX environment use the >>> last target. But that's not much different from what Mary >>> had on the slide.. >>> >>> =A0If that's not sufficient then I guess =A0we can add >>> an identifier which identifies a target with the notion of >>> =A0"use this target for voicemail" (May be use RFC4458?). >>> >>> =A0Proxy that handles the call and diverts the call to the >>> voicemail after executing whatever policy can add >>> this identifier. >>> >>> =A0Regards >>> =A0Shida >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > From christer.holmberg@ericsson.com Tue Mar 23 16:05:25 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E3E9A3A6B79 for ; Tue, 23 Mar 2010 16:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.53 X-Spam-Level: * X-Spam-Status: No, score=1.53 tagged_above=-999 required=5 tests=[AWL=-3.500, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FB_CIALIS_LEO3=3.899] 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 MGwnn9r+V0K9 for ; Tue, 23 Mar 2010 16:05:24 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 65E0B3A6B61 for ; Tue, 23 Mar 2010 16:05:24 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-88-4ba949463962 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id B2.A3.23740.64949AB4; Wed, 24 Mar 2010 00:05:42 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 24 Mar 2010 00:05:40 +0100 From: Christer Holmberg To: 'Paul Kyzivat' Date: Wed, 24 Mar 2010 00:05:39 +0100 Thread-Topic: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] Thread-Index: Acq+FehRkl3VTiIMR6CGH/oE5p4IjQMxZc7Q Message-ID: References: <4B918DED.6090108@cisco.com> , <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> In-Reply-To: <4B93D8A6.1040105@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 23:05:26 -0000 Hi, =20 >>>>>If you want parallel forking, even if done by the UAC, there is no=20 >>>>>good solution to this problem. The parallel early media is going to=20 >>>>>be generated and something must happen to it. The only question is whi= ch of the bad=20 >>>>>solutions you prefer. >>>>> >>>>>For instance, you may have one stream asking you to enter an access=20 >>>>>code, another playing an out-of- service tone, and a third sending=20 >>>>>no media which will eventually pick up with a real person. What would = you *like* for the=20 >>>>>caller to hear? >>>>For this reasons you have B2BUAs, application servers, gating nodes=20 >>>>etc, that at least TRY to deal with the problem, to ensure that whateve= r the user=20 >>>>eventually hears, at least the quality will be good. >>>For what that's worth! You get a good quality rendering of that=20 >>>out-of-service tone, and so hang up even though the call was ringing=20 >>>elsewhere, but without any ringback. >>> >>>I guess we just have to "let a 1000 flowers bloom" on this one. >>=20 >>As I've said before, I don't think there is a very big risk that the "wro= ng" early media=20 >>would be presented to you. >> >> >>Leaving PSTN interworking aside, most early media (at least the one of re= al importance) will=20 >>be generated by application servers/B2BUAs in the network, and they will = normally be able to=20 >>control the media pretty well. A SIP UA might generate something, but unl= ess it's a Henry=20 >>Sinnreich device (where all the services are implemented in the end devic= e :) I don't think=20 >>UAs will normally send service related announcement etc. > >I gather you are arguing that there just aren't many calls with early medi= a. But "leaving=20 >PSTN interworking aside" isn't really fair, since there is so much of that= . I agree. My intention was only to say that the only "endpoints" that are li= kely to send early media in most cases are PSTN networks. >For instance there could be a lot of the google service that simply forks = calls to multiple=20 >PSTN lines. And don't most pstn calls have in-band ringback? That would ge= t multiple early=20 >media, though if its just ringback it doesn't matter if you play it or not= . But if one of=20 >those becomes defective and starts playing out of service messages then it= does matter which=20 >one you play. Yes. >>Of course, if you have application servers sending media both in the orig= inating and=20 >>terminating network, there need to be some policy procedures on which med= ia has higher=20 >>priority etc. > >Policy doesn't help a lot. It content, not policy, that determines which i= s important to=20 >hear. Sure, but there can be policy that says "My early media is more important t= hat anything else". Having said that, having information abouot the content would probably be v= ery useful. However, I don't think it would help in the PSTN interworking c= ase, becase the MGC most likely does not know what early media (in-band rin= ging or service anouncement) comes from the PSTN network. >Perhaps the best we can do is discourage the use of early media for anythi= ng important. I guess it depends on what you mean by "important", but there are a number = of services that rely on early media. Regards, Christer >> Christer Holmberg wrote: >>> Hi, >>> >>> >>>> I would like to expand on this issue a little. Sup= pose I have at my >>>> home proxy a policy whereby calls go to B1 and B2 = in parallel, and >>>> after T seconds of no answer calls instead go to B= 3 (voicemail, >>>> perhaps). There is no way that the proxy could con= vey that policy in >>>> a 3xx response to the UAC. To make this policy (or= similar policies) >>>> work, the proxy would need to manufacturer tempora= ry contact URIs >>>> that map to B1 and B2 and send these back in a 302= . It would then >>>> need to hope that the UAC does indeed establish ne= w requests in >>>> parallel to the two temporary contacts for B1 and = B2. The proxy >>>> would need to treat the two requests as related an= d if both are >>>> unanswered after T seconds, reject one with a 4xx = and the other with >>>> a 302 (this time with a third temporary contact UR= I mapped to B3). >>>> So policy CAN be met by the proxy, although with d= ependence on the >>>> UAC doing the right thing. >>>> >>>> >>>> So here, we either need your home proxy to be a home B2BUA= (After all, >>>> what happens when B1 and B2 both send back early media, or= both get >>>> answered by a bot?), OR we need a richer 302 response that= conveys >>>> "Try these two destinations in parallel, and if neither re= plies in X >>>> seconds, try this third destination). >>>> >>>> But, the UAC still doesn't know whether B1 and B2 would send early= media. >>>> >>>> By offering different ports to B1 and B2 (especially with the media-to= -signaling coupling extensions that have been proposed) UAC at least knows = which one of B1 and B2 each stream is coming from. >>> Yes. But, there are other mechanisms to solve that, and it still doesn'= t solve the fundamental problem: the UAC can receive multiple media streams= associated with multiple early dialogs. >>> >>> Also, in bandwidth sensitive access networks there is only limited band= width, normally calculated based on the need for media associated with one = early dialog. Even if the UAC is able to select and play only one stream to= the user, the voice quality will suffer due to too little bandwidth. >>> >>> Regards, >>> >>> Christer >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> From pkyzivat@cisco.com Tue Mar 23 16:11:02 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97AD53A6A60 for ; Tue, 23 Mar 2010 16:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.97 X-Spam-Level: X-Spam-Status: No, score=-2.97 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FB_CIALIS_LEO3=3.899, RCVD_IN_DNSWL_HI=-8] 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 OwFNP108IpYQ for ; Tue, 23 Mar 2010 16:11:00 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 005E23A6CDA for ; Tue, 23 Mar 2010 16:10:59 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPXmqEurRN+J/2dsb2JhbACbJnOmPJkTglWCKAQ X-IronPort-AV: E=Sophos;i="4.51,297,1267401600"; d="scan'208";a="501713529" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 23 Mar 2010 23:11:19 +0000 Received: from [10.21.76.130] ([10.21.76.130]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o2NNBH5h017042; Tue, 23 Mar 2010 23:11:18 GMT Message-ID: <4BA94A93.4010909@cisco.com> Date: Tue, 23 Mar 2010 19:11:15 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg References: <4B918DED.6090108@cisco.com> , <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 23:11:02 -0000 My conclusion is that none of the suggestions being thrown around fundamentally improve the handling of early media in any way. Its just a mess, and there is no feasible solution. Thanks, Paul Christer Holmberg wrote: > Hi, > >>>>>> If you want parallel forking, even if done by the UAC, there is no >>>>>> good solution to this problem. The parallel early media is going to >>>>>> be generated and something must happen to it. The only question is which of the bad >>>>>> solutions you prefer. >>>>>> >>>>>> For instance, you may have one stream asking you to enter an access >>>>>> code, another playing an out-of- service tone, and a third sending >>>>>> no media which will eventually pick up with a real person. What would you *like* for the >>>>>> caller to hear? >>>>> For this reasons you have B2BUAs, application servers, gating nodes >>>>> etc, that at least TRY to deal with the problem, to ensure that whatever the user >>>>> eventually hears, at least the quality will be good. >>>> For what that's worth! You get a good quality rendering of that >>>> out-of-service tone, and so hang up even though the call was ringing >>>> elsewhere, but without any ringback. >>>> >>>> I guess we just have to "let a 1000 flowers bloom" on this one. >>> As I've said before, I don't think there is a very big risk that the "wrong" early media >>> would be presented to you. >>> >>> >>> Leaving PSTN interworking aside, most early media (at least the one of real importance) will >>> be generated by application servers/B2BUAs in the network, and they will normally be able to >>> control the media pretty well. A SIP UA might generate something, but unless it's a Henry >>> Sinnreich device (where all the services are implemented in the end device :) I don't think >>> UAs will normally send service related announcement etc. >> I gather you are arguing that there just aren't many calls with early media. But "leaving >> PSTN interworking aside" isn't really fair, since there is so much of that. > > I agree. My intention was only to say that the only "endpoints" that are likely to send early media in most cases are PSTN networks. > >> For instance there could be a lot of the google service that simply forks calls to multiple >> PSTN lines. And don't most pstn calls have in-band ringback? That would get multiple early >> media, though if its just ringback it doesn't matter if you play it or not. But if one of >> those becomes defective and starts playing out of service messages then it does matter which >> one you play. > > Yes. > >>> Of course, if you have application servers sending media both in the originating and >>> terminating network, there need to be some policy procedures on which media has higher >>> priority etc. >> Policy doesn't help a lot. It content, not policy, that determines which is important to >> hear. > > Sure, but there can be policy that says "My early media is more important that anything else". > > Having said that, having information abouot the content would probably be very useful. However, I don't think it would help in the PSTN interworking case, becase the MGC most likely does not know what early media (in-band ringing or service anouncement) comes from the PSTN network. > >> Perhaps the best we can do is discourage the use of early media for anything important. > > I guess it depends on what you mean by "important", but there are a number of services that rely on early media. > > Regards, > > Christer > > > > > > >>> Christer Holmberg wrote: >>>> Hi, >>>> >>>> >>>>> I would like to expand on this issue a little. Suppose I have at my >>>>> home proxy a policy whereby calls go to B1 and B2 in parallel, and >>>>> after T seconds of no answer calls instead go to B3 (voicemail, >>>>> perhaps). There is no way that the proxy could convey that policy in >>>>> a 3xx response to the UAC. To make this policy (or similar policies) >>>>> work, the proxy would need to manufacturer temporary contact URIs >>>>> that map to B1 and B2 and send these back in a 302. It would then >>>>> need to hope that the UAC does indeed establish new requests in >>>>> parallel to the two temporary contacts for B1 and B2. The proxy >>>>> would need to treat the two requests as related and if both are >>>>> unanswered after T seconds, reject one with a 4xx and the other with >>>>> a 302 (this time with a third temporary contact URI mapped to B3). >>>>> So policy CAN be met by the proxy, although with dependence on the >>>>> UAC doing the right thing. >>>>> >>>>> >>>>> So here, we either need your home proxy to be a home B2BUA (After all, >>>>> what happens when B1 and B2 both send back early media, or both get >>>>> answered by a bot?), OR we need a richer 302 response that conveys >>>>> "Try these two destinations in parallel, and if neither replies in X >>>>> seconds, try this third destination). >>>>> >>>>> But, the UAC still doesn't know whether B1 and B2 would send early media. >>>>> >>>>> By offering different ports to B1 and B2 (especially with the media-to-signaling coupling extensions that have been proposed) UAC at least knows which one of B1 and B2 each stream is coming from. >>>> Yes. But, there are other mechanisms to solve that, and it still doesn't solve the fundamental problem: the UAC can receive multiple media streams associated with multiple early dialogs. >>>> >>>> Also, in bandwidth sensitive access networks there is only limited bandwidth, normally calculated based on the need for media associated with one early dialog. Even if the UAC is able to select and play only one stream to the user, the voice quality will suffer due to too little bandwidth. >>>> >>>> Regards, >>>> >>>> Christer >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> > From christer.holmberg@ericsson.com Tue Mar 23 16:16:05 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA1AA3A6CBB for ; Tue, 23 Mar 2010 16:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.844 X-Spam-Level: X-Spam-Status: No, score=-2.844 tagged_above=-999 required=5 tests=[AWL=2.625, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 Wo1F0cjdGm0L for ; Tue, 23 Mar 2010 16:16:05 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 9EB0F3A6C87 for ; Tue, 23 Mar 2010 16:16:04 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-38-4ba94bc60126 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id CA.06.23532.6CB49AB4; Wed, 24 Mar 2010 00:16:22 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 24 Mar 2010 00:16:21 +0100 From: Christer Holmberg To: 'Paul Kyzivat' , Gilad Shaham Date: Wed, 24 Mar 2010 00:16:21 +0100 Thread-Topic: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] Thread-Index: Acq+zRppTdNQlnLcQ66Hk7th7DRELAMEacjA Message-ID: References: <4B918DED.6090108@cisco.com> , <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <001a01cabe3e$e7033f80$b509be80$@com> <4B950BC0.5090601@cisco.com> In-Reply-To: <4B950BC0.5090601@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: 'SIPCORE' Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 23:16:05 -0000 Hi, Maybe RFC 4574 could be used. Regards, Christer =20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: 8. maaliskuuta 2010 16:38 To: Gilad Shaham Cc: Christer Holmberg; 'SIPCORE' Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork= or not to fork?] Gilad Shaham wrote: > Paul Kyzivat wrote: >> Perhaps the best we can do is discourage the use of early media for=20 >> anything important. >> >=20 > I'm not sure this scenario is that common, but if it is something of=20 > interest, perhaps it's possible to add a header/parameter conveying=20 > the nature of the media stream (ringback, service message, voice,=20 > etc.). This is similar to the content-disposition handling parameter,=20 > but more informative than "optional" and "required". This way, a B2BUA=20 > would be able to choose the stream to forward and even without a=20 > B2BUA, an endpoint receiving several streams would know which stream to p= lay back to the user. I guess this would be something like the Reason header, or maybe it would r= eally be the Reason header, though it would take some changes to allow it f= or that. Another possibility for this is Alert-Info. The response code, possibly augmented with the Reason header, would work fo= r things like out of service that are going to cause the call to fail.=20 However the callee has to have confidence that the caller will be properly = informed of the case. The Alert-Info containing a URN can potentially work for common things that= aren't going to cause the call to fail. But that isn't sufficient if there= is variable information to convey to the caller, unless it is done with wi= th a URI that can be dereferenced and rendered. The latter would be an alte= rnative if we could convince UAs to render such things.=20 My impression is that there is reluctance to do so, though it really isn't = much different from rendering an early media string. But none of this will help with many pstn interop cases where the reason is= n't known except through the content of the media. Thanks, Paul From christer.holmberg@ericsson.com Tue Mar 23 16:28:44 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E9E53A6CDA for ; Tue, 23 Mar 2010 16:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.369 X-Spam-Level: X-Spam-Status: No, score=-3.369 tagged_above=-999 required=5 tests=[AWL=2.100, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 jjHRf-x5-SaC for ; Tue, 23 Mar 2010 16:28:43 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id C0C5F3A6B99 for ; Tue, 23 Mar 2010 16:28:42 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-31-4ba94ebdb38d Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 51.66.23532.DBE49AB4; Wed, 24 Mar 2010 00:29:01 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 24 Mar 2010 00:29:00 +0100 From: Christer Holmberg To: 'Dean Willis' , Paul Kyzivat Date: Wed, 24 Mar 2010 00:28:59 +0100 Thread-Topic: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] Thread-Index: Acq/B1DzapO2CMWvRHutj7va2RQStgL2BGDg Message-ID: References: <4B918DED.6090108@cisco.com> , <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <001a01cabe3e$e7033f80$b509be80$@com> <4B950BC0.5090601@cisco.com> <0BD9B443-C89F-4D16-819D-C35D74BAFD1B@softarmor.com> <4B9531DA.7050002@cisco.com> <50DAE276-5E08-4760-9FCC-035BEFF2C470@softarmor.com> In-Reply-To: <50DAE276-5E08-4760-9FCC-035BEFF2C470@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: 'SIPCORE' , Gilad Shaham Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 23:28:44 -0000 Hi,=20 >>I wasn't thinking of discriminating the early media streams, but=20 >>rather finding ways to eliminate them while retaining their intent. > >That would be cool. Requires a business model change at PSTN gateways, whi= ch IMHO should go=20 >to 200 OK (and a fully-connected dialog) before/ while starting the IAM or= equivalent on the=20 >PSTN side. But too many yerkaloids want to bill on 200OK. It is not only about business models. Using 200 OK would ensure that all but one dialog is terminated, but there = can still be multiple sources of early media. >But for non-gateway nodes, we could certainly do something along the lines= of a 1xx header or=20 >specific cause-codes as different 1XX response types. > > >Several years ago Rohan proposed a model where the UAC did another O/=20 >A with each early dialog to move its media to a distinct port. That=20 >way it could then associate the signaling with a particular media=20 >stream. Seems cumbersome, but maybe it will take something like that=20 >to solve the problem. > >Only works once the UAS sends back a 1xx of some sort. Some nodes just sen= d media. For=20 >gateways, we therefore have to differentiate in the OFFER as seen by the U= AS, which means=20 >sending a different offer to each UAS, which means NO FORKING! I think that UASs should send back a 1xx of some sort. >Or maybe we could do yet-another BCP on gateways to require early- dialog = before media cut- >through. This might be worth exploring. Of course, this requires updating = all the gateways=20 >before it can be relied on, or at least probing for compliant gateways wit= h a Require. Or, we may want to only SDP only to establish a control channel for some ot= her media negotiation protocol, used between the UAC and each UAS ;) Regards, Christer _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Tue Mar 23 16:34:04 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5B433A69EF for ; Tue, 23 Mar 2010 16:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.77 X-Spam-Level: X-Spam-Status: No, score=-1.77 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FB_CIALIS_LEO3=3.899, 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 fyy9E2hU93yw for ; Tue, 23 Mar 2010 16:34:03 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id C98173A68AF for ; Tue, 23 Mar 2010 16:34:02 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-5f-4ba94ffca6b5 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id B0.86.23532.CFF49AB4; Wed, 24 Mar 2010 00:34:20 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 24 Mar 2010 00:34:20 +0100 From: Christer Holmberg To: 'Paul Kyzivat' Date: Wed, 24 Mar 2010 00:34:19 +0100 Thread-Topic: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] Thread-Index: AcrK3ispeEfx5esWSya1tWa59K+dJwAAwOVQ Message-ID: References: <4B918DED.6090108@cisco.com> , <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <4BA94A93.4010909@cisco.com> In-Reply-To: <4BA94A93.4010909@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Mar 2010 23:34:05 -0000 Hi, Since there is no protocol mechanism to handle this, I guess policy (whatev= er it is based upon) is the only option. It may work well or bad, but if it= 's the only option... Regards, Christer=20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: 24. maaliskuuta 2010 1:11 To: Christer Holmberg Cc: 'Dean Willis'; SIPCORE Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork= or not to fork?] My conclusion is that none of the suggestions being thrown around fundament= ally improve the handling of early media in any way. Its just a mess, and t= here is no feasible solution. Thanks, Paul Christer Holmberg wrote: > Hi, > =20 >>>>>> If you want parallel forking, even if done by the UAC, there is=20 >>>>>> no good solution to this problem. The parallel early media is=20 >>>>>> going to be generated and something must happen to it. The only=20 >>>>>> question is which of the bad solutions you prefer. >>>>>> >>>>>> For instance, you may have one stream asking you to enter an=20 >>>>>> access code, another playing an out-of- service tone, and a third=20 >>>>>> sending no media which will eventually pick up with a real=20 >>>>>> person. What would you *like* for the caller to hear? >>>>> For this reasons you have B2BUAs, application servers, gating=20 >>>>> nodes etc, that at least TRY to deal with the problem, to ensure=20 >>>>> that whatever the user eventually hears, at least the quality will be= good. >>>> For what that's worth! You get a good quality rendering of that=20 >>>> out-of-service tone, and so hang up even though the call was=20 >>>> ringing elsewhere, but without any ringback. >>>> >>>> I guess we just have to "let a 1000 flowers bloom" on this one. >>> As I've said before, I don't think there is a very big risk that the=20 >>> "wrong" early media would be presented to you. >>> >>> >>> Leaving PSTN interworking aside, most early media (at least the one=20 >>> of real importance) will be generated by application servers/B2BUAs=20 >>> in the network, and they will normally be able to control the media=20 >>> pretty well. A SIP UA might generate something, but unless it's a=20 >>> Henry Sinnreich device (where all the services are implemented in the e= nd device :) I don't think UAs will normally send service related announcem= ent etc. >> I gather you are arguing that there just aren't many calls with early=20 >> media. But "leaving PSTN interworking aside" isn't really fair, since th= ere is so much of that. >=20 > I agree. My intention was only to say that the only "endpoints" that are = likely to send early media in most cases are PSTN networks. >=20 >> For instance there could be a lot of the google service that simply=20 >> forks calls to multiple PSTN lines. And don't most pstn calls have=20 >> in-band ringback? That would get multiple early media, though if its=20 >> just ringback it doesn't matter if you play it or not. But if one of=20 >> those becomes defective and starts playing out of service messages then = it does matter which one you play. >=20 > Yes. >=20 >>> Of course, if you have application servers sending media both in the=20 >>> originating and terminating network, there need to be some policy=20 >>> procedures on which media has higher priority etc. >> Policy doesn't help a lot. It content, not policy, that determines=20 >> which is important to hear. >=20 > Sure, but there can be policy that says "My early media is more important= that anything else". >=20 > Having said that, having information abouot the content would probably be= very useful. However, I don't think it would help in the PSTN interworking= case, becase the MGC most likely does not know what early media (in-band r= inging or service anouncement) comes from the PSTN network. >=20 >> Perhaps the best we can do is discourage the use of early media for anyt= hing important. >=20 > I guess it depends on what you mean by "important", but there are a numbe= r of services that rely on early media. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 >=20 >=20 >>> Christer Holmberg wrote: >>>> Hi, >>>> >>>> >>>>> I would like to expand on this issue a little. Su= ppose I have at my >>>>> home proxy a policy whereby calls go to B1 and B2= in parallel, and >>>>> after T seconds of no answer calls instead go to = B3 (voicemail, >>>>> perhaps). There is no way that the proxy could co= nvey that policy in >>>>> a 3xx response to the UAC. To make this policy (o= r similar policies) >>>>> work, the proxy would need to manufacturer tempor= ary contact URIs >>>>> that map to B1 and B2 and send these back in a 30= 2. It would then >>>>> need to hope that the UAC does indeed establish n= ew requests in >>>>> parallel to the two temporary contacts for B1 and= B2. The proxy >>>>> would need to treat the two requests as related a= nd if both are >>>>> unanswered after T seconds, reject one with a 4xx= and the other with >>>>> a 302 (this time with a third temporary contact U= RI mapped to B3). >>>>> So policy CAN be met by the proxy, although with = dependence on the >>>>> UAC doing the right thing. >>>>> >>>>> >>>>> So here, we either need your home proxy to be a home B2BU= A (After all, >>>>> what happens when B1 and B2 both send back early media, o= r both get >>>>> answered by a bot?), OR we need a richer 302 response tha= t conveys >>>>> "Try these two destinations in parallel, and if neither r= eplies in X >>>>> seconds, try this third destination). >>>>> >>>>> But, the UAC still doesn't know whether B1 and B2 would send earl= y media. >>>>> >>>>> By offering different ports to B1 and B2 (especially with the media-t= o-signaling coupling extensions that have been proposed) UAC at least knows= which one of B1 and B2 each stream is coming from. >>>> Yes. But, there are other mechanisms to solve that, and it still doesn= 't solve the fundamental problem: the UAC can receive multiple media stream= s associated with multiple early dialogs. >>>> >>>> Also, in bandwidth sensitive access networks there is only limited ban= dwidth, normally calculated based on the need for media associated with one= early dialog. Even if the UAC is able to select and play only one stream t= o the user, the voice quality will suffer due to too little bandwidth. >>>> >>>> Regards, >>>> >>>> Christer >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >=20 From dean.willis@softarmor.com Tue Mar 23 19:06:07 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E29753A6857 for ; Tue, 23 Mar 2010 19:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.992 X-Spam-Level: X-Spam-Status: No, score=0.992 tagged_above=-999 required=5 tests=[AWL=-0.139, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 HRKNWctK2M3W for ; Tue, 23 Mar 2010 19:06:07 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 356DF3A63D3 for ; Tue, 23 Mar 2010 19:06:07 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2O26JlP017616 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Mar 2010 21:06:22 -0500 Message-ID: <4BA9739B.9060903@softarmor.com> Date: Tue, 23 Mar 2010 21:06:19 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Paul Kyzivat References: <4B918DED.6090108@cisco.com> , <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <4BA94A93.4010909@cisco.com> In-Reply-To: <4BA94A93.4010909@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 02:06:08 -0000 Paul Kyzivat wrote: > My conclusion is that none of the suggestions being thrown around > fundamentally improve the handling of early media in any way. Its just a > mess, and there is no feasible solution. Arguably, not forking in a proxy helps. It least lets you know how to kill an early media stream that is being spewed back at you. Offerless INVITEs help more, since the media can't come back to you until the O/A has completed. What if we split the O/A stage into three phases: 1) pre-offer: Alice INVITES Bob, includes a description of media she can send and receive but not an IP address or port number 2) offer: Bob sends Alice a description of the media he expects to send and to receive, along with the IP addresses and port numbers he is going to use. 3) answer: Alice sends Bob the IP addresses and port number to whichs he should direct media and from which Alice will be sending media. Note that this eliminates early media. Bob can't send Alice any media until he receives the answer. -- Dean From dean.willis@softarmor.com Tue Mar 23 19:11:25 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 855133A68D0 for ; Tue, 23 Mar 2010 19:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.298 X-Spam-Level: X-Spam-Status: No, score=-0.298 tagged_above=-999 required=5 tests=[AWL=1.171, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 mqYmKkxfjtM5 for ; Tue, 23 Mar 2010 19:11:24 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 3ED6D3A69AE for ; Tue, 23 Mar 2010 19:11:23 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2O2BVLI017681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Mar 2010 21:11:33 -0500 Message-ID: <4BA974D2.7010108@softarmor.com> Date: Tue, 23 Mar 2010 21:11:30 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Christer Holmberg References: <4B918DED.6090108@cisco.com> , <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <001a01cabe3e$e7033f80$b509be80$@com> <4B950BC0.5090601@cisco.com> <0BD9B443-C89F-4D16-819D-C35D74BAFD1B@softarmor.com> <4B9531DA.7050002@cisco.com> <50DAE276-5E08-4760-9FCC-035BEFF2C470@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'SIPCORE' , Gilad Shaham Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 02:11:25 -0000 Christer Holmberg wrote: >>> I wasn't thinking of discriminating the early media streams, but >>> rather finding ways to eliminate them while retaining their >>> intent. >> That would be cool. Requires a business model change at PSTN >> gateways, which IMHO should go to 200 OK (and a fully-connected >> dialog) before/ while starting the IAM or equivalent on the PSTN >> side. But too many yerkaloids want to bill on 200OK. > > It is not only about business models. > > Using 200 OK would ensure that all but one dialog is terminated, but > there can still be multiple sources of early media. > No, I'm suggesting that all of the forks respond with a 200 OK and move to a connected state, not just the first fork to respond. It's not a race, and there is NO early media -- just media being sent before the PSTN side of the gateway moves to a fully-connected state. Sorting out multiple media streams is a separate problem, but there are ways to automate many cases in a B2BUA or really smart UA. But this breaks the business model, which assumes that everything everywhere is fully-connected and in a "billing starts" state when the first 200OK flies. -- dean From pkyzivat@cisco.com Tue Mar 23 20:55:38 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8FAA03A68CE for ; Tue, 23 Mar 2010 20:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.055 X-Spam-Level: X-Spam-Status: No, score=-7.055 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] 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 Cx0JkkYU8Wpd for ; Tue, 23 Mar 2010 20:55:37 -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 753B83A67A4 for ; Tue, 23 Mar 2010 20:55:37 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGoqqUutJV2d/2dsb2JhbACbJ3OlNpkThH4E X-IronPort-AV: E=Sophos;i="4.51,299,1267401600"; d="scan'208";a="95584674" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rtp-iport-2.cisco.com with ESMTP; 24 Mar 2010 03:55:56 +0000 Received: from [10.21.67.62] (sjc-vpn3-830.cisco.com [10.21.67.62]) by rcdn-core-6.cisco.com (8.14.3/8.14.3) with ESMTP id o2O3tulS005896; Wed, 24 Mar 2010 03:55:56 GMT Message-ID: <4BA98D4C.4060707@cisco.com> Date: Tue, 23 Mar 2010 23:55:56 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Dean Willis References: <4B918DED.6090108@cisco.com> , <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <4BA94A93.4010909@cisco.com> <4BA9739B.9060903@softarmor.com> In-Reply-To: <4BA9739B.9060903@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 03:55:38 -0000 Dean Willis wrote: > Paul Kyzivat wrote: >> My conclusion is that none of the suggestions being thrown around >> fundamentally improve the handling of early media in any way. Its just a >> mess, and there is no feasible solution. > > Arguably, not forking in a proxy helps. It least lets you know how to > kill an early media stream that is being spewed back at you. Well, that depends. Its really only parallel forking thats a problem, so we can probably ignore serial forking. For parallel forking, moving it from the proxy to the UAC doesn't really solve the problem - you can still end up with multiple media streams and no clue what to do with them. You can say "don't do that", but there are desirable features that depend on it - namely "simultaneous ring". Potentially that can be replaced with presence-sensitive ringing to choose the *right* on to ring first, but that requires data that often isn't available. > Offerless INVITEs help more, since the media can't come back to you > until the O/A has completed. That is just sticking your head in the sand. The media is still being generated, even if you don't know about it. It does have the advantage that you can associate the media stream to the signaling source, but it still doesn't tell you which stream is interesting to listen to. ISTM that if you want "simultaneous ring", and the things ringing are often PSTN devices, there is still no solution. Perhaps there is some possibility of automated media analysis - the pstn GW figuring out that the media being received is something uninteresting - just conventional ringback - and suppressing it. But thats a lot of trouble and is likely to have a high error rate. Thanks, Paul > What if we split the O/A stage into three phases: > > 1) pre-offer: Alice INVITES Bob, includes a description of media she can > send and receive but not an IP address or port number > > 2) offer: Bob sends Alice a description of the media he expects to send > and to receive, along with the IP addresses and port numbers he is going > to use. > > 3) answer: Alice sends Bob the IP addresses and port number to whichs he > should direct media and from which Alice will be sending media. > > Note that this eliminates early media. Bob can't send Alice any media > until he receives the answer. > > > -- > Dean > From christer.holmberg@ericsson.com Wed Mar 24 09:56:02 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A46E33A6C33 for ; Wed, 24 Mar 2010 09:56:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.691 X-Spam-Level: X-Spam-Status: No, score=-1.691 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 hnqM7AS+WvzI for ; Wed, 24 Mar 2010 09:56:01 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 1587F3A6BC9 for ; Wed, 24 Mar 2010 09:56:00 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-af-4baa44340494 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 82.3F.23740.4344AAB4; Wed, 24 Mar 2010 17:56:20 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 24 Mar 2010 17:56:20 +0100 From: Christer Holmberg To: Dean Willis Date: Wed, 24 Mar 2010 17:51:44 +0100 Thread-Topic: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] Thread-Index: AcrK91ojoAmsc5CgSyKapsy8zXkAmAAeu6RD Message-ID: References: <4B918DED.6090108@cisco.com> , <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <001a01cabe3e$e7033f80$b509be80$@com> <4B950BC0.5090601@cisco.com> <0BD9B443-C89F-4D16-819D-C35D74BAFD1B@softarmor.com> <4B9531DA.7050002@cisco.com> <50DAE276-5E08-4760-9FCC-035BEFF2C470@softarmor.com> , <4BA974D2.7010108@softarmor.com> In-Reply-To: <4BA974D2.7010108@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: 'SIPCORE' , Gilad, Shaham Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 16:56:02 -0000 Hi, >>>>I wasn't thinking of discriminating the early media streams, but >>>>rather finding ways to eliminate them while retaining their >>>>intent. >>>That would be cool. Requires a business model change at PSTN >>>gateways, which IMHO should go to 200 OK (and a fully-connected >>>dialog) before/ while starting the IAM or equivalent on the PSTN >>>side. But too many yerkaloids want to bill on 200OK. >> >>It is not only about business models. >> >>Using 200 OK would ensure that all but one dialog is terminated, but >>there can still be multiple sources of early media. > > >No, I'm suggesting that all of the forks respond with a 200 OK and move >to a connected state, not just the first fork to respond. It's not a >race, and there is NO early media -- just media being sent before the >PSTN side of the gateway moves to a fully-connected state. > >Sorting out multiple media streams is a separate problem, but there are wa= ys to >automate many cases in a B2BUA or really smart UA. > >But this breaks the business model, which assumes that everything >everywhere is fully-connected and in a "billing starts" state when the >first 200OK flies. But, what problem would that solve?=20 The only difference is in what state you are (established-dialog instead of= early-dialog), but you still have the same problem as duing the early dial= og phase: you might receive early media from multiple locations.=20 Regards, Christer= From christer.holmberg@ericsson.com Wed Mar 24 10:08:29 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AFC33A6C33 for ; Wed, 24 Mar 2010 10:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.663 X-Spam-Level: X-Spam-Status: No, score=-3.663 tagged_above=-999 required=5 tests=[AWL=1.806, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 LPm9zj97TrTg for ; Wed, 24 Mar 2010 10:08:26 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 964F23A6D15 for ; Wed, 24 Mar 2010 10:08:10 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-d1-4baa470de41a Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 3F.AF.23532.D074AAB4; Wed, 24 Mar 2010 18:08:29 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 24 Mar 2010 18:08:29 +0100 From: Christer Holmberg To: Paul Kyzivat , Dean Willis Date: Wed, 24 Mar 2010 18:08:28 +0100 Thread-Topic: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] Thread-Index: AcrLBe761X2nX+TISzy2IHAE4N8iGAAbSbq2 Message-ID: References: <4B918DED.6090108@cisco.com> , <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <4BA94A93.4010909@cisco.com> <4BA9739B.9060903@softarmor.com>,<4BA98D4C.4060707@cisco.com> In-Reply-To: <4BA98D4C.4060707@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 17:08:29 -0000 Hi, >>>My conclusion is that none of the suggestions being thrown around >>>fundamentally improve the handling of early media in any way. Its just a >>>mess, and there is no feasible solution. >> >>Arguably, not forking in a proxy helps. It least lets you know how to >>kill an early media stream that is being spewed back at you. > >Well, that depends. > >Its really only parallel forking thats a problem, so we can probably >ignore serial forking. > >For parallel forking, moving it from the proxy to the UAC doesn't really >solve the problem - you can still end up with multiple media streams and >no clue what to do with them. > >You can say "don't do that", but there are desirable features that >depend on it - namely "simultaneous ring". Potentially that can be >replaced with presence-sensitive ringing to choose the *right* on to >ring first, but that requires data that often isn't available. > >>Offerless INVITEs help more, since the media can't come back to you until= the O/A has completed. > >That is just sticking your head in the sand. The media is still being gene= rated, even if you don't know about it. > >It does have the advantage that you can associate the media stream to >the signaling source, but it still doesn't tell you which stream is >interesting to listen to. Exactly. And, in my opinion THAT is the big problem. Being able to associate a media stream with dialog is of course very useful= , and there are ways to do that (including the one presented by Dean), but = it doesn't solve the problem with multiple early media. >ISTM that if you want "simultaneous ring", and the things ringing are >often PSTN devices, there is still no solution. Perhaps there is some >possibility of automated media analysis - the pstn GW figuring out that >the media being received is something uninteresting - just conventional >ringback - and suppressing it. But thats a lot of trouble and is likely >to have a high error rate. Correct. And, as long as the protocol allows forking, I think it is not pos= sible to define a protocol mechanism how to solve the problem. We can define information elements which contain information about the earl= y media (eventhough it most likely won't work in the PSTN case), but at the= end of the day you will need policy rules in order to decide what media is= forwarded or played to the calling user.=20 Regards, Christer= From gilad@voxisoft.com Wed Mar 24 10:48:25 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FE013A6C52 for ; Wed, 24 Mar 2010 10:48:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.227 X-Spam-Level: X-Spam-Status: No, score=-0.227 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] 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 ZoA+nzFlQ8Xw for ; Wed, 24 Mar 2010 10:48:22 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 0F9313A6910 for ; Wed, 24 Mar 2010 10:48:21 -0700 (PDT) Received: by fxm5 with SMTP id 5so230362fxm.29 for ; Wed, 24 Mar 2010 10:48:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.73.4 with HTTP; Wed, 24 Mar 2010 10:48:19 -0700 (PDT) X-Originating-IP: [79.177.50.34] In-Reply-To: References: <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <4BA94A93.4010909@cisco.com> <4BA9739B.9060903@softarmor.com> <4BA98D4C.4060707@cisco.com> From: Gilad Shaham Date: Wed, 24 Mar 2010 19:48:19 +0200 Received: by 10.87.63.20 with SMTP id q20mr280565fgk.27.1269452919333; Wed, 24 Mar 2010 10:48:39 -0700 (PDT) Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary=001485f44d1650e5c904828f8aa5 Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 17:48:25 -0000 --001485f44d1650e5c904828f8aa5 Content-Type: text/plain; charset=ISO-8859-1 Even if you would define policy, that doesn't mean it doesn't make sense to provide information on the nature of the media from non-PSTN sources. So you could say (in policy), for example, that PSTN is more important than just a ringback tone, but not more important than an IVR. My main question is whether we actually see in practice these scenarios to warrant a header/parameter/attribute that indicates the nature of the early media. In any case, I personally don't believe a B2BUA or phone would ever be smart enough to know which stream to pass through. Even the smart ones usually allow the first stream and block the rest. The reason is simple - if it were easy to do that, solving the PSTN question would also be easy. On Wed, Mar 24, 2010 at 7:08 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > >>>My conclusion is that none of the suggestions being thrown around > >>>fundamentally improve the handling of early media in any way. Its just a > >>>mess, and there is no feasible solution. > >> > >>Arguably, not forking in a proxy helps. It least lets you know how to > >>kill an early media stream that is being spewed back at you. > > > >Well, that depends. > > > >Its really only parallel forking thats a problem, so we can probably > >ignore serial forking. > > > >For parallel forking, moving it from the proxy to the UAC doesn't really > >solve the problem - you can still end up with multiple media streams and > >no clue what to do with them. > > > >You can say "don't do that", but there are desirable features that > >depend on it - namely "simultaneous ring". Potentially that can be > >replaced with presence-sensitive ringing to choose the *right* on to > >ring first, but that requires data that often isn't available. > > > >>Offerless INVITEs help more, since the media can't come back to you until > the O/A has completed. > > > >That is just sticking your head in the sand. The media is still being > generated, even if you don't know about it. > > > >It does have the advantage that you can associate the media stream to > >the signaling source, but it still doesn't tell you which stream is > >interesting to listen to. > > Exactly. And, in my opinion THAT is the big problem. > > Being able to associate a media stream with dialog is of course very > useful, and there are ways to do that (including the one presented by Dean), > but it doesn't solve the problem with multiple early media. > > >ISTM that if you want "simultaneous ring", and the things ringing are > >often PSTN devices, there is still no solution. Perhaps there is some > >possibility of automated media analysis - the pstn GW figuring out that > >the media being received is something uninteresting - just conventional > >ringback - and suppressing it. But thats a lot of trouble and is likely > >to have a high error rate. > > Correct. And, as long as the protocol allows forking, I think it is not > possible to define a protocol mechanism how to solve the problem. > > We can define information elements which contain information about the > early media (eventhough it most likely won't work in the PSTN case), but at > the end of the day you will need policy rules in order to decide what media > is forwarded or played to the calling user. > > Regards, > > Christer > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001485f44d1650e5c904828f8aa5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Even if you would define policy, that doesn't mean it = doesn't make sense to provide information on the nature of the media fr= om non-PSTN sources. So you could say (in policy), for example, that PSTN i= s more important than just a ringback tone, but not more important than an = IVR.

My main question is whether we actually see in practice these scenarios= to warrant a header/parameter/attribute that indicates the nature of the e= arly media. In any case, I personally don't believe a B2BUA or phone wo= uld ever be smart enough to know which stream to pass through. Even the sma= rt ones usually allow the first stream and block the rest. The reason is si= mple - if it were easy to do that, solving the PSTN question would also be = easy.

On Wed, Mar 24, 2010 at 7:08 PM, Christer Ho= lmberg <christer.holmberg@ericsson.com> wrote:
Hi,

>>>My conclusion is that none of the suggestions being thrown arou= nd
>>>fundamentally improve the handling of early media in any way. I= ts just a
>>>mess, and there is no feasible solution.
>>
>>Arguably, not forking in a proxy helps. It least lets you know how = to
>>kill an early media stream that is being spewed back at you.
>
>Well, that depends.
>
>Its really only parallel forking thats a problem, so we can probably >ignore serial forking.
>
>For parallel forking, moving it from the proxy to the UAC doesn't r= eally
>solve the problem - you can still end up with multiple media streams an= d
>no clue what to do with them.
>
>You can say "don't do that", but there are desirable feat= ures that
>depend on it - namely "simultaneous ring". Potentially that c= an be
>replaced with presence-sensitive ringing to choose the *right* on to >ring first, but that requires data that often isn't available.
>
>>Offerless INVITEs help more, since the media can't come back to= you until the O/A has completed.
>
>That is just sticking your head in the sand. The media is still being g= enerated, even if you don't know about it.
>
>It does have the advantage that you can associate the media stream to >the signaling source, but it still doesn't tell you which stream is=
>interesting to listen to.

Exactly. And, in my opinion THAT is the big problem.

Being able to associate a media stream with dialog is of course very useful= , and there are ways to do that (including the one presented by Dean), but = it doesn't solve the problem with multiple early media.

>ISTM that if you want "simultaneous ring", and the things rin= ging are
>often PSTN devices, there is still no solution. Perhaps there is some >possibility of automated media analysis - the pstn GW figuring out that=
>the media being received is something uninteresting - just conventional=
>ringback - and suppressing it. But thats a lot of trouble and is likely=
>to have a high error rate.

Correct. And, as long as the protocol allows forking, I think it is n= ot possible to define a protocol mechanism how to solve the problem.

We can define information elements which contain information about the earl= y media (eventhough it most likely won't work in the PSTN case), but at= the end of the day you will need policy rules in order to decide what medi= a is forwarded or played to the calling user.

Regards,

Christer
__________________________________= _____________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--001485f44d1650e5c904828f8aa5-- From christer.holmberg@ericsson.com Wed Mar 24 11:06:08 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5752F3A6D6B for ; Wed, 24 Mar 2010 11:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[AWL=1.568, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 RiLSFl7VaOHS for ; Wed, 24 Mar 2010 11:06:07 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 778763A6D77 for ; Wed, 24 Mar 2010 11:06:04 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-93-4baa549f6a26 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 0E.D2.23532.F945AAB4; Wed, 24 Mar 2010 19:06:24 +0100 (CET) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 24 Mar 2010 19:06:23 +0100 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Wed, 24 Mar 2010 19:06:23 +0100 From: Christer Holmberg To: Gilad Shaham Date: Wed, 24 Mar 2010 19:01:47 +0100 Thread-Topic: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] Thread-Index: AcrLekTsXipJy3I3SJePj6pnTPx3lgAAc0wn Message-ID: References: <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <4BA94A93.4010909@cisco.com> <4BA9739B.9060903@softarmor.com> <4BA98D4C.4060707@cisco.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 18:06:08 -0000 Hi, >Even if you would define policy, that doesn't mean it doesn't make sense t= o provide information on the nature of the media from >non-PSTN sources. I agree. I think it would be very useful, and you would be able to define b= etter and more reliable policies. >So you could say (in policy), for example, that PSTN is more important tha= n just a ringback tone, but not more important than an >IVR. Yes. >My main question is whether we actually see in practice these scenarios to= warrant a header/parameter/attribute that indicates the >nature of the early media. In any case, I personally don't believe a B2BUA= or phone would ever be smart enough to know which >stream to pass through. Even the smart ones usually allow the first stream= and block the rest. The reason is simple - if it were easy >to do that, solving the PSTN question would also be easy. I haven't seen any headers/parameters, but at least in 3GPP there is curren= tly an ongoing discussion on whether some header/parameter would be needed = for some specific services using early media. Regards, Christer On Wed, Mar 24, 2010 at 7:08 PM, Christer Holmberg > wrote: Hi, >>>My conclusion is that none of the suggestions being thrown around >>>fundamentally improve the handling of early media in any way. Its just a >>>mess, and there is no feasible solution. >> >>Arguably, not forking in a proxy helps. It least lets you know how to >>kill an early media stream that is being spewed back at you. > >Well, that depends. > >Its really only parallel forking thats a problem, so we can probably >ignore serial forking. > >For parallel forking, moving it from the proxy to the UAC doesn't really >solve the problem - you can still end up with multiple media streams and >no clue what to do with them. > >You can say "don't do that", but there are desirable features that >depend on it - namely "simultaneous ring". Potentially that can be >replaced with presence-sensitive ringing to choose the *right* on to >ring first, but that requires data that often isn't available. > >>Offerless INVITEs help more, since the media can't come back to you until= the O/A has completed. > >That is just sticking your head in the sand. The media is still being gene= rated, even if you don't know about it. > >It does have the advantage that you can associate the media stream to >the signaling source, but it still doesn't tell you which stream is >interesting to listen to. Exactly. And, in my opinion THAT is the big problem. Being able to associate a media stream with dialog is of course very useful= , and there are ways to do that (including the one presented by Dean), but = it doesn't solve the problem with multiple early media. >ISTM that if you want "simultaneous ring", and the things ringing are >often PSTN devices, there is still no solution. Perhaps there is some >possibility of automated media analysis - the pstn GW figuring out that >the media being received is something uninteresting - just conventional >ringback - and suppressing it. But thats a lot of trouble and is likely >to have a high error rate. Correct. And, as long as the protocol allows forking, I think it is not pos= sible to define a protocol mechanism how to solve the problem. We can define information elements which contain information about the earl= y media (eventhough it most likely won't work in the PSTN case), but at the= end of the day you will need policy rules in order to decide what media is= forwarded or played to the calling user. Regards, Christer _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From brett@broadsoft.com Wed Mar 24 12:01:54 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 555AA3A6D1C for ; Wed, 24 Mar 2010 12:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 k-Iu17lg5BNC for ; Wed, 24 Mar 2010 12:01:53 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id DBCB93A6CE9 for ; Wed, 24 Mar 2010 12:01:29 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Wed, 24 Mar 2010 12:01:50 -0700 From: Brett Tate To: Dean Willis , Paul Kyzivat , SIPCORE Date: Wed, 24 Mar 2010 12:01:49 -0700 Thread-Topic: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] Thread-Index: AcrK9p7tSWY2deuxTqWaOgK5r2adRAAiipVo Message-ID: <747A6506A991724FB09B129B79D5FEB614808FB60B@EXMBXCLUS01.citservers.local> References: <4B918DED.6090108@cisco.com> , <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <4BA94A93.4010909@cisco.com>,<4BA9739B.9060903@softarmor.com> In-Reply-To: <4BA9739B.9060903@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 19:01:54 -0000 If rfc3959 was actually supported, doesn't it solve many of the forking rel= ated early media issues? And the use of 199 addresses the ambiguity of kno= wing if an early dialog/session actually still exists. What still needs to be addressed for early media to work when forking is in= volved? ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Dean= Willis [dean.willis@softarmor.com] Sent: Tuesday, March 23, 2010 10:06 PM To: Paul Kyzivat Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork= or not to fork?] Paul Kyzivat wrote: > My conclusion is that none of the suggestions being thrown around > fundamentally improve the handling of early media in any way. Its just a > mess, and there is no feasible solution. Arguably, not forking in a proxy helps. It least lets you know how to kill an early media stream that is being spewed back at you. Offerless INVITEs help more, since the media can't come back to you until the O/A has completed. What if we split the O/A stage into three phases: 1) pre-offer: Alice INVITES Bob, includes a description of media she can send and receive but not an IP address or port number 2) offer: Bob sends Alice a description of the media he expects to send and to receive, along with the IP addresses and port numbers he is going to use. 3) answer: Alice sends Bob the IP addresses and port number to whichs he should direct media and from which Alice will be sending media. Note that this eliminates early media. Bob can't send Alice any media until he receives the answer. -- Dean _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore= From christer.holmberg@ericsson.com Wed Mar 24 15:10:51 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D10BA3A6810 for ; Wed, 24 Mar 2010 15:10:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.044 X-Spam-Level: X-Spam-Status: No, score=-4.044 tagged_above=-999 required=5 tests=[AWL=1.425, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 nveP4YRo2Lak for ; Wed, 24 Mar 2010 15:10:49 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 137323A6A7D for ; Wed, 24 Mar 2010 15:10:48 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-de-4baa8dfce8a3 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 7E.8B.23532.CFD8AAB4; Wed, 24 Mar 2010 23:11:08 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 24 Mar 2010 23:11:08 +0100 From: Christer Holmberg To: Brett Tate , Dean Willis , Paul Kyzivat , SIPCORE Date: Wed, 24 Mar 2010 23:11:07 +0100 Thread-Topic: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] Thread-Index: AcrK9p7tSWY2deuxTqWaOgK5r2adRAAiipVoAAdA7wk= Message-ID: References: <4B918DED.6090108@cisco.com> , <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <4BA94A93.4010909@cisco.com>, <4BA9739B.9060903@softarmor.com>, <747A6506A991724FB09B129B79D5FEB614808FB60B@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB614808FB60B@EXMBXCLUS01.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2010 22:10:51 -0000 Hi, >If rfc3959 was actually supported, doesn't it solve many of the forking re= lated early media issues? 3959 allows you to provide an early-media specific SDP (there are other way= s of doing that also). The early-session SDP also works as an indicator that there will be early m= edia in the first place, but there are other ways of doing that also (e.g. = using the P-Early-Media header). But, the problem is still there: there might be multiple early media stream= s. >And the use of 199 addresses the ambiguity of knowing if an early dialog/s= ession actually still exists. True. It helps to indicate on which dialogs there will NOT be any additiona= l early media. But, it also doesn't solve the issue of having multiple active early media = streams. >What still needs to be addressed for early media to work when forking is i= nvolved? I think the main problem is having multiple early media streams. How do you= decide which to play or forward to the calling user? Regards, Christer ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Dean= Willis [dean.willis@softarmor.com] Sent: Tuesday, March 23, 2010 10:06 PM To: Paul Kyzivat Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork= or not to fork?] Paul Kyzivat wrote: > My conclusion is that none of the suggestions being thrown around > fundamentally improve the handling of early media in any way. Its just a > mess, and there is no feasible solution. Arguably, not forking in a proxy helps. It least lets you know how to kill an early media stream that is being spewed back at you. Offerless INVITEs help more, since the media can't come back to you until the O/A has completed. What if we split the O/A stage into three phases: 1) pre-offer: Alice INVITES Bob, includes a description of media she can send and receive but not an IP address or port number 2) offer: Bob sends Alice a description of the media he expects to send and to receive, along with the IP addresses and port numbers he is going to use. 3) answer: Alice sends Bob the IP addresses and port number to whichs he should direct media and from which Alice will be sending media. Note that this eliminates early media. Bob can't send Alice any media until he receives the answer. -- Dean _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore= From brett@broadsoft.com Thu Mar 25 09:53:18 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA6AB3A69DB for ; Thu, 25 Mar 2010 09:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 47tsj4SIrntB for ; Thu, 25 Mar 2010 09:53:18 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 27EEA3A692B for ; Thu, 25 Mar 2010 09:53:18 -0700 (PDT) Received: from EXMBXCLUS01.citservers.local ([fe80:0000:0000:0000:a488:d1ec:167.6.58.109]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Thu, 25 Mar 2010 09:53:39 -0700 From: Brett Tate To: Christer Holmberg , SIPCORE Date: Thu, 25 Mar 2010 09:53:39 -0700 Thread-Topic: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] Thread-Index: AcrK9p7tSWY2deuxTqWaOgK5r2adRAAiipVoAAdA7wkAJUrwmA== Message-ID: <747A6506A991724FB09B129B79D5FEB614808FB60D@EXMBXCLUS01.citservers.local> References: <4B918DED.6090108@cisco.com> , <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <4BA94A93.4010909@cisco.com>, <4BA9739B.9060903@softarmor.com>, <747A6506A991724FB09B129B79D5FEB614808FB60B@EXMBXCLUS01.citservers.local>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 16:53:18 -0000 > > What still needs to be addressed for early media to work when forking i= s involved? >=20 > I think the main problem is having multiple early media streams. How do y= ou decide=20 > which to play or forward to the calling user? RFC 3959 basically allows the caller or caller's device to decide. It can = play, ignore, reject, or conference the early media and then switch to the = answered media when appropriate. Concerning "forward to the calling user", they all can be forwarded unless = there is a middle box attempting to control things with or without input fr= om calling party. Without input from the calling party, I agree that it ca= n potentially lead to non desirable experience for the user. If the user's device and outbound middle boxes are not able to handle the s= imultaneous media for RFC 3959, I assume something could be defined (if cal= ler prefs is not adequate) to allow calling party and/or middle boxes to fo= rce/request sequential forking. However similar to solely relying upon 3xx= 's and attempting targets sequentially, this can lead to long call-setup ti= mes before finally reaching voice mail or a party likely to answer. In com= parison to a 3xx solution, the sequential solution at least still allows th= e calling party to maintain a little more control over the order/timing rel= ated to trying the various targets.= From gilad@voxisoft.com Thu Mar 25 10:36:09 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 267803A6989 for ; Thu, 25 Mar 2010 10:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.754 X-Spam-Level: * X-Spam-Status: No, score=1.754 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] 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 yEzhXnVJYZIk for ; Thu, 25 Mar 2010 10:36:08 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.153]) by core3.amsl.com (Postfix) with ESMTP id 1D5983A6CAF for ; Thu, 25 Mar 2010 10:30:37 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so2009762fga.13 for ; Thu, 25 Mar 2010 10:30:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.73.4 with HTTP; Thu, 25 Mar 2010 10:30:35 -0700 (PDT) X-Originating-IP: [80.74.109.2] In-Reply-To: <747A6506A991724FB09B129B79D5FEB614808FB60D@EXMBXCLUS01.citservers.local> References: <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <4BA94A93.4010909@cisco.com> <4BA9739B.9060903@softarmor.com> <747A6506A991724FB09B129B79D5FEB614808FB60B@EXMBXCLUS01.citservers.local> <747A6506A991724FB09B129B79D5FEB614808FB60D@EXMBXCLUS01.citservers.local> From: Gilad Shaham Date: Thu, 25 Mar 2010 19:30:35 +0200 Received: by 10.87.66.15 with SMTP id t15mr2394721fgk.37.1269538255267; Thu, 25 Mar 2010 10:30:55 -0700 (PDT) Message-ID: To: Brett Tate Content-Type: multipart/alternative; boundary=001485f1d90ebbef630482a36822 Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 17:36:09 -0000 --001485f1d90ebbef630482a36822 Content-Type: text/plain; charset=ISO-8859-1 In my experience, many implementations may actually do wrong things when faced with multipart containing several SDPs. They should not, but in practice this happens. Even if we do choose this over any other mechanism proposed (such as 3xx), I would recommend we do not rely on RFC 3959 to indicate the nature of the media. On Thu, Mar 25, 2010 at 6:53 PM, Brett Tate wrote: > > > What still needs to be addressed for early media to work when forking > is involved? > > > > I think the main problem is having multiple early media streams. How do > you decide > > which to play or forward to the calling user? > > RFC 3959 basically allows the caller or caller's device to decide. It can > play, ignore, reject, or conference the early media and then switch to the > answered media when appropriate. > > Concerning "forward to the calling user", they all can be forwarded unless > there is a middle box attempting to control things with or without input > from calling party. Without input from the calling party, I agree that it > can potentially lead to non desirable experience for the user. > > If the user's device and outbound middle boxes are not able to handle the > simultaneous media for RFC 3959, I assume something could be defined (if > caller prefs is not adequate) to allow calling party and/or middle boxes to > force/request sequential forking. However similar to solely relying upon > 3xx's and attempting targets sequentially, this can lead to long call-setup > times before finally reaching voice mail or a party likely to answer. In > comparison to a 3xx solution, the sequential solution at least still allows > the calling party to maintain a little more control over the order/timing > related to trying the various targets. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --001485f1d90ebbef630482a36822 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In my experience, many implementations may actually do wro= ng things when faced with multipart containing several SDPs. They should no= t, but in practice this happens. Even if we do choose this over any other m= echanism proposed (such as 3xx), I would recommend we do not rely on RFC 39= 59 to indicate the nature of the media.

On Thu, Mar 25, 2010 at 6:53 PM, Brett Tate = <brett@broadsof= t.com> wrote:
> > What still needs to be addressed for early medi= a to work when forking is involved?
>
> I think the main problem is having multiple early media streams. How d= o you decide
> which to play or forward to the calling user?

RFC 3959 basically allows the caller or caller's device to decide= . =A0It can play, ignore, reject, or conference the early media and then sw= itch to the answered media when appropriate.

Concerning "forward to the calling user", they all can be forward= ed unless there is a middle box attempting to control things with or withou= t input from calling party. =A0Without input from the calling party, I agre= e that it can potentially lead to non desirable experience for the user.
If the user's device and outbound middle boxes are not able to handle t= he simultaneous media for RFC 3959, I assume something could be defined (if= caller prefs is not adequate) to allow calling party and/or middle boxes t= o force/request sequential forking. =A0However similar to solely relying up= on 3xx's and attempting targets sequentially, this can lead to long cal= l-setup times before finally reaching voice mail or a party likely to answe= r. =A0In comparison to a 3xx solution, the sequential solution at least sti= ll allows the calling party to maintain a little more control over the orde= r/timing related to trying the various targets.
_________________________________________= ______
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--001485f1d90ebbef630482a36822-- From dean.willis@softarmor.com Thu Mar 25 11:12:06 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8EDEB3A6E4D for ; Thu, 25 Mar 2010 11:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.822 X-Spam-Level: X-Spam-Status: No, score=0.822 tagged_above=-999 required=5 tests=[AWL=-0.309, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 PlKSEfznakVX for ; Thu, 25 Mar 2010 11:12:05 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 872EF3A6A93 for ; Thu, 25 Mar 2010 11:11:55 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2PICBX3004091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 25 Mar 2010 13:12:13 -0500 Message-ID: <4BABA77B.90906@softarmor.com> Date: Thu, 25 Mar 2010 13:12:11 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Christer Holmberg References: <4B918DED.6090108@cisco.com> , <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <001a01cabe3e$e7033f80$b509be80$@com> <4B950BC0.5090601@cisco.com> <0BD9B443-C89F-4D16-819D-C35D74BAFD1B@softarmor.com> <4B9531DA.7050002@cisco.com> <50DAE276-5E08-4760-9FCC-035BEFF2C470@softarmor.com> , <4BA974D2.7010108@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'SIPCORE' , Gilad Shaham Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 18:12:06 -0000 Christer Holmberg wrote: >> No, I'm suggesting that all of the forks respond with a 200 OK and >> move to a connected state, not just the first fork to respond. It's >> not a race, and there is NO early media -- just media being sent >> before the PSTN side of the gateway moves to a fully-connected >> state. >> >> Sorting out multiple media streams is a separate problem, but there >> are ways to automate many cases in a B2BUA or really smart UA. >> >> But this breaks the business model, which assumes that everything >> everywhere is fully-connected and in a "billing starts" state when >> the first 200OK flies. > > But, what problem would that solve? > > The only difference is in what state you are (established-dialog > instead of early-dialog), but you still have the same problem as > duing the early dialog phase: you might receive early media from > multiple locations. > It's not "early media" if it is in an established dialog. Once you have a full dialog, you can do things like send a "BYE", have a bot do a verbal challenge-response on the media path, play one channel to the left ear and one to the right, play all of the media flows simultaneously with variable volume weighting using a hover-touch over a per-session icon (click to pick "this call" and drop the other ones), etc. But "early media" messes everything up. -- dean From dean.willis@softarmor.com Thu Mar 25 11:22:05 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D0F63A6D88 for ; Thu, 25 Mar 2010 11:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.832 X-Spam-Level: X-Spam-Status: No, score=0.832 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 wFVDYm8yQ9pM for ; Thu, 25 Mar 2010 11:21:58 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 1ED003A6D0C for ; Thu, 25 Mar 2010 11:19:39 -0700 (PDT) Received: from [130.129.28.97] (dhcp-wireless-open-abg-28-97.meeting.ietf.org [130.129.28.97]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2PIJj1D004151 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 25 Mar 2010 13:19:47 -0500 Message-ID: <4BABA93C.2010402@softarmor.com> Date: Thu, 25 Mar 2010 13:19:40 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Paul Kyzivat References: <4B918DED.6090108@cisco.com> , <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <4BA94A93.4010909@cisco.com> <4BA9739B.9060903@softarmor.com> <4BA98D4C.4060707@cisco.com> In-Reply-To: <4BA98D4C.4060707@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 18:22:05 -0000 Paul Kyzivat wrote: > Its really only parallel forking thats a problem, so we can probably > ignore serial forking. Not really. Early media is always a problem. How do you tell it to stop without whacking all your forks? > > For parallel forking, moving it from the proxy to the UAC doesn't really > solve the problem - you can still end up with multiple media streams and > no clue what to do with them. Knowing which stream is which lets you do MORE things than you can with just a bunch of garbled media coming in. > > You can say "don't do that", but there are desirable features that > depend on it - namely "simultaneous ring". Potentially that can be > replaced with presence-sensitive ringing to choose the *right* on to > ring first, but that requires data that often isn't available. Google Voice does simultaneous ring quite nicely. If you call my GV number, it will ring all my phones. If somebody answers a phone, GV will say "Press 1 to accept a call from Paul Kyzivat", and if I press 1, GV will terminate the other forks. Webster did this years ago using the dynamicsoft stuff as a call controller. But to do this kind of work, the call controller needs signaling control on each fork, which you don't get with early media. >> Offerless INVITEs help more, since the media can't come back to you >> until the O/A has completed. > > That is just sticking your head in the sand. The media is still being > generated, even if you don't know about it. No, really. They CANNOT send you media until you've sent your SDP. If you don't send your SDP (in the ACK) until they have sent theirs (in the 200OK), then there is NO EARLY MEDIA. Yes, this means that PSTN gateways would have to complete ACK before doing IAM on the PSTN side. I'm OK with that. > It does have the advantage that you can associate the media stream to > the signaling source, but it still doesn't tell you which stream is > interesting to listen to. But having associated signaling lets you do things to decide which one is interesting. > ISTM that if you want "simultaneous ring", and the things ringing are > often PSTN devices, there is still no solution. Perhaps there is some > possibility of automated media analysis - the pstn GW figuring out that > the media being received is something uninteresting - just conventional > ringback - and suppressing it. But thats a lot of trouble and is likely > to have a high error rate. Go play with Google Voice or something like it for awhile and then get back to us. -- Dean From pkyzivat@cisco.com Thu Mar 25 12:07:50 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39CDC3A67D3 for ; Thu, 25 Mar 2010 12:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.543 X-Spam-Level: X-Spam-Status: No, score=-6.543 tagged_above=-999 required=5 tests=[AWL=1.068, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] 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 xQm+N9DrsrdF for ; Thu, 25 Mar 2010 12:07:49 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 554DC3A6A2A for ; Thu, 25 Mar 2010 12:07:44 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOdRq0urRN+K/2dsb2JhbACbKHOmNZkPhH0E X-IronPort-AV: E=Sophos;i="4.51,309,1267401600"; d="scan'208";a="311740580" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-1.cisco.com with ESMTP; 25 Mar 2010 19:08:03 +0000 Received: from [10.21.91.15] (sjc-vpn5-783.cisco.com [10.21.91.15]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o2PJ83R9020425; Thu, 25 Mar 2010 19:08:03 GMT Message-ID: <4BABB493.3030304@cisco.com> Date: Thu, 25 Mar 2010 15:08:03 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Brett Tate References: <4B918DED.6090108@cisco.com> , <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <4BA94A93.4010909@cisco.com>, <4BA9739B.9060903@softarmor.com>, <747A6506A991724FB09B129B79D5FEB614808FB60B@EXMBXCLUS01.citservers.local>, <747A6506A991724FB09B129B79D5FEB614808FB60D@EXMBXCLUS01.citservers.local> In-Reply-To: <747A6506A991724FB09B129B79D5FEB614808FB60D@EXMBXCLUS01.citservers.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 19:07:50 -0000 [speaking as an individual] Brett, Its true that the caller MAY choose to render whatever it wants from the multiple media streams coming back. And thats fine if none of them contain anything of consequence. But it doesn't alter reality. One, or more, of those early media streams may contain information that the caller needs to hear. When the caller's UA chooses, it may pick one that is unimportant over one that is important. And even picking one that is important isn't good enough if another was also important. If the streams were identifiable (by automata) as to content, then at least an important one might be chosen over an unimportant one. I can only see two answers for the case where more than one has important content: - indicate to the caller that there are multiple, and permit the caller to toggle between them - indicate to the callee that its early media will not be rendered. Force it to wait to send until such time as it can be rendered. Those two are actually complementary. Unfortunately, the pstn media is probably by far the most common case. And with it: - we have no indicatino of what the content is (do we?) - indicating refusal to accept the media will not delay it, only cause it to be dropped. Thanks, Paul Brett Tate wrote: >>> What still needs to be addressed for early media to work when forking is involved? >> I think the main problem is having multiple early media streams. How do you decide >> which to play or forward to the calling user? > > RFC 3959 basically allows the caller or caller's device to decide. It can play, ignore, reject, or conference the early media and then switch to the answered media when appropriate. > > Concerning "forward to the calling user", they all can be forwarded unless there is a middle box attempting to control things with or without input from calling party. Without input from the calling party, I agree that it can potentially lead to non desirable experience for the user. > > If the user's device and outbound middle boxes are not able to handle the simultaneous media for RFC 3959, I assume something could be defined (if caller prefs is not adequate) to allow calling party and/or middle boxes to force/request sequential forking. However similar to solely relying upon 3xx's and attempting targets sequentially, this can lead to long call-setup times before finally reaching voice mail or a party likely to answer. In comparison to a 3xx solution, the sequential solution at least still allows the calling party to maintain a little more control over the order/timing related to trying the various targets. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From gao.yang2@zte.com.cn Thu Mar 25 13:51:51 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8519D3A6895 for ; Thu, 25 Mar 2010 13:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.206 X-Spam-Level: X-Spam-Status: No, score=-94.206 tagged_above=-999 required=5 tests=[AWL=-0.901, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] 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 mq+sZF3uTjMx for ; Thu, 25 Mar 2010 13:51:50 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 4E73D3A69D9 for ; Thu, 25 Mar 2010 13:51:49 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 128641727820181; Fri, 26 Mar 2010 04:50:53 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 84131.4394537513; Fri, 26 Mar 2010 04:49:33 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o2PKptho012358; Fri, 26 Mar 2010 04:51:55 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4BABA93C.2010402@softarmor.com> To: Dean Willis MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 26 Mar 2010 04:50:16 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-03-26 04:51:58, Serialize complete at 2010-03-26 04:51:58 Content-Type: multipart/alternative; boundary="=_alternative 00729B52482576F1_=" X-MAIL: mse2.zte.com.cn o2PKptho012358 Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 20:51:51 -0000 This is a multipart message in MIME format. --=_alternative 00729B52482576F1_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SU1PLCBpZiB0aGUgY2FsbGVyJ3MgVUUgaXMgYXMgc3Ryb25nIGFzIEdvb2dsZSBWb2ljZSBhbmQg aXQncyBzb2Z0d2FyZSwgDQp0aGUgbmV0d29yayBjYW4ganVzdCByZW5kZXIgYWxsIHRoZSBlYXJs eSBtZWRpYSB0byBpdC4NClNvLCB0aGUga2V5IHByb2JsZW0gaXMgYWJvdXQgVUUgd2l0aCBsZXNz IGNhcGFiaWxpdHkuDQoNCkkgc3RpbGwgdGhpbmsgaXQgaXMgQkNQIHRoaW5nLiBJIG9uY2Ugc2Fp ZCBob3cgbXkgZXF1aXBtZW50IGhhbmRsZSB0aGlzIGluIA0KdGhlIA0KbWFpbChodHRwOi8vd3d3 LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2lwY29yZS9jdXJyZW50L21zZzAyMTE0Lmh0bWwp Lg0KDQpCVFcsIGRvaW5nIHRoaXMgY2FuIG1ha2UgUFNUTiB1c2VyIGhhdmluZyB0aGUgc2FtZSBl eHBlcmllbmNlIGFzIEdWOg0KUFNUTiBnYXRld2F5KHN1Y2ggYXMgTUdDRiBpbiBJTVMpIHRlcm1p bmF0ZSB0aGUgbXVsdGlwbGUgZm9ya2VkIGVhcmx5IA0KbWVkaWEgYW5kIGp1c3Qgc2VuZCBvbmx5 IG9uZSB0byB0aGUgUFNUTiB1c2VyLiBBbmQgdXNpbmcgRFRNRiwgdGhlIHVzZXIgDQpjYW4gc3dp dGNoIGZyb20gb25lIHZvaWNlIHRvIGFub3RoZXIgYnkgcHJlc3MgdGhlIG51bWJlciBrZXkuIA0K DQpHYW8NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiBaaXAgICAgOiAy MTAwMTINCiBUZWwgICAgOiA4NzIxMQ0KIFRlbDIgICA6KCs4NiktMDI1LTUyODc3MjExDQogZV9t YWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09DQoNCg0KDQpEZWFuIFdpbGxpcyA8ZGVhbi53aWxsaXNAc29mdGFybW9yLmNvbT4gDQq3 orz+yMs6ICBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTAtMDMtMjYgMDI6MTkNCg0KytW8 /sjLDQpQYXVsIEt5eml2YXQgPHBreXppdmF0QGNpc2NvLmNvbT4NCrOty80NClNJUENPUkUgPHNp cGNvcmVAaWV0Zi5vcmc+DQrW98ziDQpSZTogW3NpcGNvcmVdIElOVklURSAzeHggYW5kIGVhcmx5 IG1lZGlhIFt3YXMgT1BUSU9OUyAzeHg6IFRvIGZvcmsgb3Igbm90IA0KdG8gZm9yaz9dDQoNCg0K DQoNCg0KDQpQYXVsIEt5eml2YXQgd3JvdGU6DQoNCj4gSXRzIHJlYWxseSBvbmx5IHBhcmFsbGVs IGZvcmtpbmcgdGhhdHMgYSBwcm9ibGVtLCBzbyB3ZSBjYW4gcHJvYmFibHkNCj4gaWdub3JlIHNl cmlhbCBmb3JraW5nLg0KDQpOb3QgcmVhbGx5LiBFYXJseSBtZWRpYSBpcyBhbHdheXMgYSBwcm9i bGVtLiBIb3cgZG8geW91IHRlbGwgaXQgdG8gc3RvcA0Kd2l0aG91dCB3aGFja2luZyBhbGwgeW91 ciBmb3Jrcz8NCg0KPiANCj4gRm9yIHBhcmFsbGVsIGZvcmtpbmcsIG1vdmluZyBpdCBmcm9tIHRo ZSBwcm94eSB0byB0aGUgVUFDIGRvZXNuJ3QgcmVhbGx5DQo+IHNvbHZlIHRoZSBwcm9ibGVtIC0g eW91IGNhbiBzdGlsbCBlbmQgdXAgd2l0aCBtdWx0aXBsZSBtZWRpYSBzdHJlYW1zIGFuZA0KPiBu byBjbHVlIHdoYXQgdG8gZG8gd2l0aCB0aGVtLg0KDQpLbm93aW5nIHdoaWNoIHN0cmVhbSBpcyB3 aGljaCBsZXRzIHlvdSBkbyBNT1JFIHRoaW5ncyB0aGFuIHlvdSBjYW4gd2l0aA0KanVzdCBhIGJ1 bmNoIG9mIGdhcmJsZWQgbWVkaWEgY29taW5nIGluLg0KDQoNCj4gDQo+IFlvdSBjYW4gc2F5ICJk b24ndCBkbyB0aGF0IiwgYnV0IHRoZXJlIGFyZSBkZXNpcmFibGUgZmVhdHVyZXMgdGhhdA0KPiBk ZXBlbmQgb24gaXQgLSBuYW1lbHkgInNpbXVsdGFuZW91cyByaW5nIi4gUG90ZW50aWFsbHkgdGhh dCBjYW4gYmUNCj4gcmVwbGFjZWQgd2l0aCBwcmVzZW5jZS1zZW5zaXRpdmUgcmluZ2luZyB0byBj aG9vc2UgdGhlICpyaWdodCogb24gdG8NCj4gcmluZyBmaXJzdCwgYnV0IHRoYXQgcmVxdWlyZXMg ZGF0YSB0aGF0IG9mdGVuIGlzbid0IGF2YWlsYWJsZS4NCg0KR29vZ2xlIFZvaWNlIGRvZXMgc2lt dWx0YW5lb3VzIHJpbmcgcXVpdGUgbmljZWx5LiBJZiB5b3UgY2FsbCBteSBHVg0KbnVtYmVyLCBp dCB3aWxsIHJpbmcgYWxsIG15IHBob25lcy4gSWYgc29tZWJvZHkgYW5zd2VycyBhIHBob25lLCBH ViB3aWxsDQpzYXkgIlByZXNzIDEgdG8gYWNjZXB0IGEgY2FsbCBmcm9tIFBhdWwgS3l6aXZhdCIs IGFuZCBpZiBJIHByZXNzIDEsIEdWDQp3aWxsIHRlcm1pbmF0ZSB0aGUgb3RoZXIgZm9ya3MuDQoN CldlYnN0ZXIgZGlkIHRoaXMgeWVhcnMgYWdvIHVzaW5nIHRoZSBkeW5hbWljc29mdCBzdHVmZiBh cyBhIGNhbGwgDQpjb250cm9sbGVyLg0KDQpCdXQgdG8gZG8gdGhpcyBraW5kIG9mIHdvcmssIHRo ZSBjYWxsIGNvbnRyb2xsZXIgbmVlZHMgc2lnbmFsaW5nIGNvbnRyb2wNCm9uIGVhY2ggZm9yaywg d2hpY2ggeW91IGRvbid0IGdldCB3aXRoIGVhcmx5IG1lZGlhLg0KDQo+PiBPZmZlcmxlc3MgSU5W SVRFcyBoZWxwIG1vcmUsIHNpbmNlIHRoZSBtZWRpYSBjYW4ndCBjb21lIGJhY2sgdG8geW91DQo+ PiB1bnRpbCB0aGUgTy9BIGhhcyBjb21wbGV0ZWQuDQo+IA0KPiBUaGF0IGlzIGp1c3Qgc3RpY2tp bmcgeW91ciBoZWFkIGluIHRoZSBzYW5kLiBUaGUgbWVkaWEgaXMgc3RpbGwgYmVpbmcNCj4gZ2Vu ZXJhdGVkLCBldmVuIGlmIHlvdSBkb24ndCBrbm93IGFib3V0IGl0Lg0KDQpObywgcmVhbGx5LiBU aGV5IENBTk5PVCBzZW5kIHlvdSBtZWRpYSB1bnRpbCB5b3UndmUgc2VudCB5b3VyIFNEUC4gIElm DQp5b3UgZG9uJ3Qgc2VuZCB5b3VyIFNEUCAoaW4gdGhlIEFDSykgdW50aWwgdGhleSBoYXZlIHNl bnQgdGhlaXJzIChpbiB0aGUNCjIwME9LKSwgdGhlbiB0aGVyZSBpcyBOTyBFQVJMWSBNRURJQS4N Cg0KWWVzLCB0aGlzIG1lYW5zIHRoYXQgUFNUTiBnYXRld2F5cyB3b3VsZCBoYXZlIHRvIGNvbXBs ZXRlIEFDSyBiZWZvcmUNCmRvaW5nIElBTSBvbiB0aGUgUFNUTiBzaWRlLiBJJ20gT0sgd2l0aCB0 aGF0Lg0KDQo+IEl0IGRvZXMgaGF2ZSB0aGUgYWR2YW50YWdlIHRoYXQgeW91IGNhbiBhc3NvY2lh dGUgdGhlIG1lZGlhIHN0cmVhbSB0bw0KPiB0aGUgc2lnbmFsaW5nIHNvdXJjZSwgYnV0IGl0IHN0 aWxsIGRvZXNuJ3QgdGVsbCB5b3Ugd2hpY2ggc3RyZWFtIGlzDQo+IGludGVyZXN0aW5nIHRvIGxp c3RlbiB0by4NCg0KQnV0IGhhdmluZyBhc3NvY2lhdGVkIHNpZ25hbGluZyBsZXRzIHlvdSBkbyB0 aGluZ3MgdG8gZGVjaWRlIHdoaWNoIG9uZQ0KaXMgaW50ZXJlc3RpbmcuDQoNCj4gSVNUTSB0aGF0 IGlmIHlvdSB3YW50ICJzaW11bHRhbmVvdXMgcmluZyIsIGFuZCB0aGUgdGhpbmdzIHJpbmdpbmcg YXJlDQo+IG9mdGVuIFBTVE4gZGV2aWNlcywgdGhlcmUgaXMgc3RpbGwgbm8gc29sdXRpb24uIFBl cmhhcHMgdGhlcmUgaXMgc29tZQ0KPiBwb3NzaWJpbGl0eSBvZiBhdXRvbWF0ZWQgbWVkaWEgYW5h bHlzaXMgLSB0aGUgcHN0biBHVyBmaWd1cmluZyBvdXQgdGhhdA0KPiB0aGUgbWVkaWEgYmVpbmcg cmVjZWl2ZWQgaXMgc29tZXRoaW5nIHVuaW50ZXJlc3RpbmcgLSBqdXN0IGNvbnZlbnRpb25hbA0K PiByaW5nYmFjayAtIGFuZCBzdXBwcmVzc2luZyBpdC4gQnV0IHRoYXRzIGEgbG90IG9mIHRyb3Vi bGUgYW5kIGlzIGxpa2VseQ0KPiB0byBoYXZlIGEgaGlnaCBlcnJvciByYXRlLg0KDQpHbyBwbGF5 IHdpdGggR29vZ2xlIFZvaWNlIG9yIHNvbWV0aGluZyBsaWtlIGl0IGZvciBhd2hpbGUgYW5kIHRo ZW4gZ2V0DQpiYWNrIHRvIHVzLg0KDQotLQ0KRGVhbg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3JlQGll dGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg0K DQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9u IGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIn cyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4g UmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kg YW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNv bW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0 dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUg dXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3Nl ZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5 IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRo aXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNz YWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3Bh bSBzeXN0ZW0uDQo= --=_alternative 00729B52482576F1_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPklNTywgaWYgdGhlIGNhbGxlcidz IFVFIGlzIGFzIHN0cm9uZw0KYXMgR29vZ2xlIFZvaWNlIGFuZCBpdCdzIHNvZnR3YXJlLCB0aGUg bmV0d29yayBjYW4ganVzdCByZW5kZXIgYWxsIHRoZQ0KZWFybHkgbWVkaWEgdG8gaXQuPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5TbywgdGhlIGtleSBwcm9ibGVt IGlzIGFib3V0IFVFIHdpdGgNCmxlc3MgY2FwYWJpbGl0eS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgc3RpbGwgdGhpbmsgaXQgaXMgQkNQIHRoaW5n LiBJIG9uY2UNCnNhaWQgaG93IG15IGVxdWlwbWVudCBoYW5kbGUgdGhpcyBpbiB0aGUgbWFpbCho dHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2lwY29yZS9jdXJyZW50L21zZzAy MTE0Lmh0bWwpLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+QlRXLCBkb2luZyB0aGlzIGNhbiBtYWtlIFBTVE4gdXNlciBoYXZpbmcNCnRoZSBzYW1lIGV4 cGVyaWVuY2UgYXMgR1Y6PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5QU1ROIGdhdGV3YXkoc3VjaCBhcyBNR0NGIGluIElNUykgdGVybWluYXRlDQp0aGUgbXVsdGlw bGUgZm9ya2VkIGVhcmx5IG1lZGlhIGFuZCBqdXN0IHNlbmQgb25seSBvbmUgdG8gdGhlIFBTVE4g dXNlci4NCkFuZCB1c2luZyBEVE1GLCB0aGUgdXNlciBjYW4gc3dpdGNoIGZyb20gb25lIHZvaWNl IHRvIGFub3RoZXIgYnkgcHJlc3MNCnRoZSBudW1iZXIga2V5LiA8L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkdhbzwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT08YnI+DQogWmlwICZuYnNwOyAmbmJzcDs6IDIxMDAxMjxicj4NCiBUZWwgJm5ic3A7ICZu YnNwOzogODcyMTE8YnI+DQogVGVsMiAmbmJzcDsgOigrODYpLTAyNS01Mjg3NzIxMTxicj4NCiBl X21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbjxicj4NCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0yNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPjxiPkRlYW4gV2lsbGlzICZsdDtkZWFuLndpbGxpc0Bzb2Z0YXJtb3IuY29tJmd0Ozwv Yj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAm bmJzcDtzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+MjAxMC0wMy0yNiAwMjoxOTwvZm9udD4NCjx0ZCB3aWR0aD03MyU+DQo8 dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRk Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5QYXVsIEt5eml2YXQgJmx0O3BreXppdmF0 QGNpc2NvLmNvbSZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249 cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8 dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlNJUENPUkUgJmx0O3NpcGNvcmVAaWV0 Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW3NpcGNvcmVdIElOVklURSAzeHggYW5k IGVhcmx5IG1lZGlhDQpbd2FzIE9QVElPTlMgM3h4OiBUbyBmb3JrIG9yIG5vdCB0byBmb3JrP108 L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRk PjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PlBhdWwgS3l6aXZhdCB3cm90ZTo8YnI+DQo8YnI+DQomZ3Q7IEl0cyByZWFsbHkgb25seSBwYXJh bGxlbCBmb3JraW5nIHRoYXRzIGEgcHJvYmxlbSwgc28gd2UgY2FuIHByb2JhYmx5PGJyPg0KJmd0 OyBpZ25vcmUgc2VyaWFsIGZvcmtpbmcuPGJyPg0KPGJyPg0KTm90IHJlYWxseS4gRWFybHkgbWVk aWEgaXMgYWx3YXlzIGEgcHJvYmxlbS4gSG93IGRvIHlvdSB0ZWxsIGl0IHRvIHN0b3A8YnI+DQp3 aXRob3V0IHdoYWNraW5nIGFsbCB5b3VyIGZvcmtzPzxicj4NCjxicj4NCiZndDsgPGJyPg0KJmd0 OyBGb3IgcGFyYWxsZWwgZm9ya2luZywgbW92aW5nIGl0IGZyb20gdGhlIHByb3h5IHRvIHRoZSBV QUMgZG9lc24ndA0KcmVhbGx5PGJyPg0KJmd0OyBzb2x2ZSB0aGUgcHJvYmxlbSAtIHlvdSBjYW4g c3RpbGwgZW5kIHVwIHdpdGggbXVsdGlwbGUgbWVkaWEgc3RyZWFtcw0KYW5kPGJyPg0KJmd0OyBu byBjbHVlIHdoYXQgdG8gZG8gd2l0aCB0aGVtLjxicj4NCjxicj4NCktub3dpbmcgd2hpY2ggc3Ry ZWFtIGlzIHdoaWNoIGxldHMgeW91IGRvIE1PUkUgdGhpbmdzIHRoYW4geW91IGNhbiB3aXRoPGJy Pg0KanVzdCBhIGJ1bmNoIG9mIGdhcmJsZWQgbWVkaWEgY29taW5nIGluLjxicj4NCjxicj4NCjxi cj4NCiZndDsgPGJyPg0KJmd0OyBZb3UgY2FuIHNheSAmcXVvdDtkb24ndCBkbyB0aGF0JnF1b3Q7 LCBidXQgdGhlcmUgYXJlIGRlc2lyYWJsZSBmZWF0dXJlcw0KdGhhdDxicj4NCiZndDsgZGVwZW5k IG9uIGl0IC0gbmFtZWx5ICZxdW90O3NpbXVsdGFuZW91cyByaW5nJnF1b3Q7LiBQb3RlbnRpYWxs eSB0aGF0DQpjYW4gYmU8YnI+DQomZ3Q7IHJlcGxhY2VkIHdpdGggcHJlc2VuY2Utc2Vuc2l0aXZl IHJpbmdpbmcgdG8gY2hvb3NlIHRoZSAqcmlnaHQqIG9uDQp0bzxicj4NCiZndDsgcmluZyBmaXJz dCwgYnV0IHRoYXQgcmVxdWlyZXMgZGF0YSB0aGF0IG9mdGVuIGlzbid0IGF2YWlsYWJsZS48YnI+ DQo8YnI+DQpHb29nbGUgVm9pY2UgZG9lcyBzaW11bHRhbmVvdXMgcmluZyBxdWl0ZSBuaWNlbHku IElmIHlvdSBjYWxsIG15IEdWPGJyPg0KbnVtYmVyLCBpdCB3aWxsIHJpbmcgYWxsIG15IHBob25l cy4gSWYgc29tZWJvZHkgYW5zd2VycyBhIHBob25lLCBHViB3aWxsPGJyPg0Kc2F5ICZxdW90O1By ZXNzIDEgdG8gYWNjZXB0IGEgY2FsbCBmcm9tIFBhdWwgS3l6aXZhdCZxdW90OywgYW5kIGlmIEkg cHJlc3MNCjEsIEdWPGJyPg0Kd2lsbCB0ZXJtaW5hdGUgdGhlIG90aGVyIGZvcmtzLjxicj4NCjxi cj4NCldlYnN0ZXIgZGlkIHRoaXMgeWVhcnMgYWdvIHVzaW5nIHRoZSBkeW5hbWljc29mdCBzdHVm ZiBhcyBhIGNhbGwgY29udHJvbGxlci48YnI+DQo8YnI+DQpCdXQgdG8gZG8gdGhpcyBraW5kIG9m IHdvcmssIHRoZSBjYWxsIGNvbnRyb2xsZXIgbmVlZHMgc2lnbmFsaW5nIGNvbnRyb2w8YnI+DQpv biBlYWNoIGZvcmssIHdoaWNoIHlvdSBkb24ndCBnZXQgd2l0aCBlYXJseSBtZWRpYS48YnI+DQo8 YnI+DQomZ3Q7Jmd0OyBPZmZlcmxlc3MgSU5WSVRFcyBoZWxwIG1vcmUsIHNpbmNlIHRoZSBtZWRp YSBjYW4ndCBjb21lIGJhY2sgdG8NCnlvdTxicj4NCiZndDsmZ3Q7IHVudGlsIHRoZSBPL0EgaGFz IGNvbXBsZXRlZC48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhdCBpcyBqdXN0IHN0aWNraW5nIHlv dXIgaGVhZCBpbiB0aGUgc2FuZC4gVGhlIG1lZGlhIGlzIHN0aWxsIGJlaW5nPGJyPg0KJmd0OyBn ZW5lcmF0ZWQsIGV2ZW4gaWYgeW91IGRvbid0IGtub3cgYWJvdXQgaXQuPGJyPg0KPGJyPg0KTm8s IHJlYWxseS4gVGhleSBDQU5OT1Qgc2VuZCB5b3UgbWVkaWEgdW50aWwgeW91J3ZlIHNlbnQgeW91 ciBTRFAuICZuYnNwO0lmPGJyPg0KeW91IGRvbid0IHNlbmQgeW91ciBTRFAgKGluIHRoZSBBQ0sp IHVudGlsIHRoZXkgaGF2ZSBzZW50IHRoZWlycyAoaW4gdGhlPGJyPg0KMjAwT0spLCB0aGVuIHRo ZXJlIGlzIE5PIEVBUkxZIE1FRElBLjxicj4NCjxicj4NClllcywgdGhpcyBtZWFucyB0aGF0IFBT VE4gZ2F0ZXdheXMgd291bGQgaGF2ZSB0byBjb21wbGV0ZSBBQ0sgYmVmb3JlPGJyPg0KZG9pbmcg SUFNIG9uIHRoZSBQU1ROIHNpZGUuIEknbSBPSyB3aXRoIHRoYXQuPGJyPg0KPGJyPg0KJmd0OyBJ dCBkb2VzIGhhdmUgdGhlIGFkdmFudGFnZSB0aGF0IHlvdSBjYW4gYXNzb2NpYXRlIHRoZSBtZWRp YSBzdHJlYW0NCnRvPGJyPg0KJmd0OyB0aGUgc2lnbmFsaW5nIHNvdXJjZSwgYnV0IGl0IHN0aWxs IGRvZXNuJ3QgdGVsbCB5b3Ugd2hpY2ggc3RyZWFtIGlzPGJyPg0KJmd0OyBpbnRlcmVzdGluZyB0 byBsaXN0ZW4gdG8uPGJyPg0KPGJyPg0KQnV0IGhhdmluZyBhc3NvY2lhdGVkIHNpZ25hbGluZyBs ZXRzIHlvdSBkbyB0aGluZ3MgdG8gZGVjaWRlIHdoaWNoIG9uZTxicj4NCmlzIGludGVyZXN0aW5n Ljxicj4NCjxicj4NCiZndDsgSVNUTSB0aGF0IGlmIHlvdSB3YW50ICZxdW90O3NpbXVsdGFuZW91 cyByaW5nJnF1b3Q7LCBhbmQgdGhlIHRoaW5ncw0KcmluZ2luZyBhcmU8YnI+DQomZ3Q7IG9mdGVu IFBTVE4gZGV2aWNlcywgdGhlcmUgaXMgc3RpbGwgbm8gc29sdXRpb24uIFBlcmhhcHMgdGhlcmUg aXMgc29tZTxicj4NCiZndDsgcG9zc2liaWxpdHkgb2YgYXV0b21hdGVkIG1lZGlhIGFuYWx5c2lz IC0gdGhlIHBzdG4gR1cgZmlndXJpbmcgb3V0DQp0aGF0PGJyPg0KJmd0OyB0aGUgbWVkaWEgYmVp bmcgcmVjZWl2ZWQgaXMgc29tZXRoaW5nIHVuaW50ZXJlc3RpbmcgLSBqdXN0IGNvbnZlbnRpb25h bDxicj4NCiZndDsgcmluZ2JhY2sgLSBhbmQgc3VwcHJlc3NpbmcgaXQuIEJ1dCB0aGF0cyBhIGxv dCBvZiB0cm91YmxlIGFuZCBpcyBsaWtlbHk8YnI+DQomZ3Q7IHRvIGhhdmUgYSBoaWdoIGVycm9y IHJhdGUuPGJyPg0KPGJyPg0KR28gcGxheSB3aXRoIEdvb2dsZSBWb2ljZSBvciBzb21ldGhpbmcg bGlrZSBpdCBmb3IgYXdoaWxlIGFuZCB0aGVuIGdldDxicj4NCmJhY2sgdG8gdXMuPGJyPg0KPGJy Pg0KLS08YnI+DQpEZWFuPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpzaXBjb3JlIG1haWxpbmcgbGlzdDxicj4NCnNpcGNvcmVAaWV0Zi5v cmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmU8YnI+ DQo8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0 aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24m bmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtz b2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtv cmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7 aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJv dmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2Vj cmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5i c3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNw O2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNw O2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7 aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNw O3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7 aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhl eSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJz cDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtw bGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0 aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7 aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJz cDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJz cDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDth bmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0u DQo8L3ByZT4= --=_alternative 00729B52482576F1_=-- From gao.yang2@zte.com.cn Thu Mar 25 14:16:30 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A40E13A6358; Thu, 25 Mar 2010 14:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.205 X-Spam-Level: X-Spam-Status: No, score=-94.205 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] 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 Chdt4miaZbcF; Thu, 25 Mar 2010 14:16:29 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 1D6453A6958; Thu, 25 Mar 2010 14:16:27 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 128642001811080; Fri, 26 Mar 2010 05:15:34 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.15] with StormMail ESMTP id 64572.4668528412; Fri, 26 Mar 2010 05:16:42 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o2PLGbme015692; Fri, 26 Mar 2010 05:16:37 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4BA98D4C.4060707@cisco.com> To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 26 Mar 2010 05:14:48 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-03-26 05:16:40, Serialize complete at 2010-03-26 05:16:40 Content-Type: multipart/alternative; boundary="=_alternative 0074D9EE482576F1_=" X-MAIL: mse2.zte.com.cn o2PLGbme015692 Cc: sipcore-bounces@ietf.org, SIPCORE Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 21:16:30 -0000 This is a multipart message in MIME format. --=_alternative 0074D9EE482576F1_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgUGF1bCwNCg0KSSBhZ3JlZSBtb3N0IG9mIHlvdXIgcG9pbnRzLiBBbmQgYW91dCBQU1ROIGNh c2UsIHRoZXJlJ3Mgb25lIHRpbnkgDQpkaXNjdXNzaW9uLCBwbGVhc2Ugc2VlIGlubGluZXMuDQoN ClRoYW5rcywNCg0KR2FvDQoNCnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyDQtNPaIDIwMTAtMDMt MjQgMTE6NTU6NTY6DQoNCj4gDQo+IA0KPiBEZWFuIFdpbGxpcyB3cm90ZToNCj4gPiBQYXVsIEt5 eml2YXQgd3JvdGU6DQo+ID4+IE15IGNvbmNsdXNpb24gaXMgdGhhdCBub25lIG9mIHRoZSBzdWdn ZXN0aW9ucyBiZWluZyB0aHJvd24gYXJvdW5kDQo+ID4+IGZ1bmRhbWVudGFsbHkgaW1wcm92ZSB0 aGUgaGFuZGxpbmcgb2YgZWFybHkgbWVkaWEgaW4gYW55IHdheS4gSXRzIA0KanVzdCBhDQo+ID4+ IG1lc3MsIGFuZCB0aGVyZSBpcyBubyBmZWFzaWJsZSBzb2x1dGlvbi4NCj4gPiANCj4gPiBBcmd1 YWJseSwgbm90IGZvcmtpbmcgaW4gYSBwcm94eSBoZWxwcy4gSXQgbGVhc3QgbGV0cyB5b3Uga25v dyBob3cgdG8NCj4gPiBraWxsIGFuIGVhcmx5IG1lZGlhIHN0cmVhbSB0aGF0IGlzIGJlaW5nIHNw ZXdlZCBiYWNrIGF0IHlvdS4NCj4gDQo+IFdlbGwsIHRoYXQgZGVwZW5kcy4NCj4gDQo+IEl0cyBy ZWFsbHkgb25seSBwYXJhbGxlbCBmb3JraW5nIHRoYXRzIGEgcHJvYmxlbSwgc28gd2UgY2FuIHBy b2JhYmx5IA0KPiBpZ25vcmUgc2VyaWFsIGZvcmtpbmcuDQo+IA0KPiBGb3IgcGFyYWxsZWwgZm9y a2luZywgbW92aW5nIGl0IGZyb20gdGhlIHByb3h5IHRvIHRoZSBVQUMgZG9lc24ndCByZWFsbHkg DQoNCj4gc29sdmUgdGhlIHByb2JsZW0gLSB5b3UgY2FuIHN0aWxsIGVuZCB1cCB3aXRoIG11bHRp cGxlIG1lZGlhIHN0cmVhbXMgYW5kIA0KDQo+IG5vIGNsdWUgd2hhdCB0byBkbyB3aXRoIHRoZW0u DQo+IA0KPiBZb3UgY2FuIHNheSAiZG9uJ3QgZG8gdGhhdCIsIGJ1dCB0aGVyZSBhcmUgZGVzaXJh YmxlIGZlYXR1cmVzIHRoYXQgDQo+IGRlcGVuZCBvbiBpdCAtIG5hbWVseSAic2ltdWx0YW5lb3Vz IHJpbmciLiBQb3RlbnRpYWxseSB0aGF0IGNhbiBiZSANCj4gcmVwbGFjZWQgd2l0aCBwcmVzZW5j ZS1zZW5zaXRpdmUgcmluZ2luZyB0byBjaG9vc2UgdGhlICpyaWdodCogb24gdG8gDQo+IHJpbmcg Zmlyc3QsIGJ1dCB0aGF0IHJlcXVpcmVzIGRhdGEgdGhhdCBvZnRlbiBpc24ndCBhdmFpbGFibGUu DQo+IA0KPiA+IE9mZmVybGVzcyBJTlZJVEVzIGhlbHAgbW9yZSwgc2luY2UgdGhlIG1lZGlhIGNh bid0IGNvbWUgYmFjayB0byB5b3UNCj4gPiB1bnRpbCB0aGUgTy9BIGhhcyBjb21wbGV0ZWQuDQo+ IA0KPiBUaGF0IGlzIGp1c3Qgc3RpY2tpbmcgeW91ciBoZWFkIGluIHRoZSBzYW5kLiBUaGUgbWVk aWEgaXMgc3RpbGwgYmVpbmcgDQo+IGdlbmVyYXRlZCwgZXZlbiBpZiB5b3UgZG9uJ3Qga25vdyBh Ym91dCBpdC4NCj4gDQo+IEl0IGRvZXMgaGF2ZSB0aGUgYWR2YW50YWdlIHRoYXQgeW91IGNhbiBh c3NvY2lhdGUgdGhlIG1lZGlhIHN0cmVhbSB0byANCj4gdGhlIHNpZ25hbGluZyBzb3VyY2UsIGJ1 dCBpdCBzdGlsbCBkb2Vzbid0IHRlbGwgeW91IHdoaWNoIHN0cmVhbSBpcyANCj4gaW50ZXJlc3Rp bmcgdG8gbGlzdGVuIHRvLg0KPiANCj4gSVNUTSB0aGF0IGlmIHlvdSB3YW50ICJzaW11bHRhbmVv dXMgcmluZyIsIGFuZCB0aGUgdGhpbmdzIHJpbmdpbmcgYXJlIA0KPiBvZnRlbiBQU1ROIGRldmlj ZXMsIHRoZXJlIGlzIHN0aWxsIG5vIHNvbHV0aW9uLiBQZXJoYXBzIHRoZXJlIGlzIHNvbWUgDQo+ IHBvc3NpYmlsaXR5IG9mIGF1dG9tYXRlZCBtZWRpYSBhbmFseXNpcyAtIHRoZSBwc3RuIEdXIGZp Z3VyaW5nIG91dCB0aGF0IA0KPiB0aGUgbWVkaWEgYmVpbmcgcmVjZWl2ZWQgaXMgc29tZXRoaW5n IHVuaW50ZXJlc3RpbmcgLSBqdXN0IGNvbnZlbnRpb25hbCANCj4gcmluZ2JhY2sgLSBhbmQgc3Vw cHJlc3NpbmcgaXQuIEJ1dCB0aGF0cyBhIGxvdCBvZiB0cm91YmxlIGFuZCBpcyBsaWtlbHkgDQo+ IHRvIGhhdmUgYSBoaWdoIGVycm9yIHJhdGUuDQoNCltHYW9dIEkgb25jZSBoYWQgdGhlIHNhbWUg dmlld3BvaW50LiBCdXQgbm93IEkgZ3Vlc3MgdGhlIGdhdGV3YXkgY2FuIGxldCANCnRoZSBjYWxs ZXIgY2hvb3NlIGZyb20gdGhlIG11bHRpcGxlIGVhcmx5IG1lZGlhIHdpdGggb3V0IG1lZGlhIGFu YWx5c2lzLiANClN1Y2ggYXMgIlByZXNzIDIgdG8gY2hvb3NlIHRoZSBzZWNvbmQgZWFybHkgbWVk aWEiLg0KSWYgdGhlIGdhdGV3YXkgc3VwcG9ydCBWb2ljZVhNTCBvciBzb21lIG90aGVyIElWUiBt ZWNoYW5pc20sIGl0IGNhbiBmb3JtYXQgDQp0aGUgdm9pY2UgYnkgdGhlIGNhbGxlZSdzIFVSSSwg c3VjaCBhcyAiUHJlc3MgMiB0byBsaXN0ZW4gdG8gQWxpY2UiLg0KDQo+IA0KPiAgICBUaGFua3Ms DQo+ICAgIFBhdWwNCj4gDQo+ID4gV2hhdCBpZiB3ZSBzcGxpdCB0aGUgTy9BIHN0YWdlIGludG8g dGhyZWUgcGhhc2VzOg0KPiA+IA0KPiA+IDEpIHByZS1vZmZlcjogQWxpY2UgSU5WSVRFUyBCb2Is IGluY2x1ZGVzIGEgZGVzY3JpcHRpb24gb2YgbWVkaWEgc2hlIA0KY2FuDQo+ID4gc2VuZCBhbmQg cmVjZWl2ZSBidXQgbm90IGFuIElQIGFkZHJlc3Mgb3IgcG9ydCBudW1iZXINCj4gPiANCj4gPiAy KSBvZmZlcjogQm9iIHNlbmRzIEFsaWNlIGEgZGVzY3JpcHRpb24gb2YgdGhlIG1lZGlhIGhlIGV4 cGVjdHMgdG8gDQpzZW5kDQo+ID4gYW5kIHRvIHJlY2VpdmUsIGFsb25nIHdpdGggdGhlIElQIGFk ZHJlc3NlcyBhbmQgcG9ydCBudW1iZXJzIGhlIGlzIA0KZ29pbmcNCj4gPiB0byB1c2UuDQo+ID4g DQo+ID4gMykgYW5zd2VyOiBBbGljZSBzZW5kcyBCb2IgdGhlIElQIGFkZHJlc3NlcyBhbmQgcG9y dCBudW1iZXIgdG8gd2hpY2hzIA0KaGUNCj4gPiBzaG91bGQgZGlyZWN0IG1lZGlhIGFuZCBmcm9t IHdoaWNoIEFsaWNlIHdpbGwgYmUgc2VuZGluZyBtZWRpYS4NCj4gPiANCj4gPiBOb3RlIHRoYXQg dGhpcyBlbGltaW5hdGVzIGVhcmx5IG1lZGlhLiBCb2IgY2FuJ3Qgc2VuZCBBbGljZSBhbnkgbWVk aWENCj4gPiB1bnRpbCBoZSByZWNlaXZlcyB0aGUgYW5zd2VyLg0KPiA+IA0KPiA+IA0KPiA+IC0t DQo+ID4gRGVhbg0KPiA+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPiBzaXBjb3JlQGlldGYub3JnDQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPiANCg0KDQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFp bmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2Fu aXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGll bnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJl IG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNh dGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0 aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2Yg dGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9y aWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNz YWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFz IGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3Rl bS4NCg== --=_alternative 0074D9EE482576F1_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFBhdWwsPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIGFncmVlIG1vc3Qgb2YgeW91 ciBwb2ludHMuIEFuZCBhb3V0DQpQU1ROIGNhc2UsIHRoZXJlJ3Mgb25lIHRpbnkgZGlzY3Vzc2lv biwgcGxlYXNlIHNlZSBpbmxpbmVzLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+VGhhbmtzLDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+R2FvPC9mb250Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+c2lw Y29yZS1ib3VuY2VzQGlldGYub3JnINC009ogMjAxMC0wMy0yNCAxMTo1NTo1Njo8YnI+DQo8YnI+ DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBEZWFuIFdpbGxpcyB3cm90ZTo8YnI+DQomZ3Q7 ICZndDsgUGF1bCBLeXppdmF0IHdyb3RlOjxicj4NCiZndDsgJmd0OyZndDsgTXkgY29uY2x1c2lv biBpcyB0aGF0IG5vbmUgb2YgdGhlIHN1Z2dlc3Rpb25zIGJlaW5nIHRocm93bg0KYXJvdW5kPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyBmdW5kYW1lbnRhbGx5IGltcHJvdmUgdGhlIGhhbmRsaW5nIG9mIGVh cmx5IG1lZGlhIGluIGFueQ0Kd2F5LiBJdHMganVzdCBhPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBtZXNz LCBhbmQgdGhlcmUgaXMgbm8gZmVhc2libGUgc29sdXRpb24uPGJyPg0KJmd0OyAmZ3Q7IDxicj4N CiZndDsgJmd0OyBBcmd1YWJseSwgbm90IGZvcmtpbmcgaW4gYSBwcm94eSBoZWxwcy4gSXQgbGVh c3QgbGV0cyB5b3Uga25vdw0KaG93IHRvPGJyPg0KJmd0OyAmZ3Q7IGtpbGwgYW4gZWFybHkgbWVk aWEgc3RyZWFtIHRoYXQgaXMgYmVpbmcgc3Bld2VkIGJhY2sgYXQgeW91Ljxicj4NCiZndDsgPGJy Pg0KJmd0OyBXZWxsLCB0aGF0IGRlcGVuZHMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEl0cyByZWFs bHkgb25seSBwYXJhbGxlbCBmb3JraW5nIHRoYXRzIGEgcHJvYmxlbSwgc28gd2UgY2FuIHByb2Jh Ymx5DQo8YnI+DQomZ3Q7IGlnbm9yZSBzZXJpYWwgZm9ya2luZy48YnI+DQomZ3Q7IDxicj4NCiZn dDsgRm9yIHBhcmFsbGVsIGZvcmtpbmcsIG1vdmluZyBpdCBmcm9tIHRoZSBwcm94eSB0byB0aGUg VUFDIGRvZXNuJ3QNCnJlYWxseSA8YnI+DQomZ3Q7IHNvbHZlIHRoZSBwcm9ibGVtIC0geW91IGNh biBzdGlsbCBlbmQgdXAgd2l0aCBtdWx0aXBsZSBtZWRpYSBzdHJlYW1zDQphbmQgPGJyPg0KJmd0 OyBubyBjbHVlIHdoYXQgdG8gZG8gd2l0aCB0aGVtLjxicj4NCiZndDsgPGJyPg0KJmd0OyBZb3Ug Y2FuIHNheSAmcXVvdDtkb24ndCBkbyB0aGF0JnF1b3Q7LCBidXQgdGhlcmUgYXJlIGRlc2lyYWJs ZSBmZWF0dXJlcw0KdGhhdCA8YnI+DQomZ3Q7IGRlcGVuZCBvbiBpdCAtIG5hbWVseSAmcXVvdDtz aW11bHRhbmVvdXMgcmluZyZxdW90Oy4gUG90ZW50aWFsbHkgdGhhdA0KY2FuIGJlIDxicj4NCiZn dDsgcmVwbGFjZWQgd2l0aCBwcmVzZW5jZS1zZW5zaXRpdmUgcmluZ2luZyB0byBjaG9vc2UgdGhl ICpyaWdodCogb24NCnRvIDxicj4NCiZndDsgcmluZyBmaXJzdCwgYnV0IHRoYXQgcmVxdWlyZXMg ZGF0YSB0aGF0IG9mdGVuIGlzbid0IGF2YWlsYWJsZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0 OyBPZmZlcmxlc3MgSU5WSVRFcyBoZWxwIG1vcmUsIHNpbmNlIHRoZSBtZWRpYSBjYW4ndCBjb21l IGJhY2sNCnRvIHlvdTxicj4NCiZndDsgJmd0OyB1bnRpbCB0aGUgTy9BIGhhcyBjb21wbGV0ZWQu PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYXQgaXMganVzdCBzdGlja2luZyB5b3VyIGhlYWQgaW4g dGhlIHNhbmQuIFRoZSBtZWRpYSBpcyBzdGlsbCBiZWluZw0KPGJyPg0KJmd0OyBnZW5lcmF0ZWQs IGV2ZW4gaWYgeW91IGRvbid0IGtub3cgYWJvdXQgaXQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEl0 IGRvZXMgaGF2ZSB0aGUgYWR2YW50YWdlIHRoYXQgeW91IGNhbiBhc3NvY2lhdGUgdGhlIG1lZGlh IHN0cmVhbQ0KdG8gPGJyPg0KJmd0OyB0aGUgc2lnbmFsaW5nIHNvdXJjZSwgYnV0IGl0IHN0aWxs IGRvZXNuJ3QgdGVsbCB5b3Ugd2hpY2ggc3RyZWFtIGlzDQo8YnI+DQomZ3Q7IGludGVyZXN0aW5n IHRvIGxpc3RlbiB0by48YnI+DQomZ3Q7IDxicj4NCiZndDsgSVNUTSB0aGF0IGlmIHlvdSB3YW50 ICZxdW90O3NpbXVsdGFuZW91cyByaW5nJnF1b3Q7LCBhbmQgdGhlIHRoaW5ncw0KcmluZ2luZyBh cmUgPGJyPg0KJmd0OyBvZnRlbiBQU1ROIGRldmljZXMsIHRoZXJlIGlzIHN0aWxsIG5vIHNvbHV0 aW9uLiBQZXJoYXBzIHRoZXJlIGlzIHNvbWUNCjxicj4NCiZndDsgcG9zc2liaWxpdHkgb2YgYXV0 b21hdGVkIG1lZGlhIGFuYWx5c2lzIC0gdGhlIHBzdG4gR1cgZmlndXJpbmcgb3V0DQp0aGF0IDxi cj4NCiZndDsgdGhlIG1lZGlhIGJlaW5nIHJlY2VpdmVkIGlzIHNvbWV0aGluZyB1bmludGVyZXN0 aW5nIC0ganVzdCBjb252ZW50aW9uYWwNCjxicj4NCiZndDsgcmluZ2JhY2sgLSBhbmQgc3VwcHJl c3NpbmcgaXQuIEJ1dCB0aGF0cyBhIGxvdCBvZiB0cm91YmxlIGFuZCBpcyBsaWtlbHkNCjxicj4N CiZndDsgdG8gaGF2ZSBhIGhpZ2ggZXJyb3IgcmF0ZS48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPltHYW9dIEkgb25jZSBoYWQgdGhlIHNhbWUgdmlld3BvaW50LiBCdXQg bm93IEkgZ3Vlc3MNCnRoZSBnYXRld2F5IGNhbiBsZXQgdGhlIGNhbGxlciBjaG9vc2UgZnJvbSB0 aGUgbXVsdGlwbGUgZWFybHkgbWVkaWEgd2l0aA0Kb3V0IG1lZGlhIGFuYWx5c2lzLiBTdWNoIGFz ICZxdW90O1ByZXNzIDIgdG8gY2hvb3NlIHRoZSBzZWNvbmQgZWFybHkgbWVkaWEmcXVvdDsuPC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5JZiB0aGUgZ2F0ZXdheSBzdXBwb3J0IFZv aWNlWE1MIG9yIHNvbWUgb3RoZXIgSVZSDQptZWNoYW5pc20sIGl0IGNhbiBmb3JtYXQgdGhlIHZv aWNlIGJ5IHRoZSBjYWxsZWUncyBVUkksIHN1Y2ggYXMgJnF1b3Q7UHJlc3MNCjIgdG8gbGlzdGVu IHRvIEFsaWNlJnF1b3Q7LjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+PGJyPg0K Jmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtUaGFua3MsPGJyPg0KJmd0OyAmbmJzcDsgJm5i c3A7UGF1bDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IFdoYXQgaWYgd2Ugc3BsaXQgdGhlIE8v QSBzdGFnZSBpbnRvIHRocmVlIHBoYXNlczo8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 IDEpIHByZS1vZmZlcjogQWxpY2UgSU5WSVRFUyBCb2IsIGluY2x1ZGVzIGEgZGVzY3JpcHRpb24g b2YgbWVkaWENCnNoZSBjYW48YnI+DQomZ3Q7ICZndDsgc2VuZCBhbmQgcmVjZWl2ZSBidXQgbm90 IGFuIElQIGFkZHJlc3Mgb3IgcG9ydCBudW1iZXI8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7IDIpIG9mZmVyOiBCb2Igc2VuZHMgQWxpY2UgYSBkZXNjcmlwdGlvbiBvZiB0aGUgbWVkaWEg aGUgZXhwZWN0cw0KdG8gc2VuZDxicj4NCiZndDsgJmd0OyBhbmQgdG8gcmVjZWl2ZSwgYWxvbmcg d2l0aCB0aGUgSVAgYWRkcmVzc2VzIGFuZCBwb3J0IG51bWJlcnMNCmhlIGlzIGdvaW5nPGJyPg0K Jmd0OyAmZ3Q7IHRvIHVzZS48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDMpIGFuc3dl cjogQWxpY2Ugc2VuZHMgQm9iIHRoZSBJUCBhZGRyZXNzZXMgYW5kIHBvcnQgbnVtYmVyIHRvDQp3 aGljaHMgaGU8YnI+DQomZ3Q7ICZndDsgc2hvdWxkIGRpcmVjdCBtZWRpYSBhbmQgZnJvbSB3aGlj aCBBbGljZSB3aWxsIGJlIHNlbmRpbmcgbWVkaWEuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsg Jmd0OyBOb3RlIHRoYXQgdGhpcyBlbGltaW5hdGVzIGVhcmx5IG1lZGlhLiBCb2IgY2FuJ3Qgc2Vu ZCBBbGljZSBhbnkNCm1lZGlhPGJyPg0KJmd0OyAmZ3Q7IHVudGlsIGhlIHJlY2VpdmVzIHRoZSBh bnN3ZXIuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgLS08 YnI+DQomZ3Q7ICZndDsgRGVhbjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBzaXBjb3JlIG1h aWxpbmcgbGlzdDxicj4NCiZndDsgc2lwY29yZUBpZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlPGJyPg0KJmd0OyA8YnI+DQo8L2Zv bnQ+PC90dD4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkm bmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJz cDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0 eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7 VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRp YWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtv YmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNw O2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0 aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJz cDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNw O2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtj b25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZu YnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29y Jm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2Fk ZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3Ro aXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkm bmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZu YnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7 bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlk dWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5i c3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7 YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 0074D9EE482576F1_=-- From jon.peterson@neustar.biz Thu Mar 25 14:27:48 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED0193A6B97 for ; Thu, 25 Mar 2010 14:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.719 X-Spam-Level: X-Spam-Status: No, score=-98.719 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, USER_IN_WHITELIST=-100] 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 GiDPv20vXyGs for ; Thu, 25 Mar 2010 14:27:47 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id A584D3A69B0 for ; Thu, 25 Mar 2010 14:27:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1269552477; x=1584912408; q=dns/txt; h=Message-ID:Date:From:Subject:Content-Type: Content-Transfer-Encoding; bh=aNF7cWvOvlH3u5thGZ6fPzwTwwG7MuQfWj BuXST5q1E=; b=VaNIhjpJ1f8pUY8ZfIZdQiWnlyyhaEXAa4zAxSNZOEY3x6Y//j esmjAZq0TVHIfQIUL9UDkXMcdE4kTeS76JdQ== Received: from ([192.168.128.18]) by stihiron1.va.neustar.com with ESMTP id G6K7MJ1.7597036; Thu, 25 Mar 2010 17:27:55 -0400 Message-ID: <4BABD55B.9040507@neustar.biz> Date: Thu, 25 Mar 2010 14:27:55 -0700 From: Jon Peterson User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: sipcore@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Subject: [sipcore] rebooting location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 21:27:49 -0000 James Polk and I sat down this week and took a hard look at the current s= ipcore-location-conveyance draft, and we believe that there's an opportun= ity to simplify (and shorten) the document. The simplification derives mostly from a single change to the operation o= f the mechanism. Today, the location-conveyance draft has a good deal of = machinery to support the case where a proxy wants to replace existing loc= ation information in a request with more accurate or preferred location i= nformation. The current approach replaces the URI in the Geolocation head= er (which probably points to a MIME body) with a URI desired by the proxy= , presumably of an Internet resource containing the desired PIDF-LO body.= This solution isn't optimal for several reasons - most notably, since th= e MIME body is not removed by said proxy, it will still be delivered to t= he eventual location recipient, even if the URI in the Geolocation header= does not point to said body. In order to handle this case, the current d= raft employs a disambiguation mechanism (relying on the "used-for-routing= " and "inserted-by" parameters, as well as the "inserter") to inform the = location recipient about the source of this location information. Moreove= r, since this change is effected unilaterally, the originating user agent= has no idea that the location it supplied has been altered in transit, a= nd may thus receive a surprising response to its request. While this use case is an important one, we believe it can be addressed w= ith a lighter mechanism. The basic idea is that a proxy server that wants= to replace the location information provided by a user agent would rejec= t a request with the 424 Bad Location response code, optionally enclosing= in the body the location information that it would like the user agent t= o incorporate. The UA can insert the LI from the 424 in its subsequent r= eissuance of the request; if no LI is supplied in the 424, then the user = agent resends the request without LI. This brings the location-conveyance= mechanism back to one its original constraints: that only one PIDF-LO bo= dy is associated with a particular SIP request. This allows us to remove = the "used-for-routing" parameter as well as the "inserted-by"/"inserter" = mechanism. In a related clean-up, several of the error codes can probably be consoli= dated or replaced with SIP response codes (for example, the Retry-After s= emantics of the 200/300 error codes). If no one objects, we'd therefore like to try to come back with a new ver= sion that has fewer moving parts and fewer pages. Thoughts? Jon Peterson NeuStar, Inc. From keith.drage@alcatel-lucent.com Thu Mar 25 14:54:27 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EF1F3A684F for ; Thu, 25 Mar 2010 14:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.66 X-Spam-Level: X-Spam-Status: No, score=-0.66 tagged_above=-999 required=5 tests=[AWL=-2.141, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35] 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 SB-awjgnGC+t for ; Thu, 25 Mar 2010 14:54:26 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 475553A682E for ; Thu, 25 Mar 2010 14:54:26 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o2PLsj6W001853 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 25 Mar 2010 22:54:45 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 25 Mar 2010 22:54:45 +0100 From: "DRAGE, Keith (Keith)" To: Jon Peterson , "sipcore@ietf.org" Date: Thu, 25 Mar 2010 22:54:44 +0100 Thread-Topic: [sipcore] rebooting location-conveyance Thread-Index: AcrMYhaLJvxu0/t5SseyN0HkgyA0WwAA1oDg Message-ID: References: <4BABD55B.9040507@neustar.biz> In-Reply-To: <4BABD55B.9040507@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: Re: [sipcore] rebooting location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 21:54:27 -0000 So, I believe the current solution allows a scenario where the originating = UA inserts a location, and various proxies along the path could insert a lo= cation, in addition to the existing one, providing they all represent their= view of the state of the user. By making this proposal, are you eliminating this scenario, or allowing it = to continue to exist. regards Keith =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Jon Peterson > Sent: Thursday, March 25, 2010 9:28 PM > To: sipcore@ietf.org > Subject: [sipcore] rebooting location-conveyance >=20 > James Polk and I sat down this week and took a hard look at=20 > the current sipcore-location-conveyance draft, and we believe=20 > that there's an opportunity to simplify (and shorten) the document. >=20 > The simplification derives mostly from a single change to the=20 > operation of the mechanism. Today, the location-conveyance=20 > draft has a good deal of machinery to support the case where=20 > a proxy wants to replace existing location information in a=20 > request with more accurate or preferred location information.=20 > The current approach replaces the URI in the Geolocation=20 > header (which probably points to a MIME body) with a URI=20 > desired by the proxy, presumably of an Internet resource=20 > containing the desired PIDF-LO body. This solution isn't=20 > optimal for several reasons - most notably, since the MIME=20 > body is not removed by said proxy, it will still be delivered=20 > to the eventual location recipient, even if the URI in the=20 > Geolocation header does not point to said body. In order to=20 > handle this case, the current draft employs a disambiguation=20 > mechanism (relying on the "used-for-routing" and=20 > "inserted-by" parameters, as well as the "inserter") to=20 > inform the location recipient about the source of th is=20 > location information. Moreover, since this change is effected=20 > unilaterally, the originating user agent has no idea that the=20 > location it supplied has been altered in transit, and may=20 > thus receive a surprising response to its request. >=20 > While this use case is an important one, we believe it can be=20 > addressed with a lighter mechanism. The basic idea is that a=20 > proxy server that wants to replace the location information=20 > provided by a user agent would reject a request with the 424=20 > Bad Location response code, optionally enclosing in the body=20 > the location information that it would like the user agent to=20 > incorporate. The UA can insert the LI from the 424 in its=20 > subsequent reissuance of the request; if no LI is supplied in=20 > the 424, then the user agent resends the request without LI.=20 > This brings the location-conveyance mechanism back to one its=20 > original constraints: that only one PIDF-LO body is=20 > associated with a particular SIP request. This allows us to=20 > remove the "used-for-routing" parameter as well as the=20 > "inserted-by"/"inserter" mechanism. >=20 > In a related clean-up, several of the error codes can=20 > probably be consolidated or replaced with SIP response codes=20 > (for example, the Retry-After semantics of the 200/300 error codes). >=20 > If no one objects, we'd therefore like to try to come back=20 > with a new version that has fewer moving parts and fewer pages. >=20 > Thoughts? >=20 > Jon Peterson > NeuStar, Inc. >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From Martin.Thomson@andrew.com Thu Mar 25 17:05:35 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FBA03A6838 for ; Thu, 25 Mar 2010 17:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.806 X-Spam-Level: X-Spam-Status: No, score=0.806 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 n3EcHzLyal4e for ; Thu, 25 Mar 2010 17:05:34 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 621933A6830 for ; Thu, 25 Mar 2010 17:05:34 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:39429 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S205390Ab0CZAD4 (ORCPT ); Thu, 25 Mar 2010 19:03:56 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Thu, 25 Mar 2010 18:41:48 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 26 Mar 2010 07:41:43 +0800 From: "Thomson, Martin" To: Jon Peterson , "sipcore@ietf.org" Date: Fri, 26 Mar 2010 07:42:59 +0800 Thread-Topic: [sipcore] rebooting location-conveyance Thread-Index: AcrMYhRzQi3LBWIZQ5af3HwrAAVZfQAAN1IA Message-ID: <8B0A9FCBB9832F43971E38010638454F03E24ED33F@SISPE7MB1.commscope.com> References: <4BABD55B.9040507@neustar.biz> In-Reply-To: <4BABD55B.9040507@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [sipcore] rebooting location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 00:05:35 -0000 SGkgSm9uLA0KDQpJJ2Qgd2VsY29tZSBhbnkgYXR0ZW1wdCB0byBtYWtlIHRoaXMgZG9jdW1lbnQg c2ltcGxlci4gIE92ZXIgdGltZSwgaXQncyBidWlsdCB1cCBhIGZhaXIgYW1vdW50IG9mIGJhZ2dh Z2UgYXMgaXQncyBtYWRlIGl0J3Mgd2F5IHRocm91Z2ggZm91ciAoPykgd29ya2luZyBncm91cHMu ICBUaGlzIHNvdW5kcyBsaWtlIGEgcmVhc29uYWJsZSBjdXQuDQoNClRoZSB1c2UgY2FzZSB0aGF0 IGlzIGEgdmljdGltIG9mIHRoaXMgaXMgdGhlIG9uZSB3aGVyZSBhIGhvc3QgaGFzIHR3byBsb2Nh dGlvbnM6IGJ5IHZhbHVlIGFuZCBieSByZWZlcmVuY2UgdGhhdCB0aGV5IHdhbnQgdG8gaW5jbHVk ZS4gIFRoaXMgbWlnaHQgYmUgdGhlICJub3ciIGFuZCAiZm9yIGxhdGVyIiB1c2UgY2FzZSwgb3Ig aXQgY291bGQgYmUgdGhlIGxvY2F0aW9uIGhpZGluZyB1c2UgY2FzZSB3aGVyZSB0aGUgdmFsdWUg aXMgcG9vciBxdWFsaXR5IGFuZCB0aGUgcmVmZXJlbmNlIG1pZ2h0IGJlIHVzZWQgdG8gZ2V0IHRo ZSByZWFsbHkgZ29vZCBzdHVmZi4gIEFzIGxvbmcgYXMgd2UgYXJlIGFibGUgdG8gYWRkcmVzcyB0 aGF0IHVzZSBjYXNlLCB0aGVuIEknbSBoYXBweS4NCg0KSSBkb24ndCB0aGluayB0aGF0IHdlIG5l ZWQgdG8gcmUtYnVpbGQgYWxsIHRoYXQgc3R1ZmYgdGhhdCB5b3UgYXJlIHN0cmlwcGluZyBvdXQs IGJ1dCB3ZSBjdXJyZW50bHkgZG9uJ3QgaGF2ZSBhIGdvb2Qgc3RvcnkgZm9yIHRoYXQuDQoNCi0t TWFydGluDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc2lwY29yZS1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBC ZWhhbGYgT2YgSm9uIFBldGVyc29uDQo+IFNlbnQ6IFRodXJzZGF5LCAyNSBNYXJjaCAyMDEwIDI6 MjggUE0NCj4gVG86IHNpcGNvcmVAaWV0Zi5vcmcNCj4gU3ViamVjdDogW3NpcGNvcmVdIHJlYm9v dGluZyBsb2NhdGlvbi1jb252ZXlhbmNlDQo+IA0KPiBKYW1lcyBQb2xrIGFuZCBJIHNhdCBkb3du IHRoaXMgd2VlayBhbmQgdG9vayBhIGhhcmQgbG9vayBhdCB0aGUgY3VycmVudA0KPiBzaXBjb3Jl LWxvY2F0aW9uLWNvbnZleWFuY2UgZHJhZnQsIGFuZCB3ZSBiZWxpZXZlIHRoYXQgdGhlcmUncyBh bg0KPiBvcHBvcnR1bml0eSB0byBzaW1wbGlmeSAoYW5kIHNob3J0ZW4pIHRoZSBkb2N1bWVudC4N Cj4gDQo+IFRoZSBzaW1wbGlmaWNhdGlvbiBkZXJpdmVzIG1vc3RseSBmcm9tIGEgc2luZ2xlIGNo YW5nZSB0byB0aGUgb3BlcmF0aW9uDQo+IG9mIHRoZSBtZWNoYW5pc20uIFRvZGF5LCB0aGUgbG9j YXRpb24tY29udmV5YW5jZSBkcmFmdCBoYXMgYSBnb29kIGRlYWwNCj4gb2YgbWFjaGluZXJ5IHRv IHN1cHBvcnQgdGhlIGNhc2Ugd2hlcmUgYSBwcm94eSB3YW50cyB0byByZXBsYWNlDQo+IGV4aXN0 aW5nIGxvY2F0aW9uIGluZm9ybWF0aW9uIGluIGEgcmVxdWVzdCB3aXRoIG1vcmUgYWNjdXJhdGUg b3INCj4gcHJlZmVycmVkIGxvY2F0aW9uIGluZm9ybWF0aW9uLiBUaGUgY3VycmVudCBhcHByb2Fj aCByZXBsYWNlcyB0aGUgVVJJDQo+IGluIHRoZSBHZW9sb2NhdGlvbiBoZWFkZXIgKHdoaWNoIHBy b2JhYmx5IHBvaW50cyB0byBhIE1JTUUgYm9keSkgd2l0aCBhDQo+IFVSSSBkZXNpcmVkIGJ5IHRo ZSBwcm94eSwgcHJlc3VtYWJseSBvZiBhbiBJbnRlcm5ldCByZXNvdXJjZSBjb250YWluaW5nDQo+ IHRoZSBkZXNpcmVkIFBJREYtTE8gYm9keS4gVGhpcyBzb2x1dGlvbiBpc24ndCBvcHRpbWFsIGZv ciBzZXZlcmFsDQo+IHJlYXNvbnMgLSBtb3N0IG5vdGFibHksIHNpbmNlIHRoZSBNSU1FIGJvZHkg aXMgbm90IHJlbW92ZWQgYnkgc2FpZA0KPiBwcm94eSwgaXQgd2lsbCBzdGlsbCBiZSBkZWxpdmVy ZWQgdG8gdGhlIGV2ZW50dWFsIGxvY2F0aW9uIHJlY2lwaWVudCwNCj4gZXZlbiBpZiB0aGUgVVJJ IGluIHRoZSBHZW9sb2NhdGlvbiBoZWFkZXIgZG9lcyBub3QgcG9pbnQgdG8gc2FpZCBib2R5Lg0K PiBJbiBvcmRlciB0byBoYW5kbGUgdGhpcyBjYXNlLCB0aGUgY3VycmVudCBkcmFmdCBlbXBsb3lz IGENCj4gZGlzYW1iaWd1YXRpb24gbWVjaGFuaXNtIChyZWx5aW5nIG9uIHRoZSAidXNlZC1mb3It cm91dGluZyIgYW5kDQo+ICJpbnNlcnRlZC1ieSIgcGFyYW1ldGVycywgYXMgd2VsbCBhcyB0aGUg Imluc2VydGVyIikgdG8gaW5mb3JtIHRoZQ0KPiBsb2NhdGlvbiByZWNpcGllbnQgYWJvdXQgdGhl IHNvdXJjZSBvZiB0aA0KPiAgaXMgbG9jYXRpb24gaW5mb3JtYXRpb24uIE1vcmVvdmVyLCBzaW5j ZSB0aGlzIGNoYW5nZSBpcyBlZmZlY3RlZA0KPiB1bmlsYXRlcmFsbHksIHRoZSBvcmlnaW5hdGlu ZyB1c2VyIGFnZW50IGhhcyBubyBpZGVhIHRoYXQgdGhlIGxvY2F0aW9uDQo+IGl0IHN1cHBsaWVk IGhhcyBiZWVuIGFsdGVyZWQgaW4gdHJhbnNpdCwgYW5kIG1heSB0aHVzIHJlY2VpdmUgYQ0KPiBz dXJwcmlzaW5nIHJlc3BvbnNlIHRvIGl0cyByZXF1ZXN0Lg0KPiANCj4gV2hpbGUgdGhpcyB1c2Ug Y2FzZSBpcyBhbiBpbXBvcnRhbnQgb25lLCB3ZSBiZWxpZXZlIGl0IGNhbiBiZSBhZGRyZXNzZWQN Cj4gd2l0aCBhIGxpZ2h0ZXIgbWVjaGFuaXNtLiBUaGUgYmFzaWMgaWRlYSBpcyB0aGF0IGEgcHJv eHkgc2VydmVyIHRoYXQNCj4gd2FudHMgdG8gcmVwbGFjZSB0aGUgbG9jYXRpb24gaW5mb3JtYXRp b24gcHJvdmlkZWQgYnkgYSB1c2VyIGFnZW50DQo+IHdvdWxkIHJlamVjdCBhIHJlcXVlc3Qgd2l0 aCB0aGUgNDI0IEJhZCBMb2NhdGlvbiByZXNwb25zZSBjb2RlLA0KPiBvcHRpb25hbGx5IGVuY2xv c2luZyBpbiB0aGUgYm9keSB0aGUgbG9jYXRpb24gaW5mb3JtYXRpb24gdGhhdCBpdCB3b3VsZA0K PiBsaWtlIHRoZSB1c2VyIGFnZW50IHRvIGluY29ycG9yYXRlLiAgVGhlIFVBIGNhbiBpbnNlcnQg dGhlIExJIGZyb20gdGhlDQo+IDQyNCBpbiBpdHMgc3Vic2VxdWVudCByZWlzc3VhbmNlIG9mIHRo ZSByZXF1ZXN0OyBpZiBubyBMSSBpcyBzdXBwbGllZA0KPiBpbiB0aGUgNDI0LCB0aGVuIHRoZSB1 c2VyIGFnZW50IHJlc2VuZHMgdGhlIHJlcXVlc3Qgd2l0aG91dCBMSS4gVGhpcw0KPiBicmluZ3Mg dGhlIGxvY2F0aW9uLWNvbnZleWFuY2UgbWVjaGFuaXNtIGJhY2sgdG8gb25lIGl0cyBvcmlnaW5h bA0KPiBjb25zdHJhaW50czogdGhhdCBvbmx5IG9uZSBQSURGLUxPIGJvZHkgaXMgYXNzb2NpYXRl ZCB3aXRoIGEgcGFydGljdWxhcg0KPiBTSVAgcmVxdWVzdC4gVGhpcyBhbGxvd3MgdXMgdG8gcmVt b3ZlIHRoZSAidXNlZC1mb3Itcm91dGluZyIgcGFyYW1ldGVyDQo+IGFzIHdlbGwgYXMgdGhlICJp bnNlcnRlZC1ieSIvImluc2VydGVyIiBtZWNoYW5pc20uDQo+IA0KPiBJbiBhIHJlbGF0ZWQgY2xl YW4tdXAsIHNldmVyYWwgb2YgdGhlIGVycm9yIGNvZGVzIGNhbiBwcm9iYWJseSBiZQ0KPiBjb25z b2xpZGF0ZWQgb3IgcmVwbGFjZWQgd2l0aCBTSVAgcmVzcG9uc2UgY29kZXMgKGZvciBleGFtcGxl LCB0aGUNCj4gUmV0cnktQWZ0ZXIgc2VtYW50aWNzIG9mIHRoZSAyMDAvMzAwIGVycm9yIGNvZGVz KS4NCj4gDQo+IElmIG5vIG9uZSBvYmplY3RzLCB3ZSdkIHRoZXJlZm9yZSBsaWtlIHRvIHRyeSB0 byBjb21lIGJhY2sgd2l0aCBhIG5ldw0KPiB2ZXJzaW9uIHRoYXQgaGFzIGZld2VyIG1vdmluZyBw YXJ0cyBhbmQgZmV3ZXIgcGFnZXMuDQo+IA0KPiBUaG91Z2h0cz8NCj4gDQo+IEpvbiBQZXRlcnNv bg0KPiBOZXVTdGFyLCBJbmMuDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUN Cg== From jon.peterson@neustar.biz Thu Mar 25 17:08:56 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3126B3A6923 for ; Thu, 25 Mar 2010 17:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.769 X-Spam-Level: X-Spam-Status: No, score=-98.769 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, USER_IN_WHITELIST=-100] 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 X13ruzAo-sDC for ; Thu, 25 Mar 2010 17:08:55 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id C92D33A6933 for ; Thu, 25 Mar 2010 17:08:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1269562153; x=1584917812; q=dns/txt; h=Message-ID:Date:From:Subject:Content-Type: Content-Transfer-Encoding; bh=dw2cUIU/0aYJ3ogT1Z91Eq2isvuy3d9J2R BvyEKTIX8=; b=moNEXJGbDGc18ia/8vxnaSsVaSM3+XIgnv8VpJzYovJWcaxVwP /HXPDkw6tjoDyVeohqALfUZEWK7ghT4taRKg== Received: from ([192.168.128.18]) by stihiron1.va.neustar.com with ESMTP id G6K7MJ1.7600923; Thu, 25 Mar 2010 20:09:11 -0400 Message-ID: <4BABFB27.3090607@neustar.biz> Date: Thu, 25 Mar 2010 17:09:11 -0700 From: Jon Peterson User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <4BABD55B.9040507@neustar.biz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] rebooting location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 00:08:56 -0000 Semantically, a single SIP request can contain multiple locations within the constraints of the presence data model - PIDF-LO is after all PIDF, and like any presence document it can make fairly complicated statements about the relationship of location information to users or devices, including enumerating multiple locations. However, the intention of the revision is to return this to an old design constraint where a SIP request may contain only a single Geolocation header field with one URI pointing to location information. Jon Peterson NeuStar, Inc. DRAGE, Keith (Keith) wrote: > So, I believe the current solution allows a scenario where the originating UA inserts a location, and various proxies along the path could insert a location, in addition to the existing one, providing they all represent their view of the state of the user. > > By making this proposal, are you eliminating this scenario, or allowing it to continue to exist. > > regards > > Keith > > > > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Jon Peterson >> Sent: Thursday, March 25, 2010 9:28 PM >> To: sipcore@ietf.org >> Subject: [sipcore] rebooting location-conveyance >> >> James Polk and I sat down this week and took a hard look at >> the current sipcore-location-conveyance draft, and we believe >> that there's an opportunity to simplify (and shorten) the document. >> >> The simplification derives mostly from a single change to the >> operation of the mechanism. Today, the location-conveyance >> draft has a good deal of machinery to support the case where >> a proxy wants to replace existing location information in a >> request with more accurate or preferred location information. >> The current approach replaces the URI in the Geolocation >> header (which probably points to a MIME body) with a URI >> desired by the proxy, presumably of an Internet resource >> containing the desired PIDF-LO body. This solution isn't >> optimal for several reasons - most notably, since the MIME >> body is not removed by said proxy, it will still be delivered >> to the eventual location recipient, even if the URI in the >> Geolocation header does not point to said body. In order to >> handle this case, the current draft employs a disambiguation >> mechanism (relying on the "used-for-routing" and >> "inserted-by" parameters, as well as the "inserter") to >> inform the location recipient about the source of th is >> location information. Moreover, since this change is effected >> unilaterally, the originating user agent has no idea that the >> location it supplied has been altered in transit, and may >> thus receive a surprising response to its request. >> >> While this use case is an important one, we believe it can be >> addressed with a lighter mechanism. The basic idea is that a >> proxy server that wants to replace the location information >> provided by a user agent would reject a request with the 424 >> Bad Location response code, optionally enclosing in the body >> the location information that it would like the user agent to >> incorporate. The UA can insert the LI from the 424 in its >> subsequent reissuance of the request; if no LI is supplied in >> the 424, then the user agent resends the request without LI. >> This brings the location-conveyance mechanism back to one its >> original constraints: that only one PIDF-LO body is >> associated with a particular SIP request. This allows us to >> remove the "used-for-routing" parameter as well as the >> "inserted-by"/"inserter" mechanism. >> >> In a related clean-up, several of the error codes can >> probably be consolidated or replaced with SIP response codes >> (for example, the Retry-After semantics of the 200/300 error codes). >> >> If no one objects, we'd therefore like to try to come back >> with a new version that has fewer moving parts and fewer pages. >> >> Thoughts? >> >> Jon Peterson >> NeuStar, Inc. >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> From jon.peterson@neustar.biz Thu Mar 25 17:23:28 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 13F5E3A6ADD for ; Thu, 25 Mar 2010 17:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.517 X-Spam-Level: X-Spam-Status: No, score=-98.517 tagged_above=-999 required=5 tests=[AWL=-0.201, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] 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 eL4gUfbi7HUp for ; Thu, 25 Mar 2010 17:23:26 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id CE7053A6A58 for ; Thu, 25 Mar 2010 17:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1269563026; x=1584917812; q=dns/txt; h=Message-ID:Date:From:Subject:Content-Type: Content-Transfer-Encoding; bh=+UYzS/9oDcrI7MPUjivYY+AccA7e8AXTS2 LPlbSTHTc=; b=f3+vQtVAwvkC3EG1H9ognL3lsZPpqj+cnmpPjgcgxEgCe7yfp2 nwYLXMgiGKyh5LUQVWstcJE8qeZoShLGEzlA== Received: from ([192.168.128.18]) by stihiron1.va.neustar.com with ESMTP id G6K7MJ1.7601165; Thu, 25 Mar 2010 20:23:44 -0400 Message-ID: <4BABFE90.9040104@neustar.biz> Date: Thu, 25 Mar 2010 17:23:44 -0700 From: Jon Peterson User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Thomson, Martin" References: <4BABD55B.9040507@neustar.biz> <8B0A9FCBB9832F43971E38010638454F03E24ED33F@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E24ED33F@SISPE7MB1.commscope.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] rebooting location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 00:23:28 -0000 Broadly, any use case where you want to deliver two different locations to the same recipient is one that can be expressed semantically in PIDF-LO. I think that trying to implement this sort of semantics in the SIP layer has to be the wrong approach - it is far less brittle to extend PIDF than to add this to SIP. Ultimately, a by value PIDF-LO MIME body in a SIP request could, for example, contain a URI where someone could go to get location by reference in the future. That sounds like it could cover your use case at a high level, though of course we'd have to explore that in more detail. Jon Peterson NeuStar, Inc. Thomson, Martin wrote: > Hi Jon, > > I'd welcome any attempt to make this document simpler. Over time, it's built up a fair amount of baggage as it's made it's way through four (?) working groups. This sounds like a reasonable cut. > > The use case that is a victim of this is the one where a host has two locations: by value and by reference that they want to include. This might be the "now" and "for later" use case, or it could be the location hiding use case where the value is poor quality and the reference might be used to get the really good stuff. As long as we are able to address that use case, then I'm happy. > > I don't think that we need to re-build all that stuff that you are stripping out, but we currently don't have a good story for that. > > --Martin > > >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >> Behalf Of Jon Peterson >> Sent: Thursday, 25 March 2010 2:28 PM >> To: sipcore@ietf.org >> Subject: [sipcore] rebooting location-conveyance >> >> James Polk and I sat down this week and took a hard look at the current >> sipcore-location-conveyance draft, and we believe that there's an >> opportunity to simplify (and shorten) the document. >> >> The simplification derives mostly from a single change to the operation >> of the mechanism. Today, the location-conveyance draft has a good deal >> of machinery to support the case where a proxy wants to replace >> existing location information in a request with more accurate or >> preferred location information. The current approach replaces the URI >> in the Geolocation header (which probably points to a MIME body) with a >> URI desired by the proxy, presumably of an Internet resource containing >> the desired PIDF-LO body. This solution isn't optimal for several >> reasons - most notably, since the MIME body is not removed by said >> proxy, it will still be delivered to the eventual location recipient, >> even if the URI in the Geolocation header does not point to said body. >> In order to handle this case, the current draft employs a >> disambiguation mechanism (relying on the "used-for-routing" and >> "inserted-by" parameters, as well as the "inserter") to inform the >> location recipient about the source of th >> is location information. Moreover, since this change is effected >> unilaterally, the originating user agent has no idea that the location >> it supplied has been altered in transit, and may thus receive a >> surprising response to its request. >> >> While this use case is an important one, we believe it can be addressed >> with a lighter mechanism. The basic idea is that a proxy server that >> wants to replace the location information provided by a user agent >> would reject a request with the 424 Bad Location response code, >> optionally enclosing in the body the location information that it would >> like the user agent to incorporate. The UA can insert the LI from the >> 424 in its subsequent reissuance of the request; if no LI is supplied >> in the 424, then the user agent resends the request without LI. This >> brings the location-conveyance mechanism back to one its original >> constraints: that only one PIDF-LO body is associated with a particular >> SIP request. This allows us to remove the "used-for-routing" parameter >> as well as the "inserted-by"/"inserter" mechanism. >> >> In a related clean-up, several of the error codes can probably be >> consolidated or replaced with SIP response codes (for example, the >> Retry-After semantics of the 200/300 error codes). >> >> If no one objects, we'd therefore like to try to come back with a new >> version that has fewer moving parts and fewer pages. >> >> Thoughts? >> >> Jon Peterson >> NeuStar, Inc. >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> From keith.drage@alcatel-lucent.com Thu Mar 25 18:19:33 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B7B53A691F for ; Thu, 25 Mar 2010 18:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.456 X-Spam-Level: X-Spam-Status: No, score=-0.456 tagged_above=-999 required=5 tests=[AWL=-1.937, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35] 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 tV9K0tbDCNes for ; Thu, 25 Mar 2010 18:19:31 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 3EBEB3A6A58 for ; Thu, 25 Mar 2010 18:19:23 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o2Q1JYpW023751 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 26 Mar 2010 02:19:43 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Fri, 26 Mar 2010 02:19:42 +0100 From: "DRAGE, Keith (Keith)" To: Jon Peterson Date: Fri, 26 Mar 2010 02:19:33 +0100 Thread-Topic: [sipcore] rebooting location-conveyance Thread-Index: AcrMeJUCuAG8mawXQn2Uwfi/jNXVkAACbA7A Message-ID: References: <4BABD55B.9040507@neustar.biz> <4BABFB27.3090607@neustar.biz> In-Reply-To: <4BABFB27.3090607@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] rebooting location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 01:19:33 -0000 So on the basis that your answer appears to be NO to my question, I believe= I cannot support the change you are proposing. regards Keith=20 > -----Original Message----- > From: Jon Peterson [mailto:jon.peterson@neustar.biz]=20 > Sent: Friday, March 26, 2010 12:09 AM > To: DRAGE, Keith (Keith) > Cc: sipcore@ietf.org > Subject: Re: [sipcore] rebooting location-conveyance >=20 >=20 > Semantically, a single SIP request can contain multiple=20 > locations within the constraints of the presence data model -=20 > PIDF-LO is after all PIDF, and like any presence document it=20 > can make fairly complicated statements about the relationship=20 > of location information to users or devices, including=20 > enumerating multiple locations. However, the intention of the=20 > revision is to return this to an old design constraint where=20 > a SIP request may contain only a single Geolocation header=20 > field with one URI pointing to location information. >=20 > Jon Peterson > NeuStar, Inc. >=20 > DRAGE, Keith (Keith) wrote: > > So, I believe the current solution allows a scenario where=20 > the originating UA inserts a location, and various proxies=20 > along the path could insert a location, in addition to the=20 > existing one, providing they all represent their view of the=20 > state of the user. > > > > By making this proposal, are you eliminating this scenario,=20 > or allowing it to continue to exist. > > > > regards > > > > Keith > > > > =20 > > > > =20 > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Jon Peterson > >> Sent: Thursday, March 25, 2010 9:28 PM > >> To: sipcore@ietf.org > >> Subject: [sipcore] rebooting location-conveyance > >> > >> James Polk and I sat down this week and took a hard look at the=20 > >> current sipcore-location-conveyance draft, and we believe that=20 > >> there's an opportunity to simplify (and shorten) the document. > >> > >> The simplification derives mostly from a single change to the=20 > >> operation of the mechanism. Today, the location-conveyance=20 > draft has=20 > >> a good deal of machinery to support the case where a proxy=20 > wants to=20 > >> replace existing location information in a request with=20 > more accurate=20 > >> or preferred location information. > >> The current approach replaces the URI in the Geolocation header=20 > >> (which probably points to a MIME body) with a URI desired by the=20 > >> proxy, presumably of an Internet resource containing the desired=20 > >> PIDF-LO body. This solution isn't optimal for several=20 > reasons - most=20 > >> notably, since the MIME body is not removed by said proxy, it will=20 > >> still be delivered to the eventual location recipient, even if the=20 > >> URI in the Geolocation header does not point to said body.=20 > In order=20 > >> to handle this case, the current draft employs a disambiguation=20 > >> mechanism (relying on the "used-for-routing" and "inserted-by"=20 > >> parameters, as well as the "inserter") to inform the location=20 > >> recipient about the source of th is location information.=20 > Moreover,=20 > >> since this change is effected unilaterally, the originating user=20 > >> agent has no idea that the location it supplied has been=20 > altered in=20 > >> transit, and may thus receive a surprising response to its request. > >> > >> While this use case is an important one, we believe it can be=20 > >> addressed with a lighter mechanism. The basic idea is that a proxy=20 > >> server that wants to replace the location information=20 > provided by a=20 > >> user agent would reject a request with the 424 Bad=20 > Location response=20 > >> code, optionally enclosing in the body the location=20 > information that=20 > >> it would like the user agent to incorporate. The UA can=20 > insert the=20 > >> LI from the 424 in its subsequent reissuance of the=20 > request; if no LI=20 > >> is supplied in the 424, then the user agent resends the request=20 > >> without LI. > >> This brings the location-conveyance mechanism back to one its=20 > >> original constraints: that only one PIDF-LO body is=20 > associated with a=20 > >> particular SIP request. This allows us to remove the=20 > >> "used-for-routing" parameter as well as the=20 > "inserted-by"/"inserter"=20 > >> mechanism. > >> > >> In a related clean-up, several of the error codes can probably be=20 > >> consolidated or replaced with SIP response codes (for example, the=20 > >> Retry-After semantics of the 200/300 error codes). > >> > >> If no one objects, we'd therefore like to try to come back=20 > with a new=20 > >> version that has fewer moving parts and fewer pages. > >> > >> Thoughts? > >> > >> Jon Peterson > >> NeuStar, Inc. > >> > >> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> =20 >=20 > = From fmenard@xittelecom.com Thu Mar 25 19:09:19 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CF433A68D1 for ; Thu, 25 Mar 2010 19:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 K9xLKLqSCw3R for ; Thu, 25 Mar 2010 19:09:18 -0700 (PDT) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id C33F23A67F8 for ; Thu, 25 Mar 2010 19:09:13 -0700 (PDT) Received: from relay.infoteck.qc.ca ([205.151.16.15]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1NuyzJ-0000sb-1Z; Thu, 25 Mar 2010 22:09:29 -0400 Received: from cable-236-60.cgotr.infoteck.qc.ca ([207.96.236.60] helo=[192.168.3.252]) by relay.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1NuyzI-0007xT-In; Thu, 25 Mar 2010 22:09:28 -0400 Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: text/plain; charset=us-ascii From: "Francois D. Menard" In-Reply-To: <4BABFB27.3090607@neustar.biz> Date: Thu, 25 Mar 2010 22:09:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4BABD55B.9040507@neustar.biz> <4BABFB27.3090607@neustar.biz> To: Jon Peterson X-Mailer: Apple Mail (2.1077) X-Mailman-Approved-At: Fri, 26 Mar 2010 01:38:01 -0700 Cc: "DRAGE, Keith \(Keith\)" , "sipcore@ietf.org" Subject: Re: [sipcore] rebooting location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 02:09:19 -0000 I am concerned that this change may impact the ability for end-to-end = location conveyance to work. Am I wrong? F. On 2010-03-25, at 8:09 PM, Jon Peterson wrote: >=20 > Semantically, a single SIP request can contain multiple locations = within the constraints of the presence data model - PIDF-LO is after all = PIDF, and like any presence document it can make fairly complicated = statements about the relationship of location information to users or = devices, including enumerating multiple locations. However, the = intention of the revision is to return this to an old design constraint = where a SIP request may contain only a single Geolocation header field = with one URI pointing to location information. >=20 > Jon Peterson > NeuStar, Inc. >=20 > DRAGE, Keith (Keith) wrote: >> So, I believe the current solution allows a scenario where the = originating UA inserts a location, and various proxies along the path = could insert a location, in addition to the existing one, providing they = all represent their view of the state of the user. >>=20 >> By making this proposal, are you eliminating this scenario, or = allowing it to continue to exist. >>=20 >> regards >>=20 >> Keith >>=20 >>=20 >> =20 >>> -----Original Message----- >>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On = Behalf Of Jon Peterson >>> Sent: Thursday, March 25, 2010 9:28 PM >>> To: sipcore@ietf.org >>> Subject: [sipcore] rebooting location-conveyance >>>=20 >>> James Polk and I sat down this week and took a hard look at the = current sipcore-location-conveyance draft, and we believe that there's = an opportunity to simplify (and shorten) the document. >>>=20 >>> The simplification derives mostly from a single change to the = operation of the mechanism. Today, the location-conveyance draft has a = good deal of machinery to support the case where a proxy wants to = replace existing location information in a request with more accurate or = preferred location information. The current approach replaces the URI in = the Geolocation header (which probably points to a MIME body) with a URI = desired by the proxy, presumably of an Internet resource containing the = desired PIDF-LO body. This solution isn't optimal for several reasons - = most notably, since the MIME body is not removed by said proxy, it will = still be delivered to the eventual location recipient, even if the URI = in the Geolocation header does not point to said body. In order to = handle this case, the current draft employs a disambiguation mechanism = (relying on the "used-for-routing" and "inserted-by" parameters, as well = as the "inserter") to inform the location recipient about the source of = th is location information. Moreover, since this change is effected = unilaterally, the originating user agent has no idea that the location = it supplied has been altered in transit, and may thus receive a = surprising response to its request. >>>=20 >>> While this use case is an important one, we believe it can be = addressed with a lighter mechanism. The basic idea is that a proxy = server that wants to replace the location information provided by a user = agent would reject a request with the 424 Bad Location response code, = optionally enclosing in the body the location information that it would = like the user agent to incorporate. The UA can insert the LI from the = 424 in its subsequent reissuance of the request; if no LI is supplied in = the 424, then the user agent resends the request without LI. This brings = the location-conveyance mechanism back to one its original constraints: = that only one PIDF-LO body is associated with a particular SIP request. = This allows us to remove the "used-for-routing" parameter as well as the = "inserted-by"/"inserter" mechanism. >>>=20 >>> In a related clean-up, several of the error codes can probably be = consolidated or replaced with SIP response codes (for example, the = Retry-After semantics of the 200/300 error codes). >>>=20 >>> If no one objects, we'd therefore like to try to come back with a = new version that has fewer moving parts and fewer pages. >>>=20 >>> Thoughts? >>>=20 >>> Jon Peterson >>> NeuStar, Inc. >>>=20 >>>=20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> =20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From Martin.Thomson@andrew.com Fri Mar 26 02:54:07 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6257D3A69B5 for ; Fri, 26 Mar 2010 02:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.871 X-Spam-Level: X-Spam-Status: No, score=0.871 tagged_above=-999 required=5 tests=[AWL=-0.260, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 IjKnaa1OrHWu for ; Fri, 26 Mar 2010 02:54:01 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 6F65A3A698E for ; Fri, 26 Mar 2010 02:54:00 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:39381 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S15672974Ab0CZJyV (ORCPT ); Fri, 26 Mar 2010 04:54:21 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Fri, 26 Mar 2010 04:52:15 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 26 Mar 2010 17:52:13 +0800 From: "Thomson, Martin" To: "Francois D. Menard" , Jon Peterson Date: Fri, 26 Mar 2010 17:52:20 +0800 Thread-Topic: [sipcore] rebooting location-conveyance Thread-Index: AcrMv/7FEGVZvvGUSxy4hMfCeWb0nQACf5wA Message-ID: <8B0A9FCBB9832F43971E38010638454F03E24ED429@SISPE7MB1.commscope.com> References: <4BABD55B.9040507@neustar.biz> <4BABFB27.3090607@neustar.biz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "DRAGE, Keith \(Keith\)" , "sipcore@ietf.org" Subject: Re: [sipcore] rebooting location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 09:54:07 -0000 WWVzLiAgT3IgYXQgbGVhc3QgSSB0aGluayBzby4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzaXBjb3JlLWJv dW5jZXNAaWV0Zi5vcmddIE9uDQo+IEJlaGFsZiBPZiBGcmFuY29pcyBELiBNZW5hcmQNCj4gU2Vu dDogVGh1cnNkYXksIDI1IE1hcmNoIDIwMTAgNzowOSBQTQ0KPiBUbzogSm9uIFBldGVyc29uDQo+ IENjOiBEUkFHRSwgS2VpdGggKEtlaXRoKTsgc2lwY29yZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBS ZTogW3NpcGNvcmVdIHJlYm9vdGluZyBsb2NhdGlvbi1jb252ZXlhbmNlDQo+IA0KPiBJIGFtIGNv bmNlcm5lZCB0aGF0IHRoaXMgY2hhbmdlIG1heSBpbXBhY3QgdGhlIGFiaWxpdHkgZm9yIGVuZC10 by1lbmQNCj4gbG9jYXRpb24gY29udmV5YW5jZSB0byB3b3JrLg0KPiANCj4gQW0gSSB3cm9uZz8N Cj4gDQo+IEYuDQo+IA0KPiBPbiAyMDEwLTAzLTI1LCBhdCA4OjA5IFBNLCBKb24gUGV0ZXJzb24g d3JvdGU6DQo+IA0KPiA+DQo+ID4gU2VtYW50aWNhbGx5LCBhIHNpbmdsZSBTSVAgcmVxdWVzdCBj YW4gY29udGFpbiBtdWx0aXBsZSBsb2NhdGlvbnMNCj4gd2l0aGluIHRoZSBjb25zdHJhaW50cyBv ZiB0aGUgcHJlc2VuY2UgZGF0YSBtb2RlbCAtIFBJREYtTE8gaXMgYWZ0ZXINCj4gYWxsIFBJREYs IGFuZCBsaWtlIGFueSBwcmVzZW5jZSBkb2N1bWVudCBpdCBjYW4gbWFrZSBmYWlybHkgY29tcGxp Y2F0ZWQNCj4gc3RhdGVtZW50cyBhYm91dCB0aGUgcmVsYXRpb25zaGlwIG9mIGxvY2F0aW9uIGlu Zm9ybWF0aW9uIHRvIHVzZXJzIG9yDQo+IGRldmljZXMsIGluY2x1ZGluZyBlbnVtZXJhdGluZyBt dWx0aXBsZSBsb2NhdGlvbnMuIEhvd2V2ZXIsIHRoZQ0KPiBpbnRlbnRpb24gb2YgdGhlIHJldmlz aW9uIGlzIHRvIHJldHVybiB0aGlzIHRvIGFuIG9sZCBkZXNpZ24gY29uc3RyYWludA0KPiB3aGVy ZSBhIFNJUCByZXF1ZXN0IG1heSBjb250YWluIG9ubHkgYSBzaW5nbGUgR2VvbG9jYXRpb24gaGVh ZGVyIGZpZWxkDQo+IHdpdGggb25lIFVSSSBwb2ludGluZyB0byBsb2NhdGlvbiBpbmZvcm1hdGlv bi4NCj4gPg0KPiA+IEpvbiBQZXRlcnNvbg0KPiA+IE5ldVN0YXIsIEluYy4NCj4gPg0KPiA+IERS QUdFLCBLZWl0aCAoS2VpdGgpIHdyb3RlOg0KPiA+PiBTbywgSSBiZWxpZXZlIHRoZSBjdXJyZW50 IHNvbHV0aW9uIGFsbG93cyBhIHNjZW5hcmlvIHdoZXJlIHRoZQ0KPiBvcmlnaW5hdGluZyBVQSBp bnNlcnRzIGEgbG9jYXRpb24sIGFuZCB2YXJpb3VzIHByb3hpZXMgYWxvbmcgdGhlIHBhdGgNCj4g Y291bGQgaW5zZXJ0IGEgbG9jYXRpb24sIGluIGFkZGl0aW9uIHRvIHRoZSBleGlzdGluZyBvbmUs IHByb3ZpZGluZw0KPiB0aGV5IGFsbCByZXByZXNlbnQgdGhlaXIgdmlldyBvZiB0aGUgc3RhdGUg b2YgdGhlIHVzZXIuDQo+ID4+DQo+ID4+IEJ5IG1ha2luZyB0aGlzIHByb3Bvc2FsLCBhcmUgeW91 IGVsaW1pbmF0aW5nIHRoaXMgc2NlbmFyaW8sIG9yDQo+IGFsbG93aW5nIGl0IHRvIGNvbnRpbnVl IHRvIGV4aXN0Lg0KPiA+Pg0KPiA+PiByZWdhcmRzDQo+ID4+DQo+ID4+IEtlaXRoDQo+ID4+DQo+ ID4+DQo+ID4+DQo+ID4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+Pj4gRnJvbTog c2lwY29yZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3Jn XSBPbg0KPiBCZWhhbGYgT2YgSm9uIFBldGVyc29uDQo+ID4+PiBTZW50OiBUaHVyc2RheSwgTWFy Y2ggMjUsIDIwMTAgOToyOCBQTQ0KPiA+Pj4gVG86IHNpcGNvcmVAaWV0Zi5vcmcNCj4gPj4+IFN1 YmplY3Q6IFtzaXBjb3JlXSByZWJvb3RpbmcgbG9jYXRpb24tY29udmV5YW5jZQ0KPiA+Pj4NCj4g Pj4+IEphbWVzIFBvbGsgYW5kIEkgc2F0IGRvd24gdGhpcyB3ZWVrIGFuZCB0b29rIGEgaGFyZCBs b29rIGF0IHRoZQ0KPiBjdXJyZW50IHNpcGNvcmUtbG9jYXRpb24tY29udmV5YW5jZSBkcmFmdCwg YW5kIHdlIGJlbGlldmUgdGhhdCB0aGVyZSdzDQo+IGFuIG9wcG9ydHVuaXR5IHRvIHNpbXBsaWZ5 IChhbmQgc2hvcnRlbikgdGhlIGRvY3VtZW50Lg0KPiA+Pj4NCj4gPj4+IFRoZSBzaW1wbGlmaWNh dGlvbiBkZXJpdmVzIG1vc3RseSBmcm9tIGEgc2luZ2xlIGNoYW5nZSB0byB0aGUNCj4gb3BlcmF0 aW9uIG9mIHRoZSBtZWNoYW5pc20uIFRvZGF5LCB0aGUgbG9jYXRpb24tY29udmV5YW5jZSBkcmFm dCBoYXMgYQ0KPiBnb29kIGRlYWwgb2YgbWFjaGluZXJ5IHRvIHN1cHBvcnQgdGhlIGNhc2Ugd2hl cmUgYSBwcm94eSB3YW50cyB0bw0KPiByZXBsYWNlIGV4aXN0aW5nIGxvY2F0aW9uIGluZm9ybWF0 aW9uIGluIGEgcmVxdWVzdCB3aXRoIG1vcmUgYWNjdXJhdGUNCj4gb3IgcHJlZmVycmVkIGxvY2F0 aW9uIGluZm9ybWF0aW9uLiBUaGUgY3VycmVudCBhcHByb2FjaCByZXBsYWNlcyB0aGUNCj4gVVJJ IGluIHRoZSBHZW9sb2NhdGlvbiBoZWFkZXIgKHdoaWNoIHByb2JhYmx5IHBvaW50cyB0byBhIE1J TUUgYm9keSkNCj4gd2l0aCBhIFVSSSBkZXNpcmVkIGJ5IHRoZSBwcm94eSwgcHJlc3VtYWJseSBv ZiBhbiBJbnRlcm5ldCByZXNvdXJjZQ0KPiBjb250YWluaW5nIHRoZSBkZXNpcmVkIFBJREYtTE8g Ym9keS4gVGhpcyBzb2x1dGlvbiBpc24ndCBvcHRpbWFsIGZvcg0KPiBzZXZlcmFsIHJlYXNvbnMg LSBtb3N0IG5vdGFibHksIHNpbmNlIHRoZSBNSU1FIGJvZHkgaXMgbm90IHJlbW92ZWQgYnkNCj4g c2FpZCBwcm94eSwgaXQgd2lsbCBzdGlsbCBiZSBkZWxpdmVyZWQgdG8gdGhlIGV2ZW50dWFsIGxv Y2F0aW9uDQo+IHJlY2lwaWVudCwgZXZlbiBpZiB0aGUgVVJJIGluIHRoZSBHZW9sb2NhdGlvbiBo ZWFkZXIgZG9lcyBub3QgcG9pbnQgdG8NCj4gc2FpZCBib2R5LiBJbiBvcmRlciB0byBoYW5kbGUg dGhpcyBjYXNlLCB0aGUgY3VycmVudCBkcmFmdCBlbXBsb3lzIGENCj4gZGlzYW1iaWd1YXRpb24g bWVjaGFuaXNtIChyZWx5aW5nIG9uIHRoZSAidXNlZC1mb3Itcm91dGluZyIgYW5kDQo+ICJpbnNl cnRlZC1ieSIgcGFyYW1ldGVycywgYXMgd2VsbCBhcyB0aGUgImluc2VydGVyIikgdG8gaW5mb3Jt IHRoZQ0KPiBsb2NhdGlvbiByZWNpcGllbnQgYWJvdXQgdGhlIHNvdXJjZSBvDQo+ICBmIHRoICBp cyBsb2NhdGlvbiBpbmZvcm1hdGlvbi4gTW9yZW92ZXIsIHNpbmNlIHRoaXMgY2hhbmdlIGlzIGVm ZmVjdGVkDQo+IHVuaWxhdGVyYWxseSwgdGhlIG9yaWdpbmF0aW5nIHVzZXIgYWdlbnQgaGFzIG5v IGlkZWEgdGhhdCB0aGUgbG9jYXRpb24NCj4gaXQgc3VwcGxpZWQgaGFzIGJlZW4gYWx0ZXJlZCBp biB0cmFuc2l0LCBhbmQgbWF5IHRodXMgcmVjZWl2ZSBhDQo+IHN1cnByaXNpbmcgcmVzcG9uc2Ug dG8gaXRzIHJlcXVlc3QuDQo+ID4+Pg0KPiA+Pj4gV2hpbGUgdGhpcyB1c2UgY2FzZSBpcyBhbiBp bXBvcnRhbnQgb25lLCB3ZSBiZWxpZXZlIGl0IGNhbiBiZQ0KPiBhZGRyZXNzZWQgd2l0aCBhIGxp Z2h0ZXIgbWVjaGFuaXNtLiBUaGUgYmFzaWMgaWRlYSBpcyB0aGF0IGEgcHJveHkNCj4gc2VydmVy IHRoYXQgd2FudHMgdG8gcmVwbGFjZSB0aGUgbG9jYXRpb24gaW5mb3JtYXRpb24gcHJvdmlkZWQg YnkgYQ0KPiB1c2VyIGFnZW50IHdvdWxkIHJlamVjdCBhIHJlcXVlc3Qgd2l0aCB0aGUgNDI0IEJh ZCBMb2NhdGlvbiByZXNwb25zZQ0KPiBjb2RlLCBvcHRpb25hbGx5IGVuY2xvc2luZyBpbiB0aGUg Ym9keSB0aGUgbG9jYXRpb24gaW5mb3JtYXRpb24gdGhhdCBpdA0KPiB3b3VsZCBsaWtlIHRoZSB1 c2VyIGFnZW50IHRvIGluY29ycG9yYXRlLiAgVGhlIFVBIGNhbiBpbnNlcnQgdGhlIExJDQo+IGZy b20gdGhlIDQyNCBpbiBpdHMgc3Vic2VxdWVudCByZWlzc3VhbmNlIG9mIHRoZSByZXF1ZXN0OyBp ZiBubyBMSSBpcw0KPiBzdXBwbGllZCBpbiB0aGUgNDI0LCB0aGVuIHRoZSB1c2VyIGFnZW50IHJl c2VuZHMgdGhlIHJlcXVlc3Qgd2l0aG91dA0KPiBMSS4gVGhpcyBicmluZ3MgdGhlIGxvY2F0aW9u LWNvbnZleWFuY2UgbWVjaGFuaXNtIGJhY2sgdG8gb25lIGl0cw0KPiBvcmlnaW5hbCBjb25zdHJh aW50czogdGhhdCBvbmx5IG9uZSBQSURGLUxPIGJvZHkgaXMgYXNzb2NpYXRlZCB3aXRoIGENCj4g cGFydGljdWxhciBTSVAgcmVxdWVzdC4gVGhpcyBhbGxvd3MgdXMgdG8gcmVtb3ZlIHRoZSAidXNl ZC1mb3Itcm91dGluZyINCj4gcGFyYW1ldGVyIGFzIHdlbGwgYXMgdGhlICJpbnNlcnRlZC1ieSIv Imluc2VydGVyIiBtZWNoYW5pc20uDQo+ID4+Pg0KPiA+Pj4gSW4gYSByZWxhdGVkIGNsZWFuLXVw LCBzZXZlcmFsIG9mIHRoZSBlcnJvciBjb2RlcyBjYW4gcHJvYmFibHkgYmUNCj4gY29uc29saWRh dGVkIG9yIHJlcGxhY2VkIHdpdGggU0lQIHJlc3BvbnNlIGNvZGVzIChmb3IgZXhhbXBsZSwgdGhl DQo+IFJldHJ5LUFmdGVyIHNlbWFudGljcyBvZiB0aGUgMjAwLzMwMCBlcnJvciBjb2RlcykuDQo+ ID4+Pg0KPiA+Pj4gSWYgbm8gb25lIG9iamVjdHMsIHdlJ2QgdGhlcmVmb3JlIGxpa2UgdG8gdHJ5 IHRvIGNvbWUgYmFjayB3aXRoIGENCj4gbmV3IHZlcnNpb24gdGhhdCBoYXMgZmV3ZXIgbW92aW5n IHBhcnRzIGFuZCBmZXdlciBwYWdlcy4NCj4gPj4+DQo+ID4+PiBUaG91Z2h0cz8NCj4gPj4+DQo+ ID4+PiBKb24gUGV0ZXJzb24NCj4gPj4+IE5ldVN0YXIsIEluYy4NCj4gPj4+DQo+ID4+Pg0KPiA+ Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+ IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+ID4+PiBzaXBjb3JlQGlldGYub3JnDQo+ID4+PiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCj4gPj4+DQo+ID4NCj4g PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHNp cGNvcmUgbWFpbGluZyBsaXN0DQo+ID4gc2lwY29yZUBpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPiANCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2lwY29yZSBtYWlsaW5nIGxpc3QN Cj4gc2lwY29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NpcGNvcmUNCg== From john.elwell@siemens-enterprise.com Fri Mar 26 07:47:54 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 781AC3A695A for ; Fri, 26 Mar 2010 07:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.854 X-Spam-Level: X-Spam-Status: No, score=0.854 tagged_above=-999 required=5 tests=[AWL=-0.277, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 Z3xQqccOWSK5 for ; Fri, 26 Mar 2010 07:47:53 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 56BC83A680F for ; Fri, 26 Mar 2010 07:47:53 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-1359879; Fri, 26 Mar 2010 15:48:15 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 955AF23F028E; Fri, 26 Mar 2010 15:48:15 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 26 Mar 2010 15:48:15 +0100 From: "Elwell, John" To: Jon Peterson , "sipcore@ietf.org" Date: Fri, 26 Mar 2010 15:45:54 +0100 Thread-Topic: [sipcore] rebooting location-conveyance Thread-Index: AcrMYiOrmXAiOCoAS925yv298rCiyQAkLJcg Message-ID: References: <4BABD55B.9040507@neustar.biz> In-Reply-To: <4BABD55B.9040507@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] rebooting location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 14:47:54 -0000 What do the emergency call people think about having to retry, with a possi= ble impact on call establishment times? John=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Jon Peterson > Sent: 25 March 2010 14:28 > To: sipcore@ietf.org > Subject: [sipcore] rebooting location-conveyance >=20 > James Polk and I sat down this week and took a hard look at=20 > the current sipcore-location-conveyance draft, and we believe=20 > that there's an opportunity to simplify (and shorten) the document. >=20 > The simplification derives mostly from a single change to the=20 > operation of the mechanism. Today, the location-conveyance=20 > draft has a good deal of machinery to support the case where=20 > a proxy wants to replace existing location information in a=20 > request with more accurate or preferred location information.=20 > The current approach replaces the URI in the Geolocation=20 > header (which probably points to a MIME body) with a URI=20 > desired by the proxy, presumably of an Internet resource=20 > containing the desired PIDF-LO body. This solution isn't=20 > optimal for several reasons - most notably, since the MIME=20 > body is not removed by said proxy, it will still be delivered=20 > to the eventual location recipient, even if the URI in the=20 > Geolocation header does not point to said body. In order to=20 > handle this case, the current draft employs a disambiguation=20 > mechanism (relying on the "used-for-routing" and=20 > "inserted-by" parameters, as well as the "inserter") to=20 > inform the location recipient about the source of th > is location information. Moreover, since this change is=20 > effected unilaterally, the originating user agent has no idea=20 > that the location it supplied has been altered in transit,=20 > and may thus receive a surprising response to its request. >=20 > While this use case is an important one, we believe it can be=20 > addressed with a lighter mechanism. The basic idea is that a=20 > proxy server that wants to replace the location information=20 > provided by a user agent would reject a request with the 424=20 > Bad Location response code, optionally enclosing in the body=20 > the location information that it would like the user agent to=20 > incorporate. The UA can insert the LI from the 424 in its=20 > subsequent reissuance of the request; if no LI is supplied in=20 > the 424, then the user agent resends the request without LI.=20 > This brings the location-conveyance mechanism back to one its=20 > original constraints: that only one PIDF-LO body is=20 > associated with a particular SIP request. This allows us to=20 > remove the "used-for-routing" parameter as well as the=20 > "inserted-by"/"inserter" mechanism. >=20 > In a related clean-up, several of the error codes can=20 > probably be consolidated or replaced with SIP response codes=20 > (for example, the Retry-After semantics of the 200/300 error codes). >=20 > If no one objects, we'd therefore like to try to come back=20 > with a new version that has fewer moving parts and fewer pages. >=20 > Thoughts? >=20 > Jon Peterson > NeuStar, Inc. >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From jon.peterson@neustar.biz Fri Mar 26 07:50:49 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 053083A69A8 for ; Fri, 26 Mar 2010 07:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.753 X-Spam-Level: X-Spam-Status: No, score=-98.753 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 z7MLTM7io6y7 for ; Fri, 26 Mar 2010 07:50:45 -0700 (PDT) Received: from neustar.com (ns7.neustar.com [156.154.24.88]) by core3.amsl.com (Postfix) with ESMTP id 755833A691B for ; Fri, 26 Mar 2010 07:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1269615031; x=1584970723; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=UL9zGmvV4oSrgKw7ShT/7haTD2MI4/NpqDwZ+0jj7Ig=; b=HHFJrl+5D5Wcdzn1zLCYxWgN3kpfsterOoTSwQR0bAfiy/7yHlEVgTZVlgG3je uYMLNCyMhyYGFsu9cgM5tT/g== Received: from ([10.31.13.78]) by chihiron1.nc.neustar.com with ESMTP id 5202942.25913256; Fri, 26 Mar 2010 10:50:30 -0400 Received: from STNTEXCHHT01.cis.neustar.com ([10.31.13.228]) by STNTEXCH13.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Mar 2010 10:50:30 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Fri, 26 Mar 2010 10:50:28 -0400 From: "Peterson, Jon" To: "Francois D. Menard" Date: Fri, 26 Mar 2010 10:50:28 -0400 Thread-Topic: [sipcore] rebooting location-conveyance Thread-Index: AcrMiWPHm+8izBS3TSOie04ogmyY7AAakjrM Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 8TN7CZ23y8oat33BXrzmog== Content-Type: multipart/alternative; boundary="_000_C7D217C43BC30jonpetersonneustarbiz_" MIME-Version: 1.0 X-OriginalArrivalTime: 26 Mar 2010 14:50:30.0057 (UTC) FILETIME=[ADECB190:01CACCF3] Cc: "DRAGE, Keith \(Keith\)" , "sipcore@ietf.org" Subject: Re: [sipcore] rebooting location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 14:50:49 -0000 --_000_C7D217C43BC30jonpetersonneustarbiz_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I can't imagine it could - in fact, I think it makes end-to-end work better= - but if you can elaborate on your concern we could explore that further. Jon Peterson NeuStar, Inc. On 3/25/10 7:09 PM, "Francois D. Menard" wrote: I am concerned that this change may impact the ability for end-to-end locat= ion conveyance to work. Am I wrong? F. On 2010-03-25, at 8:09 PM, Jon Peterson wrote: > > Semantically, a single SIP request can contain multiple locations within = the constraints of the presence data model - PIDF-LO is after all PIDF, and= like any presence document it can make fairly complicated statements about= the relationship of location information to users or devices, including en= umerating multiple locations. However, the intention of the revision is to = return this to an old design constraint where a SIP request may contain onl= y a single Geolocation header field with one URI pointing to location infor= mation. > > Jon Peterson > NeuStar, Inc. > > DRAGE, Keith (Keith) wrote: >> So, I believe the current solution allows a scenario where the originati= ng UA inserts a location, and various proxies along the path could insert a= location, in addition to the existing one, providing they all represent th= eir view of the state of the user. >> >> By making this proposal, are you eliminating this scenario, or allowing = it to continue to exist. >> >> regards >> >> Keith >> >> >> >>> -----Original Message----- >>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Beh= alf Of Jon Peterson >>> Sent: Thursday, March 25, 2010 9:28 PM >>> To: sipcore@ietf.org >>> Subject: [sipcore] rebooting location-conveyance >>> >>> James Polk and I sat down this week and took a hard look at the current= sipcore-location-conveyance draft, and we believe that there's an opportun= ity to simplify (and shorten) the document. >>> >>> The simplification derives mostly from a single change to the operation= of the mechanism. Today, the location-conveyance draft has a good deal of = machinery to support the case where a proxy wants to replace existing locat= ion information in a request with more accurate or preferred location infor= mation. The current approach replaces the URI in the Geolocation header (wh= ich probably points to a MIME body) with a URI desired by the proxy, presum= ably of an Internet resource containing the desired PIDF-LO body. This solu= tion isn't optimal for several reasons - most notably, since the MIME body = is not removed by said proxy, it will still be delivered to the eventual lo= cation recipient, even if the URI in the Geolocation header does not point = to said body. In order to handle this case, the current draft employs a dis= ambiguation mechanism (relying on the "used-for-routing" and "inserted-by" = parameters, as well as the "inserter") to inform the location recipient abo= ut the source of th is location information. Moreover, since this change i= s effected unilaterally, the originating user agent has no idea that the lo= cation it supplied has been altered in transit, and may thus receive a surp= rising response to its request. >>> >>> While this use case is an important one, we believe it can be addressed= with a lighter mechanism. The basic idea is that a proxy server that wants= to replace the location information provided by a user agent would reject = a request with the 424 Bad Location response code, optionally enclosing in = the body the location information that it would like the user agent to inco= rporate. The UA can insert the LI from the 424 in its subsequent reissuanc= e of the request; if no LI is supplied in the 424, then the user agent rese= nds the request without LI. This brings the location-conveyance mechanism b= ack to one its original constraints: that only one PIDF-LO body is associat= ed with a particular SIP request. This allows us to remove the "used-for-ro= uting" parameter as well as the "inserted-by"/"inserter" mechanism. >>> >>> In a related clean-up, several of the error codes can probably be conso= lidated or replaced with SIP response codes (for example, the Retry-After s= emantics of the 200/300 error codes). >>> >>> If no one objects, we'd therefore like to try to come back with a new v= ersion that has fewer moving parts and fewer pages. >>> >>> Thoughts? >>> >>> Jon Peterson >>> NeuStar, Inc. >>> >>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --_000_C7D217C43BC30jonpetersonneustarbiz_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [sipcore] rebooting location-conveyance
I can’t imagine it could – in fact, I think it makes end-to-end= work better – but if you can elaborate on your concern we could expl= ore that further.

Jon Peterson
NeuStar, Inc.


On 3/25/10 7:09 PM, "Francois D. Menard" <fmenard@xittelecom.com> wrote:

I am concerned that this change may impact = the ability for end-to-end location conveyance to work.

Am I wrong?

F.

On 2010-03-25, at 8:09 PM, Jon Peterson wrote:

>
> Semantically, a single SIP request can contain multiple locations with= in the constraints of the presence data model - PIDF-LO is after all PIDF, = and like any presence document it can make fairly complicated statements ab= out the relationship of location information to users or devices, including= enumerating multiple locations. However, the intention of the revision is = to return this to an old design constraint where a SIP request may contain = only a single Geolocation header field with one URI pointing to location in= formation.
>
> Jon Peterson
> NeuStar, Inc.
>
> DRAGE, Keith (Keith) wrote:
>> So, I believe the current solution allows a scenario where the ori= ginating UA inserts a location, and various proxies along the path could in= sert a location, in addition to the existing one, providing they all repres= ent their view of the state of the user.
>>
>> By making this proposal, are you eliminating this scenario, or all= owing it to continue to exist.
>>
>> regards
>>
>> Keith
>>
>>
>>
>>> -----Original Message-----
>>> From: sipcore-bounces@iet= f.org [mailto:sipcore-bounc= es@ietf.org] On Behalf Of Jon Peterson
>>> Sent: Thursday, March 25, 2010 9:28 PM
>>> To: sipcore@ietf.org
>>> Subject: [sipcore] rebooting location-conveyance
>>>
>>> James Polk and I sat down this week and took a hard look at th= e current sipcore-location-conveyance draft, and we believe that there's an= opportunity to simplify (and shorten) the document.
>>>
>>> The simplification derives mostly from a single change to the = operation of the mechanism. Today, the location-conveyance draft has a good= deal of machinery to support the case where a proxy wants to replace exist= ing location information in a request with more accurate or preferred locat= ion information. The current approach replaces the URI in the Geolocation h= eader (which probably points to a MIME body) with a URI desired by the prox= y, presumably of an Internet resource containing the desired PIDF-LO body. = This solution isn't optimal for several reasons - most notably, since the M= IME body is not removed by said proxy, it will still be delivered to the ev= entual location recipient, even if the URI in the Geolocation header does n= ot point to said body. In order to handle this case, the current draft empl= oys a disambiguation mechanism (relying on the "used-for-routing"= and "inserted-by" parameters, as well as the "inserter"= ;) to inform the location recipient about the source of th  is locatio= n information. Moreover, since this change is effected unilaterally, the or= iginating user agent has no idea that the location it supplied has been alt= ered in transit, and may thus receive a surprising response to its request.=
>>>
>>> While this use case is an important one, we believe it can be = addressed with a lighter mechanism. The basic idea is that a proxy server t= hat wants to replace the location information provided by a user agent woul= d reject a request with the 424 Bad Location response code, optionally encl= osing in the body the location information that it would like the user agen= t to incorporate.  The UA can insert the LI from the 424 in its subseq= uent reissuance of the request; if no LI is supplied in the 424, then the u= ser agent resends the request without LI. This brings the location-conveyan= ce mechanism back to one its original constraints: that only one PIDF-LO bo= dy is associated with a particular SIP request. This allows us to remove th= e "used-for-routing" parameter as well as the "inserted-by&q= uot;/"inserter" mechanism.
>>>
>>> In a related clean-up, several of the error codes can probably= be consolidated or replaced with SIP response codes (for example, the Retr= y-After semantics of the 200/300 error codes).
>>>
>>> If no one objects, we'd therefore like to try to come back wit= h a new version that has fewer moving parts and fewer pages.
>>>
>>> Thoughts?
>>>
>>> Jon Peterson
>>> NeuStar, Inc.
>>>
>>>
>>> _______________________________________________
>>> sipcore mailing list
>>> sipcore@ietf.org
>>> http= s://www.ietf.org/mailman/listinfo/sipcore
>>>   
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.= ietf.org/mailman/listinfo/sipcore


--_000_C7D217C43BC30jonpetersonneustarbiz_-- From jon.peterson@neustar.biz Fri Mar 26 08:09:24 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9D1E93A67EC for ; Fri, 26 Mar 2010 08:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.496 X-Spam-Level: X-Spam-Status: No, score=-98.496 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_MISMATCH_COM=0.553, USER_IN_WHITELIST=-100] 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 HrjrDKiOIukF for ; Fri, 26 Mar 2010 08:09:23 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id 4569F3A695A for ; Fri, 26 Mar 2010 08:09:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1269616176; x=1584970707; q=dns/txt; h=Message-ID:Date:From:Subject:Content-Type: Content-Transfer-Encoding; bh=bFndGqPa7D5Q/8Whj02Ld4ccQB+Hz3qegk edUeC+PIc=; b=B25pjWh5KTsi4ROIlhaFz2NtXMTKyCUgGEq6jvuvGlJ0L2g4u3 rx88QHpEVMJULlNFby/pPhwpia395RZfCfAA== Received: from ([192.168.128.18]) by stihiron1.va.neustar.com with ESMTP id G6K7MJ1.7624770; Fri, 26 Mar 2010 11:09:35 -0400 Message-ID: <4BACCE2F.5020606@neustar.biz> Date: Fri, 26 Mar 2010 08:09:35 -0700 From: Jon Peterson User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 To: "Elwell, John" References: <4BABD55B.9040507@neustar.biz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] rebooting location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 15:09:24 -0000 In the emergency services case, I would not imagine intermediaries would confine themselves to the role of proxy servers - if they don't like the location attached to a message, I'm sure they'd just remove it, insert their own and forward the request. Why would we expect them to do otherwise? The way the location-conveyance mechanism works now - where, in that case, the intermediary removes the cid pointer to the MIME body it doesn't like, but leaves the MIME body in the request and provides a new URL to the preferred location information - seems like it is an even worse way of accomplishing the aims of an emergency services intermediary, and one that surely would be supplanted in deployments by some kind of special-purpose intermediary that doesn't conform to the standard. In the emergency services case, we need to do several things we wouldn't do otherwise, such as ignoring some classes of security violations because the consequences of not processing a call are so dire that we need to be generous in what we accept. The real question is if the steadily-growing set of parameters that have been defined in the draft to this point actually serve the practical requirements for emergency services or other use cases. Jon Peterson NeuStar, Inc. Elwell, John wrote: > What do the emergency call people think about having to retry, with a possible impact on call establishment times? > > John > > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Jon Peterson >> Sent: 25 March 2010 14:28 >> To: sipcore@ietf.org >> Subject: [sipcore] rebooting location-conveyance >> >> James Polk and I sat down this week and took a hard look at >> the current sipcore-location-conveyance draft, and we believe >> that there's an opportunity to simplify (and shorten) the document. >> >> The simplification derives mostly from a single change to the >> operation of the mechanism. Today, the location-conveyance >> draft has a good deal of machinery to support the case where >> a proxy wants to replace existing location information in a >> request with more accurate or preferred location information. >> The current approach replaces the URI in the Geolocation >> header (which probably points to a MIME body) with a URI >> desired by the proxy, presumably of an Internet resource >> containing the desired PIDF-LO body. This solution isn't >> optimal for several reasons - most notably, since the MIME >> body is not removed by said proxy, it will still be delivered >> to the eventual location recipient, even if the URI in the >> Geolocation header does not point to said body. In order to >> handle this case, the current draft employs a disambiguation >> mechanism (relying on the "used-for-routing" and >> "inserted-by" parameters, as well as the "inserter") to >> inform the location recipient about the source of th >> is location information. Moreover, since this change is >> effected unilaterally, the originating user agent has no idea >> that the location it supplied has been altered in transit, >> and may thus receive a surprising response to its request. >> >> While this use case is an important one, we believe it can be >> addressed with a lighter mechanism. The basic idea is that a >> proxy server that wants to replace the location information >> provided by a user agent would reject a request with the 424 >> Bad Location response code, optionally enclosing in the body >> the location information that it would like the user agent to >> incorporate. The UA can insert the LI from the 424 in its >> subsequent reissuance of the request; if no LI is supplied in >> the 424, then the user agent resends the request without LI. >> This brings the location-conveyance mechanism back to one its >> original constraints: that only one PIDF-LO body is >> associated with a particular SIP request. This allows us to >> remove the "used-for-routing" parameter as well as the >> "inserted-by"/"inserter" mechanism. >> >> In a related clean-up, several of the error codes can >> probably be consolidated or replaced with SIP response codes >> (for example, the Retry-After semantics of the 200/300 error codes). >> >> If no one objects, we'd therefore like to try to come back >> with a new version that has fewer moving parts and fewer pages. >> >> Thoughts? >> >> Jon Peterson >> NeuStar, Inc. >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> From ivo.sedlacek@ericsson.com Fri Mar 26 08:51:36 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F85A3A6B2D for ; Fri, 26 Mar 2010 08:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.054 X-Spam-Level: X-Spam-Status: No, score=-3.054 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, 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 ho9jCBARpvb0 for ; Fri, 26 Mar 2010 08:51:32 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id DFEF23A6A0B for ; Fri, 26 Mar 2010 08:51:29 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-e7-4bacd817ff3c Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id F2.4B.23532.718DCAB4; Fri, 26 Mar 2010 16:51:51 +0100 (CET) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.1.375.2; Fri, 26 Mar 2010 16:51:51 +0100 Received: from ESESSCMS0359.eemea.ericsson.se ([169.254.1.67]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Fri, 26 Mar 2010 16:51:51 +0100 From: Ivo Sedlacek To: "sipcore@ietf.org" Date: Fri, 26 Mar 2010 16:51:50 +0100 Thread-Topic: element in RFC 4235 Thread-Index: AcrM/D9oGFk/9CqrQzSU7gC3i9c8aQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C64F1A8E3F9E3C409DFC005F502C40D03E2967A0ESESSCMS0359eem_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] element in RFC 4235 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 15:51:36 -0000 --_000_C64F1A8E3F9E3C409DFC005F502C40D03E2967A0ESESSCMS0359eem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Let's suppose that Alice called Bob and Bob forwarded the call to Cecil whi= ch accepted the call. When Alice's UE sent the INVITE, the To header was set to Bob's SIP URI (si= p:bob@example.com). Cecil's network provided P-Asserted-Identity header set to Cecil's SIP URI = (sip:cecil@example.com) in 2xx response. Now Duren subscribes to dialog event package at Alice's UE. Alice's UE generates dialog event package notification including the create= d dialog. Is the element of the element of the created dialog sup= posed to contain: 1) the original To header field URI (sip:bob@example.com); 2) the true identity of the participant (sip:cecil@example.com); or 3) none of them? RFC4235 states: ---------------------------------------------------------------------------= -------------------------- 4.1.6.1. Identity Element The "identity" element indicates a local or remote URI, as defined in [2] as appropriate. It has an optional attribute, display, that contains the display name from the appropriate URI. Note that multiple identities (for example a sip: URI and a tel: URI) could be included if they all correspond to the participant. To avoid repeating identity information in each request, the subscriber can assume that the identity URIs are the same as in previous notifications if no identity elements are present in the corresponding local or remote element. If any identity elements are present in the local or remote part of a notification, the new list of identity tags completely supersedes the old list in the corresponding part. sip:anonymous@anonymous.invalid ---------------------------------------------------------------------------= -------------------------- remote URI as defined in [2] (RFC3261) is the original To header field URI = (sip:bob@example.com). However, the original To header field URI does not correspond to the true r= emote participant (sip:cecil@example.com). Does "as appropriate" have any particular meaning? Thanks for clarification. Kind regards Ivo Sedlacek Ericsson Technology and Portfolio Management, Terminal Standardization Sweden Office: +46 10 711 9382 Fax: +46 10 713 5929 ivo.sedlacek@ericsson.com www.ericsson.com [http://www.ericsson.com/shared/images/Email.gif] This communication is confidential. We only send and receive email on the b= asis of the term set out at www.ericsson.com/email_disclaimer --_000_C64F1A8E3F9E3C409DFC005F502C40D03E2967A0ESESSCMS0359eem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello,
 
Let's sup= pose that=20 = Alice=20 called Bob and Bob forwarded the call to Cecil which accepted the=20 call. 
Whe= n Alice's=20 UE sent the INVITE, the To header was set to Bob's SIP URI=20 (sip:bob@example.com).
Cecil's network provided=20 P-Asserted-Identity header set to Cecil's SIP URI (sip:cecil@example.com) i= n 2xx=20 response.
 
Now Duren= subscribes=20 to dialog event package at Alice's UE.
Alice's U= E generates=20 dialog event package notification including the created dialog.=20
 
Is the=20 <identity> element of the <remote> eleme= nt of the=20 created dialog supposed to contain:
1) t= he original=20 To header field URI (sip:bob@example.com);
2) the true identity of the participant=20 (sip:cecil@example.com); or
3) none of them?
 
RFC4235 states:
 
------------------------------------------------------------------= -----------------------------------
4.1.6.1.&= nbsp;=20 Identity Element
 
 &nb= sp; The=20 "identity" element indicates a local or remote URI, as defined=20 in
   [2] as appropriate.  It has an optional attribute,= =20 display, that
   contains the display name from the appropriat= e=20 URI.
 
      Note that multiple identities (for = example=20 a sip: URI and a tel:
      URI) could be inclu= ded=20 if they all correspond to the participant.
     = ; To=20 avoid repeating identity information in each request,=20 the
      subscriber can assume that the identi= ty=20 URIs are the same as in
      previous notifica= tions=20 if no identity elements are present in the
     = ;=20 corresponding local or remote element.  If any identity=20 elements
      are present in the local or remo= te=20 part of a notification, the new
      list of=20 identity tags completely supersedes the old list in=20 the
      corresponding part.
 
      <identity=20 display=3D"Anonymous">
       &nbs= p;  =20 sip:anonymous@anonymous.invalid</identity>
------------------------------------------------------------------= -----------------------------------
 
remote URI as defined in [2] (RFC3261) is the or= iginal=20 To header field URI (sip:bob@example.com).
However, the original To header field URI=20 does not correspond to the true r= emote=20 participant (sip:cecil@example.com).
Does "as appropriate" have any particular=20 meaning?
 
Thanks for clarification.
 
Kind regards =
 

Ivo Sedlacek= =20


Ericsson
T= echnology=20 and Portfolio Management, Terminal Standardization
Sweden
Office: +4= 6 10=20 711 9382
Fax: +46 10 713=20 5929
ivo.sedlacek@ericsson.com
www.ericsson.com


3D"Ericsson



This=20 communication is confidential. We only send and receive email on the basis = of=20 the term set out at www.ericsson.com/email_di= sclaimer=20

 
--_000_C64F1A8E3F9E3C409DFC005F502C40D03E2967A0ESESSCMS0359eem_-- From keith.drage@alcatel-lucent.com Fri Mar 26 08:58:41 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8E2E3A6B43 for ; Fri, 26 Mar 2010 08:58:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.327 X-Spam-Level: X-Spam-Status: No, score=-0.327 tagged_above=-999 required=5 tests=[AWL=-1.808, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35] 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 lfilhKAYxlJo for ; Fri, 26 Mar 2010 08:58:37 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id DA3F13A6B42 for ; Fri, 26 Mar 2010 08:58:36 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o2QFrEPD002644 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 26 Mar 2010 16:58:57 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 26 Mar 2010 16:58:12 +0100 From: "DRAGE, Keith (Keith)" To: Jon Peterson , "Elwell, John" Date: Fri, 26 Mar 2010 16:54:48 +0100 Thread-Topic: [sipcore] rebooting location-conveyance Thread-Index: AcrM9nFWgVep6VJoQeecjE/IePOgIQABcNQA Message-ID: References: <4BABD55B.9040507@neustar.biz> <4BACCE2F.5020606@neustar.biz> In-Reply-To: <4BACCE2F.5020606@neustar.biz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] rebooting location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 15:58:41 -0000 1) At least on the emergency calls I've been looking at, we've been doing o= ur best to make sure intermediaries are proxies. Insertions could well be l= ocation by reference, rather than location by value as a result. B2BUAs bre= ak transparency - remember? 2) From day 1) on emergency calls, the ethos has been - Do not make judgeme= nts on the value of information to the PSAP. Therefore in the work I've bee= n involved in, we never remove information from an emergency call. Everythi= ng is passed to the PSAP in some form. This makes it impossible to fulfil t= hat. regards Keith=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Jon Peterson > Sent: Friday, March 26, 2010 3:10 PM > To: Elwell, John > Cc: sipcore@ietf.org > Subject: Re: [sipcore] rebooting location-conveyance >=20 >=20 > In the emergency services case, I would not imagine=20 > intermediaries would confine themselves to the role of proxy=20 > servers - if they don't like the location attached to a=20 > message, I'm sure they'd just remove it, insert their own and=20 > forward the request. Why would we expect them to do otherwise? >=20 > The way the location-conveyance mechanism works now - where,=20 > in that case, the intermediary removes the cid pointer to the=20 > MIME body it doesn't like, but leaves the MIME body in the=20 > request and provides a new URL to the preferred location=20 > information - seems like it is an even worse way of=20 > accomplishing the aims of an emergency services intermediary,=20 > and one that surely would be supplanted in deployments by=20 > some kind of special-purpose intermediary that doesn't=20 > conform to the standard. >=20 > In the emergency services case, we need to do several things=20 > we wouldn't do otherwise, such as ignoring some classes of=20 > security violations because the consequences of not=20 > processing a call are so dire that we need to be generous in=20 > what we accept. The real question is if the steadily-growing=20 > set of parameters that have been defined in the draft to this=20 > point actually serve the practical requirements for emergency=20 > services or other use cases. >=20 > Jon Peterson > NeuStar, Inc. >=20 > Elwell, John wrote: > > What do the emergency call people think about having to=20 > retry, with a possible impact on call establishment times? > > > > John > > > > =20 > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Jon Peterson > >> Sent: 25 March 2010 14:28 > >> To: sipcore@ietf.org > >> Subject: [sipcore] rebooting location-conveyance > >> > >> James Polk and I sat down this week and took a hard look at the=20 > >> current sipcore-location-conveyance draft, and we believe that=20 > >> there's an opportunity to simplify (and shorten) the document. > >> > >> The simplification derives mostly from a single change to the=20 > >> operation of the mechanism. Today, the location-conveyance=20 > draft has=20 > >> a good deal of machinery to support the case where a proxy=20 > wants to=20 > >> replace existing location information in a request with=20 > more accurate=20 > >> or preferred location information. > >> The current approach replaces the URI in the Geolocation header=20 > >> (which probably points to a MIME body) with a URI desired by the=20 > >> proxy, presumably of an Internet resource containing the desired=20 > >> PIDF-LO body. This solution isn't optimal for several=20 > reasons - most=20 > >> notably, since the MIME body is not removed by said proxy, it will=20 > >> still be delivered to the eventual location recipient, even if the=20 > >> URI in the Geolocation header does not point to said body.=20 > In order=20 > >> to handle this case, the current draft employs a disambiguation=20 > >> mechanism (relying on the "used-for-routing" and "inserted-by"=20 > >> parameters, as well as the "inserter") to inform the location=20 > >> recipient about the source of th is location information.=20 > Moreover,=20 > >> since this change is effected unilaterally, the originating user=20 > >> agent has no idea that the location it supplied has been=20 > altered in=20 > >> transit, and may thus receive a surprising response to its request. > >> > >> While this use case is an important one, we believe it can be=20 > >> addressed with a lighter mechanism. The basic idea is that a proxy=20 > >> server that wants to replace the location information=20 > provided by a=20 > >> user agent would reject a request with the 424 Bad=20 > Location response=20 > >> code, optionally enclosing in the body the location=20 > information that=20 > >> it would like the user agent to incorporate. The UA can=20 > insert the=20 > >> LI from the 424 in its subsequent reissuance of the=20 > request; if no LI=20 > >> is supplied in the 424, then the user agent resends the request=20 > >> without LI. > >> This brings the location-conveyance mechanism back to one its=20 > >> original constraints: that only one PIDF-LO body is=20 > associated with a=20 > >> particular SIP request. This allows us to remove the=20 > >> "used-for-routing" parameter as well as the=20 > "inserted-by"/"inserter"=20 > >> mechanism. > >> > >> In a related clean-up, several of the error codes can probably be=20 > >> consolidated or replaced with SIP response codes (for example, the=20 > >> Retry-After semantics of the 200/300 error codes). > >> > >> If no one objects, we'd therefore like to try to come back=20 > with a new=20 > >> version that has fewer moving parts and fewer pages. > >> > >> Thoughts? > >> > >> Jon Peterson > >> NeuStar, Inc. > >> > >> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> =20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From pkyzivat@cisco.com Fri Mar 26 09:36:42 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 913803A6BB0 for ; Fri, 26 Mar 2010 09:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.128 X-Spam-Level: X-Spam-Status: No, score=-8.128 tagged_above=-999 required=5 tests=[AWL=1.341, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] 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 EloG1aQuiSnT for ; Fri, 26 Mar 2010 09:36:41 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 9249E3A6C3C for ; Fri, 26 Mar 2010 09:31:49 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANZ+rEurR7Hu/2dsb2JhbACbJnOnHpkYglCCLgQ X-IronPort-AV: E=Sophos;i="4.51,315,1267401600"; d="scan'208";a="503542672" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 26 Mar 2010 16:32:13 +0000 Received: from [10.21.92.209] (sjc-vpn5-1233.cisco.com [10.21.92.209]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o2QGWD4p023373; Fri, 26 Mar 2010 16:32:13 GMT Message-ID: <4BACE18D.2090809@cisco.com> Date: Fri, 26 Mar 2010 12:32:13 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Ivo Sedlacek References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] element in RFC 4235 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 16:36:42 -0000 [as individual] comment at end... Ivo Sedlacek wrote: > Hello, > > Let's suppose that Alice called Bob and Bob forwarded the call to Cecil > which accepted the call. > When Alice's UE sent the INVITE, the To header was set to Bob's SIP URI > (sip:bob@example.com). > Cecil's network provided P-Asserted-Identity header set to Cecil's SIP > URI (sip:cecil@example.com) in 2xx response. > > Now Duren subscribes to dialog event package at Alice's UE. > Alice's UE generates dialog event package notification including the > created dialog. > > Is the element of the element of the created dialog > supposed to contain: > 1) the original To header field URI (sip:bob@example.com); > 2) the true identity of the participant (sip:cecil@example.com); or > 3) none of them? > > RFC4235 states: > > ----------------------------------------------------------------------------------------------------- > 4.1.6.1. Identity Element > > The "identity" element indicates a local or remote URI, as defined in > [2] as appropriate. It has an optional attribute, display, that > contains the display name from the appropriate URI. > > Note that multiple identities (for example a sip: URI and a tel: > URI) could be included if they all correspond to the participant. > To avoid repeating identity information in each request, the > subscriber can assume that the identity URIs are the same as in > previous notifications if no identity elements are present in the > corresponding local or remote element. If any identity elements > are present in the local or remote part of a notification, the new > list of identity tags completely supersedes the old list in the > corresponding part. > > > sip:anonymous@anonymous.invalid > ----------------------------------------------------------------------------------------------------- > > remote URI as defined in [2] (RFC3261) is the original To header field > URI (sip:bob@example.com). > However, the original To header field URI does not correspond to the > true remote participant (sip:cecil@example.com). > Does "as appropriate" have any particular meaning? You mention Cecil's PAI being returned in the 2xx. The semantics of that are not defined in ietf. (I believe this usage *is* defined in IMS.) RFC 4916 (connected identity) defines a mechanism to deliver that back to the caller in a request. If 4916 is used, the actual remote identity that is part of dialog state according to 3261 will be changed, and presumably will then be reported in the notify. The impact of PAI on returns from the dialog event package is, AFAIK, undefined. (Does IMS define it?) Thanks, Paul From adam@nostrum.com Fri Mar 26 09:40:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F308F3A6B32 for ; Fri, 26 Mar 2010 09:40:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.913 X-Spam-Level: X-Spam-Status: No, score=0.913 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, SPF_PASS=-0.001] 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 3k7vHCxFTDay for ; Fri, 26 Mar 2010 09:40:50 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id DF6233A6BE0 for ; Fri, 26 Mar 2010 09:37:43 -0700 (PDT) Received: from dhcp-wireless-open-abg-24-56.meeting.ietf.org (dhcp-wireless-open-abg-24-56.meeting.ietf.org [130.129.24.56]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o2QGc2rw075421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Mar 2010 11:38:03 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BACE2EA.7020605@nostrum.com> Date: Fri, 26 Mar 2010 09:38:02 -0700 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <4BABD55B.9040507@neustar.biz> <4BABFB27.3090607@neustar.biz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.24.56 is authenticated by a trusted mechanism) Cc: "sipcore@ietf.org" Subject: Re: [sipcore] rebooting location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 16:40:52 -0000 [as participant] Actually, I read his response as a qualified "yes." If we go to base requirements and ask whether proxies on the path can take action to cause their own view of the user's location to be added to the request, then the requirement -- by my understanding -- is satisfied by the proposed mechanism. /a On 3/25/10 6:19 PM, DRAGE, Keith (Keith) wrote: > So on the basis that your answer appears to be NO to my question, I believe I cannot support the change you are proposing. > > regards > > Keith > > >> -----Original Message----- >> From: Jon Peterson [mailto:jon.peterson@neustar.biz] >> Sent: Friday, March 26, 2010 12:09 AM >> To: DRAGE, Keith (Keith) >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] rebooting location-conveyance >> >> >> Semantically, a single SIP request can contain multiple >> locations within the constraints of the presence data model - >> PIDF-LO is after all PIDF, and like any presence document it >> can make fairly complicated statements about the relationship >> of location information to users or devices, including >> enumerating multiple locations. However, the intention of the >> revision is to return this to an old design constraint where >> a SIP request may contain only a single Geolocation header >> field with one URI pointing to location information. >> >> Jon Peterson >> NeuStar, Inc. >> >> DRAGE, Keith (Keith) wrote: >> >>> So, I believe the current solution allows a scenario where >>> >> the originating UA inserts a location, and various proxies >> along the path could insert a location, in addition to the >> existing one, providing they all represent their view of the >> state of the user. >> >>> By making this proposal, are you eliminating this scenario, >>> >> or allowing it to continue to exist. >> >>> regards >>> >>> Keith >>> >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org >>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Jon Peterson >>>> Sent: Thursday, March 25, 2010 9:28 PM >>>> To: sipcore@ietf.org >>>> Subject: [sipcore] rebooting location-conveyance >>>> >>>> James Polk and I sat down this week and took a hard look at the >>>> current sipcore-location-conveyance draft, and we believe that >>>> there's an opportunity to simplify (and shorten) the document. >>>> >>>> The simplification derives mostly from a single change to the >>>> operation of the mechanism. Today, the location-conveyance >>>> >> draft has >> >>>> a good deal of machinery to support the case where a proxy >>>> >> wants to >> >>>> replace existing location information in a request with >>>> >> more accurate >> >>>> or preferred location information. >>>> The current approach replaces the URI in the Geolocation header >>>> (which probably points to a MIME body) with a URI desired by the >>>> proxy, presumably of an Internet resource containing the desired >>>> PIDF-LO body. This solution isn't optimal for several >>>> >> reasons - most >> >>>> notably, since the MIME body is not removed by said proxy, it will >>>> still be delivered to the eventual location recipient, even if the >>>> URI in the Geolocation header does not point to said body. >>>> >> In order >> >>>> to handle this case, the current draft employs a disambiguation >>>> mechanism (relying on the "used-for-routing" and "inserted-by" >>>> parameters, as well as the "inserter") to inform the location >>>> recipient about the source of th is location information. >>>> >> Moreover, >> >>>> since this change is effected unilaterally, the originating user >>>> agent has no idea that the location it supplied has been >>>> >> altered in >> >>>> transit, and may thus receive a surprising response to its request. >>>> >>>> While this use case is an important one, we believe it can be >>>> addressed with a lighter mechanism. The basic idea is that a proxy >>>> server that wants to replace the location information >>>> >> provided by a >> >>>> user agent would reject a request with the 424 Bad >>>> >> Location response >> >>>> code, optionally enclosing in the body the location >>>> >> information that >> >>>> it would like the user agent to incorporate. The UA can >>>> >> insert the >> >>>> LI from the 424 in its subsequent reissuance of the >>>> >> request; if no LI >> >>>> is supplied in the 424, then the user agent resends the request >>>> without LI. >>>> This brings the location-conveyance mechanism back to one its >>>> original constraints: that only one PIDF-LO body is >>>> >> associated with a >> >>>> particular SIP request. This allows us to remove the >>>> "used-for-routing" parameter as well as the >>>> >> "inserted-by"/"inserter" >> >>>> mechanism. >>>> >>>> In a related clean-up, several of the error codes can probably be >>>> consolidated or replaced with SIP response codes (for example, the >>>> Retry-After semantics of the 200/300 error codes). >>>> >>>> If no one objects, we'd therefore like to try to come back >>>> >> with a new >> >>>> version that has fewer moving parts and fewer pages. >>>> >>>> Thoughts? >>>> >>>> Jon Peterson >>>> NeuStar, Inc. >>>> >>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>>> >> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From jon.peterson@neustar.biz Fri Mar 26 10:07:40 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 316D03A67AC for ; Fri, 26 Mar 2010 10:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.746 X-Spam-Level: X-Spam-Status: No, score=-98.746 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 hpPAuY9UDboB for ; Fri, 26 Mar 2010 10:07:32 -0700 (PDT) Received: from neustar.com (ns7.neustar.com [156.154.24.88]) by core3.amsl.com (Postfix) with ESMTP id D9CB33A6B5A for ; Fri, 26 Mar 2010 10:07:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1269623226; x=1584970724; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=mUM2SWmvhCgBXpz+ugXGKJdIY9WqxcfdeoG1clLAhnI=; b=IvsCWvkzPfX6S3k9+8WluhfdYVwRuaepFKUcQhQCOx/UUcwpkSDYl5SqTv2pS9 /Grj9ABYdZmE5KR5K2bjnvQg== Received: from ([10.31.13.31]) by chihiron2.nc.neustar.com with ESMTP id 5202415.23917072; Fri, 26 Mar 2010 13:07:05 -0400 Received: from STNTEXCHHT01.cis.neustar.com ([10.31.13.228]) by stntexch12.cis.neustar.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 26 Mar 2010 13:07:05 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Fri, 26 Mar 2010 13:07:04 -0400 From: "Peterson, Jon" To: "DRAGE, Keith (Keith)" , "Elwell, John" Date: Fri, 26 Mar 2010 13:07:02 -0400 Thread-Topic: [sipcore] rebooting location-conveyance Thread-Index: AcrM9nFWgVep6VJoQeecjE/IePOgIQABcNQAAAKjA7s= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 9cwX3YORQs/n/aVbUo2S0Q== Content-Type: multipart/alternative; boundary="_000_C7D237C63BC7Fjonpetersonneustarbiz_" MIME-Version: 1.0 X-OriginalArrivalTime: 26 Mar 2010 17:07:05.0652 (UTC) FILETIME=[C2E13F40:01CACD06] Cc: "sipcore@ietf.org" Subject: Re: [sipcore] rebooting location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 17:07:40 -0000 --_000_C7D237C63BC7Fjonpetersonneustarbiz_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Taxonomy aside, the core architectural question is how much support is need= ed for carrying multiple locations in a single SIP request, and whether th= at support should be staged at the SIP layer or the body (PIDF) layer. Para= meters like "inserted-by" cause immediate suspicion precisely because they = straddle that boundary - it is the job of PIDF to explain who generated thi= s location information and what data model element is coupled to the locati= on information. Merely pointing from the SIP layer to different PIDF bodies= describing different locations does not clarify the relationship of these = elements to one another in data model terms. While one can argue that you couldn't sort that out in a timeframe expedien= t enough for the emergency services case, I continue to maintain that we sh= ould expect exceptional behavior from intermediaries tailored to help emerg= ency services calls along their path. The job of the network in this case i= s to deliver quickly the best information it can to the right service - the= argument that you "never remove information from an emergency call" does n= ot entail "encourage the accumulation of a bewildering variety of different= locations without describing their relationship to one another." At the en= d of the day, of course, the result of placing an emergency services call w= ill probably be the delivery of location information to someone who is stil= l required to ask the caller personally for their location, and this only f= urther illustrates why we treat this as a special case. For the common case= , we want an architecturally clean way to associate a SIP request with loca= tion information. Jon Peterson NeuStar, Inc. On 3/26/10 8:54 AM, "DRAGE, Keith (Keith)" = wrote: 1) At least on the emergency calls I've been looking at, we've been do= ing our best to make sure intermediaries are proxies. Insertions could well= be location by reference, rather than location by value as a result. B2BUA= s break transparency - remember? 2) From day 1) on emergency calls, the ethos has been - Do not make ju= dgements on the value of information to the PSAP. Therefore in the work I'v= e been involved in, we never remove information from an emergency call. Eve= rything is passed to the PSAP in some form. This makes it impossible to ful= fil that. regards Keith > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Jon Peterson > Sent: Friday, March 26, 2010 3:10 PM > To: Elwell, John > Cc: sipcore@ietf.org > Subject: Re: [sipcore] rebooting location-conveyance > > > In the emergency services case, I would not imagine > intermediaries would confine themselves to the role of proxy > servers - if they don't like the location attached to a > message, I'm sure they'd just remove it, insert their own and > forward the request. Why would we expect them to do otherwise? > > The way the location-conveyance mechanism works now - where, > in that case, the intermediary removes the cid pointer to the > MIME body it doesn't like, but leaves the MIME body in the > request and provides a new URL to the preferred location > information - seems like it is an even worse way of > accomplishing the aims of an emergency services intermediary, > and one that surely would be supplanted in deployments by > some kind of special-purpose intermediary that doesn't > conform to the standard. > > In the emergency services case, we need to do several things > we wouldn't do otherwise, such as ignoring some classes of > security violations because the consequences of not > processing a call are so dire that we need to be generous in > what we accept. The real question is if the steadily-growing > set of parameters that have been defined in the draft to this > point actually serve the practical requirements for emergency > services or other use cases. > > Jon Peterson > NeuStar, Inc. > > Elwell, John wrote: > > What do the emergency call people think about having to > retry, with a possible impact on call establishment times? > > > > John > > > > > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Jon Peterson > >> Sent: 25 March 2010 14:28 > >> To: sipcore@ietf.org > >> Subject: [sipcore] rebooting location-conveyance > >> > >> James Polk and I sat down this week and took a hard look at the > >> current sipcore-location-conveyance draft, and we believe that > >> there's an opportunity to simplify (and shorten) the document. > >> > >> The simplification derives mostly from a single change to the > >> operation of the mechanism. Today, the location-conveyance > draft has > >> a good deal of machinery to support the case where a proxy > wants to > >> replace existing location information in a request with > more accurate > >> or preferred location information. > >> The current approach replaces the URI in the Geolocation header > >> (which probably points to a MIME body) with a URI desired by the > >> proxy, presumably of an Internet resource containing the desired > >> PIDF-LO body. This solution isn't optimal for several > reasons - most > >> notably, since the MIME body is not removed by said proxy, it will > >> still be delivered to the eventual location recipient, even if the > >> URI in the Geolocation header does not point to said body. > In order > >> to handle this case, the current draft employs a disambiguation > >> mechanism (relying on the "used-for-routing" and "inserted-by" > >> parameters, as well as the "inserter") to inform the location > >> recipient about the source of th is location information. > Moreover, > >> since this change is effected unilaterally, the originating user > >> agent has no idea that the location it supplied has been > altered in > >> transit, and may thus receive a surprising response to its request. > >> > >> While this use case is an important one, we believe it can be > >> addressed with a lighter mechanism. The basic idea is that a proxy > >> server that wants to replace the location information > provided by a > >> user agent would reject a request with the 424 Bad > Location response > >> code, optionally enclosing in the body the location > information that > >> it would like the user agent to incorporate. The UA can > insert the > >> LI from the 424 in its subsequent reissuance of the > request; if no LI > >> is supplied in the 424, then the user agent resends the request > >> without LI. > >> This brings the location-conveyance mechanism back to one its > >> original constraints: that only one PIDF-LO body is > associated with a > >> particular SIP request. This allows us to remove the > >> "used-for-routing" parameter as well as the > "inserted-by"/"inserter" > >> mechanism. > >> > >> In a related clean-up, several of the error codes can probably be > >> consolidated or replaced with SIP response codes (for example, the > >> Retry-After semantics of the 200/300 error codes). > >> > >> If no one objects, we'd therefore like to try to come back > with a new > >> version that has fewer moving parts and fewer pages. > >> > >> Thoughts? > >> > >> Jon Peterson > >> NeuStar, Inc. > >> > >> > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --_000_C7D237C63BC7Fjonpetersonneustarbiz_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [sipcore] rebooting location-conveyance
Taxonomy aside, the core architectural question is how much support is need= ed for carrying multiple locations in a single  SIP request, and wheth= er that support should be staged at the SIP layer or the body (PIDF) layer.= Parameters like “inserted-by” cause immediate suspicion precis= ely because they straddle that boundary – it is the job of PIDF to ex= plain who generated this location information and what data model element i= s coupled to the location information. Merely pointing from the SIP layer t= o different PIDF bodies describing different locations does not clarify the= relationship of these elements to one another in data model terms.

While one can argue that you couldn’t sort that out in a timeframe ex= pedient enough for the emergency services case, I continue to maintain that= we should expect exceptional behavior from intermediaries tailored to help= emergency services calls along their path. The job of the network in this = case is to deliver quickly the best information it can to the right service= - the argument that you “never remove information from an emergency = call” does not entail “encourage the accumulation of a bewilder= ing variety of different locations without describing their relationship to= one another.” At the end of the day, of course, the result of placin= g an emergency services call will probably be the delivery of location info= rmation to someone who is still required to ask the caller personally for t= heir location, and this only further illustrates why we treat this as a spe= cial case. For the common case, we want an architecturally clean way to ass= ociate a SIP request with location information.

Jon Peterson
NeuStar, Inc.

On 3/26/10 8:54 AM, "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> wrote:

1)      At least o= n the emergency calls I've been looking at, we've been doing our best to ma= ke sure intermediaries are proxies. Insertions could well be location by re= ference, rather than location by value as a result. B2BUAs break transparen= cy - remember?

2)      From day 1) on emergency calls, the ethos = has been - Do not make judgements on the value of information to the PSAP. = Therefore in the work I've been involved in, we never remove information fr= om an emergency call. Everything is passed to the PSAP in some form. This m= akes it impossible to fulfil that.

regards

Keith

> -----Original Message-----
> From: sipcore-bounces@ietf.org
> [mailto:sipcore-bounces@ie= tf.org] On Behalf Of Jon Peterson
> Sent: Friday, March 26, 2010 3:10 PM
> To: Elwell, John
> Cc: sipcore@ietf.org
> Subject: Re: [sipcore] rebooting location-conveyance
>
>
> In the emergency services case, I would not imagine
> intermediaries would confine themselves to the role of proxy
> servers - if they don't like the location attached to a
> message, I'm sure they'd just remove it, insert their own and
> forward the request. Why would we expect them to do otherwise?
>
> The way the location-conveyance mechanism works now - where,
> in that case, the intermediary removes the cid pointer to the
> MIME body it doesn't like, but leaves the MIME body in the
> request and provides a new URL to the preferred location
> information - seems like it is an even worse way of
> accomplishing the aims of an emergency services intermediary,
> and one that surely would be supplanted in deployments by
> some kind of special-purpose intermediary that doesn't
> conform to the standard.
>
> In the emergency services case, we need to do several things
> we wouldn't do otherwise, such as ignoring some classes of
> security violations because the consequences of not
> processing a call are so dire that we need to be generous in
> what we accept. The real question is if the steadily-growing
> set of parameters that have been defined in the draft to this
> point actually serve the practical requirements for emergency
> services or other use cases.
>
> Jon Peterson
> NeuStar, Inc.
>
> Elwell, John wrote:
> > What do the emergency call people think about having to
> retry, with a possible impact on call establishment times?
> >
> > John
> >
> >  
> >> -----Original Message-----
> >> From: sipcore-bounces@ie= tf.org
> >> [mailto:sipcore-b= ounces@ietf.org] On Behalf Of Jon Peterson
> >> Sent: 25 March 2010 14:28
> >> To: sipcore@ietf.org
> >> Subject: [sipcore] rebooting location-conveyance
> >>
> >> James Polk and I sat down this week and took a hard look at t= he
> >> current sipcore-location-conveyance draft, and we believe tha= t
> >> there's an opportunity to simplify (and shorten) the document= .
> >>
> >> The simplification derives mostly from a single change to the=
> >> operation of the mechanism. Today, the location-conveyance > draft has
> >> a good deal of machinery to support the case where a proxy > wants to
> >> replace existing location information in a request with
> more accurate
> >> or preferred location information.
> >> The current approach replaces the URI in the Geolocation head= er
> >> (which probably points to a MIME body) with a URI desired by = the
> >> proxy, presumably of an Internet resource containing the desi= red
> >> PIDF-LO body. This solution isn't optimal for several
> reasons - most
> >> notably, since the MIME body is not removed by said proxy, it= will
> >> still be delivered to the eventual location recipient, even i= f the
> >> URI in the Geolocation header does not point to said body. > In order
> >> to handle this case, the current draft employs a disambiguati= on
> >> mechanism (relying on the "used-for-routing" and &q= uot;inserted-by"
> >> parameters, as well as the "inserter") to inform th= e location
> >> recipient about the source of th  is location informatio= n.
> Moreover,
> >> since this change is effected unilaterally, the originating u= ser
> >> agent has no idea that the location it supplied has been
> altered in
> >> transit, and may thus receive a surprising response to its re= quest.
> >>
> >> While this use case is an important one, we believe it can be=
> >> addressed with a lighter mechanism. The basic idea is that a = proxy
> >> server that wants to replace the location information
> provided by a
> >> user agent would reject a request with the 424 Bad
> Location response
> >> code, optionally enclosing in the body the location
> information that
> >> it would like the user agent to incorporate.  The UA can=
> insert the
> >> LI from the 424 in its subsequent reissuance of the
> request; if no LI
> >> is supplied in the 424, then the user agent resends the reque= st
> >> without LI.
> >> This brings the location-conveyance mechanism back to one its=
> >> original constraints: that only one PIDF-LO body is
> associated with a
> >> particular SIP request. This allows us to remove the
> >> "used-for-routing" parameter as well as the
> "inserted-by"/"inserter"
> >> mechanism.
> >>
> >> In a related clean-up, several of the error codes can probabl= y be
> >> consolidated or replaced with SIP response codes (for example= , the
> >> Retry-After semantics of the 200/300 error codes).
> >>
> >> If no one objects, we'd therefore like to try to come back > with a new
> >> version that has fewer moving parts and fewer pages.
> >>
> >> Thoughts?
> >>
> >> Jon Peterson
> >> NeuStar, Inc.
> >>
> >>
> >> _______________________________________________
> >> sipcore mailing list
> >> sipcore@ietf.org
> >> htt= ps://www.ietf.org/mailman/listinfo/sipcore
> >>    
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.= ietf.org/mailman/listinfo/sipcore
>

--_000_C7D237C63BC7Fjonpetersonneustarbiz_-- From keith.drage@alcatel-lucent.com Fri Mar 26 10:41:08 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 513693A6A40 for ; Fri, 26 Mar 2010 10:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.281 X-Spam-Level: X-Spam-Status: No, score=-2.281 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, 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 msi01obhb1j9 for ; Fri, 26 Mar 2010 10:41:07 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 86F9C3A6BFF for ; Fri, 26 Mar 2010 10:41:03 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o2QHfO6N032624 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 26 Mar 2010 18:41:25 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 26 Mar 2010 18:41:25 +0100 From: "DRAGE, Keith (Keith)" To: Adam Roach Date: Fri, 26 Mar 2010 18:41:22 +0100 Thread-Topic: [sipcore] rebooting location-conveyance Thread-Index: AcrNAr47g84P3JKIQgCEQeQNj4QD9AABqBRQ Message-ID: References: <4BABD55B.9040507@neustar.biz> <4BABFB27.3090607@neustar.biz> <4BACE2EA.7020605@nostrum.com> In-Reply-To: <4BACE2EA.7020605@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] rebooting location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 17:41:08 -0000 And I read it as no, as essentially only one location goes forward. The original predicate from Jon was that we have multiple locations because= an intermediate devices wants to replace the existing location. My view is that this never was a use case. The use case was that an interme= diate entity had location information relating to the sender of the message= , for which it did not know whether it was better or worse that that create= d by other location inserters. Therefore the solution sends all the locatio= ns to the location recipient, and the recipient then makes its own value di= scussion.=20 There was also a use case where there was no location from the original sen= der at all, but I read that as not being impacted by Jon's input. For information the relevant requirement for this part of the work was: " Proxy-1 Proxy servers must be capable of adding a Location header=20 field during processing of SIP requests. Motivation: Provide network assertion of location when UACs are unable to do so, or when network assertion is more reliable than UAC assertion of location Note: Because UACs connected to SIP signaling networks may have=20 widely varying access network arrangements, including VPN=20 tunnels and roaming mechanisms, it may be difficult for a=20 network to reliably know the location of the endpoint. Proxy=20 assertion of location is NOT RECOMMENDED unless the SIP=20 signaling network has reliable knowledge of the actual=20 location of the Targets. " However it probably does not help advance the argument from either side. regards Keith > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: Friday, March 26, 2010 4:38 PM > To: DRAGE, Keith (Keith) > Cc: Jon Peterson; sipcore@ietf.org > Subject: Re: [sipcore] rebooting location-conveyance >=20 > [as participant] >=20 > Actually, I read his response as a qualified "yes." If we go=20 > to base requirements and ask whether proxies on the path can=20 > take action to cause their own view of the user's location to=20 > be added to the request, then the requirement -- by my=20 > understanding -- is satisfied by the proposed mechanism. >=20 > /a >=20 > On 3/25/10 6:19 PM, DRAGE, Keith (Keith) wrote: > > So on the basis that your answer appears to be NO to my=20 > question, I believe I cannot support the change you are proposing. > > > > regards > > > > Keith > > > > =20 > >> -----Original Message----- > >> From: Jon Peterson [mailto:jon.peterson@neustar.biz] > >> Sent: Friday, March 26, 2010 12:09 AM > >> To: DRAGE, Keith (Keith) > >> Cc: sipcore@ietf.org > >> Subject: Re: [sipcore] rebooting location-conveyance > >> > >> > >> Semantically, a single SIP request can contain multiple locations=20 > >> within the constraints of the presence data model -=20 > PIDF-LO is after=20 > >> all PIDF, and like any presence document it can make fairly=20 > >> complicated statements about the relationship of location=20 > information=20 > >> to users or devices, including enumerating multiple locations.=20 > >> However, the intention of the revision is to return this to an old=20 > >> design constraint where a SIP request may contain only a single=20 > >> Geolocation header field with one URI pointing to location=20 > >> information. > >> > >> Jon Peterson > >> NeuStar, Inc. > >> > >> DRAGE, Keith (Keith) wrote: > >> =20 > >>> So, I believe the current solution allows a scenario where > >>> =20 > >> the originating UA inserts a location, and various proxies=20 > along the=20 > >> path could insert a location, in addition to the existing one,=20 > >> providing they all represent their view of the state of the user. > >> =20 > >>> By making this proposal, are you eliminating this scenario, > >>> =20 > >> or allowing it to continue to exist. > >> =20 > >>> regards > >>> > >>> Keith > >>> > >>> > >>> > >>> > >>> =20 > >>>> -----Original Message----- > >>>> From: sipcore-bounces@ietf.org > >>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Jon Peterson > >>>> Sent: Thursday, March 25, 2010 9:28 PM > >>>> To: sipcore@ietf.org > >>>> Subject: [sipcore] rebooting location-conveyance > >>>> > >>>> James Polk and I sat down this week and took a hard look at the=20 > >>>> current sipcore-location-conveyance draft, and we believe that=20 > >>>> there's an opportunity to simplify (and shorten) the document. > >>>> > >>>> The simplification derives mostly from a single change to the=20 > >>>> operation of the mechanism. Today, the location-conveyance > >>>> =20 > >> draft has > >> =20 > >>>> a good deal of machinery to support the case where a proxy > >>>> =20 > >> wants to > >> =20 > >>>> replace existing location information in a request with > >>>> =20 > >> more accurate > >> =20 > >>>> or preferred location information. > >>>> The current approach replaces the URI in the Geolocation header=20 > >>>> (which probably points to a MIME body) with a URI desired by the=20 > >>>> proxy, presumably of an Internet resource containing the desired=20 > >>>> PIDF-LO body. This solution isn't optimal for several > >>>> =20 > >> reasons - most > >> =20 > >>>> notably, since the MIME body is not removed by said=20 > proxy, it will=20 > >>>> still be delivered to the eventual location recipient,=20 > even if the=20 > >>>> URI in the Geolocation header does not point to said body. > >>>> =20 > >> In order > >> =20 > >>>> to handle this case, the current draft employs a disambiguation=20 > >>>> mechanism (relying on the "used-for-routing" and "inserted-by" > >>>> parameters, as well as the "inserter") to inform the location=20 > >>>> recipient about the source of th is location information. > >>>> =20 > >> Moreover, > >> =20 > >>>> since this change is effected unilaterally, the originating user=20 > >>>> agent has no idea that the location it supplied has been > >>>> =20 > >> altered in > >> =20 > >>>> transit, and may thus receive a surprising response to=20 > its request. > >>>> > >>>> While this use case is an important one, we believe it can be=20 > >>>> addressed with a lighter mechanism. The basic idea is=20 > that a proxy=20 > >>>> server that wants to replace the location information > >>>> =20 > >> provided by a > >> =20 > >>>> user agent would reject a request with the 424 Bad > >>>> =20 > >> Location response > >> =20 > >>>> code, optionally enclosing in the body the location > >>>> =20 > >> information that > >> =20 > >>>> it would like the user agent to incorporate. The UA can > >>>> =20 > >> insert the > >> =20 > >>>> LI from the 424 in its subsequent reissuance of the > >>>> =20 > >> request; if no LI > >> =20 > >>>> is supplied in the 424, then the user agent resends the request=20 > >>>> without LI. > >>>> This brings the location-conveyance mechanism back to one its=20 > >>>> original constraints: that only one PIDF-LO body is > >>>> =20 > >> associated with a > >> =20 > >>>> particular SIP request. This allows us to remove the=20 > >>>> "used-for-routing" parameter as well as the > >>>> =20 > >> "inserted-by"/"inserter" > >> =20 > >>>> mechanism. > >>>> > >>>> In a related clean-up, several of the error codes can=20 > probably be=20 > >>>> consolidated or replaced with SIP response codes (for=20 > example, the=20 > >>>> Retry-After semantics of the 200/300 error codes). > >>>> > >>>> If no one objects, we'd therefore like to try to come back > >>>> =20 > >> with a new > >> =20 > >>>> version that has fewer moving parts and fewer pages. > >>>> > >>>> Thoughts? > >>>> > >>>> Jon Peterson > >>>> NeuStar, Inc. > >>>> > >>>> > >>>> _______________________________________________ > >>>> sipcore mailing list > >>>> sipcore@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/sipcore > >>>> > >>>> =20 > >> > >> =20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > =20 >=20 > = From Martin.Thomson@andrew.com Fri Mar 26 12:37:04 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 502963A6C0F for ; Fri, 26 Mar 2010 12:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.915 X-Spam-Level: X-Spam-Status: No, score=0.915 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] 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 6yz58ybEqpC7 for ; Fri, 26 Mar 2010 12:37:02 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 98C733A680E for ; Fri, 26 Mar 2010 12:37:02 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:11529 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S209793Ab0CZTh0 (ORCPT ); Fri, 26 Mar 2010 14:37:26 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Fri, 26 Mar 2010 14:37:25 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Sat, 27 Mar 2010 03:37:21 +0800 From: "Thomson, Martin" To: "Peterson, Jon" , "DRAGE, Keith (Keith)" , "Elwell, John" Date: Sat, 27 Mar 2010 03:38:39 +0800 Thread-Topic: [sipcore] rebooting location-conveyance Thread-Index: AcrM9nFWgVep6VJoQeecjE/IePOgIQABcNQAAAKjA7sABR8+EA== Message-ID: <8B0A9FCBB9832F43971E38010638454F03E24ED44E@SISPE7MB1.commscope.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8B0A9FCBB9832F43971E38010638454F03E24ED44ESISPE7MB1comm_" MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "sipcore@ietf.org" Subject: Re: [sipcore] rebooting location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 19:37:04 -0000 --_000_8B0A9FCBB9832F43971E38010638454F03E24ED44ESISPE7MB1comm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcywgdG8gbWUgaXMgdGhlIGJlc3QgdHJhZGUtb2ZmLiAgVGhlIGNvbXBsZXhpdHkgY29zdHMg dGhhdCB3b3VsZCBiZSBpbmN1cnJlZCBmcm9tIHRoZSBjdXJyZW50IHNwZWNpZmljYXRpb24gYXJl IG5vdCBqdXN0aWZpYWJsZSB3aGVuIGNvbnNpZGVyZWQgYWdhaW5zdCB3aGF0IGlzIG9ubHkgaWRl YWxpc3RpYyBhZHZhbnRhZ2UuICBUaGlzIGlzIGVzcGVjaWFsbHkgdHJ1ZSB3aGVuLCBhcyBKb24g cG9pbnRzIG91dCwgdGhlIHVzZSBjYXNlIHdlIGFyZSBkaXNjdXNzaW5nIGFsbG93cyBmb3IgZXh0 cmFvcmRpbmFyeSBhY3Rpb25zIHRoYXQgaGF2ZSBtb3JlIHNlcmlvdXMgcmFtaWZpY2F0aW9ucyB0 aGFuIHRoZSBtZXJlIGxvc3Mgb2YgdHJhbnNwYXJlbmN5Lg0KDQotLU1hcnRpbg0KDQpGcm9tOiBz aXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBQZXRlcnNvbiwgSm9uDQpTZW50OiBGcmlkYXksIDI2IE1hcmNoIDIwMTAg MTA6MDcgQU0NClRvOiBEUkFHRSwgS2VpdGggKEtlaXRoKTsgRWx3ZWxsLCBKb2huDQpDYzogc2lw Y29yZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSByZWJvb3RpbmcgbG9jYXRpb24t Y29udmV5YW5jZQ0KDQoNClRheG9ub215IGFzaWRlLCB0aGUgY29yZSBhcmNoaXRlY3R1cmFsIHF1 ZXN0aW9uIGlzIGhvdyBtdWNoIHN1cHBvcnQgaXMgbmVlZGVkIGZvciBjYXJyeWluZyBtdWx0aXBs ZSBsb2NhdGlvbnMgaW4gYSBzaW5nbGUgIFNJUCByZXF1ZXN0LCBhbmQgd2hldGhlciB0aGF0IHN1 cHBvcnQgc2hvdWxkIGJlIHN0YWdlZCBhdCB0aGUgU0lQIGxheWVyIG9yIHRoZSBib2R5IChQSURG KSBsYXllci4gUGFyYW1ldGVycyBsaWtlIOKAnGluc2VydGVkLWJ54oCdIGNhdXNlIGltbWVkaWF0 ZSBzdXNwaWNpb24gcHJlY2lzZWx5IGJlY2F1c2UgdGhleSBzdHJhZGRsZSB0aGF0IGJvdW5kYXJ5 IOKAkyBpdCBpcyB0aGUgam9iIG9mIFBJREYgdG8gZXhwbGFpbiB3aG8gZ2VuZXJhdGVkIHRoaXMg bG9jYXRpb24gaW5mb3JtYXRpb24gYW5kIHdoYXQgZGF0YSBtb2RlbCBlbGVtZW50IGlzIGNvdXBs ZWQgdG8gdGhlIGxvY2F0aW9uIGluZm9ybWF0aW9uLiBNZXJlbHkgcG9pbnRpbmcgZnJvbSB0aGUg U0lQIGxheWVyIHRvIGRpZmZlcmVudCBQSURGIGJvZGllcyBkZXNjcmliaW5nIGRpZmZlcmVudCBs b2NhdGlvbnMgZG9lcyBub3QgY2xhcmlmeSB0aGUgcmVsYXRpb25zaGlwIG9mIHRoZXNlIGVsZW1l bnRzIHRvIG9uZSBhbm90aGVyIGluIGRhdGEgbW9kZWwgdGVybXMuDQoNCldoaWxlIG9uZSBjYW4g YXJndWUgdGhhdCB5b3UgY291bGRu4oCZdCBzb3J0IHRoYXQgb3V0IGluIGEgdGltZWZyYW1lIGV4 cGVkaWVudCBlbm91Z2ggZm9yIHRoZSBlbWVyZ2VuY3kgc2VydmljZXMgY2FzZSwgSSBjb250aW51 ZSB0byBtYWludGFpbiB0aGF0IHdlIHNob3VsZCBleHBlY3QgZXhjZXB0aW9uYWwgYmVoYXZpb3Ig ZnJvbSBpbnRlcm1lZGlhcmllcyB0YWlsb3JlZCB0byBoZWxwIGVtZXJnZW5jeSBzZXJ2aWNlcyBj YWxscyBhbG9uZyB0aGVpciBwYXRoLiBUaGUgam9iIG9mIHRoZSBuZXR3b3JrIGluIHRoaXMgY2Fz ZSBpcyB0byBkZWxpdmVyIHF1aWNrbHkgdGhlIGJlc3QgaW5mb3JtYXRpb24gaXQgY2FuIHRvIHRo ZSByaWdodCBzZXJ2aWNlIC0gdGhlIGFyZ3VtZW50IHRoYXQgeW91IOKAnG5ldmVyIHJlbW92ZSBp bmZvcm1hdGlvbiBmcm9tIGFuIGVtZXJnZW5jeSBjYWxs4oCdIGRvZXMgbm90IGVudGFpbCDigJxl bmNvdXJhZ2UgdGhlIGFjY3VtdWxhdGlvbiBvZiBhIGJld2lsZGVyaW5nIHZhcmlldHkgb2YgZGlm ZmVyZW50IGxvY2F0aW9ucyB3aXRob3V0IGRlc2NyaWJpbmcgdGhlaXIgcmVsYXRpb25zaGlwIHRv IG9uZSBhbm90aGVyLuKAnSBBdCB0aGUgZW5kIG9mIHRoZSBkYXksIG9mIGNvdXJzZSwgdGhlIHJl c3VsdCBvZiBwbGFjaW5nIGFuIGVtZXJnZW5jeSBzZXJ2aWNlcyBjYWxsIHdpbGwgcHJvYmFibHkg YmUgdGhlIGRlbGl2ZXJ5IG9mIGxvY2F0aW9uIGluZm9ybWF0aW9uIHRvIHNvbWVvbmUgd2hvIGlz IHN0aWxsIHJlcXVpcmVkIHRvIGFzayB0aGUgY2FsbGVyIHBlcnNvbmFsbHkgZm9yIHRoZWlyIGxv Y2F0aW9uLCBhbmQgdGhpcyBvbmx5IGZ1cnRoZXIgaWxsdXN0cmF0ZXMgd2h5IHdlIHRyZWF0IHRo aXMgYXMgYSBzcGVjaWFsIGNhc2UuIEZvciB0aGUgY29tbW9uIGNhc2UsIHdlIHdhbnQgYW4gYXJj aGl0ZWN0dXJhbGx5IGNsZWFuIHdheSB0byBhc3NvY2lhdGUgYSBTSVAgcmVxdWVzdCB3aXRoIGxv Y2F0aW9uIGluZm9ybWF0aW9uLg0KDQpKb24gUGV0ZXJzb24NCk5ldVN0YXIsIEluYy4NCg0KT24g My8yNi8xMCA4OjU0IEFNLCAiRFJBR0UsIEtlaXRoIChLZWl0aCkiIDxrZWl0aC5kcmFnZUBhbGNh dGVsLWx1Y2VudC5jb20+IHdyb3RlOg0KMSkgICAgICBBdCBsZWFzdCBvbiB0aGUgZW1lcmdlbmN5 IGNhbGxzIEkndmUgYmVlbiBsb29raW5nIGF0LCB3ZSd2ZSBiZWVuIGRvaW5nIG91ciBiZXN0IHRv IG1ha2Ugc3VyZSBpbnRlcm1lZGlhcmllcyBhcmUgcHJveGllcy4gSW5zZXJ0aW9ucyBjb3VsZCB3 ZWxsIGJlIGxvY2F0aW9uIGJ5IHJlZmVyZW5jZSwgcmF0aGVyIHRoYW4gbG9jYXRpb24gYnkgdmFs dWUgYXMgYSByZXN1bHQuIEIyQlVBcyBicmVhayB0cmFuc3BhcmVuY3kgLSByZW1lbWJlcj8NCg0K MikgICAgICBGcm9tIGRheSAxKSBvbiBlbWVyZ2VuY3kgY2FsbHMsIHRoZSBldGhvcyBoYXMgYmVl biAtIERvIG5vdCBtYWtlIGp1ZGdlbWVudHMgb24gdGhlIHZhbHVlIG9mIGluZm9ybWF0aW9uIHRv IHRoZSBQU0FQLiBUaGVyZWZvcmUgaW4gdGhlIHdvcmsgSSd2ZSBiZWVuIGludm9sdmVkIGluLCB3 ZSBuZXZlciByZW1vdmUgaW5mb3JtYXRpb24gZnJvbSBhbiBlbWVyZ2VuY3kgY2FsbC4gRXZlcnl0 aGluZyBpcyBwYXNzZWQgdG8gdGhlIFBTQVAgaW4gc29tZSBmb3JtLiBUaGlzIG1ha2VzIGl0IGlt cG9zc2libGUgdG8gZnVsZmlsIHRoYXQuDQoNCnJlZ2FyZHMNCg0KS2VpdGgNCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcNCj4g W21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb24gUGV0ZXJz b24NCj4gU2VudDogRnJpZGF5LCBNYXJjaCAyNiwgMjAxMCAzOjEwIFBNDQo+IFRvOiBFbHdlbGws IEpvaG4NCj4gQ2M6IHNpcGNvcmVAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtzaXBjb3JlXSBy ZWJvb3RpbmcgbG9jYXRpb24tY29udmV5YW5jZQ0KPg0KPg0KPiBJbiB0aGUgZW1lcmdlbmN5IHNl cnZpY2VzIGNhc2UsIEkgd291bGQgbm90IGltYWdpbmUNCj4gaW50ZXJtZWRpYXJpZXMgd291bGQg Y29uZmluZSB0aGVtc2VsdmVzIHRvIHRoZSByb2xlIG9mIHByb3h5DQo+IHNlcnZlcnMgLSBpZiB0 aGV5IGRvbid0IGxpa2UgdGhlIGxvY2F0aW9uIGF0dGFjaGVkIHRvIGENCj4gbWVzc2FnZSwgSSdt IHN1cmUgdGhleSdkIGp1c3QgcmVtb3ZlIGl0LCBpbnNlcnQgdGhlaXIgb3duIGFuZA0KPiBmb3J3 YXJkIHRoZSByZXF1ZXN0LiBXaHkgd291bGQgd2UgZXhwZWN0IHRoZW0gdG8gZG8gb3RoZXJ3aXNl Pw0KPg0KPiBUaGUgd2F5IHRoZSBsb2NhdGlvbi1jb252ZXlhbmNlIG1lY2hhbmlzbSB3b3JrcyBu b3cgLSB3aGVyZSwNCj4gaW4gdGhhdCBjYXNlLCB0aGUgaW50ZXJtZWRpYXJ5IHJlbW92ZXMgdGhl IGNpZCBwb2ludGVyIHRvIHRoZQ0KPiBNSU1FIGJvZHkgaXQgZG9lc24ndCBsaWtlLCBidXQgbGVh dmVzIHRoZSBNSU1FIGJvZHkgaW4gdGhlDQo+IHJlcXVlc3QgYW5kIHByb3ZpZGVzIGEgbmV3IFVS TCB0byB0aGUgcHJlZmVycmVkIGxvY2F0aW9uDQo+IGluZm9ybWF0aW9uIC0gc2VlbXMgbGlrZSBp dCBpcyBhbiBldmVuIHdvcnNlIHdheSBvZg0KPiBhY2NvbXBsaXNoaW5nIHRoZSBhaW1zIG9mIGFu IGVtZXJnZW5jeSBzZXJ2aWNlcyBpbnRlcm1lZGlhcnksDQo+IGFuZCBvbmUgdGhhdCBzdXJlbHkg d291bGQgYmUgc3VwcGxhbnRlZCBpbiBkZXBsb3ltZW50cyBieQ0KPiBzb21lIGtpbmQgb2Ygc3Bl Y2lhbC1wdXJwb3NlIGludGVybWVkaWFyeSB0aGF0IGRvZXNuJ3QNCj4gY29uZm9ybSB0byB0aGUg c3RhbmRhcmQuDQo+DQo+IEluIHRoZSBlbWVyZ2VuY3kgc2VydmljZXMgY2FzZSwgd2UgbmVlZCB0 byBkbyBzZXZlcmFsIHRoaW5ncw0KPiB3ZSB3b3VsZG4ndCBkbyBvdGhlcndpc2UsIHN1Y2ggYXMg aWdub3Jpbmcgc29tZSBjbGFzc2VzIG9mDQo+IHNlY3VyaXR5IHZpb2xhdGlvbnMgYmVjYXVzZSB0 aGUgY29uc2VxdWVuY2VzIG9mIG5vdA0KPiBwcm9jZXNzaW5nIGEgY2FsbCBhcmUgc28gZGlyZSB0 aGF0IHdlIG5lZWQgdG8gYmUgZ2VuZXJvdXMgaW4NCj4gd2hhdCB3ZSBhY2NlcHQuIFRoZSByZWFs IHF1ZXN0aW9uIGlzIGlmIHRoZSBzdGVhZGlseS1ncm93aW5nDQo+IHNldCBvZiBwYXJhbWV0ZXJz IHRoYXQgaGF2ZSBiZWVuIGRlZmluZWQgaW4gdGhlIGRyYWZ0IHRvIHRoaXMNCj4gcG9pbnQgYWN0 dWFsbHkgc2VydmUgdGhlIHByYWN0aWNhbCByZXF1aXJlbWVudHMgZm9yIGVtZXJnZW5jeQ0KPiBz ZXJ2aWNlcyBvciBvdGhlciB1c2UgY2FzZXMuDQo+DQo+IEpvbiBQZXRlcnNvbg0KPiBOZXVTdGFy LCBJbmMuDQo+DQrigKYNCg== --_000_8B0A9FCBB9832F43971E38010638454F03E24ED44ESISPE7MB1comm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPg0KPGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6 dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDov L3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KDQo8bWV0YSBuYW1lPUdlbmVy YXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8dGl0 bGU+UmU6IFtzaXBjb3JlXSByZWJvb3RpbmcgbG9jYXRpb24tY29udmV5YW5jZTwvdGl0bGU+DQo8 c3R5bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7Zm9u dC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0 IDIgNDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowbW07DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNl cmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5 bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMyNDQwNjE7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBT ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3 Mi4wcHQgNzIuMHB0O30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9z dHlsZT4NCjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCiA8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQogIDxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KIDwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0t LT4NCjwvaGVhZD4NCg0KPGJvZHkgbGFuZz1FTi1BVSBsaW5rPWJsdWUgdmxpbms9cHVycGxlPg0K DQo8ZGl2IGNsYXNzPVNlY3Rpb24xPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNv bG9yOiMyNDQwNjEnPlRoaXMsIHRvIG1lIGlzIHRoZSBiZXN0IHRyYWRlLW9mZi7CoCBUaGUgY29t cGxleGl0eSBjb3N0cyB0aGF0IHdvdWxkDQpiZSBpbmN1cnJlZCBmcm9tIHRoZSBjdXJyZW50IHNw ZWNpZmljYXRpb24gYXJlIG5vdCBqdXN0aWZpYWJsZSB3aGVuIGNvbnNpZGVyZWQNCmFnYWluc3Qg d2hhdCBpcyBvbmx5IGlkZWFsaXN0aWMgYWR2YW50YWdlLsKgIFRoaXMgaXMgZXNwZWNpYWxseSB0 cnVlIHdoZW4sIGFzDQpKb24gcG9pbnRzIG91dCwgdGhlIHVzZSBjYXNlIHdlIGFyZSBkaXNjdXNz aW5nIGFsbG93cyBmb3IgZXh0cmFvcmRpbmFyeSBhY3Rpb25zDQp0aGF0IGhhdmUgbW9yZSBzZXJp b3VzIHJhbWlmaWNhdGlvbnMgdGhhbiB0aGUgbWVyZSBsb3NzIG9mIHRyYW5zcGFyZW5jeS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6 IzI0NDA2MSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjsNCmNvbG9yOiMyNDQwNjEnPi0tTWFydGluIDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMjQ0MDYxJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowbW0gMG1tIDBtbSA0LjBwdCc+DQoNCjxkaXY+ DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBtbSAwbW0gMG1tJz4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxz cGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6DQoiVGFo b21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLVVTIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4g c2lwY29yZS1ib3VuY2VzQGlldGYub3JnDQpbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9y Z10gPGI+T24gQmVoYWxmIE9mIDwvYj5QZXRlcnNvbiwgSm9uPGJyPg0KPGI+U2VudDo8L2I+IEZy aWRheSwgMjYgTWFyY2ggMjAxMCAxMDowNyBBTTxicj4NCjxiPlRvOjwvYj4gRFJBR0UsIEtlaXRo IChLZWl0aCk7IEVsd2VsbCwgSm9objxicj4NCjxiPkNjOjwvYj4gc2lwY29yZUBpZXRmLm9yZzxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NpcGNvcmVdIHJlYm9vdGluZyBsb2NhdGlvbi1jb252 ZXlhbmNlPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7DQpmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48YnI+DQpUYXhvbm9teSBh c2lkZSwgdGhlIGNvcmUgYXJjaGl0ZWN0dXJhbCBxdWVzdGlvbiBpcyBob3cgbXVjaCBzdXBwb3J0 IGlzIG5lZWRlZA0KZm9yIGNhcnJ5aW5nIG11bHRpcGxlIGxvY2F0aW9ucyBpbiBhIHNpbmdsZSAm bmJzcDtTSVAgcmVxdWVzdCwgYW5kIHdoZXRoZXIgdGhhdA0Kc3VwcG9ydCBzaG91bGQgYmUgc3Rh Z2VkIGF0IHRoZSBTSVAgbGF5ZXIgb3IgdGhlIGJvZHkgKFBJREYpIGxheWVyLiBQYXJhbWV0ZXJz DQpsaWtlIOKAnGluc2VydGVkLWJ54oCdIGNhdXNlIGltbWVkaWF0ZSBzdXNwaWNpb24gcHJlY2lz ZWx5IGJlY2F1c2UgdGhleSBzdHJhZGRsZQ0KdGhhdCBib3VuZGFyeSDigJMgaXQgaXMgdGhlIGpv YiBvZiBQSURGIHRvIGV4cGxhaW4gd2hvIGdlbmVyYXRlZCB0aGlzIGxvY2F0aW9uDQppbmZvcm1h dGlvbiBhbmQgd2hhdCBkYXRhIG1vZGVsIGVsZW1lbnQgaXMgY291cGxlZCB0byB0aGUgbG9jYXRp b24gaW5mb3JtYXRpb24uDQpNZXJlbHkgcG9pbnRpbmcgZnJvbSB0aGUgU0lQIGxheWVyIHRvIGRp ZmZlcmVudCBQSURGIGJvZGllcyBkZXNjcmliaW5nDQpkaWZmZXJlbnQgbG9jYXRpb25zIGRvZXMg bm90IGNsYXJpZnkgdGhlIHJlbGF0aW9uc2hpcCBvZiB0aGVzZSBlbGVtZW50cyB0byBvbmUNCmFu b3RoZXIgaW4gZGF0YSBtb2RlbCB0ZXJtcy48YnI+DQo8YnI+DQpXaGlsZSBvbmUgY2FuIGFyZ3Vl IHRoYXQgeW91IGNvdWxkbuKAmXQgc29ydCB0aGF0IG91dCBpbiBhIHRpbWVmcmFtZSBleHBlZGll bnQNCmVub3VnaCBmb3IgdGhlIGVtZXJnZW5jeSBzZXJ2aWNlcyBjYXNlLCBJIGNvbnRpbnVlIHRv IG1haW50YWluIHRoYXQgd2Ugc2hvdWxkDQpleHBlY3QgZXhjZXB0aW9uYWwgYmVoYXZpb3IgZnJv bSBpbnRlcm1lZGlhcmllcyB0YWlsb3JlZCB0byBoZWxwIGVtZXJnZW5jeQ0Kc2VydmljZXMgY2Fs bHMgYWxvbmcgdGhlaXIgcGF0aC4gVGhlIGpvYiBvZiB0aGUgbmV0d29yayBpbiB0aGlzIGNhc2Ug aXMgdG8NCmRlbGl2ZXIgcXVpY2tseSB0aGUgYmVzdCBpbmZvcm1hdGlvbiBpdCBjYW4gdG8gdGhl IHJpZ2h0IHNlcnZpY2UgLSB0aGUgYXJndW1lbnQNCnRoYXQgeW91IOKAnG5ldmVyIHJlbW92ZSBp bmZvcm1hdGlvbiBmcm9tIGFuIGVtZXJnZW5jeSBjYWxs4oCdIGRvZXMgbm90IGVudGFpbA0K4oCc ZW5jb3VyYWdlIHRoZSBhY2N1bXVsYXRpb24gb2YgYSBiZXdpbGRlcmluZyB2YXJpZXR5IG9mIGRp ZmZlcmVudCBsb2NhdGlvbnMNCndpdGhvdXQgZGVzY3JpYmluZyB0aGVpciByZWxhdGlvbnNoaXAg dG8gb25lIGFub3RoZXIu4oCdIEF0IHRoZSBlbmQgb2YgdGhlIGRheSwNCm9mIGNvdXJzZSwgdGhl IHJlc3VsdCBvZiBwbGFjaW5nIGFuIGVtZXJnZW5jeSBzZXJ2aWNlcyBjYWxsIHdpbGwgcHJvYmFi bHkgYmUNCnRoZSBkZWxpdmVyeSBvZiBsb2NhdGlvbiBpbmZvcm1hdGlvbiB0byBzb21lb25lIHdo byBpcyBzdGlsbCByZXF1aXJlZCB0byBhc2sNCnRoZSBjYWxsZXIgcGVyc29uYWxseSBmb3IgdGhl aXIgbG9jYXRpb24sIGFuZCB0aGlzIG9ubHkgZnVydGhlciBpbGx1c3RyYXRlcyB3aHkNCndlIHRy ZWF0IHRoaXMgYXMgYSBzcGVjaWFsIGNhc2UuIEZvciB0aGUgY29tbW9uIGNhc2UsIHdlIHdhbnQg YW4NCmFyY2hpdGVjdHVyYWxseSBjbGVhbiB3YXkgdG8gYXNzb2NpYXRlIGEgU0lQIHJlcXVlc3Qg d2l0aCBsb2NhdGlvbiBpbmZvcm1hdGlvbi48YnI+DQo8YnI+DQpKb24gUGV0ZXJzb248YnI+DQpO ZXVTdGFyLCBJbmMuPGJyPg0KPGJyPg0KT24gMy8yNi8xMCA4OjU0IEFNLCAmcXVvdDtEUkFHRSwg S2VpdGggKEtlaXRoKSZxdW90OyAmbHQ7PGENCmhyZWY9ImtlaXRoLmRyYWdlQGFsY2F0ZWwtbHVj ZW50LmNvbSI+a2VpdGguZHJhZ2VAYWxjYXRlbC1sdWNlbnQuY29tPC9hPiZndDsNCndyb3RlOjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4t Ym90dG9tOjEyLjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz4xKSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDtBdCBsZWFzdA0Kb24gdGhlIGVtZXJnZW5jeSBjYWxscyBJJ3ZlIGJlZW4gbG9va2luZyBhdCwg d2UndmUgYmVlbiBkb2luZyBvdXIgYmVzdCB0byBtYWtlDQpzdXJlIGludGVybWVkaWFyaWVzIGFy ZSBwcm94aWVzLiBJbnNlcnRpb25zIGNvdWxkIHdlbGwgYmUgbG9jYXRpb24gYnkNCnJlZmVyZW5j ZSwgcmF0aGVyIHRoYW4gbG9jYXRpb24gYnkgdmFsdWUgYXMgYSByZXN1bHQuIEIyQlVBcyBicmVh ayB0cmFuc3BhcmVuY3kNCi0gcmVtZW1iZXI/PGJyPg0KPGJyPg0KMikgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7RnJvbSBkYXkgMSkgb24gZW1lcmdlbmN5IGNhbGxzLCB0aGUgZXRob3Mg aGFzDQpiZWVuIC0gRG8gbm90IG1ha2UganVkZ2VtZW50cyBvbiB0aGUgdmFsdWUgb2YgaW5mb3Jt YXRpb24gdG8gdGhlIFBTQVAuIFRoZXJlZm9yZQ0KaW4gdGhlIHdvcmsgSSd2ZSBiZWVuIGludm9s dmVkIGluLCB3ZSBuZXZlciByZW1vdmUgaW5mb3JtYXRpb24gZnJvbSBhbg0KZW1lcmdlbmN5IGNh bGwuIEV2ZXJ5dGhpbmcgaXMgcGFzc2VkIHRvIHRoZSBQU0FQIGluIHNvbWUgZm9ybS4gVGhpcyBt YWtlcyBpdA0KaW1wb3NzaWJsZSB0byBmdWxmaWwgdGhhdC48YnI+DQo8YnI+DQpyZWdhcmRzPGJy Pg0KPGJyPg0KS2VpdGg8YnI+DQo8YnI+DQomZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PGJyPg0KJmd0OyBGcm9tOiA8YSBocmVmPSJzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmciPnNpcGNv cmUtYm91bmNlc0BpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IFs8YSBocmVmPSJtYWlsdG86c2lwY29y ZS1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnPC9hPl0N Ck9uIEJlaGFsZiBPZiBKb24gUGV0ZXJzb248YnI+DQomZ3Q7IFNlbnQ6IEZyaWRheSwgTWFyY2gg MjYsIDIwMTAgMzoxMCBQTTxicj4NCiZndDsgVG86IEVsd2VsbCwgSm9objxicj4NCiZndDsgQ2M6 IDxhIGhyZWY9InNpcGNvcmVAaWV0Zi5vcmciPnNpcGNvcmVAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0 OyBTdWJqZWN0OiBSZTogW3NpcGNvcmVdIHJlYm9vdGluZyBsb2NhdGlvbi1jb252ZXlhbmNlPGJy Pg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEluIHRoZSBlbWVyZ2VuY3kgc2VydmljZXMgY2Fz ZSwgSSB3b3VsZCBub3QgaW1hZ2luZTxicj4NCiZndDsgaW50ZXJtZWRpYXJpZXMgd291bGQgY29u ZmluZSB0aGVtc2VsdmVzIHRvIHRoZSByb2xlIG9mIHByb3h5PGJyPg0KJmd0OyBzZXJ2ZXJzIC0g aWYgdGhleSBkb24ndCBsaWtlIHRoZSBsb2NhdGlvbiBhdHRhY2hlZCB0byBhPGJyPg0KJmd0OyBt ZXNzYWdlLCBJJ20gc3VyZSB0aGV5J2QganVzdCByZW1vdmUgaXQsIGluc2VydCB0aGVpciBvd24g YW5kPGJyPg0KJmd0OyBmb3J3YXJkIHRoZSByZXF1ZXN0LiBXaHkgd291bGQgd2UgZXhwZWN0IHRo ZW0gdG8gZG8gb3RoZXJ3aXNlPzxicj4NCiZndDs8YnI+DQomZ3Q7IFRoZSB3YXkgdGhlIGxvY2F0 aW9uLWNvbnZleWFuY2UgbWVjaGFuaXNtIHdvcmtzIG5vdyAtIHdoZXJlLDxicj4NCiZndDsgaW4g dGhhdCBjYXNlLCB0aGUgaW50ZXJtZWRpYXJ5IHJlbW92ZXMgdGhlIGNpZCBwb2ludGVyIHRvIHRo ZTxicj4NCiZndDsgTUlNRSBib2R5IGl0IGRvZXNuJ3QgbGlrZSwgYnV0IGxlYXZlcyB0aGUgTUlN RSBib2R5IGluIHRoZTxicj4NCiZndDsgcmVxdWVzdCBhbmQgcHJvdmlkZXMgYSBuZXcgVVJMIHRv IHRoZSBwcmVmZXJyZWQgbG9jYXRpb248YnI+DQomZ3Q7IGluZm9ybWF0aW9uIC0gc2VlbXMgbGlr ZSBpdCBpcyBhbiBldmVuIHdvcnNlIHdheSBvZjxicj4NCiZndDsgYWNjb21wbGlzaGluZyB0aGUg YWltcyBvZiBhbiBlbWVyZ2VuY3kgc2VydmljZXMgaW50ZXJtZWRpYXJ5LDxicj4NCiZndDsgYW5k IG9uZSB0aGF0IHN1cmVseSB3b3VsZCBiZSBzdXBwbGFudGVkIGluIGRlcGxveW1lbnRzIGJ5PGJy Pg0KJmd0OyBzb21lIGtpbmQgb2Ygc3BlY2lhbC1wdXJwb3NlIGludGVybWVkaWFyeSB0aGF0IGRv ZXNuJ3Q8YnI+DQomZ3Q7IGNvbmZvcm0gdG8gdGhlIHN0YW5kYXJkLjxicj4NCiZndDs8YnI+DQom Z3Q7IEluIHRoZSBlbWVyZ2VuY3kgc2VydmljZXMgY2FzZSwgd2UgbmVlZCB0byBkbyBzZXZlcmFs IHRoaW5nczxicj4NCiZndDsgd2Ugd291bGRuJ3QgZG8gb3RoZXJ3aXNlLCBzdWNoIGFzIGlnbm9y aW5nIHNvbWUgY2xhc3NlcyBvZjxicj4NCiZndDsgc2VjdXJpdHkgdmlvbGF0aW9ucyBiZWNhdXNl IHRoZSBjb25zZXF1ZW5jZXMgb2Ygbm90PGJyPg0KJmd0OyBwcm9jZXNzaW5nIGEgY2FsbCBhcmUg c28gZGlyZSB0aGF0IHdlIG5lZWQgdG8gYmUgZ2VuZXJvdXMgaW48YnI+DQomZ3Q7IHdoYXQgd2Ug YWNjZXB0LiBUaGUgcmVhbCBxdWVzdGlvbiBpcyBpZiB0aGUgc3RlYWRpbHktZ3Jvd2luZzxicj4N CiZndDsgc2V0IG9mIHBhcmFtZXRlcnMgdGhhdCBoYXZlIGJlZW4gZGVmaW5lZCBpbiB0aGUgZHJh ZnQgdG8gdGhpczxicj4NCiZndDsgcG9pbnQgYWN0dWFsbHkgc2VydmUgdGhlIHByYWN0aWNhbCBy ZXF1aXJlbWVudHMgZm9yIGVtZXJnZW5jeTxicj4NCiZndDsgc2VydmljZXMgb3Igb3RoZXIgdXNl IGNhc2VzLjxicj4NCiZndDs8YnI+DQomZ3Q7IEpvbiBQZXRlcnNvbjxicj4NCiZndDsgTmV1U3Rh ciwgSW5jLjxicj4NCiZndDs8YnI+DQo8c3BhbiBzdHlsZT0nY29sb3I6IzI0NDA2MSc+4oCmPC9z cGFuPiA8L3NwYW4+PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9ib2R5 Pg0KDQo8L2h0bWw+DQo= --_000_8B0A9FCBB9832F43971E38010638454F03E24ED44ESISPE7MB1comm_-- From mary.ietf.barnes@gmail.com Fri Mar 26 14:13:06 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BA7E3A6BFB for ; Fri, 26 Mar 2010 14:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.968 X-Spam-Level: X-Spam-Status: No, score=0.968 tagged_above=-999 required=5 tests=[AWL=-0.162, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 3Vz68EL9XzjS for ; Fri, 26 Mar 2010 14:13:02 -0700 (PDT) Received: from mail-iw0-f191.google.com (mail-iw0-f191.google.com [209.85.223.191]) by core3.amsl.com (Postfix) with ESMTP id 520F23A6B45 for ; Fri, 26 Mar 2010 14:13:01 -0700 (PDT) Received: by iwn29 with SMTP id 29so4948208iwn.17 for ; Fri, 26 Mar 2010 14:13:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:received:message-id :subject:from:to:content-type; bh=aVd9c/bf7sWMtuM2Xj3wU/DbyqisuT94yn7qAVW7m9k=; b=a9qaJXQNtsQEeNsyZBzcKrt9G2xXIGfNllBvZIev//qIiMgnZXsX9ZT+N+XBcnNA8a j/VyicurP1HV2PDbx7f8IK+k+karOp4H+f4Hb4gACCWTbJc2WGKb/cUvng4wc4XJGwh2 QCiXwBLMcWnQIvuS2AmwcAs/ye/ZpkKR+xLkg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=oj4U8tqIJX7Yq/7PxjBjDXP0eH93ZT7dPQNZcDJMUhy36mLZk4AkDOt3N5ddJ0ITMA DLoIabDwQnHH/BaMF4tyRWB/G2zVUwLUjBRzMcHguFnb9iOnYZjMBQc69LTSjD1+E2eb 5pGWBbQcfZ60b8V5P2U9WFMaj760etdhnH4d8= MIME-Version: 1.0 Received: by 10.231.169.65 with HTTP; Fri, 26 Mar 2010 14:13:22 -0700 (PDT) Date: Fri, 26 Mar 2010 16:13:22 -0500 Received: by 10.231.174.147 with SMTP id t19mr689991ibz.74.1269638002271; Fri, 26 Mar 2010 14:13:22 -0700 (PDT) Message-ID: <184b5e71003261413t5b65c644y6b08f96a23c065b@mail.gmail.com> From: Mary Barnes To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1 Subject: [sipcore] Mary's notes from SIPCORE session on Friday, March 26 13:00-14:00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2010 21:13:06 -0000 Below are my raw notes from the IETF-77 Friday SIPCORE session. Mary. ================================================================================ Table 2 (Adam): ----------------------- Call for consensus: 1. All documents defining new header fields and methods...define in semantics and no longer table 2. 2. Produce an RFC that defines new procesdures for adding elements to table 2 as a new header field and methods Discussion of what would be for the form for item 2: - Adam: we're not defining this yet. - Keith: what will be the form for item 2. webpage? Adam: No. - Adam: it could be an RFC. - Jonathan Lennox: can we write a document that says that table 2 is no longer normative. Adam: not deciding that yet. Consensus call: - Overwhelming hum for item 1. [Note: one in jabber room also support item 1] Gonzalo: let's make sure that we don't just go update things for completeness - address when there are real (e.g., interop problems) Options (Christer) -------------------------- Procedural Problems: [Note: potential gap in notes 13:15-13:20] 1) Proc Problem: response code. 3261 states that response code should be the same in an INVITE Q: does this mean the OPTIONS request should be rejected if the UAS is currently in a call and would reject an INVITE? Proposal: Clarify that OPTIONS is about returning general capabilities. Discussion: Adam: agree with John E. - we need to have a meta discussion before we dive. But, other aspects of options are dependent on call state. Christer: we need to provide guidance on this. 2) Proc Problem: to tag. If the OPTIONS request contains a TO tag, but no associated dialog exists, procs seem to allow both 481 and 200 responses and even cause dialog to be recreated. Q: Do we need to clarify behavior Proposal: If dialog does not exist, return a 481. Discussion: Keith: if you use 481, then you're just dropping. Suggests that you can still allow folks to respond to OPTIONS, then use 200 (per previous chart) - if you didn't want to respond to options then you can send whatever you want. Christer: asks for clarification. Robert: Keith isn't arguing against this case. This isn't special about OPTIONS. Brett: Lack of clarity (ie. not requiring 481) Robert: suggests that Brett is implying to be careful with RFC 5057 implications General comment: Adam - doesn't want to focus so much on details - wants to figure out if group wants to work on problem. 3) Problem: Accept-contact. 3841 states that a request can be rejected if UAS doesn't suipport feature tags in Accept-contact Forking problems: [refer to charts for details] Questions: 1) How does proxy make a decision whether to return 3xx or fork? Proposal: use Request-Disposition:redirect Issue: if there is no RD header, does proxy still return 3xx or assume default RD. 2) Does proxy return contact addr/gruu of the UAS(s) or something that hides addresses Proposal: Policy decision 3) If OPTIONS request contains Accept-contact with capability feature tags, does the proxy only return contacts for UAS that matches capabilities? Proposal: Yes. Discussion: Adam: get back to general discussion of whether group wants to work on this. Way Forward options: 1) Do nothing. Adam: reworded do we want to work on this at all - doesn't imply everything is clear) 2) BCP clarifying issues. Adam: this is too specific - do we want to solve this problem at all? Discussion: John E: not certain yet. But do something simple with 2 - more inline with warnings, etc. Cullen: don't think we can get consensus on any of these problems. Don't see a compelling problem. Prefers alternative 1) James P: [missed this point] Hadriel: hasn't seen these as problems - these are more features. Prefers option 1. Christer: even if we go with option 1 - is there someone that thinks there is a problem? Hadriel: has never seen a 3xx to an OPTIONS. Christer: some folks need this, though. Peanut Gallery: if you use proxies and not SBCs, you do see this. Hadriel: to get the feature you want, you need a new capability - not an interop problem Brett: Don't think this can be useful to capture things in a way that pre-conditions did. Christer: agree - you need something else if you want to do beyond what options does. Brett: example of simring ... you can't guarantee subsequent invite would be routed the same. Adam: we're back to discussing fiddly bits - need to discuss meta issue. Robert: tangental point - wants to raise level of awareness on the use of the BCP acronym. There will be mounting pushback on the use of BCPs that are really INFO. Keith: Will we have an Internet draft for the next discussion? Adam: most folks are aware of this from ML discussion. Conclusion: None - take discussion to the list. Draft-sipcore-location-conveyance (Jon P): -------------------------------------------------------------- Proposing to simply - there's been a gradual accumulation of parms, error codes, etc. - reduce to cover only necessary cases - Improve predictability from the perspective of the UA Important use cases: - Proxies asserting location Propose to go back to UA just inserting PIDF-LO and proxy can change or add to. All the parms, etc. on who added what can be included in PIDF-LO, thus architectural separation from SIP. If we do this... - no need for "used-for-routing", "inserted-by", etc. [Refer to charts] Discussion: James W: right now can support a Location URI and a PIDF LO. John E: have we considered the possibility of looping? Jon P: sure we did account for that. The possibility to reject is necessary for a number of cases. John E: if flow itself includes an indication. Jon P: don't think we need new stuff, just new language. Keith: this is not a good idea. There are use cases that we are needing to support. Jon P: you haven't elucidated use case. Keith: in an emergency call, if UAC inserts a location. The network adds to that. Wants the functionality of both. Jon P: walks through - in example on chart 4, both original and corrected location are included in PIDF LO Keith: what if UAC doesn't include a header, would that also use a 424. Jon P: if you think UAC supports geo location, then you could use 424. Hadriel: nice idea in theory, but there's already stuff that is deployed. In reality, UAs don't support "jack". Jon P: don't think specialized intermediaries are going to listen to anything that we say. They just want location expediently. They'll chop and dice how they want. Hadriel: want to change mechanism but not use case? Jon P: want to remove mechanisms for that use case that won't be used Hadriel: people (proxies) are inserting PIDF LO and just forwarding it along. The guy that is receiving this stuff should be the one doing all the work to get the information. Jon P: you don't really care about these headers being removed since they're included in PIDF LO (i.e., who inserted). Anything that SIP doesn't need for routing should be in PIDF-LO Christer: if UA doesn't support 424, UA won't add the new location in the PIDF LO. Is proxy happy if it just has one location that it wants (i.e., ignore others) Jon P: that's always been a problem. Only changing syntax and not semantics James P: for Christer's concern, as long as a proxy's location is included, then other doesn't matter Martin Thomson: haven't been convinced by any arguments against proposal. May be problems with stuff that is already deployed. James W: only concern is around strong language about what should be included...need to keep some of that. James P: there can be multiple PIDF LOs in request. Maybe should do a 403...This might be okay if you agree to accept limitations. Cullen: ..concern over end quality of what gets deployed. Thinks this is far simpler - easier to get right. Understand impact on what's existingly deployed. This should finish much sooner than what we have now. Conclusion: Good discussion ... need to drive this to conclusion. From christer.holmberg@ericsson.com Fri Mar 26 20:50:46 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E20E3A6C83 for ; Fri, 26 Mar 2010 20:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.124 X-Spam-Level: X-Spam-Status: No, score=-1.124 tagged_above=-999 required=5 tests=[AWL=-2.255, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 leyY-B2OoYtO for ; Fri, 26 Mar 2010 20:50:45 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 696E13A6C55 for ; Fri, 26 Mar 2010 20:50:45 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-9b-4bad80ac3ab2 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 88.35.23740.CA08DAB4; Sat, 27 Mar 2010 04:51:08 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Sat, 27 Mar 2010 04:51:07 +0100 From: Christer Holmberg To: Dean Willis Date: Sat, 27 Mar 2010 04:51:08 +0100 Thread-Topic: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] Thread-Index: AcrMRrhMz8+P4+ABQIOv67jGkTMviwA4h2k7 Message-ID: References: <4B918DED.6090108@cisco.com> , <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <001a01cabe3e$e7033f80$b509be80$@com> <4B950BC0.5090601@cisco.com> <0BD9B443-C89F-4D16-819D-C35D74BAFD1B@softarmor.com> <4B9531DA.7050002@cisco.com> <50DAE276-5E08-4760-9FCC-035BEFF2C470@softarmor.com> , <4BA974D2.7010108@softarmor.com> , <4BABA77B.90906@softarmor.com> In-Reply-To: <4BABA77B.90906@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: 'SIPCORE' , Gilad, Shaham Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Mar 2010 03:50:46 -0000 Hi, >>> No, I'm suggesting that all of the forks respond with a 200 OK and >>> move to a connected state, not just the first fork to respond. It's >>> not a race, and there is NO early media -- just media being sent >>> before the PSTN side of the gateway moves to a fully-connected >>> state. >>> >>> Sorting out multiple media streams is a separate problem, but there >>> are ways to automate many cases in a B2BUA or really smart UA. >>> >>> But this breaks the business model, which assumes that everything >>> everywhere is fully-connected and in a "billing starts" state when >>> the first 200OK flies. >> >> But, what problem would that solve? >> >> The only difference is in what state you are (established-dialog >> instead of early-dialog), but you still have the same problem as >> duing the early dialog phase: you might receive early media from >> multiple locnennations. >> > > >It's not "early media" if it is in an established dialog. True. But I don't understand why that is relevant in this context. The prob= lem is that you are receiving media from multiple locations, so I don't see= how it matters whether you are in the early dialog phase or not. >Once you have a full dialog, you can do things like send a "BYE" I don't remember if you're allowed to send BYE in the forward direction on = an early dialog (you cannot send it in the backward direction, which is one= reason we have this wonderful thing called 199 :), but if you can't you ca= n always send a new offer with "inactive" (eventhough the early dialog itse= lf will not be terminated). However, I am not sure you always want to terminate dialogs. Just because y= ou don't "like" the before-the-remote-user-has-picked-up-the-hook media it = doesn't mean you necessarily want to terminate the whole dialog. >have a bot do a verbal challenge-response on the media path, Why can't you do that with early media?=20 > play one channel to the left ear and one to the right, You can do that with early dialogs also. And, if the user have to listen at both channels at the same time, it is st= ill going to be messy even you use "stereo". >play all of the media flows simultaneously with variable volume weighting = using a hover-touch over a >per-session icon (click to pick "this call" and drop the other ones), Sure, it may work with geeky users using fancy equipment. It doesn't work for PSTN (DTMF is the best you can get there), and I don't = think it would work with the average user who just wants to make a call. And, again, you may not even have enough bandwidth to forward media to the = calling user in the first place. I don't think networks are designed that w= ay. >etc. But "early media" messes everything up. Simultanous media from multiple remote locations messes things up. Regards, Christer= From christer.holmberg@ericsson.com Fri Mar 26 21:06:04 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 390DA3A6C56 for ; Fri, 26 Mar 2010 21:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.983 X-Spam-Level: X-Spam-Status: No, score=-0.983 tagged_above=-999 required=5 tests=[AWL=-2.114, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 mGcdaata-Y2u for ; Fri, 26 Mar 2010 21:06:03 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 0DCFB3A6832 for ; Fri, 26 Mar 2010 21:06:02 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-bb-4bad84423352 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 25.95.23740.2448DAB4; Sat, 27 Mar 2010 05:06:26 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sat, 27 Mar 2010 05:06:25 +0100 From: Christer Holmberg To: Dean Willis , Paul Kyzivat Date: Sat, 27 Mar 2010 05:06:24 +0100 Thread-Topic: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] Thread-Index: AcrMR8uaNIhSsBurQRanc5HC/gT0CwBGRX1D Message-ID: References: <4B918DED.6090108@cisco.com> , <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <4BA94A93.4010909@cisco.com> <4BA9739B.9060903@softarmor.com> <4BA98D4C.4060707@cisco.com>,<4BABA93C.2010402@softarmor.com> In-Reply-To: <4BABA93C.2010402@softarmor.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Mar 2010 04:06:04 -0000 Hi, >>Its really only parallel forking thats a problem, so we can probably igno= re serial forking. > >Not really. Early media is always a problem. How do you tell it to stop wi= thout whacking all your forks? "inactive". Some anouncement based services also use DTMF control to control the media. >>For parallel forking, moving it from the proxy to the UAC doesn't really = solve the problem - you can still end up with=20 >>multiple media streams and no clue what to do with them. > >Knowing which stream is which lets you do MORE things than you can with >just a bunch of garbled media coming in. Knowing which stream is which - AND knowing something about the content of = the media. >>You can say "don't do that", but there are desirable features that >>depend on it - namely "simultaneous ring". Potentially that can be >>replaced with presence-sensitive ringing to choose the *right* on to >>ring first, but that requires data that often isn't available. > >Google Voice does simultaneous ring quite nicely. If you call my GV >number, it will ring all my phones. If somebody answers a phone, GV will >say "Press 1 to accept a call from Paul Kyzivat", and if I press 1, GV >will terminate the other forks. But, at that poing the call has been answered by Paul. It is whatever happe= ns before that (no matter whether the call, from a SIP perspective, is in t= he early dialog phase or not) that is the problem. >Webster did this years ago using the dynamicsoft stuff as a call controlle= r. > >But to do this kind of work, the call controller needs signaling control >on each fork, which you don't get with early media. It does if you create a dialog, using 18x (or, as you suggest, 200) before = playing the media. (The fact that SIP allows media to be sent before any response has been sen= t is a bug, in my opinion.) >>> Offerless INVITEs help more, since the media can't come back to you >>> until the O/A has completed. >> >> That is just sticking your head in the sand. The media is still being >> generated, even if you don't know about it. > >No, really. They CANNOT send you media until you've sent your SDP. If >you don't send your SDP (in the ACK) until they have sent theirs (in the >200OK), then there is NO EARLY MEDIA. > >Yes, this means that PSTN gateways would have to complete ACK before >doing IAM on the PSTN side. I'm OK with that. But, if the ACK is sent to multiple remote destinations at the same time yo= u are still going to end up with the same media-from-multiple-locations pro= blem - it will just occur a little later. If you do NOT want to send ACK to multiple remote destinations at the same = time, you can as well to serial forking to start with. >>It does have the advantage that you can associate the media stream to >>the signaling source, but it still doesn't tell you which stream is >>interesting to listen to. > >But having associated signaling lets you do things to decide which one >is interesting. Having signalling which gives information about the content of the media, y= es. I agree that would be useful. But, using your offerless-INVITE-mechanish is not going to give you any mor= e information about the content of the media. It only allows you to not rec= eive media until you've sent the ACK. >>ISTM that if you want "simultaneous ring", and the things ringing are >>often PSTN devices, there is still no solution. Perhaps there is some >>possibility of automated media analysis - the pstn GW figuring out that >>the media being received is something uninteresting - just conventional >>ringback - and suppressing it. But thats a lot of trouble and is likely >>to have a high error rate. > >Go play with Google Voice or something like it for awhile and then get >back to us. Does GV have the possibility to receive media (other than "meaningless" rin= gtones) from multiple locations? Regards, Christer= From christer.holmberg@ericsson.com Fri Mar 26 21:12:55 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 901003A6882 for ; Fri, 26 Mar 2010 21:12:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 Os+ArgfXcY9S for ; Fri, 26 Mar 2010 21:12:54 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id C45E83A6872 for ; Fri, 26 Mar 2010 21:12:53 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-db-4bad85dc719c Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 4E.54.23532.CD58DAB4; Sat, 27 Mar 2010 05:13:16 +0100 (CET) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Sat, 27 Mar 2010 05:13:16 +0100 From: Christer Holmberg To: "gao.yang2@zte.com.cn" , Dean Willis Date: Sat, 27 Mar 2010 05:10:20 +0100 Thread-Topic: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] Thread-Index: AcrMXRDlkri7MDzBTReIe+Rq1KX8SgBBllWZ Message-ID: References: <4BABA93C.2010402@softarmor.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Mar 2010 04:12:55 -0000 Hi, >IMO, if the caller's UE is as strong as Google Voice and it's software, th= e network can just render all the early media to it. >So, the key problem is about UE with less capability. > >I still think it is BCP thing. I once said how my equipment handle this in= the mail(http://www.ietf.org/mail->archive/web/sipcore/current/msg02114.ht= ml). > >BTW, doing this can make PSTN user having the same experience as GV: >PSTN gateway(such as MGCF in IMS) terminate the multiple forked early medi= a and just send only one to the PSTN user. And >using DTMF, the user can switch from one voice to another by press the num= ber key. That could work if the media isn't actually played until it is "chosen" (us= ing DTMF). If the early media A and B is played at the same time, the user = will miss B while listening to A, and when the user switches to B the messa= ge may already be over... Regards, Christer Paul Kyzivat wrote: > Its really only parallel forking thats a problem, so we can probably > ignore serial forking. Not really. Early media is always a problem. How do you tell it to stop without whacking all your forks? > > For parallel forking, moving it from the proxy to the UAC doesn't really > solve the problem - you can still end up with multiple media streams and > no clue what to do with them. Knowing which stream is which lets you do MORE things than you can with just a bunch of garbled media coming in. > > You can say "don't do that", but there are desirable features that > depend on it - namely "simultaneous ring". Potentially that can be > replaced with presence-sensitive ringing to choose the *right* on to > ring first, but that requires data that often isn't available. Google Voice does simultaneous ring quite nicely. If you call my GV number, it will ring all my phones. If somebody answers a phone, GV will say "Press 1 to accept a call from Paul Kyzivat", and if I press 1, GV will terminate the other forks. Webster did this years ago using the dynamicsoft stuff as a call controller= . But to do this kind of work, the call controller needs signaling control on each fork, which you don't get with early media. >> Offerless INVITEs help more, since the media can't come back to you >> until the O/A has completed. > > That is just sticking your head in the sand. The media is still being > generated, even if you don't know about it. No, really. They CANNOT send you media until you've sent your SDP. If you don't send your SDP (in the ACK) until they have sent theirs (in the 200OK), then there is NO EARLY MEDIA. Yes, this means that PSTN gateways would have to complete ACK before doing IAM on the PSTN side. I'm OK with that. > It does have the advantage that you can associate the media stream to > the signaling source, but it still doesn't tell you which stream is > interesting to listen to. But having associated signaling lets you do things to decide which one is interesting. > ISTM that if you want "simultaneous ring", and the things ringing are > often PSTN devices, there is still no solution. Perhaps there is some > possibility of automated media analysis - the pstn GW figuring out that > the media being received is something uninteresting - just conventional > ringback - and suppressing it. But thats a lot of trouble and is likely > to have a high error rate. Go play with Google Voice or something like it for awhile and then get back to us. -- Dean _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is = solely property of the sender's organization. This mail communication is co= nfidential. Recipients named above are obligated to maintain secrecy and ar= e not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the originator of th= e message. Any views expressed in this message are those of the individual = sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. From dean.willis@softarmor.com Mon Mar 29 16:53:27 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC64C3A686C for ; Mon, 29 Mar 2010 16:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.899 X-Spam-Level: X-Spam-Status: No, score=0.899 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 isdfmoqTDu6d for ; Mon, 29 Mar 2010 16:53:27 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 3CCC63A6774 for ; Mon, 29 Mar 2010 16:53:27 -0700 (PDT) Received: from [192.168.2.101] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2TNrndY009533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Mar 2010 18:53:51 -0500 From: Dean Willis To: Christer Holmberg In-Reply-To: References: <4B918DED.6090108@cisco.com> , <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <001a01cabe3e$e7033f80$b509be80$@com> <4B950BC0.5090601@cisco.com> <0BD9B443-C89F-4D16-819D-C35D74BAFD1B@softarmor.com> <4B9531DA.7050002@cisco.com> <50DAE276-5E08-4760-9FCC-035BEFF2C470@softarmor.com> ,<4BA974D2.7010108@softarmor.com> ,<4BABA77B.90906@softarmor.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 29 Mar 2010 18:53:43 -0500 Message-ID: <1269906823.2312.2.camel@damnable-lx> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Cc: 'SIPCORE' , Gilad Shaham Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 23:53:28 -0000 On Sat, 2010-03-27 at 04:51 +0100, Christer Holmberg wrote: > > True. But I don't understand why that is relevant in this context. The > problem is that you are receiving media from multiple locations, so I > don't see how it matters whether you are in the early dialog phase or > not. > The problem is not just that you are receiving media from multiple locations. It's that you're receiving data from multiple locations, you don't know who those locations are or anything else about them, and you have no way to stop the media nor manipulate it in any useful way besides just discarding it. -- Dean From dean.willis@softarmor.com Mon Mar 29 16:59:48 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC8583A6ACE for ; Mon, 29 Mar 2010 16:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.917 X-Spam-Level: X-Spam-Status: No, score=0.917 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 UXcSDonYH9rv for ; Mon, 29 Mar 2010 16:59:47 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id A96A43A6774 for ; Mon, 29 Mar 2010 16:59:47 -0700 (PDT) Received: from [192.168.2.101] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id o2U00B0T009583 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 29 Mar 2010 19:00:12 -0500 From: Dean Willis To: Christer Holmberg In-Reply-To: References: <4B918DED.6090108@cisco.com> ,<4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <4BA94A93.4010909@cisco.com> <4BA9739B.9060903@softarmor.com> <4BA98D4C.4060707@cisco.com>,<4BABA93C.2010402@softarmor.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 29 Mar 2010 19:00:03 -0500 Message-ID: <1269907203.2312.9.camel@damnable-lx> Mime-Version: 1.0 X-Mailer: Evolution 2.28.1 Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2010 23:59:48 -0000 On Sat, 2010-03-27 at 05:06 +0100, Christer Holmberg wrote: > Hi, > > >>Its really only parallel forking thats a problem, so we can probably ignore serial forking. > > > >Not really. Early media is always a problem. How do you tell it to stop without whacking all your forks? > > "inactive". You can't send it an inactive because it hasn't sent you an answer yet, so you can't target that fork with an inactive. > > Some anouncement based services also use DTMF control to control the media. > > >>For parallel forking, moving it from the proxy to the UAC doesn't really solve the problem - you can still end up with > >>multiple media streams and no clue what to do with them. > > > >Knowing which stream is which lets you do MORE things than you can with > >just a bunch of garbled media coming in. > > Knowing which stream is which - AND knowing something about the content of the media. > > >>You can say "don't do that", but there are desirable features that > >>depend on it - namely "simultaneous ring". Potentially that can be > >>replaced with presence-sensitive ringing to choose the *right* on to > >>ring first, but that requires data that often isn't available. > > > >Google Voice does simultaneous ring quite nicely. If you call my GV > >number, it will ring all my phones. If somebody answers a phone, GV will > >say "Press 1 to accept a call from Paul Kyzivat", and if I press 1, GV > >will terminate the other forks. > > But, at that poing the call has been answered by Paul. It is whatever happens before that (no matter whether the call, from a SIP perspective, is in the early dialog phase or not) that is the problem. > > >Webster did this years ago using the dynamicsoft stuff as a call controller. > > > >But to do this kind of work, the call controller needs signaling control > >on each fork, which you don't get with early media. > > It does if you create a dialog, using 18x (or, as you suggest, 200) before playing the media. > > (The fact that SIP allows media to be sent before any response has been sent is a bug, in my opinion.) > > >>> Offerless INVITEs help more, since the media can't come back to you > >>> until the O/A has completed. > >> > >> That is just sticking your head in the sand. The media is still being > >> generated, even if you don't know about it. > > > >No, really. They CANNOT send you media until you've sent your SDP. If > >you don't send your SDP (in the ACK) until they have sent theirs (in the > >200OK), then there is NO EARLY MEDIA. > > > >Yes, this means that PSTN gateways would have to complete ACK before > >doing IAM on the PSTN side. I'm OK with that. > > But, if the ACK is sent to multiple remote destinations at the same > time you are still going to end up with the same > media-from-multiple-locations problem - it will just occur a little > later. There's a difference between having multiple active dialogs, each with related media, and having a bunch of early-media streams just coming at you outside of a dialog context. In this case, it's a different set of ACKs -- the caller could, for example, serialize the acks and resort the order based on application-determined probability of an interesting result. Or pick one to play to the user and three more to hand to a challenge-response bot just in case a human answers. > But, using your offerless-INVITE-mechanish is not going to give you any > more information about the content of the media. It only allows you to > not receive media until you've sent the ACK. Which gives you the "identity" aof the fork-terminator and any further related information that might be available before sending the ACK. > Does GV have the possibility to receive media (other than > "meaningless" ringtones) from multiple locations? > Yes. It uses an IVR to challenge the recipient and decide which fork to "complete". -- Dean From christer.holmberg@ericsson.com Mon Mar 29 19:53:35 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C7913A685A for ; Mon, 29 Mar 2010 19:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.842 X-Spam-Level: X-Spam-Status: No, score=-2.842 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 O+36gUOcLmD7 for ; Mon, 29 Mar 2010 19:53:34 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 0B5413A63EB for ; Mon, 29 Mar 2010 19:53:33 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-6b-4bb167c87db6 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id CE.AC.23532.8C761BB4; Tue, 30 Mar 2010 04:54:00 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 30 Mar 2010 04:54:00 +0200 From: Christer Holmberg To: 'Dean Willis' Date: Tue, 30 Mar 2010 04:53:58 +0200 Thread-Topic: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] Thread-Index: AcrPmxfxNGJrY5RqSwaUpnVqjPEsVwAGKAjQ Message-ID: References: <4B918DED.6090108@cisco.com> , <4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <001a01cabe3e$e7033f80$b509be80$@com> <4B950BC0.5090601@cisco.com> <0BD9B443-C89F-4D16-819D-C35D74BAFD1B@softarmor.com> <4B9531DA.7050002@cisco.com> <50DAE276-5E08-4760-9FCC-035BEFF2C470@softarmor.com> ,<4BA974D2.7010108@softarmor.com> ,<4BABA77B.90906@softarmor.com> <1269906823.2312.2.camel@damnable-lx> In-Reply-To: <1269906823.2312.2.camel@damnable-lx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: 'SIPCORE' , Gilad, Shaham Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 02:53:35 -0000 Hi,=20 >>True. But I don't understand why that is relevant in this context. The =20 >>problem is that you are receiving media from multiple locations, so I =20 >>don't see how it matters whether you are in the early dialog phase or =20 >>not. >=20 >The problem is not just that you are receiving media from multiple locatio= ns. It's that you're receiving data from multiple locations, you don't know= who those locations are or anything else about them,=20 >and you have no way to stop the media nor manipulate it in any useful way = besides just discarding it. That is the case if you receive media before you have received ANY response= (18x or 200), yes, and personally I think it should not be allowed to send= media in that way. "Fortunately", in many environments, such early media w= ill never reach the UAC (due to gating procedures etc), so hopefully it wil= l encourage people not to send early media that way :) But, IF the UAS sends a 18x, and establishes an early dialog, I don't see t= he difference. Regards, Christer From christer.holmberg@ericsson.com Mon Mar 29 20:04:12 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2566A3A67FF for ; Mon, 29 Mar 2010 20:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.144 X-Spam-Level: X-Spam-Status: No, score=-4.144 tagged_above=-999 required=5 tests=[AWL=1.325, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 LY9s9nsLrq+k for ; Mon, 29 Mar 2010 20:04:11 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 08AFB3A67A2 for ; Mon, 29 Mar 2010 20:04:10 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-d5-4bb16a46bb12 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id BD.3D.23532.64A61BB4; Tue, 30 Mar 2010 05:04:38 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Tue, 30 Mar 2010 05:04:38 +0200 From: Christer Holmberg To: 'Dean Willis' Date: Tue, 30 Mar 2010 05:04:37 +0200 Thread-Topic: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] Thread-Index: AcrPm/sxuPzcV2XVTnSxEdtpMlyNlgAGFy4Q Message-ID: References: <4B918DED.6090108@cisco.com> ,<4B919413.60506@cisco.com> <4B93D8A6.1040105@cisco.com> <4BA94A93.4010909@cisco.com> <4BA9739B.9060903@softarmor.com> <4BA98D4C.4060707@cisco.com>,<4BABA93C.2010402@softarmor.com> <1269907203.2312.9.camel@damnable-lx> In-Reply-To: <1269907203.2312.9.camel@damnable-lx> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 03:04:12 -0000 Hi, >>>>Its really only parallel forking thats a problem, so we can probably ig= nore serial forking. >>> >>>Not really. Early media is always a problem. How do you tell it to stop = without whacking all your forks? >>=20 >>"inactive". > >You can't send it an inactive because it hasn't sent you an answer yet, so= you can't target that fork with an inactive. I think we talk about different "early media" scenarios. You talk about the case when there is NO answer coming from the UAS before = the early media, while I talk about the case when there IS an answer (recei= ved in a 18x) before the early media. I AGREE with the issues related to your case, and I have not been arguing a= gainst those :)=20 As I've said earlier, sending early media before an answer is not good, in = my opinion. I think the issue is that you and I have different solutions to that proble= m: you think that a 200 OK should be sent before any media is sent, while I= think it is enough to send a 18x. >>>Yes, this means that PSTN gateways would have to complete ACK before=20 >>>doing IAM on the PSTN side. I'm OK with that. >>>=20 >>But, if the ACK is sent to multiple remote destinations at the same =20 >>time you are still going to end up with the same =20 >>media-from-multiple-locations problem - it will just occur a little =20 >>later. > >There's a difference between having multiple active dialogs, each with rel= ated media, and having a bunch of early-media streams just coming at you ou= tside of a dialog context. I totally agree. Each media stream should have an associated dialog. But, t= hat dialog could be an early dialog. >>Does GV have the possibility to receive media (other than "meaningless" r= ingtones) from multiple locations? >=20 >Yes. It uses an IVR to challenge the recipient and decide which fork to "c= omplete". But, does it play the IVR message at the same time as the "ringtones" (whic= h could also be anouncements), or does it not even contact the remote termi= nals before the work to complete has been chosen? Regards, Christer From ivo.sedlacek@ericsson.com Mon Mar 29 23:11:04 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A467B3A69D0 for ; Mon, 29 Mar 2010 23:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.332 X-Spam-Level: X-Spam-Status: No, score=-1.332 tagged_above=-999 required=5 tests=[AWL=-1.722, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13] 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 d-KF08-ArqoV for ; Mon, 29 Mar 2010 23:11:03 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 5EE6E3A69B6 for ; Mon, 29 Mar 2010 23:10:59 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-a2-4bb1960eeeac Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 40.DA.23740.E0691BB4; Tue, 30 Mar 2010 08:11:26 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.86) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.1.375.2; Tue, 30 Mar 2010 08:11:26 +0200 Received: from ESESSCMS0359.eemea.ericsson.se ([169.254.1.67]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Tue, 30 Mar 2010 08:11:26 +0200 From: Ivo Sedlacek To: Paul Kyzivat Date: Tue, 30 Mar 2010 08:11:24 +0200 Thread-Topic: [sipcore] element in RFC 4235 Thread-Index: AcrNAeVpWjrle1mtTe+E++badb5NKgCzPzcw Message-ID: References: <4BACE18D.2090809@cisco.com> In-Reply-To: <4BACE18D.2090809@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] element in RFC 4235 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 06:11:04 -0000 Thanks for clarification. See comment at the end. Kind regards Ivo Sedlacek Ericsson Technology and Portfolio Management, Terminal Standardization Sweden Office: +46 10 711 9382 Fax: +46 10 713 5929 ivo.sedlacek@ericsson.com www.ericsson.com This communication is confidential. We only send and receive email on the b= asis of the term set out at www.ericsson.com/email_disclaimer -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 26. b=F8ezna 2010 17:32 > To: Ivo Sedlacek > Cc: sipcore@ietf.org > Subject: Re: [sipcore] element in RFC 4235 > > [as individual] > comment at end... > > Ivo Sedlacek wrote: > > Hello, > > > > Let's suppose that Alice called Bob and Bob forwarded the call to > > Cecil which accepted the call. > > When Alice's UE sent the INVITE, the To header was set to Bob's SIP > > URI (sip:bob@example.com). > > Cecil's network provided P-Asserted-Identity header set to Cecil's SIP > > URI (sip:cecil@example.com) in 2xx response. > > > > Now Duren subscribes to dialog event package at Alice's UE. > > Alice's UE generates dialog event package notification including the > > created dialog. > > > > Is the element of the element of the created > > dialog supposed to contain: > > 1) the original To header field URI (sip:bob@example.com); > > 2) the true identity of the participant (sip:cecil@example.com); or > > 3) none of them? > > > > RFC4235 states: > > > > ---------------------------------------------------------------------- > > ------------------------------- > > 4.1.6.1. Identity Element > > > > The "identity" element indicates a local or remote URI, as defined i= n > > [2] as appropriate. It has an optional attribute, display, that > > contains the display name from the appropriate URI. > > > > Note that multiple identities (for example a sip: URI and a tel: > > URI) could be included if they all correspond to the participant. > > To avoid repeating identity information in each request, the > > subscriber can assume that the identity URIs are the same as in > > previous notifications if no identity elements are present in the > > corresponding local or remote element. If any identity elements > > are present in the local or remote part of a notification, the ne= w > > list of identity tags completely supersedes the old list in the > > corresponding part. > > > > > > sip:anonymous@anonymous.invalid > > ---------------------------------------------------------------------- > > ------------------------------- > > > > remote URI as defined in [2] (RFC3261) is the original To header field > > URI (sip:bob@example.com). > > However, the original To header field URI does not correspond to the > > true remote participant (sip:cecil@example.com). > > Does "as appropriate" have any particular meaning? > > You mention Cecil's PAI being returned in the 2xx. The semantics of that = are not > defined in ietf. (I believe this usage *is* defined in IMS.) > > RFC 4916 (connected identity) defines a mechanism to deliver that back to= the caller > in a request. If 4916 is used, the actual remote identity that is part of= dialog > state according to 3261 will be changed, and presumably will then be repo= rted in > the notify. > > The impact of PAI on returns from the dialog event package is, AFAIK, und= efined. > (Does IMS define it?) > > Thanks, > Paul IMS (so far) does not define any further rules above RFC 4235 on what to pu= t in the dialog event package notification body. From adam@nostrum.com Tue Mar 30 11:38:09 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2ACB63A684B for ; Tue, 30 Mar 2010 11:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.82 X-Spam-Level: X-Spam-Status: No, score=-0.82 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, SPF_PASS=-0.001] 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 Hzuf7BhkOFmr for ; Tue, 30 Mar 2010 11:38:08 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id A174E3A67AC for ; Tue, 30 Mar 2010 11:38:07 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o2UIcTSZ056522 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Mar 2010 13:38:29 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BB24525.7040006@nostrum.com> Date: Tue, 30 Mar 2010 13:38:29 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] Minutes Posted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 18:38:09 -0000 [as chair] A draft version of the minutes from the recent IETF meeting in Anaheim has been posted to the proceedings site: http://www.ietf.org/proceedings/10mar/minutes/sipcore.html Please review the minutes and submit any corrections to the chairs no later than April 15th. Thank you. /a From adam@nostrum.com Tue Mar 30 11:50:55 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DC753A69E8 for ; Tue, 30 Mar 2010 11:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.264 X-Spam-Level: X-Spam-Status: No, score=0.264 tagged_above=-999 required=5 tests=[AWL=-0.867, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 BEBp+zh-ttmj for ; Tue, 30 Mar 2010 11:50:54 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 48FB83A694F for ; Tue, 30 Mar 2010 11:50:53 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o2UIpKeu057486 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Mar 2010 13:51:20 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BB24828.80805@nostrum.com> Date: Tue, 30 Mar 2010 13:51:20 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: SIPCORE Content-Type: multipart/alternative; boundary="------------030001080907000408040909" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] Consensus Call: SIP Table 2 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 18:50:55 -0000 This is a multi-part message in MIME format. --------------030001080907000408040909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [as chair] Last week, at the face-to-face meeting in Anaheim, the SIPCORE participants in attendance had a discussion regarding the future of Tables 2 and 3 in RFC 3261. A summary of the conversation, along with links to the presentations and an audio recording of the conversation, can be found in the minutes: http://www.ietf.org/proceedings/10mar/minutes/sipcore.html#SIP%20Table%202%20/%203 During that conversation, the chairs polled those present for support between two options: 1. Produce an artifact stating that documents defining new header fields and methods define semantics in prose, and will no longer extend Table 2; or 2. Produce an RFC that defines new procedures for adding elements to Table 2 as new header fields and methods are defined Among those present, there was strong support for option 1. If you wish to raise an objection to this direction, please do so on the SIPCORE mailing list before April 15th. Thank you. /a --------------030001080907000408040909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit [as chair]

Last week, at the face-to-face meeting in Anaheim, the SIPCORE participants in attendance had a discussion regarding the future of Tables 2 and 3 in RFC 3261. A summary of the conversation, along with links to the presentations and an audio recording of the conversation, can be found in the minutes:

http://www.ietf.org/proceedings/10mar/minutes/sipcore.html#SIP%20Table%202%20/%203

During that conversation, the chairs polled those present for support between two options:
  1. Produce an artifact stating that documents defining new header fields and methods define semantics in prose, and will no longer extend Table 2; or

  2. Produce an RFC that defines new procedures for adding elements to Table 2 as new header fields and methods are defined
Among those present, there was strong support for option 1. If you wish to raise an objection to this direction, please do so on the SIPCORE mailing list before April 15th.

Thank you.

/a
--------------030001080907000408040909-- From adam@nostrum.com Tue Mar 30 12:05:11 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD6BC3A6847 for ; Tue, 30 Mar 2010 12:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.11 X-Spam-Level: X-Spam-Status: No, score=0.11 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 deIMoNV3pDo4 for ; Tue, 30 Mar 2010 12:05:10 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 7683D3A6823 for ; Tue, 30 Mar 2010 12:05:10 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o2UJ5bC0073408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Mar 2010 14:05:37 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BB24B81.1050006@nostrum.com> Date: Tue, 30 Mar 2010 14:05:37 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: SIPCORE Content-Type: multipart/alternative; boundary="------------070406010406090507020301" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 19:05:11 -0000 This is a multi-part message in MIME format. --------------070406010406090507020301 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [as chair] One of the topics of discussion at the recent face-to-face meeting in Anaheim was the SIP OPTIONS method. We have had significant discussion of some specific technical topics on the SIPCORE mailing list, such that all participants should have a reasonable overview of the scope that any related work may entail. Participants may also benefit from reading through the minutes of the corresponding conversation in Anaheim: http://www.ietf.org/proceedings/10mar/minutes/sipcore.html#The%20SIP%20OPTIONS%20Method Rather than continue discussion of the specific technical topics related to OPTIONS, the chairs would encourage the working group to engage in a discussion around whether we should, as a group, work on addressing some of the issues that have been identified. In particular, we would direct the group to consider the nature of such work: * Are we proposing to introduce new features, or fix existing bugs? * If we are adding new features: is OPTIONS the best way to introduce these features, or would other mechanisms (presence, callee-caps) produce superior results? * If we are fixing bugs: are the bugs theoretical, or can we cite actual interoperability issues in the field? * If there are identified interoperability issues: is the level of effort involved in fixing them commensurate with the impact of the problems? Finally, keep in mind that work does not happen unless participants are willing to invest time. If you speak out in favor of pursuing this work, please indicate the level of time commitment that you will personally invest in bringing such work to a successful conclusion (e.g., will author drafts; will perform dedicated reviews; etc). Thanks. /a --------------070406010406090507020301 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit [as chair]

One of the topics of discussion at the recent face-to-face meeting in Anaheim was the SIP OPTIONS method. We have had significant discussion of some specific technical topics on the SIPCORE mailing list, such that all participants should have a reasonable overview of the scope that any related work may entail. Participants may also benefit from reading through the minutes of the corresponding conversation in Anaheim:

http://www.ietf.org/proceedings/10mar/minutes/sipcore.html#The%20SIP%20OPTIONS%20Method

Rather than continue discussion of the specific technical topics related to OPTIONS, the chairs would encourage the working group to engage in a discussion around whether we should, as a group, work on addressing some of the issues that have been identified.

In particular, we would direct the group to consider the nature of such work:
  • Are we proposing to introduce new features, or fix existing bugs?
  • If we are adding new features: is OPTIONS the best way to introduce these features, or would other mechanisms (presence, callee-caps) produce superior results?
  • If we are fixing bugs: are the bugs theoretical, or can we cite actual interoperability issues in the field?
  • If there are identified interoperability issues: is the level of effort involved in fixing them commensurate with the impact of the problems?
Finally, keep in mind that work does not happen unless participants are willing to invest time. If you speak out in favor of pursuing this work, please indicate the level of time commitment that you will personally invest in bringing such work to a successful conclusion (e.g., will author drafts; will perform dedicated reviews; etc).

Thanks.

/a
--------------070406010406090507020301-- From adam@nostrum.com Tue Mar 30 13:04:47 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48F1D3A6812 for ; Tue, 30 Mar 2010 13:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.537 X-Spam-Level: X-Spam-Status: No, score=0.537 tagged_above=-999 required=5 tests=[AWL=-0.594, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 XGdASNKSvQzO for ; Tue, 30 Mar 2010 13:04:45 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 596643A691C for ; Tue, 30 Mar 2010 13:04:44 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o2UK5CTm090890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 30 Mar 2010 15:05:12 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BB25978.3080701@nostrum.com> Date: Tue, 30 Mar 2010 15:05:12 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: SIPCORE Content-Type: multipart/alternative; boundary="------------000903020903090007000806" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] Mea Culpa: Dialog Necromancy in RFC 3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Mar 2010 20:04:47 -0000 This is a multi-part message in MIME format. --------------000903020903090007000806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [as participant] During the Anaheim meeting, I made an assertion that the optional feature of re-creating dialogs upon receipt of an in-dialog INVITE (i.e., one with a "To" tag) that did not match an ongoing dialog had been removed between RFC 2543 and RFC 3261. I was wrong. What I was recalling was a related change in handling; between 2543 and 3261, the creation of such zombie dialogs changed from mandatory to optional (instead of going from "optional" to "prohibited," as I mistakenly recalled). In 2543, the arrival of an apparently-in-dialog INVITE that didn't match an ongoing "call-leg" (dialog) would always create a new "call leg"; the called party had no way of rejecting the call with an indication that the associated "call leg" had been previously terminated (RFC 2543, section 10.1.1) -- the 481 response code had semantics only for CANCEL and BYE. In 3261, the UAS is given the _option_ of re-creating the dialog under such circumstances. From 3261, section 12.2.2: > If the request has a tag in the To header field, but the dialog > identifier does not match any existing dialogs, the UAS may have > crashed and restarted, or it may have received a request for a > different (possibly failed) UAS (the UASs can construct the To tags > so that a UAS can identify that the tag was for a UAS for which it is > providing recovery). Another possibility is that the incoming > request has been simply misrouted. Based on the To tag, the UAS MAY > either accept or reject the request. Accepting the request for > acceptable To tags provides robustness, so that dialogs can persist > even through crashes. UAs wishing to support this capability must > take into consideration some issues such as choosing monotonically > increasing CSeq sequence numbers even across reboots, reconstructing > the route set, and accepting out-of-range RTP timestamps and sequence > numbers. > > If the UAS wishes to reject the request because it does not wish to > recreate the dialog, it MUST respond to the request with a 481 > (Call/Transaction Does Not Exist) status code and pass that to the > server transaction. > In the interest of not digging into the actual details of the OPTIONS-related issues, I am intentionally refraining from commenting on the relationship between this behavior and the associated OPTIONS discussion topic from the Anaheim meeting. /a --------------000903020903090007000806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit [as participant]

During the Anaheim meeting, I made an assertion that the optional feature of re-creating dialogs upon receipt of an in-dialog INVITE (i.e., one with a "To" tag) that did not match an ongoing dialog had been removed between RFC 2543 and RFC 3261.

I was wrong.

What I was recalling was a related change in handling; between 2543 and 3261, the creation of such zombie dialogs changed from mandatory to optional (instead of going from "optional" to "prohibited," as I mistakenly recalled).

In 2543, the arrival of an apparently-in-dialog INVITE that didn't match an ongoing "call-leg" (dialog) would always create a new "call leg"; the called party had no way of rejecting the call with an indication that the associated "call leg" had been previously terminated (RFC 2543, section 10.1.1) -- the 481 response code had semantics only for CANCEL and BYE.

In 3261, the UAS is given the _option_ of re-creating the dialog under such circumstances. From 3261, section 12.2.2:

   If the request has a tag in the To header field, but the dialog
   identifier does not match any existing dialogs, the UAS may have
   crashed and restarted, or it may have received a request for a
   different (possibly failed) UAS (the UASs can construct the To tags
   so that a UAS can identify that the tag was for a UAS for which it is
   providing recovery).  Another possibility is that the incoming
   request has been simply misrouted.  Based on the To tag, the UAS MAY
   either accept or reject the request.  Accepting the request for
   acceptable To tags provides robustness, so that dialogs can persist
   even through crashes.  UAs wishing to support this capability must
   take into consideration some issues such as choosing monotonically
   increasing CSeq sequence numbers even across reboots, reconstructing
   the route set, and accepting out-of-range RTP timestamps and sequence
   numbers.

   If the UAS wishes to reject the request because it does not wish to
   recreate the dialog, it MUST respond to the request with a 481
   (Call/Transaction Does Not Exist) status code and pass that to the
   server transaction.

In the interest of not digging into the actual details of the OPTIONS-related issues, I am intentionally refraining from commenting on the relationship between this behavior and the associated OPTIONS discussion topic from the Anaheim meeting.

/a
--------------000903020903090007000806-- From gao.yang2@zte.com.cn Tue Mar 30 20:34:45 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D7553A6A01; Tue, 30 Mar 2010 20:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.83 X-Spam-Level: X-Spam-Status: No, score=-93.83 tagged_above=-999 required=5 tests=[AWL=-0.525, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] 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 qcTtOoV-6CtD; Tue, 30 Mar 2010 20:34:44 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id B181D3A6882; Tue, 30 Mar 2010 20:34:42 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 128642001811080; Wed, 31 Mar 2010 11:33:23 +0800 (CST) Received: from [192.168.168.1] by [192.168.168.16] with StormMail ESMTP id 86863.4472856207; Wed, 31 Mar 2010 11:32:25 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o2V3Y2HO083807; Wed, 31 Mar 2010 11:34:45 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: Christer Holmberg MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Wed, 31 Mar 2010 11:33:02 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-03-31 11:34:41, Serialize complete at 2010-03-31 11:34:41 Content-Type: multipart/alternative; boundary="=_alternative 0013A458482576F7_=" X-MAIL: mse2.zte.com.cn o2V3Y2HO083807 Cc: sipcore-bounces@ietf.org, SIPCORE Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 03:34:45 -0000 This is a multipart message in MIME format. --=_alternative 0013A458482576F7_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SU1PLCBhcyB0aGUgUFNUTidzIHRlcm1pbmFsIGhhcyBubyBhYmlsaXR5IHRvIGhhbmRsZSBtb3Jl IHRoYW4gb25lIGNoYW5uZWwgDQpvZiBtZWRpYSwgSSB0aGluayBpdCBpcyBoYXJkbHkgdG8gaGFu ZGxlIGl0IGJldHRlci4NCklmIHlvdSBoYXZlIG9uZSBiZXR0ZXIgc29sdXRpb24vc3VnZ2VzdGlv biwgcGxlYXNlIHNoYXJlIGl0IHRvIHVzLg0KDQpUaGVuLCBhYm91dCB0aGUgbm9ybWF0aXZlL0JD UCwgSSBwcmVmZXIgaXQgdG8gYmUgQkNQLCBhcyBob3cgdG8gaGFuZGxlIGl0IA0Kc2hvdWxkIGJl IG9wZW4gd2F5cy4NCg0KVGhhbmtzLA0KDQpHYW8NCg0KPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT0NCiBaaXAgICAgOiAyMTAwMTINCiBUZWwgICAgOiA4NzIxMQ0KIFRlbDIgICA6 KCs4NiktMDI1LTUyODc3MjExDQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCg0KDQpDaHJpc3RlciBIb2xtYmVyZyA8 Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPiANCreivP7IyzogIHNpcGNvcmUtYm91bmNl c0BpZXRmLm9yZw0KMjAxMC0wMy0yNyAxMjoxMA0KDQrK1bz+yMsNCiJnYW8ueWFuZzJAenRlLmNv bS5jbiIgPGdhby55YW5nMkB6dGUuY29tLmNuPiwgRGVhbiBXaWxsaXMgDQo8ZGVhbi53aWxsaXNA c29mdGFybW9yLmNvbT4NCrOty80NClNJUENPUkUgPHNpcGNvcmVAaWV0Zi5vcmc+DQrW98ziDQpS ZTogW3NpcGNvcmVdIElOVklURSAzeHggYW5kIGVhcmx5IG1lZGlhIFt3YXMgT1BUSU9OUyAzeHg6 IFRvIGZvcmsgb3Igbm90IA0KdG8gZm9yaz9dDQoNCg0KDQoNCg0KDQpIaSwNCg0KPklNTywgaWYg dGhlIGNhbGxlcidzIFVFIGlzIGFzIHN0cm9uZyBhcyBHb29nbGUgVm9pY2UgYW5kIGl0J3Mgc29m dHdhcmUsIA0KdGhlIG5ldHdvcmsgY2FuIGp1c3QgcmVuZGVyIGFsbCB0aGUgZWFybHkgbWVkaWEg dG8gaXQuDQo+U28sIHRoZSBrZXkgcHJvYmxlbSBpcyBhYm91dCBVRSB3aXRoIGxlc3MgY2FwYWJp bGl0eS4NCj4NCj5JIHN0aWxsIHRoaW5rIGl0IGlzIEJDUCB0aGluZy4gSSBvbmNlIHNhaWQgaG93 IG15IGVxdWlwbWVudCBoYW5kbGUgdGhpcyANCmluIHRoZSBtYWlsKGh0dHA6Ly93d3cuaWV0Zi5v cmcvbWFpbC0NCj5hcmNoaXZlL3dlYi9zaXBjb3JlL2N1cnJlbnQvbXNnMDIxMTQuaHRtbCkuDQo+ DQo+QlRXLCBkb2luZyB0aGlzIGNhbiBtYWtlIFBTVE4gdXNlciBoYXZpbmcgdGhlIHNhbWUgZXhw ZXJpZW5jZSBhcyBHVjoNCj5QU1ROIGdhdGV3YXkoc3VjaCBhcyBNR0NGIGluIElNUykgdGVybWlu YXRlIHRoZSBtdWx0aXBsZSBmb3JrZWQgZWFybHkgDQptZWRpYSBhbmQganVzdCBzZW5kIG9ubHkg b25lIHRvIHRoZSBQU1ROIHVzZXIuIEFuZA0KPnVzaW5nIERUTUYsIHRoZSB1c2VyIGNhbiBzd2l0 Y2ggZnJvbSBvbmUgdm9pY2UgdG8gYW5vdGhlciBieSBwcmVzcyB0aGUgDQpudW1iZXIga2V5Lg0K DQoNCg0KVGhhdCBjb3VsZCB3b3JrIGlmIHRoZSBtZWRpYSBpc24ndCBhY3R1YWxseSBwbGF5ZWQg dW50aWwgaXQgaXMgImNob3NlbiIgDQoodXNpbmcgRFRNRikuIElmIHRoZSBlYXJseSBtZWRpYSBB IGFuZCBCIGlzIHBsYXllZCBhdCB0aGUgc2FtZSB0aW1lLCB0aGUgDQp1c2VyIHdpbGwgbWlzcyBC IHdoaWxlIGxpc3RlbmluZyB0byBBLCBhbmQgd2hlbiB0aGUgdXNlciBzd2l0Y2hlcyB0byBCIHRo ZSANCm1lc3NhZ2UgbWF5IGFscmVhZHkgYmUgb3Zlci4uLg0KDQoNCg0KUmVnYXJkcywNCg0KDQoN CkNocmlzdGVyDQoNCg0KDQoNCg0KUGF1bCBLeXppdmF0IHdyb3RlOg0KDQo+IEl0cyByZWFsbHkg b25seSBwYXJhbGxlbCBmb3JraW5nIHRoYXRzIGEgcHJvYmxlbSwgc28gd2UgY2FuIHByb2JhYmx5 DQo+IGlnbm9yZSBzZXJpYWwgZm9ya2luZy4NCg0KTm90IHJlYWxseS4gRWFybHkgbWVkaWEgaXMg YWx3YXlzIGEgcHJvYmxlbS4gSG93IGRvIHlvdSB0ZWxsIGl0IHRvIHN0b3ANCndpdGhvdXQgd2hh Y2tpbmcgYWxsIHlvdXIgZm9ya3M/DQoNCj4NCj4gRm9yIHBhcmFsbGVsIGZvcmtpbmcsIG1vdmlu ZyBpdCBmcm9tIHRoZSBwcm94eSB0byB0aGUgVUFDIGRvZXNuJ3QgcmVhbGx5DQo+IHNvbHZlIHRo ZSBwcm9ibGVtIC0geW91IGNhbiBzdGlsbCBlbmQgdXAgd2l0aCBtdWx0aXBsZSBtZWRpYSBzdHJl YW1zIGFuZA0KPiBubyBjbHVlIHdoYXQgdG8gZG8gd2l0aCB0aGVtLg0KDQpLbm93aW5nIHdoaWNo IHN0cmVhbSBpcyB3aGljaCBsZXRzIHlvdSBkbyBNT1JFIHRoaW5ncyB0aGFuIHlvdSBjYW4gd2l0 aA0KanVzdCBhIGJ1bmNoIG9mIGdhcmJsZWQgbWVkaWEgY29taW5nIGluLg0KDQoNCj4NCj4gWW91 IGNhbiBzYXkgImRvbid0IGRvIHRoYXQiLCBidXQgdGhlcmUgYXJlIGRlc2lyYWJsZSBmZWF0dXJl cyB0aGF0DQo+IGRlcGVuZCBvbiBpdCAtIG5hbWVseSAic2ltdWx0YW5lb3VzIHJpbmciLiBQb3Rl bnRpYWxseSB0aGF0IGNhbiBiZQ0KPiByZXBsYWNlZCB3aXRoIHByZXNlbmNlLXNlbnNpdGl2ZSBy aW5naW5nIHRvIGNob29zZSB0aGUgKnJpZ2h0KiBvbiB0bw0KPiByaW5nIGZpcnN0LCBidXQgdGhh dCByZXF1aXJlcyBkYXRhIHRoYXQgb2Z0ZW4gaXNuJ3QgYXZhaWxhYmxlLg0KDQpHb29nbGUgVm9p Y2UgZG9lcyBzaW11bHRhbmVvdXMgcmluZyBxdWl0ZSBuaWNlbHkuIElmIHlvdSBjYWxsIG15IEdW DQpudW1iZXIsIGl0IHdpbGwgcmluZyBhbGwgbXkgcGhvbmVzLiBJZiBzb21lYm9keSBhbnN3ZXJz IGEgcGhvbmUsIEdWIHdpbGwNCnNheSAiUHJlc3MgMSB0byBhY2NlcHQgYSBjYWxsIGZyb20gUGF1 bCBLeXppdmF0IiwgYW5kIGlmIEkgcHJlc3MgMSwgR1YNCndpbGwgdGVybWluYXRlIHRoZSBvdGhl ciBmb3Jrcy4NCg0KV2Vic3RlciBkaWQgdGhpcyB5ZWFycyBhZ28gdXNpbmcgdGhlIGR5bmFtaWNz b2Z0IHN0dWZmIGFzIGEgY2FsbCANCmNvbnRyb2xsZXIuDQoNCkJ1dCB0byBkbyB0aGlzIGtpbmQg b2Ygd29yaywgdGhlIGNhbGwgY29udHJvbGxlciBuZWVkcyBzaWduYWxpbmcgY29udHJvbA0Kb24g ZWFjaCBmb3JrLCB3aGljaCB5b3UgZG9uJ3QgZ2V0IHdpdGggZWFybHkgbWVkaWEuDQoNCj4+IE9m ZmVybGVzcyBJTlZJVEVzIGhlbHAgbW9yZSwgc2luY2UgdGhlIG1lZGlhIGNhbid0IGNvbWUgYmFj ayB0byB5b3UNCj4+IHVudGlsIHRoZSBPL0EgaGFzIGNvbXBsZXRlZC4NCj4NCj4gVGhhdCBpcyBq dXN0IHN0aWNraW5nIHlvdXIgaGVhZCBpbiB0aGUgc2FuZC4gVGhlIG1lZGlhIGlzIHN0aWxsIGJl aW5nDQo+IGdlbmVyYXRlZCwgZXZlbiBpZiB5b3UgZG9uJ3Qga25vdyBhYm91dCBpdC4NCg0KTm8s IHJlYWxseS4gVGhleSBDQU5OT1Qgc2VuZCB5b3UgbWVkaWEgdW50aWwgeW91J3ZlIHNlbnQgeW91 ciBTRFAuICBJZg0KeW91IGRvbid0IHNlbmQgeW91ciBTRFAgKGluIHRoZSBBQ0spIHVudGlsIHRo ZXkgaGF2ZSBzZW50IHRoZWlycyAoaW4gdGhlDQoyMDBPSyksIHRoZW4gdGhlcmUgaXMgTk8gRUFS TFkgTUVESUEuDQoNClllcywgdGhpcyBtZWFucyB0aGF0IFBTVE4gZ2F0ZXdheXMgd291bGQgaGF2 ZSB0byBjb21wbGV0ZSBBQ0sgYmVmb3JlDQpkb2luZyBJQU0gb24gdGhlIFBTVE4gc2lkZS4gSSdt IE9LIHdpdGggdGhhdC4NCg0KPiBJdCBkb2VzIGhhdmUgdGhlIGFkdmFudGFnZSB0aGF0IHlvdSBj YW4gYXNzb2NpYXRlIHRoZSBtZWRpYSBzdHJlYW0gdG8NCj4gdGhlIHNpZ25hbGluZyBzb3VyY2Us IGJ1dCBpdCBzdGlsbCBkb2Vzbid0IHRlbGwgeW91IHdoaWNoIHN0cmVhbSBpcw0KPiBpbnRlcmVz dGluZyB0byBsaXN0ZW4gdG8uDQoNCkJ1dCBoYXZpbmcgYXNzb2NpYXRlZCBzaWduYWxpbmcgbGV0 cyB5b3UgZG8gdGhpbmdzIHRvIGRlY2lkZSB3aGljaCBvbmUNCmlzIGludGVyZXN0aW5nLg0KDQo+ IElTVE0gdGhhdCBpZiB5b3Ugd2FudCAic2ltdWx0YW5lb3VzIHJpbmciLCBhbmQgdGhlIHRoaW5n cyByaW5naW5nIGFyZQ0KPiBvZnRlbiBQU1ROIGRldmljZXMsIHRoZXJlIGlzIHN0aWxsIG5vIHNv bHV0aW9uLiBQZXJoYXBzIHRoZXJlIGlzIHNvbWUNCj4gcG9zc2liaWxpdHkgb2YgYXV0b21hdGVk IG1lZGlhIGFuYWx5c2lzIC0gdGhlIHBzdG4gR1cgZmlndXJpbmcgb3V0IHRoYXQNCj4gdGhlIG1l ZGlhIGJlaW5nIHJlY2VpdmVkIGlzIHNvbWV0aGluZyB1bmludGVyZXN0aW5nIC0ganVzdCBjb252 ZW50aW9uYWwNCj4gcmluZ2JhY2sgLSBhbmQgc3VwcHJlc3NpbmcgaXQuIEJ1dCB0aGF0cyBhIGxv dCBvZiB0cm91YmxlIGFuZCBpcyBsaWtlbHkNCj4gdG8gaGF2ZSBhIGhpZ2ggZXJyb3IgcmF0ZS4N Cg0KR28gcGxheSB3aXRoIEdvb2dsZSBWb2ljZSBvciBzb21ldGhpbmcgbGlrZSBpdCBmb3IgYXdo aWxlIGFuZCB0aGVuIGdldA0KYmFjayB0byB1cy4NCg0KLS0NCkRlYW4NCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcgbGlzdA0K c2lwY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z aXBjb3JlDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5m b3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyANCnNvbGVseSBwcm9wZXJ0eSBvZiB0 aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyANCmNv bmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50 YWluIHNlY3JlY3kgYW5kIA0KYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRl bnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byANCm90aGVycy4NClRoaXMgZW1haWwgYW5kIGFu eSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVk IA0Kc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9t IHRoZXkgYXJlIGFkZHJlc3NlZC4gDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGlu IGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgDQp0aGUgbWVzc2FnZS4gQW55 IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSANCmluZGl2 aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMg YW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSANCnN5c3RlbS4NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBj b3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNv cmUNCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBz ZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVu dGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNl Y3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0 aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRy YW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZv ciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFk ZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ug bm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2Vk IGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhp cyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFu dGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 0013A458482576F7_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPklNTywgYXMgdGhlIFBTVE4ncyB0 ZXJtaW5hbCBoYXMgbm8gYWJpbGl0eQ0KdG8gaGFuZGxlIG1vcmUgdGhhbiBvbmUgY2hhbm5lbCBv ZiBtZWRpYSwgSSB0aGluayBpdCBpcyBoYXJkbHkgdG8gaGFuZGxlDQppdCBiZXR0ZXIuPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JZiB5b3UgaGF2ZSBvbmUgYmV0 dGVyIHNvbHV0aW9uL3N1Z2dlc3Rpb24sDQpwbGVhc2Ugc2hhcmUgaXQgdG8gdXMuPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGVuLCBhYm91dCB0aGUg bm9ybWF0aXZlL0JDUCwgSSBwcmVmZXINCml0IHRvIGJlIEJDUCwgYXMgaG93IHRvIGhhbmRsZSBp dCBzaG91bGQgYmUgb3BlbiB3YXlzLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+VGhhbmtzLDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+R2FvPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCiBaaXAg Jm5ic3A7ICZuYnNwOzogMjEwMDEyPGJyPg0KIFRlbCAmbmJzcDsgJm5ic3A7OiA4NzIxMTxicj4N CiBUZWwyICZuYnNwOyA6KCs4NiktMDI1LTUyODc3MjExPGJyPg0KIGVfbWFpbCA6IGdhby55YW5n MkB6dGUuY29tLmNuPGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L2Zv bnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkIHdpZHRoPTI2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+Q2hyaXN0 ZXIgSG9sbWJlcmcgJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSZndDs8L2I+DQo8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7 c2lwY29yZS1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPjIwMTAtMDMtMjcgMTI6MTA8L2ZvbnQ+DQo8dGQgd2lkdGg9NzMlPg0KPHRhYmxl IHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+JnF1b3Q7Z2FvLnlhbmcyQHp0ZS5jb20uY24mcXVv dDsgJmx0O2dhby55YW5nMkB6dGUuY29tLmNuJmd0OywNCkRlYW4gV2lsbGlzICZsdDtkZWFuLndp bGxpc0Bzb2Z0YXJtb3IuY29tJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRp diBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48 L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+U0lQQ09SRSAmbHQ7c2lw Y29yZUBpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxp Z249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+ DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlJlOiBbc2lwY29yZV0gSU5WSVRF IDN4eCBhbmQgZWFybHkgbWVkaWENClt3YXMgT1BUSU9OUyAzeHg6IFRvIGZvcmsgb3Igbm90IHRv IGZvcms/XTwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+SGksPGJyPg0KPGJyPg0KJmd0O0lNTywgaWYgdGhlIGNhbGxlcidzIFVFIGlzIGFz IHN0cm9uZyBhcyBHb29nbGUgVm9pY2UgYW5kIGl0J3Mgc29mdHdhcmUsDQp0aGUgbmV0d29yayBj YW4ganVzdCByZW5kZXIgYWxsIHRoZSBlYXJseSBtZWRpYSB0byBpdC48YnI+DQomZ3Q7U28sIHRo ZSBrZXkgcHJvYmxlbSBpcyBhYm91dCBVRSB3aXRoIGxlc3MgY2FwYWJpbGl0eS48YnI+DQomZ3Q7 PGJyPg0KJmd0O0kgc3RpbGwgdGhpbmsgaXQgaXMgQkNQIHRoaW5nLiBJIG9uY2Ugc2FpZCBob3cg bXkgZXF1aXBtZW50IGhhbmRsZQ0KdGhpcyBpbiB0aGUgbWFpbChodHRwOi8vd3d3LmlldGYub3Jn L21haWwtJmd0O2FyY2hpdmUvd2ViL3NpcGNvcmUvY3VycmVudC9tc2cwMjExNC5odG1sKS48YnI+ DQomZ3Q7PGJyPg0KJmd0O0JUVywgZG9pbmcgdGhpcyBjYW4gbWFrZSBQU1ROIHVzZXIgaGF2aW5n IHRoZSBzYW1lIGV4cGVyaWVuY2UgYXMgR1Y6PGJyPg0KJmd0O1BTVE4gZ2F0ZXdheShzdWNoIGFz IE1HQ0YgaW4gSU1TKSB0ZXJtaW5hdGUgdGhlIG11bHRpcGxlIGZvcmtlZCBlYXJseQ0KbWVkaWEg YW5kIGp1c3Qgc2VuZCBvbmx5IG9uZSB0byB0aGUgUFNUTiB1c2VyLiBBbmQ8YnI+DQomZ3Q7dXNp bmcgRFRNRiwgdGhlIHVzZXIgY2FuIHN3aXRjaCBmcm9tIG9uZSB2b2ljZSB0byBhbm90aGVyIGJ5 IHByZXNzDQp0aGUgbnVtYmVyIGtleS48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpUaGF0IGNvdWxk IHdvcmsgaWYgdGhlIG1lZGlhIGlzbid0IGFjdHVhbGx5IHBsYXllZCB1bnRpbCBpdCBpcyAmcXVv dDtjaG9zZW4mcXVvdDsNCih1c2luZyBEVE1GKS4gSWYgdGhlIGVhcmx5IG1lZGlhIEEgYW5kIEIg aXMgcGxheWVkIGF0IHRoZSBzYW1lIHRpbWUsIHRoZQ0KdXNlciB3aWxsIG1pc3MgQiB3aGlsZSBs aXN0ZW5pbmcgdG8gQSwgYW5kIHdoZW4gdGhlIHVzZXIgc3dpdGNoZXMgdG8gQg0KdGhlIG1lc3Nh Z2UgbWF5IGFscmVhZHkgYmUgb3Zlci4uLjxicj4NCjxicj4NCjxicj4NCjxicj4NClJlZ2FyZHMs PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KQ2hyaXN0ZXI8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQpQYXVsIEt5eml2YXQgd3JvdGU6PGJyPg0KPGJyPg0KJmd0OyBJdHMgcmVhbGx5 IG9ubHkgcGFyYWxsZWwgZm9ya2luZyB0aGF0cyBhIHByb2JsZW0sIHNvIHdlIGNhbiBwcm9iYWJs eTxicj4NCiZndDsgaWdub3JlIHNlcmlhbCBmb3JraW5nLjxicj4NCjxicj4NCk5vdCByZWFsbHku IEVhcmx5IG1lZGlhIGlzIGFsd2F5cyBhIHByb2JsZW0uIEhvdyBkbyB5b3UgdGVsbCBpdCB0byBz dG9wPGJyPg0Kd2l0aG91dCB3aGFja2luZyBhbGwgeW91ciBmb3Jrcz88YnI+DQo8YnI+DQomZ3Q7 PGJyPg0KJmd0OyBGb3IgcGFyYWxsZWwgZm9ya2luZywgbW92aW5nIGl0IGZyb20gdGhlIHByb3h5 IHRvIHRoZSBVQUMgZG9lc24ndA0KcmVhbGx5PGJyPg0KJmd0OyBzb2x2ZSB0aGUgcHJvYmxlbSAt IHlvdSBjYW4gc3RpbGwgZW5kIHVwIHdpdGggbXVsdGlwbGUgbWVkaWEgc3RyZWFtcw0KYW5kPGJy Pg0KJmd0OyBubyBjbHVlIHdoYXQgdG8gZG8gd2l0aCB0aGVtLjxicj4NCjxicj4NCktub3dpbmcg d2hpY2ggc3RyZWFtIGlzIHdoaWNoIGxldHMgeW91IGRvIE1PUkUgdGhpbmdzIHRoYW4geW91IGNh biB3aXRoPGJyPg0KanVzdCBhIGJ1bmNoIG9mIGdhcmJsZWQgbWVkaWEgY29taW5nIGluLjxicj4N Cjxicj4NCjxicj4NCiZndDs8YnI+DQomZ3Q7IFlvdSBjYW4gc2F5ICZxdW90O2Rvbid0IGRvIHRo YXQmcXVvdDssIGJ1dCB0aGVyZSBhcmUgZGVzaXJhYmxlIGZlYXR1cmVzDQp0aGF0PGJyPg0KJmd0 OyBkZXBlbmQgb24gaXQgLSBuYW1lbHkgJnF1b3Q7c2ltdWx0YW5lb3VzIHJpbmcmcXVvdDsuIFBv dGVudGlhbGx5IHRoYXQNCmNhbiBiZTxicj4NCiZndDsgcmVwbGFjZWQgd2l0aCBwcmVzZW5jZS1z ZW5zaXRpdmUgcmluZ2luZyB0byBjaG9vc2UgdGhlICpyaWdodCogb24NCnRvPGJyPg0KJmd0OyBy aW5nIGZpcnN0LCBidXQgdGhhdCByZXF1aXJlcyBkYXRhIHRoYXQgb2Z0ZW4gaXNuJ3QgYXZhaWxh YmxlLjxicj4NCjxicj4NCkdvb2dsZSBWb2ljZSBkb2VzIHNpbXVsdGFuZW91cyByaW5nIHF1aXRl IG5pY2VseS4gSWYgeW91IGNhbGwgbXkgR1Y8YnI+DQpudW1iZXIsIGl0IHdpbGwgcmluZyBhbGwg bXkgcGhvbmVzLiBJZiBzb21lYm9keSBhbnN3ZXJzIGEgcGhvbmUsIEdWIHdpbGw8YnI+DQpzYXkg JnF1b3Q7UHJlc3MgMSB0byBhY2NlcHQgYSBjYWxsIGZyb20gUGF1bCBLeXppdmF0JnF1b3Q7LCBh bmQgaWYgSSBwcmVzcw0KMSwgR1Y8YnI+DQp3aWxsIHRlcm1pbmF0ZSB0aGUgb3RoZXIgZm9ya3Mu PGJyPg0KPGJyPg0KV2Vic3RlciBkaWQgdGhpcyB5ZWFycyBhZ28gdXNpbmcgdGhlIGR5bmFtaWNz b2Z0IHN0dWZmIGFzIGEgY2FsbCBjb250cm9sbGVyLjxicj4NCjxicj4NCkJ1dCB0byBkbyB0aGlz IGtpbmQgb2Ygd29yaywgdGhlIGNhbGwgY29udHJvbGxlciBuZWVkcyBzaWduYWxpbmcgY29udHJv bDxicj4NCm9uIGVhY2ggZm9yaywgd2hpY2ggeW91IGRvbid0IGdldCB3aXRoIGVhcmx5IG1lZGlh Ljxicj4NCjxicj4NCiZndDsmZ3Q7IE9mZmVybGVzcyBJTlZJVEVzIGhlbHAgbW9yZSwgc2luY2Ug dGhlIG1lZGlhIGNhbid0IGNvbWUgYmFjayB0bw0KeW91PGJyPg0KJmd0OyZndDsgdW50aWwgdGhl IE8vQSBoYXMgY29tcGxldGVkLjxicj4NCiZndDs8YnI+DQomZ3Q7IFRoYXQgaXMganVzdCBzdGlj a2luZyB5b3VyIGhlYWQgaW4gdGhlIHNhbmQuIFRoZSBtZWRpYSBpcyBzdGlsbCBiZWluZzxicj4N CiZndDsgZ2VuZXJhdGVkLCBldmVuIGlmIHlvdSBkb24ndCBrbm93IGFib3V0IGl0Ljxicj4NCjxi cj4NCk5vLCByZWFsbHkuIFRoZXkgQ0FOTk9UIHNlbmQgeW91IG1lZGlhIHVudGlsIHlvdSd2ZSBz ZW50IHlvdXIgU0RQLiAmbmJzcDtJZjxicj4NCnlvdSBkb24ndCBzZW5kIHlvdXIgU0RQIChpbiB0 aGUgQUNLKSB1bnRpbCB0aGV5IGhhdmUgc2VudCB0aGVpcnMgKGluIHRoZTxicj4NCjIwME9LKSwg dGhlbiB0aGVyZSBpcyBOTyBFQVJMWSBNRURJQS48YnI+DQo8YnI+DQpZZXMsIHRoaXMgbWVhbnMg dGhhdCBQU1ROIGdhdGV3YXlzIHdvdWxkIGhhdmUgdG8gY29tcGxldGUgQUNLIGJlZm9yZTxicj4N CmRvaW5nIElBTSBvbiB0aGUgUFNUTiBzaWRlLiBJJ20gT0sgd2l0aCB0aGF0Ljxicj4NCjxicj4N CiZndDsgSXQgZG9lcyBoYXZlIHRoZSBhZHZhbnRhZ2UgdGhhdCB5b3UgY2FuIGFzc29jaWF0ZSB0 aGUgbWVkaWEgc3RyZWFtDQp0bzxicj4NCiZndDsgdGhlIHNpZ25hbGluZyBzb3VyY2UsIGJ1dCBp dCBzdGlsbCBkb2Vzbid0IHRlbGwgeW91IHdoaWNoIHN0cmVhbSBpczxicj4NCiZndDsgaW50ZXJl c3RpbmcgdG8gbGlzdGVuIHRvLjxicj4NCjxicj4NCkJ1dCBoYXZpbmcgYXNzb2NpYXRlZCBzaWdu YWxpbmcgbGV0cyB5b3UgZG8gdGhpbmdzIHRvIGRlY2lkZSB3aGljaCBvbmU8YnI+DQppcyBpbnRl cmVzdGluZy48YnI+DQo8YnI+DQomZ3Q7IElTVE0gdGhhdCBpZiB5b3Ugd2FudCAmcXVvdDtzaW11 bHRhbmVvdXMgcmluZyZxdW90OywgYW5kIHRoZSB0aGluZ3MNCnJpbmdpbmcgYXJlPGJyPg0KJmd0 OyBvZnRlbiBQU1ROIGRldmljZXMsIHRoZXJlIGlzIHN0aWxsIG5vIHNvbHV0aW9uLiBQZXJoYXBz IHRoZXJlIGlzIHNvbWU8YnI+DQomZ3Q7IHBvc3NpYmlsaXR5IG9mIGF1dG9tYXRlZCBtZWRpYSBh bmFseXNpcyAtIHRoZSBwc3RuIEdXIGZpZ3VyaW5nIG91dA0KdGhhdDxicj4NCiZndDsgdGhlIG1l ZGlhIGJlaW5nIHJlY2VpdmVkIGlzIHNvbWV0aGluZyB1bmludGVyZXN0aW5nIC0ganVzdCBjb252 ZW50aW9uYWw8YnI+DQomZ3Q7IHJpbmdiYWNrIC0gYW5kIHN1cHByZXNzaW5nIGl0LiBCdXQgdGhh dHMgYSBsb3Qgb2YgdHJvdWJsZSBhbmQgaXMgbGlrZWx5PGJyPg0KJmd0OyB0byBoYXZlIGEgaGln aCBlcnJvciByYXRlLjxicj4NCjxicj4NCkdvIHBsYXkgd2l0aCBHb29nbGUgVm9pY2Ugb3Igc29t ZXRoaW5nIGxpa2UgaXQgZm9yIGF3aGlsZSBhbmQgdGhlbiBnZXQ8YnI+DQpiYWNrIHRvIHVzLjxi cj4NCjxicj4NCi0tPGJyPg0KRGVhbjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0Kc2lwY29yZSBtYWlsaW5nIGxpc3Q8YnI+DQpzaXBjb3Jl QGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBj b3JlPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpaVEUgSW5mb3JtYXRpb24gU2Vj dXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbA0KaXMg c29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBj b21tdW5pY2F0aW9uDQppcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJl IG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5DQphbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8g ZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0bw0Kb3RoZXJzLjxi cj4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25m aWRlbnRpYWwgYW5kIGludGVuZGVkDQpzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1 YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLg0KSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9m DQp0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRo b3NlIG9mIHRoZSBpbmRpdmlkdWFsDQpzZW5kZXIuPGJyPg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVu IHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uPGJy Pg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpzaXBjb3JlIG1haWxpbmcgbGlzdDxicj4NCnNpcGNvcmVAaWV0Zi5vcmc8YnI+DQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmU8YnI+DQo8YnI+DQo8L2Zv bnQ+PC90dD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2Vj dXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWlu ZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtw cm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24u Jm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25m aWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUm bmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2Fu ZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2Um bmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRp b24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2Fu eSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUm bmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNw O2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZu YnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZu YnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZu YnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtu b3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNz YWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlz Jm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtp bmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDti ZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFt Jm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 0013A458482576F7_=-- From christer.holmberg@ericsson.com Tue Mar 30 22:45:48 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58E203A684D; Tue, 30 Mar 2010 22:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.434 X-Spam-Level: * X-Spam-Status: No, score=1.434 tagged_above=-999 required=5 tests=[AWL=-4.314, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_74=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45] 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 WlNOf0jacikI; Tue, 30 Mar 2010 22:45:47 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id A4ED03A6993; Tue, 30 Mar 2010 22:45:24 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-10-4bb2e18d7193 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 53.7D.23740.D81E2BB4; Wed, 31 Mar 2010 07:45:50 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 31 Mar 2010 07:45:49 +0200 From: Christer Holmberg To: "gao.yang2@zte.com.cn" Date: Wed, 31 Mar 2010 07:45:48 +0200 Thread-Topic: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] Thread-Index: AcrQgyxxqo+QTdPWSBa7liAfiUqHIQAEftvA Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore-bounces@ietf.org" , SIPCORE Subject: Re: [sipcore] INVITE 3xx and early media [was OPTIONS 3xx: To fork or not to fork?] X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 05:45:48 -0000 DQpIaSwgDQoNCj5JTU8sIGFzIHRoZSBQU1ROJ3MgdGVybWluYWwgaGFzIG5vIGFiaWxpdHkgdG8g aGFuZGxlIG1vcmUgdGhhbiBvbmUgY2hhbm5lbCBvZiBtZWRpYSwgSSB0aGluayBpdCBpcyBoYXJk bHkgdG8gaGFuZGxlIGl0IGJldHRlci4gDQo+SWYgeW91IGhhdmUgb25lIGJldHRlciBzb2x1dGlv bi9zdWdnZXN0aW9uLCBwbGVhc2Ugc2hhcmUgaXQgdG8gdXMuIA0KDQpUcnVzdCBtZSwgSSB3aXNo IEkgaGFkIGEgc29sdXRpb24uDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KCQ0KCQ0KCQ0K CUNocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+IA0KCbei vP7IyzogIHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyANCg0KCTIwMTAtMDMtMjcgMTI6MTAgDQoN CgkJDQoJCcrVvP7Iyw0KCQkiZ2FvLnlhbmcyQHp0ZS5jb20uY24iIDxnYW8ueWFuZzJAenRlLmNv bS5jbj4sIERlYW4gV2lsbGlzIDxkZWFuLndpbGxpc0Bzb2Z0YXJtb3IuY29tPiANCgkJs63LzQ0K CQlTSVBDT1JFIDxzaXBjb3JlQGlldGYub3JnPiANCgkJ1vfM4g0KCQlSZTogW3NpcGNvcmVdIElO VklURSAzeHggYW5kIGVhcmx5IG1lZGlhIFt3YXMgT1BUSU9OUyAzeHg6IFRvIGZvcmsgb3Igbm90 IHRvIGZvcms/XQ0KDQoJCQ0KDQoNCg0KDQoJSGksDQoJDQoJPklNTywgaWYgdGhlIGNhbGxlcidz IFVFIGlzIGFzIHN0cm9uZyBhcyBHb29nbGUgVm9pY2UgYW5kIGl0J3Mgc29mdHdhcmUsIHRoZSBu ZXR3b3JrIGNhbiBqdXN0IHJlbmRlciBhbGwgdGhlIGVhcmx5IG1lZGlhIHRvIGl0Lg0KCT5Tbywg dGhlIGtleSBwcm9ibGVtIGlzIGFib3V0IFVFIHdpdGggbGVzcyBjYXBhYmlsaXR5Lg0KCT4NCgk+ SSBzdGlsbCB0aGluayBpdCBpcyBCQ1AgdGhpbmcuIEkgb25jZSBzYWlkIGhvdyBteSBlcXVpcG1l bnQgaGFuZGxlIHRoaXMgaW4gdGhlIG1haWwoaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLT5hcmNo aXZlL3dlYi9zaXBjb3JlL2N1cnJlbnQvbXNnMDIxMTQuaHRtbCkuDQoJPg0KCT5CVFcsIGRvaW5n IHRoaXMgY2FuIG1ha2UgUFNUTiB1c2VyIGhhdmluZyB0aGUgc2FtZSBleHBlcmllbmNlIGFzIEdW Og0KCT5QU1ROIGdhdGV3YXkoc3VjaCBhcyBNR0NGIGluIElNUykgdGVybWluYXRlIHRoZSBtdWx0 aXBsZSBmb3JrZWQgZWFybHkgbWVkaWEgYW5kIGp1c3Qgc2VuZCBvbmx5IG9uZSB0byB0aGUgUFNU TiB1c2VyLiBBbmQNCgk+dXNpbmcgRFRNRiwgdGhlIHVzZXIgY2FuIHN3aXRjaCBmcm9tIG9uZSB2 b2ljZSB0byBhbm90aGVyIGJ5IHByZXNzIHRoZSBudW1iZXIga2V5Lg0KCQ0KCQ0KCQ0KCVRoYXQg Y291bGQgd29yayBpZiB0aGUgbWVkaWEgaXNuJ3QgYWN0dWFsbHkgcGxheWVkIHVudGlsIGl0IGlz ICJjaG9zZW4iICh1c2luZyBEVE1GKS4gSWYgdGhlIGVhcmx5IG1lZGlhIEEgYW5kIEIgaXMgcGxh eWVkIGF0IHRoZSBzYW1lIHRpbWUsIHRoZSB1c2VyIHdpbGwgbWlzcyBCIHdoaWxlIGxpc3Rlbmlu ZyB0byBBLCBhbmQgd2hlbiB0aGUgdXNlciBzd2l0Y2hlcyB0byBCIHRoZSBtZXNzYWdlIG1heSBh bHJlYWR5IGJlIG92ZXIuLi4NCgkNCgkNCgkNCglSZWdhcmRzLA0KCQ0KCQ0KCQ0KCUNocmlzdGVy DQoJDQoJDQoJDQoJDQoJDQoJUGF1bCBLeXppdmF0IHdyb3RlOg0KCQ0KCT4gSXRzIHJlYWxseSBv bmx5IHBhcmFsbGVsIGZvcmtpbmcgdGhhdHMgYSBwcm9ibGVtLCBzbyB3ZSBjYW4gcHJvYmFibHkN Cgk+IGlnbm9yZSBzZXJpYWwgZm9ya2luZy4NCgkNCglOb3QgcmVhbGx5LiBFYXJseSBtZWRpYSBp cyBhbHdheXMgYSBwcm9ibGVtLiBIb3cgZG8geW91IHRlbGwgaXQgdG8gc3RvcA0KCXdpdGhvdXQg d2hhY2tpbmcgYWxsIHlvdXIgZm9ya3M/DQoJDQoJPg0KCT4gRm9yIHBhcmFsbGVsIGZvcmtpbmcs IG1vdmluZyBpdCBmcm9tIHRoZSBwcm94eSB0byB0aGUgVUFDIGRvZXNuJ3QgcmVhbGx5DQoJPiBz b2x2ZSB0aGUgcHJvYmxlbSAtIHlvdSBjYW4gc3RpbGwgZW5kIHVwIHdpdGggbXVsdGlwbGUgbWVk aWEgc3RyZWFtcyBhbmQNCgk+IG5vIGNsdWUgd2hhdCB0byBkbyB3aXRoIHRoZW0uDQoJDQoJS25v d2luZyB3aGljaCBzdHJlYW0gaXMgd2hpY2ggbGV0cyB5b3UgZG8gTU9SRSB0aGluZ3MgdGhhbiB5 b3UgY2FuIHdpdGgNCglqdXN0IGEgYnVuY2ggb2YgZ2FyYmxlZCBtZWRpYSBjb21pbmcgaW4uDQoJ DQoJDQoJPg0KCT4gWW91IGNhbiBzYXkgImRvbid0IGRvIHRoYXQiLCBidXQgdGhlcmUgYXJlIGRl c2lyYWJsZSBmZWF0dXJlcyB0aGF0DQoJPiBkZXBlbmQgb24gaXQgLSBuYW1lbHkgInNpbXVsdGFu ZW91cyByaW5nIi4gUG90ZW50aWFsbHkgdGhhdCBjYW4gYmUNCgk+IHJlcGxhY2VkIHdpdGggcHJl c2VuY2Utc2Vuc2l0aXZlIHJpbmdpbmcgdG8gY2hvb3NlIHRoZSAqcmlnaHQqIG9uIHRvDQoJPiBy aW5nIGZpcnN0LCBidXQgdGhhdCByZXF1aXJlcyBkYXRhIHRoYXQgb2Z0ZW4gaXNuJ3QgYXZhaWxh YmxlLg0KCQ0KCUdvb2dsZSBWb2ljZSBkb2VzIHNpbXVsdGFuZW91cyByaW5nIHF1aXRlIG5pY2Vs eS4gSWYgeW91IGNhbGwgbXkgR1YNCgludW1iZXIsIGl0IHdpbGwgcmluZyBhbGwgbXkgcGhvbmVz LiBJZiBzb21lYm9keSBhbnN3ZXJzIGEgcGhvbmUsIEdWIHdpbGwNCglzYXkgIlByZXNzIDEgdG8g YWNjZXB0IGEgY2FsbCBmcm9tIFBhdWwgS3l6aXZhdCIsIGFuZCBpZiBJIHByZXNzIDEsIEdWDQoJ d2lsbCB0ZXJtaW5hdGUgdGhlIG90aGVyIGZvcmtzLg0KCQ0KCVdlYnN0ZXIgZGlkIHRoaXMgeWVh cnMgYWdvIHVzaW5nIHRoZSBkeW5hbWljc29mdCBzdHVmZiBhcyBhIGNhbGwgY29udHJvbGxlci4N CgkNCglCdXQgdG8gZG8gdGhpcyBraW5kIG9mIHdvcmssIHRoZSBjYWxsIGNvbnRyb2xsZXIgbmVl ZHMgc2lnbmFsaW5nIGNvbnRyb2wNCglvbiBlYWNoIGZvcmssIHdoaWNoIHlvdSBkb24ndCBnZXQg d2l0aCBlYXJseSBtZWRpYS4NCgkNCgk+PiBPZmZlcmxlc3MgSU5WSVRFcyBoZWxwIG1vcmUsIHNp bmNlIHRoZSBtZWRpYSBjYW4ndCBjb21lIGJhY2sgdG8geW91DQoJPj4gdW50aWwgdGhlIE8vQSBo YXMgY29tcGxldGVkLg0KCT4NCgk+IFRoYXQgaXMganVzdCBzdGlja2luZyB5b3VyIGhlYWQgaW4g dGhlIHNhbmQuIFRoZSBtZWRpYSBpcyBzdGlsbCBiZWluZw0KCT4gZ2VuZXJhdGVkLCBldmVuIGlm IHlvdSBkb24ndCBrbm93IGFib3V0IGl0Lg0KCQ0KCU5vLCByZWFsbHkuIFRoZXkgQ0FOTk9UIHNl bmQgeW91IG1lZGlhIHVudGlsIHlvdSd2ZSBzZW50IHlvdXIgU0RQLiAgSWYNCgl5b3UgZG9uJ3Qg c2VuZCB5b3VyIFNEUCAoaW4gdGhlIEFDSykgdW50aWwgdGhleSBoYXZlIHNlbnQgdGhlaXJzIChp biB0aGUNCgkyMDBPSyksIHRoZW4gdGhlcmUgaXMgTk8gRUFSTFkgTUVESUEuDQoJDQoJWWVzLCB0 aGlzIG1lYW5zIHRoYXQgUFNUTiBnYXRld2F5cyB3b3VsZCBoYXZlIHRvIGNvbXBsZXRlIEFDSyBi ZWZvcmUNCglkb2luZyBJQU0gb24gdGhlIFBTVE4gc2lkZS4gSSdtIE9LIHdpdGggdGhhdC4NCgkN Cgk+IEl0IGRvZXMgaGF2ZSB0aGUgYWR2YW50YWdlIHRoYXQgeW91IGNhbiBhc3NvY2lhdGUgdGhl IG1lZGlhIHN0cmVhbSB0bw0KCT4gdGhlIHNpZ25hbGluZyBzb3VyY2UsIGJ1dCBpdCBzdGlsbCBk b2Vzbid0IHRlbGwgeW91IHdoaWNoIHN0cmVhbSBpcw0KCT4gaW50ZXJlc3RpbmcgdG8gbGlzdGVu IHRvLg0KCQ0KCUJ1dCBoYXZpbmcgYXNzb2NpYXRlZCBzaWduYWxpbmcgbGV0cyB5b3UgZG8gdGhp bmdzIHRvIGRlY2lkZSB3aGljaCBvbmUNCglpcyBpbnRlcmVzdGluZy4NCgkNCgk+IElTVE0gdGhh dCBpZiB5b3Ugd2FudCAic2ltdWx0YW5lb3VzIHJpbmciLCBhbmQgdGhlIHRoaW5ncyByaW5naW5n IGFyZQ0KCT4gb2Z0ZW4gUFNUTiBkZXZpY2VzLCB0aGVyZSBpcyBzdGlsbCBubyBzb2x1dGlvbi4g UGVyaGFwcyB0aGVyZSBpcyBzb21lDQoJPiBwb3NzaWJpbGl0eSBvZiBhdXRvbWF0ZWQgbWVkaWEg YW5hbHlzaXMgLSB0aGUgcHN0biBHVyBmaWd1cmluZyBvdXQgdGhhdA0KCT4gdGhlIG1lZGlhIGJl aW5nIHJlY2VpdmVkIGlzIHNvbWV0aGluZyB1bmludGVyZXN0aW5nIC0ganVzdCBjb252ZW50aW9u YWwNCgk+IHJpbmdiYWNrIC0gYW5kIHN1cHByZXNzaW5nIGl0LiBCdXQgdGhhdHMgYSBsb3Qgb2Yg dHJvdWJsZSBhbmQgaXMgbGlrZWx5DQoJPiB0byBoYXZlIGEgaGlnaCBlcnJvciByYXRlLg0KCQ0K CUdvIHBsYXkgd2l0aCBHb29nbGUgVm9pY2Ugb3Igc29tZXRoaW5nIGxpa2UgaXQgZm9yIGF3aGls ZSBhbmQgdGhlbiBnZXQNCgliYWNrIHRvIHVzLg0KCQ0KCS0tDQoJRGVhbg0KCV9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJc2lwY29yZSBtYWlsaW5nIGxp c3QNCglzaXBjb3JlQGlldGYub3JnDQoJaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zaXBjb3JlDQoJDQoJDQoJDQoJDQoJLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCglaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90 aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJv cGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRp b24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQg dG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhl IGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQoJVGhpcyBlbWFpbCBh bmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50 ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3 aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkg dmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1 YWwgc2VuZGVyLg0KCVRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFu ZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0KCQ0KCV9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoJc2lwY29yZSBtYWlsaW5nIGxpc3QNCglzaXBj b3JlQGlldGYub3JnDQoJaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBj b3JlDQoJDQoJDQoJDQoJDQoJLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCglaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUg aW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2Yg dGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29u ZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRh aW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRz IG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQoJVGhpcyBlbWFpbCBhbmQgYW55IGZp bGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29s ZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkg YXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBw bGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhw cmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVy Lg0KCVRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5 IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0KCQ0KDQo= From christer.holmberg@ericsson.com Tue Mar 30 22:55:41 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 332BA3A6B04 for ; Tue, 30 Mar 2010 22:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.048 X-Spam-Level: X-Spam-Status: No, score=-4.048 tagged_above=-999 required=5 tests=[AWL=1.420, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 ouXd+x5TLUXx for ; Tue, 30 Mar 2010 22:55:39 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 6621D3A693D for ; Tue, 30 Mar 2010 22:55:38 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-1a-4bb2e3f7827b Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 25.DC.23532.7F3E2BB4; Wed, 31 Mar 2010 07:56:07 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Wed, 31 Mar 2010 07:56:06 +0200 From: Christer Holmberg To: 'Adam Roach' , SIPCORE Date: Wed, 31 Mar 2010 07:56:05 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrQPAB1i2VEAimGSFKUG42bG2CATAAPowaA Message-ID: References: <4BB24B81.1050006@nostrum.com> In-Reply-To: <4BB24B81.1050006@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FF84A09F50A6DC48ACB6714F4666CC745E21BEF4EAESESSCMS0354e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 05:55:41 -0000 --_000_FF84A09F50A6DC48ACB6714F4666CC745E21BEF4EAESESSCMS0354e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Adam, thanks for sending out the the e-mail! First, a clarification regarding "new features": When we say "new features", I assume (based on Hadriel's comment in the mee= ting) it means the possibility to, with a single OPTIONS request, retrieve = the capabilities from ALL UAS(s) behind a forking proxy - instead of only o= ne UAS (whoever sends the 200 OK to the forking proxy first). The message I got from the meeting, and also previous e-mail discussions, w= as that the "OPTIONS 3xx" solution already provideds this feature, and that= it can be used (without defining new protocol elements etc). So, in my opinion the "adding" word is a little missleading. Instead I thin= k the question is whether we want to DOCUMENT that existing feature. Second, regarding bugs and interoperability issues in the field. Personally= I am not sure of any major ones at the moment, but that is probably becaus= e OPTIONS haven't been very much deployed in the first place (it has been u= sed for some keep-alive/ping purposes, but in those cases it really doesn't= matter what comes in the response etc). Now, however, at least I am starti= ng to get questions regarding the usage of OPTIONS, so I guess we need to a= sk ourselves whether we think the bugs WILL create interoperability issues. And, the issue you raised regarding using the re-INVITE to re-create dialog= s ("[sipcore] Mea Culpa: Dialog Necromancy in RFC 3261") also affects OPTIO= NS, eventhough you want to keep them separate (which is ok). Obviously I am in favor of pursuing the work, and will be willing to author= drafts :) Regards, Christer ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Adam Roach Sent: 30. maaliskuuta 2010 22:06 To: SIPCORE Subject: [sipcore] SIP OPTIONS: Shall we work on this? [as chair] One of the topics of discussion at the recent face-to-face meeting in Anahe= im was the SIP OPTIONS method. We have had significant discussion of some s= pecific technical topics on the SIPCORE mailing list, such that all partici= pants should have a reasonable overview of the scope that any related work = may entail. Participants may also benefit from reading through the minutes = of the corresponding conversation in Anaheim: http://www.ietf.org/proceedings/10mar/minutes/sipcore.html#The%20SIP%20OPTI= ONS%20Method Rather than continue discussion of the specific technical topics related to= OPTIONS, the chairs would encourage the working group to engage in a discu= ssion around whether we should, as a group, work on addressing some of the = issues that have been identified. In particular, we would direct the group to consider the nature of such wor= k: * Are we proposing to introduce new features, or fix existing bugs? * If we are adding new features: is OPTIONS the best way to introduce th= ese features, or would other mechanisms (presence, callee-caps) produce sup= erior results? * If we are fixing bugs: are the bugs theoretical, or can we cite actual= interoperability issues in the field? * If there are identified interoperability issues: is the level of effor= t involved in fixing them commensurate with the impact of the problems? Finally, keep in mind that work does not happen unless participants are wil= ling to invest time. If you speak out in favor of pursuing this work, pleas= e indicate the level of time commitment that you will personally invest in = bringing such work to a successful conclusion (e.g., will author drafts; wi= ll perform dedicated reviews; etc). Thanks. /a --_000_FF84A09F50A6DC48ACB6714F4666CC745E21BEF4EAESESSCMS0354e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Adam, thanks for sending out the the=20 e-mail!
 
First, a clarification regarding "new featu= res":=20
 
When we say "new features", I assume (= based=20 on Hadriel's comment in the meeting) it means the possibility to,= with=20 a single OPTIONS request, retrieve the capabilities from ALL UAS(s) be= hind=20 a forking proxy - instead of only one UAS (whoever sends the 200 = OK to=20 the forking proxy first).
 
The message I got from the meeting, and also pre= vious=20 e-mail discussions, was that the "OPTIONS 3xx" solution already provideds t= his=20 feature, and that it can be used (without defining new protocol elements=20 etc).
 
So, in my opinion the "adding" word is a little= =20 missleading. Instead I think the question is whether we want to DOCUMENT th= at=20 existing feature.
 
 
Second, regarding bugs and interoperability issu= es in=20 the field. Personally I am not sure of any major ones at the moment, but th= at is=20 probably because OPTIONS haven't been very much deployed in the first = place=20 (it has been used for some keep-alive/ping purposes, but in those cases it= =20 really doesn't matter what comes in the response etc). Now, however, at lea= st I=20 am starting to get questions regarding the usage of OPTIONS, so I guess we = need=20 to ask ourselves whether we think the bugs WILL create interoperability=20 issues.
 
And, the issue you raised regarding using t= he=20 re-INVITE to re-create dialogs ("[sipcore] Mea Culpa: Dialog Necromancy in = RFC=20 3261") also affects OPTIONS, eventhough you want to keep them separate (whi= ch is=20 ok).
 
Obviously I am in favor of pursuing the work, an= d will=20 be willing to author drafts :)
 
Regards,
 
Christer
 
 
 

From: sipcore-bounces@ietf.org=20 [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach
Sent= :=20 30. maaliskuuta 2010 22:06
To: SIPCORE
Subject: [sipcor= e]=20 SIP OPTIONS: Shall we work on this?

[as chair]

One of the topics of discussion at the recent= =20 face-to-face meeting in Anaheim was the SIP OPTIONS method. We have had=20 significant discussion of some specific technical topics on the SIPCORE mai= ling=20 list, such that all participants should have a reasonable overview of the s= cope=20 that any related work may entail. Participants may also benefit from readin= g=20 through the minutes of the corresponding conversation in Anaheim:

http://www.ietf.org/proceedings/10mar/minutes/sipcore= .html#The%20SIP%20OPTIONS%20Method

Rather=20 than continue discussion of the specific technical topics related to OPTION= S,=20 the chairs would encourage the working group to engage in a discussion arou= nd=20 whether we should, as a group, work on addressing some of the issues that h= ave=20 been identified.

In particular, we would direct the group to conside= r the=20 nature of such work:
  • Are we proposing to introduce new features, or fix existing bugs?=20
  • If we are adding new features: is OPTIONS the best way to introduce t= hese=20 features, or would other mechanisms (presence, callee-caps) produce super= ior=20 results?
  • If we are fixing bugs: are the bugs theoretical, or can we cite actua= l=20 interoperability issues in the field?=20
  • If there are identified interoperability issues: is the level of effo= rt=20 involved in fixing them commensurate with the impact of the problems?=20
Finally, keep in mind that work does not happen unless participan= ts=20 are willing to invest time. If you speak out in favor of pursuing this work= ,=20 please indicate the level of time commitment that you will personally inves= t in=20 bringing such work to a successful conclusion (e.g., will author drafts; wi= ll=20 perform dedicated reviews; etc).

Thanks.

/a
--_000_FF84A09F50A6DC48ACB6714F4666CC745E21BEF4EAESESSCMS0354e_-- From christer.holmberg@ericsson.com Wed Mar 31 01:26:18 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B3F13A6BDF for ; Wed, 31 Mar 2010 01:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.105 X-Spam-Level: X-Spam-Status: No, score=-4.105 tagged_above=-999 required=5 tests=[AWL=1.363, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 wOmfw+mqA86q for ; Wed, 31 Mar 2010 01:26:17 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id F14C83A6C69 for ; Wed, 31 Mar 2010 01:18:46 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-f2-4bb305848b29 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 14.CF.23532.48503BB4; Wed, 31 Mar 2010 10:19:16 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.86) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.1.375.2; Wed, 31 Mar 2010 10:19:14 +0200 Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0191.eemea.ericsson.se ([10.2.3.60]) with mapi; Wed, 31 Mar 2010 10:19:14 +0200 From: Christer Holmberg To: SIPCORE Date: Wed, 31 Mar 2010 10:19:13 +0200 Thread-Topic: RFC3265/3265bis and draft-ietf-sipcore-subnot-etags issue regarding notification suppression Thread-Index: AcrQqtkcKmMbqpCjRMqOjz8NFG2XnQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FF84A09F50A6DC48ACB6714F4666CC745E21BEF5EEESESSCMS0354e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "aki.niemi@nokia.com" Subject: [sipcore] RFC3265/3265bis and draft-ietf-sipcore-subnot-etags issue regarding notification suppression X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 08:26:18 -0000 --_000_FF84A09F50A6DC48ACB6714F4666CC745E21BEF5EEESESSCMS0354e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, A question regarding the notification suppression function in draft-ietf-si= pcore-subnot-etags: The draft allows NOTIFY requests to be suppressed for re/de-SUBSCRIBEs. Section 5.8 of the draft says that the suppression might be an issue for B2= BUAs that expect a NOTIFY. But, doesn't this issue also apply to stateful p= roxies which keep track of subscription dialogs? Don't they also expect NOT= IFY? Or, is a proxy which maintains subscription dialog state considered to= be a B2BUA? So, when NOTIFY is suppressed for de-subscribe then stateful proxies (or wh= atever they are called) which keep track of subscription dialogs and which = do not support draft-ietf-sipcore-subnot-etags-04 will still believe the su= bscription dialog exists. Now, 3265bis defines timer N, so if it applies also to proxies (open issue = in the draft) I assume that proxies will simply ignore the re/de-subscripti= on in case of no associated NOTIFY within a certain time, and eventually th= e subscription will expire and the proxy will release the state. However, I= think that is bad protocol design. RFC3265 does not define timer N, though, so the behavior for RFC compliant = proxies is unclear. Now, since the NOTIFY request is so essential (at least in 3265bis the SUB = 200 OK becomes almost meaningless from a functional perspective) to the who= le SUB/NOT framework, I wonder whether it is a very good idea to allow the = NOTIFY request suppression. I DO like the idea of being able to suppress th= e NOTIFY message body, and maybe suppressing the NOTIFY request for re-subs= criptions isn't that dangerous. But, suppressing the NOTIFY for de-subscrip= tions is bad, in my opinion. Regards, Christer --_000_FF84A09F50A6DC48ACB6714F4666CC745E21BEF5EEESESSCMS0354e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
A question regarding the notification suppression fun= ction in draft-ietf-sipcore-subnot-etags:
 
The draft allows NOTIFY requests to be suppressed for= re/de-SUBSCRIBEs.
 
Section 5.8 of the draft says that the suppression mi= ght be an issue for B2BUAs that expect a NOTIFY. But, doesn't this issue al= so apply to stateful proxies which keep track of subscription dialogs? Don'= t they also expect NOTIFY? Or, is a proxy which maintains subscription dialog state considered to be a B2BUA?=
 
So, when NOTIFY is suppressed for de-subscribe then s= tateful proxies (or whatever they are called) which keep track of subscript= ion dialogs and which do not support draft-ietf-sipcore-subnot-etags-04 wil= l still believe the subscription dialog exists.
 
Now, 3265bis defines timer N, so if it applies also t= o proxies (open issue in the draft) I assume that proxies will simply ignor= e the re/de-subscription in case of no associated NOTIFY within a certain t= ime, and eventually the subscription will expire and the proxy will release the state. However, I think that is = bad protocol design.
 
RFC3265 does not define timer N, though, so the behav= ior for RFC compliant proxies is unclear.
 
Now, since the NOTIFY request is so essential (at lea= st in 3265bis the SUB 200 OK becomes almost meaningless from a functional p= erspective) to the whole SUB/NOT framework, I wonder whether it is a very g= ood idea to allow the NOTIFY request suppression. I DO like the idea of being able to suppress the NOTIFY messag= e body, and maybe suppressing the NOTIFY request for re-subscriptions isn't= that dangerous. But, suppressing the NOTIFY for de-subscriptions is bad, i= n my opinion.
 
Regards,
 
Christer
 
 
 
 
 
 
 
 --_000_FF84A09F50A6DC48ACB6714F4666CC745E21BEF5EEESESSCMS0354e_-- From christer.holmberg@ericsson.com Wed Mar 31 01:30:38 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 52B733A6C63 for ; Wed, 31 Mar 2010 01:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.857 X-Spam-Level: X-Spam-Status: No, score=-0.857 tagged_above=-999 required=5 tests=[AWL=-1.989, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] 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 zOVu9rL5sAxa for ; Wed, 31 Mar 2010 01:30:37 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 6ADF73A68CB for ; Wed, 31 Mar 2010 01:26:41 -0700 (PDT) X-AuditID: c1b4fb39-b7b85ae000005cbc-ee-4bb3075c2d48 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 12.62.23740.C5703BB4; Wed, 31 Mar 2010 10:27:08 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 31 Mar 2010 10:27:08 +0200 From: Christer Holmberg To: Adam Roach , SIPCORE Date: Wed, 31 Mar 2010 10:27:07 +0200 Thread-Topic: [sipcore] Mea Culpa: Dialog Necromancy in RFC 3261 Thread-Index: AcrQRFO6bpAUN0jpQ7aJU2i/0akrBwAZpp5g Message-ID: References: <4BB25978.3080701@nostrum.com> In-Reply-To: <4BB25978.3080701@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FF84A09F50A6DC48ACB6714F4666CC745E21BEF611ESESSCMS0354e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Mea Culpa: Dialog Necromancy in RFC 3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 08:30:38 -0000 --_000_FF84A09F50A6DC48ACB6714F4666CC745E21BEF611ESESSCMS0354e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Adam, Mabye you were thinking about RFC 4028 (session timer)? It's a while since = we worked on that draft, but I THINK we in some early versions had some tex= t about session re-creation, which was later removed. And, based on a quick= look, the RFC only talks about session re-fresh. I think the usage of re-INVITE to re-create a dialog is bad, and will most = likely cause all kind of issues. For example, there is no indication whethe= r the UAC even wants the dialog to be re-created in the first place, in cas= e it doesn't exist. And, in order to work any entity involved will have to = be able to restore all resources (related to media, NAT traversal, security= etc etc etc) from when the dialog existed - which means they have to maint= ain data for that dialog, and maybe even some procedures (keep-alives etc). Now, I didn't see any question in your e-mail, e.g. wheter we should do som= ething about this, but my opinion is still: do not allow it :) Regards, Christer ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Adam Roach Sent: 30. maaliskuuta 2010 23:05 To: SIPCORE Subject: [sipcore] Mea Culpa: Dialog Necromancy in RFC 3261 [as participant] During the Anaheim meeting, I made an assertion that the optional feature o= f re-creating dialogs upon receipt of an in-dialog INVITE (i.e., one with a= "To" tag) that did not match an ongoing dialog had been removed between RF= C 2543 and RFC 3261. I was wrong. What I was recalling was a related change in handling; between 2543 and 326= 1, the creation of such zombie dialogs changed from mandatory to optional (= instead of going from "optional" to "prohibited," as I mistakenly recalled)= . In 2543, the arrival of an apparently-in-dialog INVITE that didn't match an= ongoing "call-leg" (dialog) would always create a new "call leg"; the call= ed party had no way of rejecting the call with an indication that the assoc= iated "call leg" had been previously terminated (RFC 2543, section 10.1.1) = -- the 481 response code had semantics only for CANCEL and BYE. In 3261, the UAS is given the _option_ of re-creating the dialog under such= circumstances. From 3261, section 12.2.2: If the request has a tag in the To header field, but the dialog identifier does not match any existing dialogs, the UAS may have crashed and restarted, or it may have received a request for a different (possibly failed) UAS (the UASs can construct the To tags so that a UAS can identify that the tag was for a UAS for which it is providing recovery). Another possibility is that the incoming request has been simply misrouted. Based on the To tag, the UAS MAY either accept or reject the request. Accepting the request for acceptable To tags provides robustness, so that dialogs can persist even through crashes. UAs wishing to support this capability must take into consideration some issues such as choosing monotonically increasing CSeq sequence numbers even across reboots, reconstructing the route set, and accepting out-of-range RTP timestamps and sequence numbers. If the UAS wishes to reject the request because it does not wish to recreate the dialog, it MUST respond to the request with a 481 (Call/Transaction Does Not Exist) status code and pass that to the server transaction. In the interest of not digging into the actual details of the OPTIONS-relat= ed issues, I am intentionally refraining from commenting on the relationshi= p between this behavior and the associated OPTIONS discussion topic from th= e Anaheim meeting. /a --_000_FF84A09F50A6DC48ACB6714F4666CC745E21BEF611ESESSCMS0354e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi Adam,
 
Mabye you were thinking about RFC 4028 (session = timer)?=20 It's a while since we worked on that draft, but = I THINK=20 we in some early versions had some text about session re-creation, which wa= s=20 later removed. And, based on a quick look, the RFC only talks about se= ssion=20 re-fresh.
 
I think the usage of re-INVITE to re-create a di= alog is=20 bad, and will most likely cause all kind of issues. For example, there is n= o=20 indication whether the UAC even wants the dialog to be re-created in the fi= rst=20 place, in case it doesn't exist. And, in order to work any entity invo= lved=20 will have to be able to restore all resources (related to media, NAT traver= sal,=20 security etc etc etc) from when the dialog existed - which means they have = to=20 maintain data for that dialog, and maybe even some procedures (keep-alives= =20 etc).
 
Now, I didn't see any question in your e-mail, e= .g.=20 wheter we should do something about this, but my opinion is still: do not a= llow=20 it :)
 
Regards,
 
Christer
 
 
 

From: sipcore-bounces@ietf.org=20 [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam=20 Roach
Sent: 30. maaliskuuta 2010 23:05
To:=20 SIPCORE
Subject: [sipcore] Mea Culpa: Dialog Necromancy in RFC= =20 3261

[as participant]

During the Anaheim meeting, I made an= =20 assertion that the optional feature of re-creating dialogs upon receipt o= f an=20 in-dialog INVITE (i.e., one with a "To" tag) that did not match an ongoin= g=20 dialog had been removed between RFC 2543 and RFC 3261.

I was=20 wrong.

What I was recalling was a related change in handling; betw= een=20 2543 and 3261, the creation of such zombie dialogs changed from mandatory= to=20 optional (instead of going from "optional" to "prohibited," as I mistaken= ly=20 recalled).

In 2543, the arrival of an apparently-in-dialog INVITE = that=20 didn't match an ongoing "call-leg" (dialog) would always create a new "ca= ll=20 leg"; the called party had no way of rejecting the call with an indicatio= n=20 that the associated "call leg" had been previously terminated (RFC 2543,= =20 section 10.1.1) -- the 481 response code had semantics only for CANCEL an= d=20 BYE.

In 3261, the UAS is given the _option_ of re-creating the dia= log=20 under such circumstances. From 3261, section 12.2.2:

   If the request has a tag in the To head=
er field, but the dialog
   identifier does not match any existing dialogs, the UAS may have
   crashed and restarted, or it may have received a request for a
   different (possibly failed) UAS (the UASs can construct the To tags
   so that a UAS can identify that the tag was for a UAS for which it is
   providing recovery).  Another possibility is that the incoming
   request has been simply misrouted.  Based on the To tag, the UAS MAY
   either accept or reject the request.  Accepting the request for
   acceptable To tags provides robustness, so that dialogs can persist
   even through crashes.  UAs wishing to support this capability must
   take into consideration some issues such as choosing monotonically
   increasing CSeq sequence numbers even across reboots, reconstructing
   the route set, and accepting out-of-range RTP timestamps and sequence
   numbers.

   If the UAS wishes to reject the request because it does not wish to
   recreate the dialog, it MUST respond to the request with a 481
   (Call/Transaction Does Not Exist) status code and pass that to the
   server transaction.

In the interest of not digging into the actual=20 details of the OPTIONS-related issues, I am intentionally refraining from= =20 commenting on the relationship between this behavior and the associated=20 OPTIONS discussion topic from the Anaheim=20 meeting.

/a
--_000_FF84A09F50A6DC48ACB6714F4666CC745E21BEF611ESESSCMS0354e_-- From pkyzivat@cisco.com Wed Mar 31 06:43:58 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2B10D3A6989 for ; Wed, 31 Mar 2010 06:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.519 X-Spam-Level: X-Spam-Status: No, score=-8.519 tagged_above=-999 required=5 tests=[AWL=0.950, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_HI=-8] 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 4ZYBaL1Vwwu2 for ; Wed, 31 Mar 2010 06:43:57 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id D440B3A68DB for ; Wed, 31 Mar 2010 06:43:56 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEPusktAZnwM/2dsb2JhbACbNXGnbZkXhQAE X-IronPort-AV: E=Sophos;i="4.51,341,1267401600"; d="scan'208";a="97661167" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 31 Mar 2010 13:44:27 +0000 Received: from [161.44.174.156] (dhcp-161-44-174-156.cisco.com [161.44.174.156]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o2VDiRwa011019; Wed, 31 Mar 2010 13:44:27 GMT Message-ID: <4BB351BA.5030706@cisco.com> Date: Wed, 31 Mar 2010 09:44:26 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg References: <4BB24B81.1050006@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 13:43:58 -0000 Christer, [as chair] By accepting the 3xx solution to handling multiple UAs, you have removed the most obvious "new feature". There may or may not be other less obvious ones lurking in there. For instance, you (and I) have suggested using Request-Disposition:redirect to "ensure" the 3xx is returned. But honoring R-D is optional by the proxy. So at the moment there is no way to be certain that you are getting info for all the available UAs. Anything that somehow made honoring R-D mandatory for OPTIONS would be a new feature. Also, there are other cases where the behavior is currently optional/ambiguous. "Fixing" those to be unambiguous/non-optional can also be construed as a *change*. (There is a fine line here about what is intended by the current texts.) It will certainly be easier if no normative changes are required. In any case, having you willing to do the work is a good thing. But there had better also be others that are interested in the work enough to review and comment on it, and to justify spending list and meeting time on. [As individual] I have "mild" interest in this from an academic perspective, but I don't see it as necessary work. I'm waiting to see how much other interest there is. Thanks, Paul Christer Holmberg wrote: > Hi, > > Adam, thanks for sending out the the e-mail! > > First, a clarification regarding "new features": > > When we say "new features", I assume (based on Hadriel's comment in the > meeting) it means the possibility to, with a single OPTIONS > request, retrieve the capabilities from ALL UAS(s) behind a forking > proxy - instead of only one UAS (whoever sends the 200 OK to the forking > proxy first). > > The message I got from the meeting, and also previous e-mail > discussions, was that the "OPTIONS 3xx" solution already provideds this > feature, and that it can be used (without defining new protocol elements > etc). > > So, in my opinion the "adding" word is a little missleading. Instead I > think the question is whether we want to DOCUMENT that existing feature. > > > Second, regarding bugs and interoperability issues in the field. > Personally I am not sure of any major ones at the moment, but that is > probably because OPTIONS haven't been very much deployed in the first > place (it has been used for some keep-alive/ping purposes, but in those > cases it really doesn't matter what comes in the response etc). Now, > however, at least I am starting to get questions regarding the usage of > OPTIONS, so I guess we need to ask ourselves whether we think the bugs > WILL create interoperability issues. > > And, the issue you raised regarding using the re-INVITE to re-create > dialogs ("[sipcore] Mea Culpa: Dialog Necromancy in RFC 3261") also > affects OPTIONS, eventhough you want to keep them separate (which is ok). > > Obviously I am in favor of pursuing the work, and will be willing to > author drafts :) > > Regards, > > Christer > > > > > ------------------------------------------------------------------------ > *From:* sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] *On > Behalf Of *Adam Roach > *Sent:* 30. maaliskuuta 2010 22:06 > *To:* SIPCORE > *Subject:* [sipcore] SIP OPTIONS: Shall we work on this? > > [as chair] > > One of the topics of discussion at the recent face-to-face meeting in > Anaheim was the SIP OPTIONS method. We have had significant discussion > of some specific technical topics on the SIPCORE mailing list, such that > all participants should have a reasonable overview of the scope that any > related work may entail. Participants may also benefit from reading > through the minutes of the corresponding conversation in Anaheim: > > http://www.ietf.org/proceedings/10mar/minutes/sipcore.html#The%20SIP%20OPTIONS%20Method > > Rather than continue discussion of the specific technical topics related > to OPTIONS, the chairs would encourage the working group to engage in a > discussion around whether we should, as a group, work on addressing some > of the issues that have been identified. > > In particular, we would direct the group to consider the nature of such > work: > > * Are we proposing to introduce new features, or fix existing bugs? > * If we are adding new features: is OPTIONS the best way to > introduce these features, or would other mechanisms (presence, > callee-caps) produce superior results? > * If we are fixing bugs: are the bugs theoretical, or can we cite > actual interoperability issues in the field? > * If there are identified interoperability issues: is the level of > effort involved in fixing them commensurate with the impact of the > problems? > > Finally, keep in mind that work does not happen unless participants are > willing to invest time. If you speak out in favor of pursuing this work, > please indicate the level of time commitment that you will personally > invest in bringing such work to a successful conclusion (e.g., will > author drafts; will perform dedicated reviews; etc). > > Thanks. > > /a > > > ------------------------------------------------------------------------ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From adam@nostrum.com Wed Mar 31 07:22:39 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2717A3A67B1 for ; Wed, 31 Mar 2010 07:22:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.866 X-Spam-Level: X-Spam-Status: No, score=-0.866 tagged_above=-999 required=5 tests=[AWL=0.604, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 mqyy5PxWeEBo for ; Wed, 31 Mar 2010 07:22:34 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 198B43A685E for ; Wed, 31 Mar 2010 07:22:32 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o2VEMxiB082132 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Mar 2010 09:22:59 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BB35AC3.9060602@nostrum.com> Date: Wed, 31 Mar 2010 09:22:59 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Christer Holmberg References: <4BB25978.3080701@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090404090605050405010007" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] Mea Culpa: Dialog Necromancy in RFC 3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 14:22:39 -0000 This is a multi-part message in MIME format. --------------090404090605050405010007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 3/31/10 3:27 AM, Christer Holmberg wrote: > Now, I didn't see any question in your e-mail, e.g. wheter we should > do something about this, but my opinion is still: do not allow it :) > Sorry if I was unclear in the original email. It wasn't a question; it was a correction. I didn't want people laboring under a misconception because of my confusion. This behavior is hardly something we need to go back and change in RFC 3261. /a --------------090404090605050405010007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 3/31/10 3:27 AM, Christer Holmberg wrote:
Now, I didn't see any question in your e-mail, e.g. wheter we should do something about this, but my opinion is still: do not allow it :)


Sorry if I was unclear in the original email. It wasn't a question; it was a correction. I didn't want people laboring under a misconception because of my confusion.

This behavior is hardly something we need to go back and change in RFC 3261.

/a
--------------090404090605050405010007-- From christer.holmberg@ericsson.com Wed Mar 31 12:48:20 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D2383A6A29 for ; Wed, 31 Mar 2010 12:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.041 X-Spam-Level: X-Spam-Status: No, score=-4.041 tagged_above=-999 required=5 tests=[AWL=1.427, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 GO8PZnzPhY1c for ; Wed, 31 Mar 2010 12:48:19 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id F2EDD3A6A34 for ; Wed, 31 Mar 2010 12:48:18 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-39-4bb3a72011da Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 7D.C7.23532.027A3BB4; Wed, 31 Mar 2010 21:48:49 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 31 Mar 2010 21:48:48 +0200 From: Christer Holmberg To: 'Adam Roach' Date: Wed, 31 Mar 2010 21:48:47 +0200 Thread-Topic: [sipcore] Mea Culpa: Dialog Necromancy in RFC 3261 Thread-Index: AcrQ3ayZz+zDgvOGQkKVw9UkvXNVVQALMKvw Message-ID: References: <4BB25978.3080701@nostrum.com> <4BB35AC3.9060602@nostrum.com> In-Reply-To: <4BB35AC3.9060602@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FF84A09F50A6DC48ACB6714F4666CC745E21B5A905ESESSCMS0354e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Mea Culpa: Dialog Necromancy in RFC 3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 19:48:20 -0000 --_000_FF84A09F50A6DC48ACB6714F4666CC745E21B5A905ESESSCMS0354e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable So, you are saying that it is ok to re-crete dialogs using re-INVITEs? If that's the way we want to go, fine. I just hope people actually won't st= art re-creating dialogs, because I think that could cause interop issues an= d state unsynchronization - without anyone to blame, since everyone can cla= im that they are acting according to the RFC... Also, as I said earlier, I thought be decided that the session timer functi= onality could not be used to re-created dialogs. But, again, it's a while s= ince we did that work, so... Regards, Christer ________________________________ From: Adam Roach [mailto:adam@nostrum.com] Sent: 31. maaliskuuta 2010 17:23 To: Christer Holmberg Cc: SIPCORE Subject: Re: [sipcore] Mea Culpa: Dialog Necromancy in RFC 3261 On 3/31/10 3:27 AM, Christer Holmberg wrote: Now, I didn't see any question in your e-mail, e.g. wheter we should do som= ething about this, but my opinion is still: do not allow it :) Sorry if I was unclear in the original email. It wasn't a question; it was = a correction. I didn't want people laboring under a misconception because o= f my confusion. This behavior is hardly something we need to go back and change in RFC 3261= . /a --_000_FF84A09F50A6DC48ACB6714F4666CC745E21B5A905ESESSCMS0354e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
So, you are saying that it is ok to re-crete dialo= gs using=20 re-INVITEs?
 
If that's the way we want to go, fine. I just hope= people=20 actually won't start re-creating dialogs, because I think that could=20 cause interop issues and state unsynchronization - without anyone to b= lame,=20 since everyone can claim that they are acting according to the=20 RFC...
 
Also, as I said earlier, I thought be decided that= the=20 session timer functionality could not be used to re-created dialogs. But, a= gain,=20 it's a while since we did that work, so...
 
Regards,
 
Christer

From: Adam Roach [mailto:adam@nostrum.c= om]=20
Sent: 31. maaliskuuta 2010 17:23
To: Christer=20 Holmberg
Cc: SIPCORE
Subject: Re: [sipcore] Mea Culpa:= =20 Dialog Necromancy in RFC 3261

On 3/31/10 3:27 AM, Christer Holmberg wrote:=20
<= SPAN=20 class=3D294491908-31032010>Now, I didn't see any question in your e-mail,= e.g.=20 wheter we should do something about this, but my opinion is still: do not= =20 allow it :)


Sorry if I was unclea= r in=20 the original email. It wasn't a question; it was a correction. I didn't wan= t=20 people laboring under a misconception because of my confusion.

This= =20 behavior is hardly something we need to go back and change in RFC=20 3261.

/a
--_000_FF84A09F50A6DC48ACB6714F4666CC745E21B5A905ESESSCMS0354e_-- From christer.holmberg@ericsson.com Wed Mar 31 13:16:55 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E2F33A6A35 for ; Wed, 31 Mar 2010 13:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[AWL=1.380, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 0TFF95XmyVk2 for ; Wed, 31 Mar 2010 13:16:54 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 586863A68BC for ; Wed, 31 Mar 2010 13:16:10 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-99-4bb3ada8a974 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 94.09.23532.8ADA3BB4; Wed, 31 Mar 2010 22:16:40 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 31 Mar 2010 22:16:39 +0200 From: Christer Holmberg To: 'Paul Kyzivat' Date: Wed, 31 Mar 2010 22:16:39 +0200 Thread-Topic: [sipcore] SIP OPTIONS: Shall we work on this? Thread-Index: AcrQ2EtgWbHyyQL9T7iPTFfUisPxHwAMuc6w Message-ID: References: <4BB24B81.1050006@nostrum.com> <4BB351BA.5030706@cisco.com> In-Reply-To: <4BB351BA.5030706@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] SIP OPTIONS: Shall we work on this? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 20:16:55 -0000 Hi,=20 >[as chair] > >By accepting the 3xx solution to handling multiple UAs, you have removed t= he most obvious "new feature". There may or may not be other less obvious o= nes lurking in there. For instance, you (and I) have=20 >suggested using Request-Disposition:redirect to "ensure" the 3xx is return= ed. But honoring R-D is optional by the proxy. So at the moment there is no= way to be certain that you are getting info for all=20 >the available UAs.=20 >Anything that somehow made honoring R-D mandatory for OPTIONS would be a n= ew feature. I agree. To clarify, I have not suggested anything that would make honoring R-D mand= atory. I am fully aware that proxies may not do that (due to policy rules, = or the fact that they don't support R-D in the first place). That is true f= or the 3841 mechanism in general. So, if the proxy does not honor R-D, thin= gs will work as today. I am not even sure how we could mandate the proxy to honor R-D. Proxy-Requi= re is bad, since it affects all proxies, and we don't have a Proxy-Require-= If-You-Intend-To-Fork header field :) >Also, there are other cases where the behavior is currently optional/ambig= uous. "Fixing" those to be unambiguous/non-optional can also be construed a= s a *change*. (There is a fine line here about what is=20 >intended by the current texts.) > >It will certainly be easier if no normative changes are required. I agree. Personally, based on the studies and discussions so far, I think a BCP woul= d be enough. Yes, people can claim that the RFC still allows this and that,= but I think that most people do take BCPs into considerations when they de= sign their implementations. >In any case, having you willing to do the work is a good thing. But there = had better also be others that are interested in the work enough to review = and comment on it, and to justify spending list and=20 >meeting time on. Sure. For me the main issue was to find a solution for the forking issue, a= nd the 3xx solution should probably be ok (even if it can't be mandated).=20 I DO think it would be good to document it, and also to document/clarify th= e unambiguous stuff, but if people object I am not going to fight for it, e= venthough I think that it generally is very bad to have that kind of unambi= guous stuff in our protocol speicifcations :) Regards, Christer Christer Holmberg wrote: > Hi, > =20 > Adam, thanks for sending out the the e-mail! > =20 > First, a clarification regarding "new features": > =20 > When we say "new features", I assume (based on Hadriel's comment in=20 > the > meeting) it means the possibility to, with a single OPTIONS request,=20 > retrieve the capabilities from ALL UAS(s) behind a forking proxy -=20 > instead of only one UAS (whoever sends the 200 OK to the forking proxy=20 > first). > =20 > The message I got from the meeting, and also previous e-mail=20 > discussions, was that the "OPTIONS 3xx" solution already provideds=20 > this feature, and that it can be used (without defining new protocol=20 > elements etc). > =20 > So, in my opinion the "adding" word is a little missleading. Instead I=20 > think the question is whether we want to DOCUMENT that existing feature. > =20 > =20 > Second, regarding bugs and interoperability issues in the field.=20 > Personally I am not sure of any major ones at the moment, but that is=20 > probably because OPTIONS haven't been very much deployed in the first=20 > place (it has been used for some keep-alive/ping purposes, but in=20 > those cases it really doesn't matter what comes in the response etc).=20 > Now, however, at least I am starting to get questions regarding the=20 > usage of OPTIONS, so I guess we need to ask ourselves whether we think=20 > the bugs WILL create interoperability issues. > =20 > And, the issue you raised regarding using the re-INVITE to re-create=20 > dialogs ("[sipcore] Mea Culpa: Dialog Necromancy in RFC 3261") also=20 > affects OPTIONS, eventhough you want to keep them separate (which is ok). > =20 > Obviously I am in favor of pursuing the work, and will be willing to=20 > author drafts :) > =20 > Regards, > =20 > Christer > =20 > =20 > =20 >=20 > ---------------------------------------------------------------------- > -- > *From:* sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] *On=20 > Behalf Of *Adam Roach > *Sent:* 30. maaliskuuta 2010 22:06 > *To:* SIPCORE > *Subject:* [sipcore] SIP OPTIONS: Shall we work on this? >=20 > [as chair] >=20 > One of the topics of discussion at the recent face-to-face meeting in=20 > Anaheim was the SIP OPTIONS method. We have had significant discussion=20 > of some specific technical topics on the SIPCORE mailing list, such=20 > that all participants should have a reasonable overview of the scope=20 > that any related work may entail. Participants may also benefit from=20 > reading through the minutes of the corresponding conversation in Anaheim: >=20 > http://www.ietf.org/proceedings/10mar/minutes/sipcore.html#The%20SIP%2 > 0OPTIONS%20Method >=20 > Rather than continue discussion of the specific technical topics=20 > related to OPTIONS, the chairs would encourage the working group to=20 > engage in a discussion around whether we should, as a group, work on=20 > addressing some of the issues that have been identified. >=20 > In particular, we would direct the group to consider the nature of=20 > such > work: >=20 > * Are we proposing to introduce new features, or fix existing bugs? > * If we are adding new features: is OPTIONS the best way to > introduce these features, or would other mechanisms (presence, > callee-caps) produce superior results? > * If we are fixing bugs: are the bugs theoretical, or can we cite > actual interoperability issues in the field? > * If there are identified interoperability issues: is the level of > effort involved in fixing them commensurate with the impact of the > problems?=20 >=20 > Finally, keep in mind that work does not happen unless participants=20 > are willing to invest time. If you speak out in favor of pursuing this=20 > work, please indicate the level of time commitment that you will=20 > personally invest in bringing such work to a successful conclusion=20 > (e.g., will author drafts; will perform dedicated reviews; etc). >=20 > Thanks. >=20 > /a >=20 >=20 > ---------------------------------------------------------------------- > -- >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Wed Mar 31 13:29:42 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05A9B3A685B for ; Wed, 31 Mar 2010 13:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.133 X-Spam-Level: X-Spam-Status: No, score=-4.133 tagged_above=-999 required=5 tests=[AWL=1.335, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 JYnSz16LWpyD for ; Wed, 31 Mar 2010 13:29:41 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 6CA073A6A6C for ; Wed, 31 Mar 2010 13:29:39 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-1e-4bb3b0d17a46 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 7B.99.23532.1D0B3BB4; Wed, 31 Mar 2010 22:30:09 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Wed, 31 Mar 2010 22:30:09 +0200 From: Christer Holmberg To: 'Adam Roach' , SIPCORE Date: Wed, 31 Mar 2010 22:30:08 +0200 Thread-Topic: [sipcore] Consensus Call: SIP Table 2 Thread-Index: AcrQOgLd1kNF4zfJSZm6fYKHyPTX2wA1bz7Q Message-ID: References: <4BB24828.80805@nostrum.com> In-Reply-To: <4BB24828.80805@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_FF84A09F50A6DC48ACB6714F4666CC745E21B5A908ESESSCMS0354e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Consensus Call: SIP Table 2 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 20:29:42 -0000 --_000_FF84A09F50A6DC48ACB6714F4666CC745E21B5A908ESESSCMS0354e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Just to clarify: both alternatives will leave whatever is currently unclear= as it is, and only for new header fields and methods would be make things = clear (whatever mechanism we would use)? And, couldn't alternative 1 result in lots of "defined semantics" - especia= lly if we define a new method and may have to take a large number of header= fields into consideration? Maybe you'll even end up with something that lo= oks like Table 2... Note that I am not objecting to option 1 - I just haven't been able to "pic= ture" it yet :) Regards, Christer ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Adam Roach Sent: 30. maaliskuuta 2010 21:51 To: SIPCORE Subject: [sipcore] Consensus Call: SIP Table 2 [as chair] Last week, at the face-to-face meeting in Anaheim, the SIPCORE participants= in attendance had a discussion regarding the future of Tables 2 and 3 in R= FC 3261. A summary of the conversation, along with links to the presentatio= ns and an audio recording of the conversation, can be found in the minutes: http://www.ietf.org/proceedings/10mar/minutes/sipcore.html#SIP%20Table%202%= 20/%203 During that conversation, the chairs polled those present for support betwe= en two options: 1. Produce an artifact stating that documents defining new header fields = and methods define semantics in prose, and will no longer extend Table 2; o= r 2. Produce an RFC that defines new procedures for adding elements to Tabl= e 2 as new header fields and methods are defined Among those present, there was strong support for option 1. If you wish to = raise an objection to this direction, please do so on the SIPCORE mailing l= ist before April 15th. Thank you. /a --_000_FF84A09F50A6DC48ACB6714F4666CC745E21B5A908ESESSCMS0354e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
Just to clarify: both alternatives will leave what= ever is=20 currently unclear as it is, and only for new header fields and methods woul= d be=20 make things clear (whatever mechanism we would use)?
 
And, couldn't alternative 1 result in lots of "def= ined=20 semantics" - especially if we define a new method and may have to take a la= rge=20 number of header fields into consideration? Maybe you'll even end up with=20 something that looks like Table 2...
 
Note that I am not objecting to option 1 - I just = haven't=20 been able to "picture" it yet :)
 
Regards,
 
Christer

From: sipcore-bounces@ietf.org=20 [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach
Sent= :=20 30. maaliskuuta 2010 21:51
To: SIPCORE
Subject: [sipcor= e]=20 Consensus Call: SIP Table 2

[as chair]

Last week, at the face-to-face meeting in Anah= eim,=20 the SIPCORE participants in attendance had a discussion regarding the futur= e of=20 Tables 2 and 3 in RFC 3261. A summary of the conversation, along with links= to=20 the presentations and an audio recording of the conversation, can be found = in=20 the minutes:

http://www.ietf.org/proceedings/10mar/minutes/sipcore.html= #SIP%20Table%202%20/%203

During=20 that conversation, the chairs polled those present for support between two= =20 options:
  1. Produce an artifact stating that documents defining new header fields= and=20 methods define semantics in prose, and will no longer extend Table 2;=20 or

  2. Produce an RFC that defines new procedures for adding elements to Tab= le 2=20 as new header fields and methods are defined
Among those presen= t,=20 there was strong support for option 1. If you wish to raise an objection to= this=20 direction, please do so on the SIPCORE mailing list before April=20 15th.

Thank you.

/a
--_000_FF84A09F50A6DC48ACB6714F4666CC745E21B5A908ESESSCMS0354e_-- From adam@nostrum.com Wed Mar 31 14:38:32 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B10F3A689A for ; Wed, 31 Mar 2010 14:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[AWL=0.536, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 KoKQnUagV4Bk for ; Wed, 31 Mar 2010 14:38:30 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id E3B4E3A68CC for ; Wed, 31 Mar 2010 14:38:29 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o2VLcvFT015526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Mar 2010 16:38:57 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BB3C0F1.8050900@nostrum.com> Date: Wed, 31 Mar 2010 16:38:57 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Christer Holmberg References: <4BB24828.80805@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030809040708020206060204" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] Consensus Call: SIP Table 2 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 21:38:32 -0000 This is a multi-part message in MIME format. --------------030809040708020206060204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 3/31/10 3:30 PM, Christer Holmberg wrote: > Just to clarify: both alternatives will leave whatever is currently > unclear as it is.... [as individual] In truth, I don't think anything is particularly unclear -- it's just not documented the same way. The documents that didn't expand table 2 while adding new header fields all have prose that describes when the header field can appear. (Yes, I know this, because I looked at every one of them when I did the table 2 expansion that appears in the slides). [as chair] But, yes, the consensus call only deals with actions as they apply to future documents -- such as RFC3265bis -- and does not address actions that would affect RFCs or any other documents that have already cleared IETF review. > And, couldn't alternative 1 result in lots of "defined semantics" - > especially if we define a new method and may have to take a large > number of header fields into consideration? Maybe you'll even end up > with something that looks like Table 2... [as individual again] I don't think so. As Keith has pointed out, statements like "both header fields defined in this document can appear only in methods that create new dialogs" fill out entire swaths of the table all at once. They also have the pleasantly future-proof quality that we don't need to say anything specifically about the header fields when someone creates a new method. A simple evaluation of the new method's properties against the header fields' normative text makes the answer brilliantly clear. /a > Note that I am not objecting to option 1 - I just haven't been able to > "picture" it yet :) > Regards, > Christer > > ------------------------------------------------------------------------ > *From:* sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] *On > Behalf Of *Adam Roach > *Sent:* 30. maaliskuuta 2010 21:51 > *To:* SIPCORE > *Subject:* [sipcore] Consensus Call: SIP Table 2 > > [as chair] > > Last week, at the face-to-face meeting in Anaheim, the SIPCORE > participants in attendance had a discussion regarding the future of > Tables 2 and 3 in RFC 3261. A summary of the conversation, along with > links to the presentations and an audio recording of the conversation, > can be found in the minutes: > > http://www.ietf.org/proceedings/10mar/minutes/sipcore.html#SIP%20Table%202%20/%203 > > During that conversation, the chairs polled those present for support > between two options: > > 1. Produce an artifact stating that documents defining new header > fields and methods define semantics in prose, and will no longer > extend Table 2; or > > 2. Produce an RFC that defines new procedures for adding elements > to Table 2 as new header fields and methods are defined > > Among those present, there was strong support for option 1. If you > wish to raise an objection to this direction, please do so on the > SIPCORE mailing list before April 15th. > > Thank you. > > /a --------------030809040708020206060204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 3/31/10 3:30 PM, Christer Holmberg wrote:
Just to clarify: both alternatives will leave whatever is currently unclear as it is....
[as individual]

In truth, I don't think anything is particularly unclear -- it's just not documented the same way. The documents that didn't expand table 2 while adding new header fields all have prose that describes when the header field can appear. (Yes, I know this, because I looked at every one of them when I did the table 2 expansion that appears in the slides).

[as chair]

But, yes, the consensus call only deals with actions as they apply to future documents -- such as RFC3265bis -- and does not address actions that would affect RFCs or any other documents that have already cleared IETF review.

And, couldn't alternative 1 result in lots of "defined semantics" - especially if we define a new method and may have to take a large number of header fields into consideration? Maybe you'll even end up with something that looks like Table 2...

[as individual again]

I don't think so. As Keith has pointed out, statements like "both header fields defined in this document can appear only in methods that create new dialogs" fill out entire swaths of the table all at once. They also have the pleasantly future-proof quality that we don't need to say anything specifically about the header fields when someone creates a new method. A simple evaluation of the new method's properties against the header fields' normative text makes the answer brilliantly clear.

/a

Note that I am not objecting to option 1 - I just haven't been able to "picture" it yet :)
 
Regards,
 
Christer

From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach
Sent: 30. maaliskuuta 2010 21:51
To: SIPCORE
Subject: [sipcore] Consensus Call: SIP Table 2

[as chair]

Last week, at the face-to-face meeting in Anaheim, the SIPCORE participants in attendance had a discussion regarding the future of Tables 2 and 3 in RFC 3261. A summary of the conversation, along with links to the presentations and an audio recording of the conversation, can be found in the minutes:

http://www.ietf.org/proceedings/10mar/minutes/sipcore.html#SIP%20Table%202%20/%203

During that conversation, the chairs polled those present for support between two options:
  1. Produce an artifact stating that documents defining new header fields and methods define semantics in prose, and will no longer extend Table 2; or

  2. Produce an RFC that defines new procedures for adding elements to Table 2 as new header fields and methods are defined
Among those present, there was strong support for option 1. If you wish to raise an objection to this direction, please do so on the SIPCORE mailing list before April 15th.

Thank you.

/a

--------------030809040708020206060204-- From adam@nostrum.com Wed Mar 31 14:39:03 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D853E3A689A for ; Wed, 31 Mar 2010 14:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.986 X-Spam-Level: X-Spam-Status: No, score=-0.986 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 J3cOnbj-FZG7 for ; Wed, 31 Mar 2010 14:39:03 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id B386A3A6877 for ; Wed, 31 Mar 2010 14:39:02 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o2VLdTtm015574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Mar 2010 16:39:30 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4BB3C111.1070803@nostrum.com> Date: Wed, 31 Mar 2010 16:39:29 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Christer Holmberg References: <4BB25978.3080701@nostrum.com> <4BB35AC3.9060602@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040605000107090903030006" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] Mea Culpa: Dialog Necromancy in RFC 3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Mar 2010 21:39:03 -0000 This is a multi-part message in MIME format. --------------040605000107090903030006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [as individual] On 3/31/10 2:48 PM, Christer Holmberg wrote: > So, you are saying that it is ok to re-crete dialogs using re-INVITEs? No, I'm pointing out that RFC 3261 says that. I have attached no moral value to that normative behavior. Just because SIPCORE is chartered to work on core SIP protocol issues does not obligate us to challenge the validity of the normative statements in RFC 3261 whenever one is mentioned. The role of SIPCORE is to solve clear interoperability problems that people are actually experiencing, and extend the core protocol when doing so helps create new services. It does not serve us well to invent new problems where none exist, nor is it a worthy investment of time to create new tools that cannot be usefully made into actual features. /a --------------040605000107090903030006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit [as individual]

On 3/31/10 2:48 PM, Christer Holmberg wrote:
So, you are saying that it is ok to re-crete dialogs using re-INVITEs?

No, I'm pointing out that RFC 3261 says that. I have attached no moral value to that normative behavior.

Just because SIPCORE is chartered to work on core SIP protocol issues does not obligate us to challenge the validity of the normative statements in RFC 3261 whenever one is mentioned. The role of SIPCORE is to solve clear interoperability problems that people are actually experiencing, and extend the core protocol when doing so helps create new services. It does not serve us well to invent new problems where none exist, nor is it a worthy investment of time to create new tools that cannot be usefully made into actual features.

/a
--------------040605000107090903030006-- From christer.holmberg@ericsson.com Wed Mar 31 23:44:46 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2FBC93A68A2 for ; Wed, 31 Mar 2010 23:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.243 X-Spam-Level: X-Spam-Status: No, score=-4.243 tagged_above=-999 required=5 tests=[AWL=1.226, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 UTW3b-gdpCwx for ; Wed, 31 Mar 2010 23:44:45 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id E4D153A68B7 for ; Wed, 31 Mar 2010 23:44:42 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-92-4bb440f8fbbb Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id D2.1B.23532.8F044BB4; Thu, 1 Apr 2010 08:45:13 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 1 Apr 2010 08:45:13 +0200 From: Christer Holmberg To: Adam Roach Date: Thu, 1 Apr 2010 08:45:11 +0200 Thread-Topic: [sipcore] Consensus Call: SIP Table 2 Thread-Index: AcrRGpOCPmIVaxcjTKqhCZjnjsto0wAR/9mw Message-ID: References: <4BB24828.80805@nostrum.com> <4BB3C0F1.8050900@nostrum.com> In-Reply-To: <4BB3C0F1.8050900@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Consensus Call: SIP Table 2 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 06:44:46 -0000 Hi,=20 >Just to clarify: both alternatives will leave whatever is currently unclea= r as it is.... > =09 > >[as individual] >=09 >In truth, I don't think anything is particularly unclear -- it's just not = documented the same way. The documents that didn't expand table 2 while add= ing new header fields all have prose that=20 >describes when the header field can appear. (Yes, I know this, because I l= ooked at every one of them when I did the table 2 expansion that appears in= the slides). > >So, you are saying that by reading the specs we would be able to complete = the table you had put toghether? >=09 > [as chair] >=09 >But, yes, the consensus call only deals with actions as they apply to futu= re documents -- such as RFC3265bis -- and does not address actions that wou= ld affect RFCs or any other documents that=20 >have already cleared IETF review.=20 >=09 >And, couldn't alternative 1 result in lots of "defined semantics" - especi= ally if we define a new method and may have to take a large number of heade= r fields into consideration? Maybe you'll=20 >even end up with something that looks like Table 2... > > >[as individual again] >=09 >I don't think so. As Keith has pointed out, statements like "both header f= ields defined in this document can appear only in methods that create new d= ialogs" fill out entire swaths of the table=20 >all at once. They also have the pleasantly future-proof quality that we do= n't need to say anything specifically about the header fields when someone = creates a new method. A simple evaluation of=20 >the new method's properties against the header fields' normative text make= s the answer brilliantly clear. Sure. That is fine when you define new headers, and when you define new met= hods and need to cover those new headers. But, when you define a new method, you still also need to consider all "old= " existing header fields - for which we unfortunately do not have statement= s as those suggested by Keith. Take 3265bis as an example, and assume you remove table 2. The text will of= course describe the usage of header fields directly associated with SUB/NO= T, eg. Allow-Events. But, how will you deal with all the other header field= s that we have defined over the years? I am sure there are header fields th= at we do NOT need to cover, because they are associated with specific mecha= nisms (e.g. RSeq and RAck). But, there is a huge number of more "generic" h= eader fields that somehow need to be covered. Anyway, there is only one way to figure out: by doing the work :) Regards, Christer ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f Of Adam Roach Sent: 30. maaliskuuta 2010 21:51 To: SIPCORE Subject: [sipcore] Consensus Call: SIP Table 2 =09 =09 [as chair] =09 Last week, at the face-to-face meeting in Anaheim, the SIPCORE participan= ts in attendance had a discussion regarding the future of Tables 2 and 3 in= RFC 3261. A summary of the conversation, along with links to the presentat= ions and an audio recording of the conversation, can be found in the minute= s: =09 http://www.ietf.org/proceedings/10mar/minutes/sipcore.html#SIP%20Table%20= 2%20/%203 =09 During that conversation, the chairs polled those present for support bet= ween two options: =09 1. Produce an artifact stating that documents defining new header fields = and methods define semantics in prose, and will no longer extend Table 2; o= r =09 =09 2. Produce an RFC that defines new procedures for adding elements to Tabl= e 2 as new header fields and methods are defined=20 Among those present, there was strong support for option 1. If you wish t= o raise an objection to this direction, please do so on the SIPCORE mailing= list before April 15th. =09 Thank you. =09 /a =09 From christer.holmberg@ericsson.com Wed Mar 31 23:57:27 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B82D93A6955 for ; Wed, 31 Mar 2010 23:57:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.278 X-Spam-Level: X-Spam-Status: No, score=-4.278 tagged_above=-999 required=5 tests=[AWL=1.191, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 4YokdjsXcUem for ; Wed, 31 Mar 2010 23:57:27 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id AC9263A6828 for ; Wed, 31 Mar 2010 23:57:26 -0700 (PDT) X-AuditID: c1b4fb3d-b7bf6ae000005bec-4f-4bb443f54f44 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Brightmail Gateway) with SMTP id 47.7C.23532.5F344BB4; Thu, 1 Apr 2010 08:57:57 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.223]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Thu, 1 Apr 2010 08:57:57 +0200 From: Christer Holmberg To: Adam Roach Date: Thu, 1 Apr 2010 08:57:56 +0200 Thread-Topic: [sipcore] Mea Culpa: Dialog Necromancy in RFC 3261 Thread-Index: AcrRGqclOHsORan6TRKhp1oko3lVwAATI/Lw Message-ID: References: <4BB25978.3080701@nostrum.com> <4BB35AC3.9060602@nostrum.com> <4BB3C111.1070803@nostrum.com> In-Reply-To: <4BB3C111.1070803@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Mea Culpa: Dialog Necromancy in RFC 3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2010 06:57:27 -0000 Hi,=20 >>So, you are saying that it is ok to re-crete dialogs using re-INVITEs? > > >No, I'm pointing out that RFC 3261 says that. I have attached no moral val= ue to that normative behavior. >=09 >Just because SIPCORE is chartered to work on core SIP protocol issues does= not obligate us to challenge the validity of the normative statements in R= FC 3261 whenever one is mentioned. The role=20 >of SIPCORE is to solve clear interoperability problems that people are act= ually experiencing, and extend the core protocol when doing so helps create= new services. It does not serve us well to=20 >invent new problems where none exist, nor is it a worthy investment of tim= e to create new tools that cannot be usefully made into actual features. I agree. But, before things are actually deployed, people are writing test specifica= tions, designing protocol procedures for certain features and services, and= they may find that difficult/impossible if the spec is unclear on how enti= ties are supposed to behave. Regards, Christer