From sip-bounces@ietf.org Tue Mar 1 01:37:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25939 for ; Tue, 1 Mar 2005 01:37:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D611b-0003Pe-DT for sip-web-archive@ietf.org; Tue, 01 Mar 2005 01:38:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D60zA-0007AF-KK; Tue, 01 Mar 2005 01:36:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D60z7-0007A4-4K for sip@megatron.ietf.org; Tue, 01 Mar 2005 01:35:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25894 for ; Tue, 1 Mar 2005 01:35:56 -0500 (EST) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D60zw-0003OP-GT for sip@ietf.org; Tue, 01 Mar 2005 01:36:53 -0500 Received: from esealmw142.al.sw.ericsson.se ([153.88.254.119]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j216Zmh5022177 for ; Tue, 1 Mar 2005 07:35:48 +0100 (MET) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw142.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Mar 2005 07:36:34 +0100 Received: from mail.lmf.ericsson.se (dossier.lmf.ericsson.se [131.160.11.13]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id F5NBN06T; Tue, 1 Mar 2005 07:39:42 +0100 Received: from [131.160.37.196] (EFO9N000L5C7100.lmf.ericsson.se [131.160.37.196]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 38639189CC; Tue, 1 Mar 2005 08:35:47 +0200 (EET) Message-ID: <42240D71.4020109@ericsson.com> Date: Tue, 01 Mar 2005 08:36:33 +0200 X-Sybari-Trust: a45f19b9 b8ec86c7 21804147 00000139 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Burger Subject: Re: [Sip] Draft defining the Accept-Disposition header field References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Mar 2005 06:36:34.0469 (UTC) FILETIME=[031D9550:01C51E29] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: sip X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Hi Eric, yes, the draft should reference RFC3459 instead of RFC3204. I will fix that. In any case, the problem remains the same. There is a need for the UAS to indicate what went wrong with the message (i.e., the disposition type of the body part was not supported). Thanks, Gonzalo Eric Burger wrote: > Could you leverage RFC3459? > > >>-----Original Message----- >>From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] >>Sent: Wednesday, January 12, 2005 7:36 AM >>To: sip >>Subject: [Sip] Draft defining the Accept-Disposition header field >> >> >>Folks, >> >>I have submitted a draft that defines the Accept-Disposition header >>field. The usage of this header field would be similar to the >>usage of >>Accept, Accept-Encoding, or Accept-Language, but it would indicate >>support for disposition types. >> >> > > http://www.ietf.org/internet-drafts/draft-camarillo-sip-accept-disposition-0 > 0.txt > > Your comments are welcome. > > Thanks, > > Gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 1 06:59:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16014 for ; Tue, 1 Mar 2005 06:59:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D663C-00013P-7g for sip-web-archive@ietf.org; Tue, 01 Mar 2005 07:00:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D65yZ-0007gN-5i; Tue, 01 Mar 2005 06:55:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D65yX-0007gI-LG for sip@megatron.ietf.org; Tue, 01 Mar 2005 06:55:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15704 for ; Tue, 1 Mar 2005 06:55:39 -0500 (EST) Received: from [80.74.106.10] (helo=rvil-mail.RADVISION.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D65zS-0000x7-Sd for sip@ietf.org; Tue, 01 Mar 2005 06:56:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 1 Mar 2005 13:55:31 +0200 Message-ID: <10DA2C035FE3BC4FA8D73EC55FC43D9B043DEE@rvil-mail.radvision.com> Thread-Topic: mistake in the Tel-Uri syntax Thread-Index: AcUeVY1cmCKJ8kKFQMqXjmZz8uyu/w== From: "Tamar Barzuza" To: , X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80 Subject: [Sip] mistake in the Tel-Uri syntax X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1320586371==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d This is a multi-part message in MIME format. --===============1320586371== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C51E55.9194377C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C51E55.9194377C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 The BNF of Tel-Uri as described in RFC 3966 defines the isdn sub-address parameter as follows: =20 isdn-subaddress =3D ";isub=3D" 1*uric uric =3D reserved / unreserved / pct-encoded reserved =3D ";" / "/" / "?" / ":" / "@" / "&" / "=3D" / "+" = / "$" / "," =20 But this implies that the isub parameter can contain a semicolon, which is used to distinguish between parameters. For example, the following tel-uri can be interpreted in different ways: =20 tel:+97235451122;isub=3DIsrael;exmpl=3Dex =20 Either "Israel;exmpl=3Dex" is the value of the isub parameter, or = "Israel" is the value of the isub parameter and "exmpl" is the name of an extra parameter. =20 Thanks, Tamar Barzuza. ------_=_NextPart_001_01C51E55.9194377C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The BNF of Tel-Uri as described in RFC 3966 defines the isdn sub-address = parameter as follows:

 

isdn-subaddress  =3D ";isub=3D" 1*uric

uric    =                 =3D = reserved / unreserved / pct-encoded

reserved   &n= bsp;         =3D ";" / = "/" / "?" / ":" / "@" / "&" / = "=3D" / "+" / "$" / ","

 

But this implies that the isub parameter can contain a semicolon, which is = used to distinguish between parameters. For example, the following tel-uri can be = interpreted in different ways:

 

tel:+97235451122;isub=3DIsrael;exmpl=3Dex

 

Either "Israel;exmpl=3Dex" is the = value of the isub parameter, or "Israel" = is the value of the isub parameter and "exmpl" is the name of an extra = parameter.

 

Thanks,

Tamar Barzuza.

------_=_NextPart_001_01C51E55.9194377C-- --===============1320586371== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1320586371==-- From sip-bounces@ietf.org Tue Mar 1 09:33:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29378 for ; Tue, 1 Mar 2005 09:33:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D68SQ-0004dN-K8 for sip-web-archive@ietf.org; Tue, 01 Mar 2005 09:34:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D68PB-0004pK-82; Tue, 01 Mar 2005 09:31:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D68P9-0004o6-HC for sip@megatron.ietf.org; Tue, 01 Mar 2005 09:31:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29168 for ; Tue, 1 Mar 2005 09:31:18 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D68Q6-0004ZH-J2 for sip@ietf.org; Tue, 01 Mar 2005 09:32:19 -0500 Received: from [127.0.0.1] (IDENT:U2FsdGVkX190+NG4lSSbJtmxuD7gvjk5zb0p2sw6UUk@razor.cs.columbia.edu [128.59.16.8]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j21EVBh3005028 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 1 Mar 2005 09:31:12 -0500 (EST) Message-ID: <42247C93.2000501@cs.columbia.edu> Date: Tue, 01 Mar 2005 09:30:43 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tamar Barzuza Subject: Re: [Sip] mistake in the Tel-Uri syntax References: <10DA2C035FE3BC4FA8D73EC55FC43D9B043DEE@rvil-mail.radvision.com> In-Reply-To: <10DA2C035FE3BC4FA8D73EC55FC43D9B043DEE@rvil-mail.radvision.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, sip-implementors@cs.columbia.edu X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit RFC 3896 handles this better than 2396 that RFC 3966 had to rely on. This should indeed be written as something like ";isub=" *1 paramchar Tamar Barzuza wrote: > Hi, > > > > The BNF of Tel-Uri as described in RFC 3966 defines the isdn sub-address > parameter as follows: > > > > isdn-subaddress = ";isub=" 1*uric > > uric = reserved / unreserved / pct-encoded > > reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" / > "$" / "," > > > > But this implies that the isub parameter can contain a semicolon, which > is used to distinguish between parameters. For example, the following > tel-uri can be interpreted in different ways: > > > > tel:+97235451122;isub=Israel;exmpl=ex > > > > Either "Israel;exmpl=ex" is the value of the isub parameter, or "Israel" > is the value of the isub parameter and "exmpl" is the name of an extra > parameter. > > > > Thanks, > > Tamar Barzuza. > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 2 02:59:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09766 for ; Wed, 2 Mar 2005 02:59:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6On0-0001RN-5F for sip-web-archive@ietf.org; Wed, 02 Mar 2005 03:01:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Okd-0006i9-BT; Wed, 02 Mar 2005 02:58:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6OkV-0006gS-Eq for sip@megatron.ietf.org; Wed, 02 Mar 2005 02:58:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09678 for ; Wed, 2 Mar 2005 02:58:25 -0500 (EST) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Olb-0001OW-RL for sip@ietf.org; Wed, 02 Mar 2005 02:59:37 -0500 Received: from esealmw143.al.sw.ericsson.se ([153.88.254.118]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j227wFh5026354 for ; Wed, 2 Mar 2005 08:58:17 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw143.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Mar 2005 08:59:03 +0100 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Wed, 2 Mar 2005 08:58:15 +0100 Message-ID: From: "Peter Hedman (LD/EAB)" To: "'Scott Godin'" , "'James M. Polk'" , Scott Godin , sip@ietf.org Subject: RE: [SIP] SDP in OPTIONS Date: Wed, 2 Mar 2005 08:57:20 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 02 Mar 2005 07:59:03.0046 (UTC) FILETIME=[B31C4260:01C51EFD] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Thanks for the comments! Just to be sure that I understood this. RFC3264 states in chapter 9 Indicating Capabilities: "The port MUST be set to zero, but the connection address is arbitrary. The usage of port zero makes sure that an SDP formatted for capabilities does not cause media streams to be established if it is interpreted as an offer or answer." RFC3264 further states the following in chapter 6 "To reject an offered stream, the port number in the corresponding stream in the answer MUST be set to zero." As the SDP in the OPTIONS request would indicate a capability the ports should be set to zero, i.e. UAS can't express whether the media is supported or not as the UAS would always set the ports to zero in the response. Then I hope the following example is correct interpretation: If UAC indicates support for audio and video, the UAC would set the ports to zero in the OPTIONS request. The UAS would then only indicate what it supports in the OPTIONS response, e.g. if only audio the UAC wouldn't include any video m= line and set the port for the audio to zero. BR, Peter > -----Original Message----- > From: Scott Godin [mailto:slgodin@icescape.com] > Sent: den 24 februari 2005 18:13 > To: 'James M. Polk'; Scott Godin; Peter Hedman (LD/EAB); sip@ietf.org > Cc: 'Robert Sparks' > Subject: RE: [SIP] SDP in OPTIONS > > > After re-reading Section 11 of RFC3261 - there doesn't really > seem to be any > definitive answer to this. The following quotes are what I based my > assumptions on: > > "The response code chosen MUST be the same that would have > been chosen had > the request > been an INVITE. That is, a 200 (OK) would be returned if the > UAS is ready to > accept a call, a 486 (Busy > Here) would be returned if the UAS is busy, etc. This allows > an OPTIONS > request to be used to determine > the basic state of a UAS, which can be an indication of > whether the UAS will > accept an INVITE request." > > Technically this quote refers to the response code - but it > would seem to > make sense to apply to the other parts of the options response too. > > "A message body MAY be sent, the type of which is determined > by the Accept > header field in the OPTIONS > request (application/sdp is the default if the Accept header > field is not > present). If the types include one that > can describe media capabilities, the UAS SHOULD include a body in the > response for that purpose. Details > on the construction of such a body in the case of application/sdp are > described in [12]." > > This quote references RFC3264 (SDP Offer Answer) as a > mechanism to form the > SDP response. > > Scott > > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Thursday, February 24, 2005 10:56 AM > To: Scott Godin; 'Peter Hedman (LD/EAB)'; sip@ietf.org > Subject: RE: [SIP] SDP in OPTIONS > > At 08:20 AM 2/24/2005 -0500, Scott Godin wrote: > >My understanding is that if an SDP if provided in the > OPTIONS request the > >SDP in the 200 response should be the same as it would be if > the UA was > >responding to an INVITE request > > I thought the SDP in the 200 OK could/would include all the session > parameters the UAS was willing to reveal (including all the > codecs the UAS > was willing to communicate with). > > > - of course the SDP exchange should not be > >acted on - it is only used for capability discovery. > > > >Scott > > > cheers, > James > > ******************* > Truth is not to be argued... it is to be presented > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 2 04:59:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19872 for ; Wed, 2 Mar 2005 04:59:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6QeR-0003xS-SL for sip-web-archive@ietf.org; Wed, 02 Mar 2005 05:00:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Qbz-00056V-8z; Wed, 02 Mar 2005 04:57:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Qbw-00056L-Vt for sip@megatron.ietf.org; Wed, 02 Mar 2005 04:57:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19633 for ; Wed, 2 Mar 2005 04:57:42 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Qd5-0003vG-23 for sip@ietf.org; Wed, 02 Mar 2005 04:58:55 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 02 Mar 2005 02:10:22 -0800 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j229vTq8023608; Wed, 2 Mar 2005 01:57:30 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-16.cisco.com [10.86.240.16]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AIE10012; Wed, 2 Mar 2005 01:57:31 -0800 (PST) Message-ID: <42258E0B.6020206@cisco.com> Date: Wed, 02 Mar 2005 04:57:31 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peter Hedman (LD/EAB)" Subject: Re: [SIP] SDP in OPTIONS References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, "'James M. Polk'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Content-Transfer-Encoding: 7bit OPTIONS is meant to solicit the capabilities of the UAS, including SIP things (Allow, Accept, Accept-Encoding) and media things (through the SDP in the body). It was not meant to be a way to do some kind of capability negotiation. Indeed, a UAS should reject an OPTIONS request with a body unless the body was marked as optional using the Content-Disposition header field. Putting an SDP in the body of an OPTIONS request, even with an optional content-disposition, feels like a misuse of OPTIONS to me. That said, I don't understand the specific problem 3gpp is looking to solve by including a body in an OPTIONS request. Can you elaborate on that? Thanks, Jonathan R. Peter Hedman (LD/EAB) wrote: > Thanks for the comments! > > Just to be sure that I understood this. > > RFC3264 states in chapter 9 Indicating Capabilities: "The port MUST be set to zero, but the connection address is arbitrary. The usage of port zero makes sure that an SDP formatted for capabilities does not cause media streams to be established if it is interpreted as an offer or answer." > > RFC3264 further states the following in chapter 6 "To reject an offered stream, the port number in the corresponding stream in the answer MUST be set to zero." > > As the SDP in the OPTIONS request would indicate a capability the ports should be set to zero, i.e. UAS can't express whether the media is supported or not as the UAS would always set the ports to zero in the response. > > Then I hope the following example is correct interpretation: > If UAC indicates support for audio and video, the UAC would set the ports to zero in the OPTIONS request. > The UAS would then only indicate what it supports in the OPTIONS response, e.g. if only audio the UAC wouldn't include any video m= line and set the port for the audio to zero. > > BR, > Peter > >>-----Original Message----- >>From: Scott Godin [mailto:slgodin@icescape.com] >>Sent: den 24 februari 2005 18:13 >>To: 'James M. Polk'; Scott Godin; Peter Hedman (LD/EAB); sip@ietf.org >>Cc: 'Robert Sparks' >>Subject: RE: [SIP] SDP in OPTIONS >> >> >>After re-reading Section 11 of RFC3261 - there doesn't really >>seem to be any >>definitive answer to this. The following quotes are what I based my >>assumptions on: >> >>"The response code chosen MUST be the same that would have >>been chosen had >>the request >>been an INVITE. That is, a 200 (OK) would be returned if the >>UAS is ready to >>accept a call, a 486 (Busy >>Here) would be returned if the UAS is busy, etc. This allows >>an OPTIONS >>request to be used to determine >>the basic state of a UAS, which can be an indication of >>whether the UAS will >>accept an INVITE request." >> >>Technically this quote refers to the response code - but it >>would seem to >>make sense to apply to the other parts of the options response too. >> >>"A message body MAY be sent, the type of which is determined >>by the Accept >>header field in the OPTIONS >>request (application/sdp is the default if the Accept header >>field is not >>present). If the types include one that >>can describe media capabilities, the UAS SHOULD include a body in the >>response for that purpose. Details >>on the construction of such a body in the case of application/sdp are >>described in [12]." >> >>This quote references RFC3264 (SDP Offer Answer) as a >>mechanism to form the >>SDP response. >> >>Scott >> >>-----Original Message----- >>From: James M. Polk [mailto:jmpolk@cisco.com] >>Sent: Thursday, February 24, 2005 10:56 AM >>To: Scott Godin; 'Peter Hedman (LD/EAB)'; sip@ietf.org >>Subject: RE: [SIP] SDP in OPTIONS >> >>At 08:20 AM 2/24/2005 -0500, Scott Godin wrote: >> >>>My understanding is that if an SDP if provided in the >> >>OPTIONS request the >> >>>SDP in the 200 response should be the same as it would be if >> >>the UA was >> >>>responding to an INVITE request >> >>I thought the SDP in the 200 OK could/would include all the session >>parameters the UAS was willing to reveal (including all the >>codecs the UAS >>was willing to communicate with). >> >> >>> - of course the SDP exchange should not be >>>acted on - it is only used for capability discovery. >>> >>>Scott >> >> >>cheers, >>James >> >> ******************* >> Truth is not to be argued... it is to be presented >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 2 05:16:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22386 for ; Wed, 2 Mar 2005 05:16:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Qvf-0004Yq-4m for sip-web-archive@ietf.org; Wed, 02 Mar 2005 05:18:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Qta-0007rR-Km; Wed, 02 Mar 2005 05:15:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6QtX-0007rH-5I for sip@megatron.ietf.org; Wed, 02 Mar 2005 05:15:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22216 for ; Wed, 2 Mar 2005 05:15:52 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Quf-0004W7-6R for sip@ietf.org; Wed, 02 Mar 2005 05:17:05 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 02 Mar 2005 02:17:02 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j22AFgYO029044; Wed, 2 Mar 2005 02:15:43 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-16.cisco.com [10.86.240.16]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AIE10817; Wed, 2 Mar 2005 02:15:41 -0800 (PST) Message-ID: <4225924C.6030100@cisco.com> Date: Wed, 02 Mar 2005 05:15:40 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] draft-jennings-sip-hashcash-01 References: <1ECE0EB50388174790F9694F77522CCF01980E18@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF01980E18@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Content-Transfer-Encoding: 7bit Cc: "'Cullen Jennings'" , "'sip@ietf.org'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Content-Transfer-Encoding: 7bit Even with whitelists, I think its a fair problem to ask as to whether one can come up with an amount of hashcash that is sufficiently expensive to stop the rate of spam, yet cheap enough not to totally disrupt legitimate new calls, given the disparity of endpoints. Keep in mind we also have low end UA that run in cell phones and other things, and these may prove even more problematic than a gateway. Unclear which one has the least amount of CPU density, that is, the amount of CPU power available per call. The most recent spam draft is kind of lukewarm on hashcash for these reasons. There are some other issues that one needs to consider, ignoring the big elephant in the corner above: 1. The mechanism interacts badly with forking at the moment. One problem is HERFP. If I have a mix of endpoints, some of which support this (and thus send a 419), and others that don't (and thus ring the phone), then you'll end up always completing the call on the endpoints that don't support the extension. 2. THe mechanism doesn't provide a way for a proxy to aggregate multiple Puzzle headers from forked branches. It needs to do something like WWW-Authenticate where a proxy collects these from the various 419 and places all of them in the 419 forwarded upstream. That will also require something akin to realm, that allows a UA/proxy to pull out its own puzzle. Thanks, Jonathan R. Francois Audet wrote: > Yeah, a white list approach might work. > > The practical scenario that I am thinking about is with a typical VoIP > service provider. > > Today, the vast majority of calls from subscribers terminate on gateways > (owned by the operator of the service). These calls are not to a > specific "user" but really to a gateway, using presumably something like > the tel-URI-in-SIP-URI approach. In this case then, the white list is > not to a whole URI but to "something" that is related to the gateway > itself. This is different from the IM-scenario you quote. > > Now, if we only have to worry about one set of gateways (like the ones > owned by the service provider), I guess you could base the white list on > the domain name or find some other solution. It may be more difficult > when gateways are scattered all over the place (like in an enterprise > for example, or a federation of enterprise, or when it terminates to > another service provider). > > I believe we should make sure that we describe white list properly > before we publish the puzzle mechanism. I have a fear that we could > define something where the people who make the SIP end-devices have an > incentive to do something that is good for them (i.e., limit > vulnerability to spam) but could be very problematic for the Gateways > (or Proxies). Somehow we have to be able to mandate a white list > capabily (or some other mechanism). Otherwise software upgrades could > kill the operator of the service. > > PS: Note that this is a recurring problem with gateways (I think certs > has the same issue). > > -----Original Message----- > *From:* Cullen Jennings [mailto:fluffy@cisco.com] > *Sent:* Friday, February 25, 2005 08:03 > *To:* Audet, Francois [SC100:9T51:EXCH]; sip@ietf.org > *Subject:* Re: [Sip] draft-jennings-sip-hashcash-01 > > > The idea would be to have a very skewed amount of computation to > help rate limit attacks. Whatever amount of computation is > "reasonable" for a valid client to do, an attacker is going to be > able to apply a lot more computation to the problem. However, this > still limits the number of messages the attacker can do and thus > raises the cost. I discuss this some what in the SPAM draft. > > This could all happen in different ways. Imagine a case where my > enterprise proxy compute the puzzles on behalf of my phone when I > call another domain. Say in a large enterprise, it has 10,000 people > and during a busy hour makes 10 calls per second that are to an > address external to the domain. Of these only 2 are not whitelists. > If the enterprise proxy was willing to spend say 3GHz worth of CPU > at computing challenges for these 2cps, well that is a pretty hefty > amount of hash that could be required. > > Another ways is perhaps all the UAC are willing to do about the > amount of hashing that 1 second of G.729 compression would take. > It's hard to imagine that most UAs (even large GWs) could not do > this. This would limit the rate of attack of a single computer to in > the 100s of messages per second. This is a lot less hashing that the > example above but contrast this to what is possible today. Today I > can send in the order of 100,000 message per second. Increasing the > cost of an attack by 1000 is good. It slows it down and give you > time to trace the source and cut it off before it is everywhere. It > makes is less worth while to advertise products that a very very > small percentage of the receivers would buy. > > As discussed in the SPAM draft, you would always want to use white > lists first then if the person was not on the white list fallback to > something else like this. > > Cullen > > > On 2/24/05 11:30 AM, "Francois Audet" wrote: > > We may need to explain some of the limitations of this. It seems > to me that this mechanism would not be terribly appropriate for > applications that aggregate a large number of clients onto a > single platform. For example, this may be too computationally > intensive for a large PSTN Gateway, or even a large Proxy. > > Any ideas of how a UAS would make the decision to send the 419 > without burdening the UAC? Should there be a supported/require > header for this functionality, so that a UAC could "opt out"? > > > > -----Original Message----- > *From:* sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] > *On Behalf Of *Cullen Jennings > *Sent:* Tuesday, February 22, 2005 16:46 > *To:* sip@ietf.org > *Subject:* [Sip] draft-jennings-sip-hashcash-01 > > > I updated this draft on "SIP Computational Puzzles" so it > has enough detail to implement it. (Previous version did > not). It is in the drafts directory and also in HTML form at: > > http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip-hashcash-01.html > > Cullen > > > ------------------------------------------------------------------------ > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 2 10:35:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23419 for ; Wed, 2 Mar 2005 10:35:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Vte-0003KP-DE for sip-web-archive@ietf.org; Wed, 02 Mar 2005 10:36:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6VpJ-00014e-3a; Wed, 02 Mar 2005 10:31:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6VpG-000149-Nb for sip@megatron.ietf.org; Wed, 02 Mar 2005 10:31:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22948 for ; Wed, 2 Mar 2005 10:31:49 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6VqP-0003Bg-9G for sip@ietf.org; Wed, 02 Mar 2005 10:33:05 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 02 Mar 2005 07:45:46 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,130,1107763200"; d="scan'208"; a="617319148:sNHT23475244" Received: from edison.cisco.com (edison.cisco.com [171.71.180.109]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j22FVZq8016086; Wed, 2 Mar 2005 07:31:35 -0800 (PST) Received: from [192.168.1.103] (sjc-vpn7-827.cisco.com [10.21.147.59]) by edison.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA13277; Wed, 2 Mar 2005 07:31:34 -0800 (PST) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF01980E18@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF01980E18@zrc2hxm0.corp.nortel.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <284C5240-8B30-11D9-80C4-0003938AF740@cisco.com> Content-Transfer-Encoding: quoted-printable From: Dan Wing Subject: Re: [Sip] draft-jennings-sip-hashcash-01 Date: Wed, 2 Mar 2005 07:31:33 -0800 To: "Francois Audet" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 Content-Transfer-Encoding: quoted-printable Cc: "'Cullen Jennings'" , "'sip@ietf.org'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0cff8c3ec906d056784362c06f5f88c1 Content-Transfer-Encoding: quoted-printable I agree that proper whitelisting is important to discuss, and maybe =20 even write into an I-D, but not in -hashcash-. Cullen's Hashcash is =20 but one way to handle an incoming call that isn't on your whitelist -- =20= send them a computational challenge. -ietf-sipping-spam- lists other =20= mechanisms. -d On Feb 28, 2005, at 11:26 AM, Francois Audet wrote: > Yeah, a=A0white list approach might work. > =A0 > The practical scenario that I am thinking about is with a typical VoIP = =20 > service provider. > =A0 > Today, the vast majority of calls=A0from subscribers terminate on =20 > gateways (owned by the operator of the service). =A0These calls are = not =20 > to a specific "user" but really to a gateway, using presumably =20 > something like the tel-URI-in-SIP-URI approach. In this case then, the = =20 > white list is not to a whole URI but to "something" that is related to = =20 > the gateway itself. This is different from the IM-scenario you quote. > =A0 > Now, if we only have to worry about one set of gateways (like the ones = =20 > owned by the service provider), I guess you could base the white list =20= > on the domain name or find some other solution. It may be more =20 > difficult when gateways are scattered all over the place (like in an =20= > enterprise for example, or a federation of enterprise, or when it =20 > terminates to another service provider). > =A0 > I believe we should make sure that we describe white list properly =20 > before we publish the puzzle mechanism. I have a fear that we could =20= > define something where the people who make the SIP end-devices have an = =20 > incentive to do something that is good for them (i.e., limit =20 > vulnerability to spam) but could be very problematic for the Gateways =20= > (or Proxies). Somehow we have to be able to mandate a white list =20 > capabily (or some other mechanism). Otherwise software upgrades could =20= > kill the operator of the service. > =A0 > PS: Note that this is a recurring problem with gateways (I think certs = =20 > has the same issue). > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Friday, February 25, 2005 08:03 > To: Audet, Francois [SC100:9T51:EXCH]; sip@ietf.org > Subject: Re: [Sip] draft-jennings-sip-hashcash-01 > > > The idea would be to have a very skewed amount of computation to help =20= > rate limit attacks. Whatever amount of computation is "reasonable" for = =20 > a valid client to do, an attacker is going to be able to apply a lot =20= > more computation to the problem. However, this still limits the number = =20 > of messages the attacker can do and thus raises the cost. I discuss =20= > this some what in the SPAM draft. > > This could all happen in different ways. Imagine a case where my =20 > enterprise proxy compute the puzzles on behalf of my phone when I call = =20 > another domain. Say in a large enterprise, it has 10,000 people and =20= > during a busy hour makes 10 calls per second that are to an address =20= > external to the domain. Of these only 2 are not whitelists. If the =20 > enterprise proxy was willing to spend say 3GHz worth of CPU at =20 > computing challenges for these 2cps, well that is a pretty hefty =20 > amount of hash that could be required. > > Another ways is perhaps all the UAC are willing to do about the amount = =20 > of hashing that 1 second of G.729 compression would take. It's hard to = =20 > imagine that most UAs (even large GWs) could not do this. This would =20= > limit the rate of attack of a single computer to in the 100s of =20 > messages per second. This is a lot less hashing that the example above = =20 > but contrast this to what is possible today. Today I can send in the =20= > order of 100,000 message per second. Increasing the cost of an attack =20= > by 1000 is good. It slows it down and give you time to trace the =20 > source and cut it off before it is everywhere. It makes is less worth =20= > while to advertise products that a very very small percentage of the =20= > receivers would buy. > > As discussed in the SPAM draft, you would always want to use white =20 > lists first then if the person was not on the white list fallback to =20= > something else like this. > > Cullen > > > On 2/24/05 11:30 AM, "Francois Audet" wrote: > > > We may need to explain some of the limitations of this. It seems to me = =20 > that this mechanism would not be terribly appropriate for applications = =20 > that aggregate a large number of clients onto a single platform. For =20= > example, this may be too computationally intensive for a large PSTN =20= > Gateway, or even a large Proxy. > > Any ideas of how a UAS would make the decision to send the 419 without = =20 > burdening the UAC? Should there be a supported/require header for this = =20 > functionality, so that a UAC could "opt out"? > > > =A0 > -----Original Message----- > From: =A0sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf = Of =20 > Cullen =A0Jennings > Sent: Tuesday, February 22, 2005 16:46 > To: =A0sip@ietf.org > Subject: [Sip] =A0draft-jennings-sip-hashcash-01 > > > I updated =A0this draft on "SIP Computational Puzzles" so it has = enough =20 > detail to implement =A0it. (Previous version did not). It is in the =20= > drafts directory and also in HTML =A0form at: > > http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip-=20= > hashcash-01.html > > Cullen > > > _______________________________________________ > Sip mailing list =A0https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip= _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 2 12:42:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07997 for ; Wed, 2 Mar 2005 12:42:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6XsY-0006UD-Lo for sip-web-archive@ietf.org; Wed, 02 Mar 2005 12:43:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Xo0-0001bN-8s; Wed, 02 Mar 2005 12:38:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Xnx-0001bF-Cm for sip@megatron.ietf.org; Wed, 02 Mar 2005 12:38:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07687 for ; Wed, 2 Mar 2005 12:38:33 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Xp8-0006Nm-6e for sip@ietf.org; Wed, 02 Mar 2005 12:39:51 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 02 Mar 2005 10:54:19 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,130,1107734400"; d="scan'208"; a="230770271:sNHT20528984" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j22HcNZV003699; Wed, 2 Mar 2005 09:38:23 -0800 (PST) Received: from cisco.com (che-vpn-cluster-1-154.cisco.com [10.86.240.154]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APM83847; Wed, 2 Mar 2005 12:38:20 -0500 (EST) Message-ID: <4225FA0C.2040605@cisco.com> Date: Wed, 02 Mar 2005 12:38:20 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Burger Subject: Re: [Sip] Draft defining the Accept-Disposition header field References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Eric Burger wrote: >>-----Original Message----- >>From: Cullen Jennings [mailto:fluffy@cisco.com] >>To: gonzalo.camarillo@ericsson.com [snip] >>>The same thing with uri-list bodies. A conference server may support >>>uri-list bodies for some reason, but may not support the >>>'recipient-list' disposition type. The disposition type is > >>what tells me >>>that the conference server supports (or does not support) > >>the feature I >>>want to use. (So far there are two disposition types associated with >>>uri-list bodies and may be more in the future.) >> >>I guess I am wondering if using the MIME dispositions is >>really the right >>way to basically tell the UA what you want it to do with a >>given SIP command >>- what does recipient-list mean in the context of email or >>other users of MIME? > > [snip] > It doesn't have to make any sense whatsoever (SIP vs. E-Mail). What is > important is the disposition is well defined for the given media type. The disposition shouldn't be saying what to do with a *command* (message). It should be saying what to do with (or perhaps 'in what context to intepret') a particular body part, while processing a particular command/message. > I would offer that it might be better to have different names than "inline" > or "render", so it is clear we mean what we mean. I agree. Both are problematic, in that they seem to be meaningful only in contexts that relate to *display* of content. They makes sense in email, and maybe for MESSAGE and in MSRP as well. But not so much in INVITE, SUBSCRIBE, or NOTIFY. Render presents added challenge because it is the *default* disposition for all sip bodies with content type other than sdp. Attempts to clean this up may suffer problems of backward compatibility. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 2 13:54:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13745 for ; Wed, 2 Mar 2005 13:54:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Z0M-0007xS-RQ for sip-web-archive@ietf.org; Wed, 02 Mar 2005 13:55:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Yxf-0004RU-LM; Wed, 02 Mar 2005 13:52:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Yxd-0004RP-Ji for sip@megatron.ietf.org; Wed, 02 Mar 2005 13:52:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13661 for ; Wed, 2 Mar 2005 13:52:38 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Yyq-0007v5-Ai for sip@ietf.org; Wed, 02 Mar 2005 13:53:57 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 02 Mar 2005 12:08:24 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,130,1107734400"; d="asc'?scan'208"; a="230802854:sNHT54528136" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j22IqQq8007305; Wed, 2 Mar 2005 10:52:26 -0800 (PST) Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j22IkSu1007867; Wed, 2 Mar 2005 10:46:28 -0800 Subject: Re: [Sip] draft-jennings-sip-hashcash-01 From: Michael Thomas To: Jonathan Rosenberg In-Reply-To: <4225924C.6030100@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF01980E18@zrc2hxm0.corp.nortel.com> <4225924C.6030100@cisco.com> Organization: Cisco Systems Message-Id: <1109789547.22395.2.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 02 Mar 2005 10:52:27 -0800 IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1109789188.696144"; x:"432200"; a:"rsa-sha1"; b:"nofws:6912"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"NJGYe8IcFFUZIKhmaiVVtbtjWEekYBtQRTKVsJmTrSmzWOmC43qg/89bGrSGQHi/9KMe7BLX" "ls7SUCnI6ClQMrq+bPh8eBG/uFlsksc5FVEU+Ot4ejsFPUrf+wkGbjY/2apD3SjVcpZ2gbulXHz" "MAbnGcucwFyLxo5zGVUcsLFc="; c:"Subject: Re: [Sip] draft-jennings-sip-hashcash-01"; c:"From: Michael Thomas "; c:"Date: Wed, 02 Mar 2005 10:52:27 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: "'Cullen Jennings'" , "'sip@ietf.org'" , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0590242216==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee --===============0590242216== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-DVHLhM66iJMYGnhB9RkB" --=-DVHLhM66iJMYGnhB9RkB Content-Type: text/plain Content-Transfer-Encoding: quoted-printable The big problem I have with hashcash is the advent of=20 zombie armies. With them in mind, about them only thing you do is punish legitimate UA's with itsy-bitsy CPU's, and leave the spammers essentially unaffected=20 with their near limitless CPU resources. Mike On Wed, 2005-03-02 at 02:15, Jonathan Rosenberg wrote: > Even with whitelists, I think its a fair problem to ask as to whether=20 > one can come up with an amount of hashcash that is sufficiently=20 > expensive to stop the rate of spam, yet cheap enough not to totally=20 > disrupt legitimate new calls, given the disparity of endpoints. Keep in=20 > mind we also have low end UA that run in cell phones and other things,=20 > and these may prove even more problematic than a gateway. Unclear which=20 > one has the least amount of CPU density, that is, the amount of CPU=20 > power available per call. >=20 > The most recent spam draft is kind of lukewarm on hashcash for these=20 > reasons. >=20 > There are some other issues that one needs to consider, ignoring the big=20 > elephant in the corner above: >=20 > 1. The mechanism interacts badly with forking at the moment. One problem=20 > is HERFP. If I have a mix of endpoints, some of which support this (and=20 > thus send a 419), and others that don't (and thus ring the phone), then=20 > you'll end up always completing the call on the endpoints that don't=20 > support the extension. >=20 > 2. THe mechanism doesn't provide a way for a proxy to aggregate multiple=20 > Puzzle headers from forked branches. It needs to do something like=20 > WWW-Authenticate where a proxy collects these from the various 419 and=20 > places all of them in the 419 forwarded upstream. That will also require=20 > something akin to realm, that allows a UA/proxy to pull out its own puzzl= e. >=20 >=20 > Thanks, > Jonathan R. >=20 > Francois Audet wrote: >=20 > > Yeah, a white list approach might work. > > =20 > > The practical scenario that I am thinking about is with a typical VoIP=20 > > service provider. > > =20 > > Today, the vast majority of calls from subscribers terminate on gateway= s=20 > > (owned by the operator of the service). These calls are not to a=20 > > specific "user" but really to a gateway, using presumably something lik= e=20 > > the tel-URI-in-SIP-URI approach. In this case then, the white list is=20 > > not to a whole URI but to "something" that is related to the gateway=20 > > itself. This is different from the IM-scenario you quote. > > =20 > > Now, if we only have to worry about one set of gateways (like the ones=20 > > owned by the service provider), I guess you could base the white list o= n=20 > > the domain name or find some other solution. It may be more difficult=20 > > when gateways are scattered all over the place (like in an enterprise=20 > > for example, or a federation of enterprise, or when it terminates to=20 > > another service provider). > > =20 > > I believe we should make sure that we describe white list properly=20 > > before we publish the puzzle mechanism. I have a fear that we could=20 > > define something where the people who make the SIP end-devices have an=20 > > incentive to do something that is good for them (i.e., limit=20 > > vulnerability to spam) but could be very problematic for the Gateways=20 > > (or Proxies). Somehow we have to be able to mandate a white list=20 > > capabily (or some other mechanism). Otherwise software upgrades could=20 > > kill the operator of the service. > > =20 > > PS: Note that this is a recurring problem with gateways (I think certs=20 > > has the same issue). > >=20 > > -----Original Message----- > > *From:* Cullen Jennings [mailto:fluffy@cisco.com] > > *Sent:* Friday, February 25, 2005 08:03 > > *To:* Audet, Francois [SC100:9T51:EXCH]; sip@ietf.org > > *Subject:* Re: [Sip] draft-jennings-sip-hashcash-01 > >=20 > >=20 > > The idea would be to have a very skewed amount of computation to > > help rate limit attacks. Whatever amount of computation is > > "reasonable" for a valid client to do, an attacker is going to be > > able to apply a lot more computation to the problem. However, this > > still limits the number of messages the attacker can do and thus > > raises the cost. I discuss this some what in the SPAM draft. > >=20 > > This could all happen in different ways. Imagine a case where my > > enterprise proxy compute the puzzles on behalf of my phone when I > > call another domain. Say in a large enterprise, it has 10,000 peopl= e > > and during a busy hour makes 10 calls per second that are to an > > address external to the domain. Of these only 2 are not whitelists. > > If the enterprise proxy was willing to spend say 3GHz worth of CPU > > at computing challenges for these 2cps, well that is a pretty hefty > > amount of hash that could be required. > >=20 > > Another ways is perhaps all the UAC are willing to do about the > > amount of hashing that 1 second of G.729 compression would take. > > It's hard to imagine that most UAs (even large GWs) could not do > > this. This would limit the rate of attack of a single computer to i= n > > the 100s of messages per second. This is a lot less hashing that th= e > > example above but contrast this to what is possible today. Today I > > can send in the order of 100,000 message per second. Increasing the > > cost of an attack by 1000 is good. It slows it down and give you > > time to trace the source and cut it off before it is everywhere. It > > makes is less worth while to advertise products that a very very > > small percentage of the receivers would buy. > >=20 > > As discussed in the SPAM draft, you would always want to use white > > lists first then if the person was not on the white list fallback t= o > > something else like this. > >=20 > > Cullen > >=20 > >=20 > > On 2/24/05 11:30 AM, "Francois Audet" wrote: > >=20 > > We may need to explain some of the limitations of this. It seem= s > > to me that this mechanism would not be terribly appropriate for > > applications that aggregate a large number of clients onto a > > single platform. For example, this may be too computationally > > intensive for a large PSTN Gateway, or even a large Proxy. > >=20 > > Any ideas of how a UAS would make the decision to send the 419 > > without burdening the UAC? Should there be a supported/require > > header for this functionality, so that a UAC could "opt out"? > >=20 > >=20 > > =20 > > -----Original Message----- > > *From:* sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] > > *On Behalf Of *Cullen Jennings > > *Sent:* Tuesday, February 22, 2005 16:46 > > *To:* sip@ietf.org > > *Subject:* [Sip] draft-jennings-sip-hashcash-01 > >=20 > >=20 > > I updated this draft on "SIP Computational Puzzles" so it > > has enough detail to implement it. (Previous version did > > not). It is in the drafts directory and also in HTML form = at: > >=20 > > http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jenn= ings-sip-hashcash-01.html > >=20 > > Cullen > >=20 > >=20 > > ---------------------------------------------------------------= --------- > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current s= ip > > Use sipping@ietf.org for new developments on the application of= sip > >=20 > >=20 > >=20 > > -----------------------------------------------------------------------= - > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip --=-DVHLhM66iJMYGnhB9RkB Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUAQiYLa7MsDAj/Eq++AQJOEAQAnTaTRNzX9sHIKB6mjW23TP8wc9FkF3Lf /2SmuVPtj8ocak/0aQebn8qC5T2U4elw3ioiswuTBs/yjOagGc6JKrSCWlBqUitb 4GAbrWNcF1BIQJtgIf1cNU+qnel0eJsDgVMBg4VmSo1RF7+6J6gDYX6mEowxfeMJ VGwxSo+z6N0= =aNVY -----END PGP SIGNATURE----- --=-DVHLhM66iJMYGnhB9RkB-- --===============0590242216== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0590242216==-- From sip-bounces@ietf.org Wed Mar 2 14:03:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14689 for ; Wed, 2 Mar 2005 14:03:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Z9I-0008DI-1l for sip-web-archive@ietf.org; Wed, 02 Mar 2005 14:04:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Z5x-0005lZ-73; Wed, 02 Mar 2005 14:01:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Z5v-0005lS-2K for sip@megatron.ietf.org; Wed, 02 Mar 2005 14:01:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14428 for ; Wed, 2 Mar 2005 14:01:13 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Z77-00088m-5p for sip@ietf.org; Wed, 02 Mar 2005 14:02:30 -0500 Received: from lion.cs.columbia.edu (IDENT:qKOXG7CYXxjC9y2lmYJWy8nB/UQMr/MB@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j22J04ir005383 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 2 Mar 2005 14:00:04 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id j22J03Rn004950 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 2 Mar 2005 14:00:03 -0500 Message-ID: <42260D2E.50503@cs.columbia.edu> Date: Wed, 02 Mar 2005 13:59:58 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Thomas Subject: Re: [Sip] draft-jennings-sip-hashcash-01 References: <1ECE0EB50388174790F9694F77522CCF01980E18@zrc2hxm0.corp.nortel.com> <4225924C.6030100@cisco.com> <1109789547.22395.2.camel@thomasm-lnx.cisco.com> In-Reply-To: <1109789547.22395.2.camel@thomasm-lnx.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: "'Cullen Jennings'" , "'sip@ietf.org'" , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Also, applications like "reverse 911" (community emergency alert systems) would be severely hampered by such approaches. With verifiable source domains and domain-level trust mechanisms, I think we have better tools at hand that don't require the 'make everyone suffer' approach. Michael Thomas wrote: > The big problem I have with hashcash is the advent of > zombie armies. With them in mind, about them only > thing you do is punish legitimate UA's with itsy-bitsy > CPU's, and leave the spammers essentially unaffected > with their near limitless CPU resources. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 2 14:10:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15323 for ; Wed, 2 Mar 2005 14:10:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6ZFm-0008Ny-5n for sip-web-archive@ietf.org; Wed, 02 Mar 2005 14:11:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Z9Y-0006I8-T0; Wed, 02 Mar 2005 14:05:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Z9X-0006I1-0k for sip@megatron.ietf.org; Wed, 02 Mar 2005 14:04:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14879 for ; Wed, 2 Mar 2005 14:04:57 -0500 (EST) Message-Id: <200503021904.OAA14879@ietf.org> Received: from phobos.simply.net ([81.3.64.11]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D6ZAg-0008FW-Ri for sip@ietf.org; Wed, 02 Mar 2005 14:06:14 -0500 Received: (qmail 422 invoked from network); 2 Mar 2005 19:04:40 -0000 Received: from pcp08471369pcs.towson01.md.comcast.net (HELO albers) (69.138.76.154) by phobos.simply.net with SMTP; 2 Mar 2005 19:04:40 -0000 From: "Ken Carlberg" To: "'James M. Polk'" , Subject: RE: [Sip] New Resource Priority Draft (-06) Date: Wed, 2 Mar 2005 14:04:06 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <4.3.2.7.2.20050225112723.035dd6b0@localhost> Thread-Index: AcUbYxW33nQUxhKfSqKiM63C9nGjuAD9Ldrg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.1 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Some minor minor nits... o Section 1 Introduction: (9'th full paragraph) >is busy. The 'Priority' header field does not affect the usage of >GSTN gateway or proxy resources, for example. In addition, any User >Agent Client (UAC) can assert any 'Priority' value, while access to >resource priority values are subject to authorization. Only for the sake of clarity, you may want to change "resource priority" values in the last sentence above to " 'Resource-Priority' header values" as you have done at the start of the 10'th paragraph. It probably helps the reader a bit more in distinguishing the two fields o Section 3.1 The 'Resource-Priority' Header Field: (end of 2'nd para) >There is no protocol requirement that all requests within a SIP >dialog or session use the 'Resource-Priority' header field. Local >administrative policy MAY mandate the inclusion of the 'Resource- >Priority' header field in all requests. Implementations of this >specification MUST allow inclusion to be either by explicit user >request or automatic. The last sentence seems to be dangling a bit with the word "automatic". Would it be fair ato assume that your intention was to say "...automatically by SIP entities"? In any case, a little clarification is probably needed. o Section 4.3 OPTIONS Request with Resource-Priority (2'nd paragraph) >Note that according to RFC 3261, proxies reached with a Max-Forwards >value of zero answer the OPTIONS request, allowing a UAC to discover >the capabilities of both proxy and user agent servers. Should the phrase "value of zero answer" be "value of zero MAY answer"? -ken ps, many thanks for effort in this latest draft _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 2 15:18:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21607 for ; Wed, 2 Mar 2005 15:18:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6aJZ-0001Of-BZ for sip-web-archive@ietf.org; Wed, 02 Mar 2005 15:19:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6aGb-0000YZ-S1; Wed, 02 Mar 2005 15:16:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6aGZ-0000YU-UI for sip@megatron.ietf.org; Wed, 02 Mar 2005 15:16:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21306 for ; Wed, 2 Mar 2005 15:16:17 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6aHm-0001Ly-KZ for sip@ietf.org; Wed, 02 Mar 2005 15:17:35 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 02 Mar 2005 12:15:46 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,131,1107763200"; d="scan'208"; a="164608023:sNHT232228648" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j22KAKTM017514; Wed, 2 Mar 2005 12:10:20 -0800 (PST) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 2 Mar 2005 12:10:19 -0800 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 02 Mar 2005 12:10:15 -0800 From: Cullen Jennings To: "sip@ietf.org" Message-ID: In-Reply-To: <1C38EAC8-8796-11D9-AD2A-0003938AF740@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 02 Mar 2005 20:10:20.0051 (UTC) FILETIME=[DBD7E630:01C51F63] X-Spam-Score: 1.1 (+) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Content-Transfer-Encoding: quoted-printable Cc: Francois Audet , Michael Thomas , Dan Wing Subject: [Sip] jennings-sip-hashcash - does it help - does it work X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af Content-Transfer-Encoding: quoted-printable Long email, but I think it is worth reading..... There have been several comments that this draft does not work. This is of course true - I will go on to prove why it is impossible for anything "to work" then I will explain why I think this helps even though it does not work. The problem we are trying to solve is to let people with no previous relationship contact us and yet not get contacts that we find undesirable. How much is a bad guy willing to spend? Can we make that greater than the amount a good guy can reasonable spend? Let's consider how much bad guys will spend. Founders of acquired startups are often contacted by random financial companies to help manage their new riches. These people offer to fly from New York to San Jose and spend hours taking to you. They are clearly willing to spend in the order of 100s of dollars to contact you. This happens to a very narrow and targeted market. LL Bean is willing to paper mail a gloss catalog to house will reasonable looking demographics. This is order $1. People are willing to send Viagra emails to random email addresses and hope they work. As the costs go down, the volume goes up. Let's consider how much good guys will spend. Some student in Fiji wants to send me an email asking my about my draft. Doubt he will spend much but I would like to get that email. There s no way he will spend the 100s of dollars.=20 So what's our goal here, it's simple - as you raise the cost, you reduce both the good and bad people that are willing to contact you. My assumption would be to make the cost very low such that anyone that had the most pathetic CPU could still contact you in say 10 seconds. A key part of this draft is the person receiving the communications can set this at will. Now what will this do to bad guys - well I argue it will raise their costs. Wil= l it stop the financial advisors, not a hope of it, will it stop the people that do telemarketing today, nope, will it stop Viagra adds, it might. The expected return on those is low, will is stop a single users from ringing every Vonage phone is in 5 seconds before any operator or system can react at 2 am and making Vonage a service that people turn off - probably. It's classic type I/type II error problem and the receiver gets to choose how to balance these two errors. As I clearly say in the SPAM draft - whitelists are the best thing. After that, we need to consider multiple other options - this is one of them. In general there are two camps on why this won't work. One is the bad guys CPU is way way faster than good guys. I think I addressed this above. The other camps is that the bad guy has an army of zombie PC and basically has infinite CPU time and my argument above is bogus. The Luarie/Clayton "Proof of Work Proves not to work" paper is the crescendo of this flawed argument. To understand the problem with this paper, you A needs to assume white lists, and B need to look at a macro not the micro argument. Yes it is true= , some bad guy will have an ton of zombies and get all their stuff thought. However, our goal is not to stop messages from any single one person but to reduce the overall number of bad messages received. I agree with Mike that the Zombie issue is far more worrying to me about the viability of this approach than the relative speeds of various CPU issues. If you assume that some percentage of the machines in the world each year get owned and used as a zombie. Let's say that a given machine has 1% of having this happen to it in a year and it manages to send zombie traffic fo= r 24 hours before it gets shut down and that mechanism here limits it to 10 messages per second. In this case, each machine on the internet will receiv= e an average of about 1 bad msg per hour. If you assume there are more users than machine, this looks appealing. If you assume that msg sending technology detects users that are sending lots of messages and shuts them down in less than 24 ours, it gets better, if you live in the wonderful world of hope that OS might get better or users might pick better OS so there are less zombies, like gets better. The next one is a hard explanatio= n to make mathematical models around but it is true. The people that have the best financial incentive to send bad guy messages, do not what to be subjec= t to the legal and reputation problems of using zombies to get their message across. =20 So in summary, White Listing is your first and best defense. Make sure the Identity work gets done soon. Caller Identity is critical for this - get that work done. However, white list can not be "your first, last and only line of defense" - we have to have something else or give up getting messages from people with no previous direct or indirect relationship. Hashcash can not work in stopping all bad messages - that is not the goal - the goal is to raise the cost thus decrease the number of times it makes economic sense to send bad messages. It does assume that the bad guy will have more CPU than the good guy - and the zombie attacks will be a way to still send lots of messages. However, this will still reduce the number of bad messages - how much - no ones knows. In fact no one will ever know because there is no way to do a controlled experiment. Is it perfect - no. Will it make things better - yes. Noticeably better - n= o one knows. Does someone have a better plan - right now the only think that limits the rate I can ring every SIP phone in the world is proxies getting overloaded. And of course that most sip phones are not connected to the public internet and this is one of the reasons why. There are some other approaches as we outlined in the spam draft. They have different pro's and cons - we probably need to do most of them. Cullen PS - this conversation is more about the spam draft than the hashcash draft= . On 2/25/05 5:31 PM, "Dan Wing" wrote: >=20 > On Feb 25, 2005, at 8:03 AM, Cullen Jennings wrote: >=20 >>=20 >> The idea would be to have a very skewed amount of computation to help >> rate limit attacks. Whatever amount of computation is "reasonable" for >> a valid client to do, an attacker is going to be able to apply a lot >> more computation to the problem. However, this still limits the number >> of messages the attacker can do and thus raises the cost. I discuss >> this some what in the SPAM draft. >>=20 >> This could all happen in different ways. Imagine a case where my >> enterprise proxy compute the puzzles on behalf of my phone when I call >> another domain. Say in a large enterprise, it has 10,000 people and >> during a busy hour makes 10 calls per second that are to an address >> external to the domain. Of these only 2 are not whitelists. If the >> enterprise proxy was willing to spend say 3GHz worth of CPU at >> computing challenges for these 2cps, well that is a pretty hefty >> amount of hash that could be required. >>=20 >> Another ways is perhaps all the UAC are willing to do about the amount >> of hashing that 1 second of G.729 compression would take. It's hard to >> imagine that most UAs (even large GWs) could not do this. This would >> limit the rate of attack of a single computer to in the 100s of >> messages per second. This is a lot less hashing that the example above >> but contrast this to what is possible today. Today I can send in the >> order of 100,000 message per second. Increasing the cost of an attack >> by 1000 is good. It slows it down and give you time to trace the >> source and cut it off before it is everywhere. It makes is less worth >> while to advertise products that a very very small percentage of the >> receivers would buy. >>=20 >> As discussed in the SPAM draft, you would always want to use white >> lists first then if the person was not on the white list fallback to >> something else like this. >=20 > Unstated in either document is the assumption that every legitimate > caller and every spammer has, at their disposal, one and only one > machine that has the CPU capacity of a modern off-the-shelf PC -- "1 > Pentium Unit". If a legitimate user has less, or a spammer has more, I > don't see hashcash being very valuable. >=20 > If a legitimate caller has less than 1 Pentium Unit, it seems that > person is SOL -- they either upgrade their UA, upgrade their SIP proxy > to solve the puzzle for them, buy puzzle-solving MIPS from someone > else, or simply not complete a call to someone with a difficult > challenge? >=20 > I do agree that hashcash makes spamming more expensive, but > significantly more expensive. Today, email spammers own botnets which > are used to send email spam. Tomorrow, SIP spammers can modify those > same botnets to solve hashcash puzzles _and_ send (SIP or email) spam > -- afterall, it isn't computationally-expensive to send email spam > (it's mostly bandwidth), so each PC can do a computational puzzle in > addition to its normal spam duties. And the PCs that a spammer 'owns', > which can't send spam due to a clueful ISP, can still solve hashcash > puzzles on behalf of a SIP spammer. >=20 > And ven without a botnet of PCs, a spammer can buy a workstation with > substantially more than 1 Pentium Unit. And I expect spammers will > write software running on off-the-shelf speciality hardware, such as > graphics accelerators, to solve hashcash puzzles faster than 1 Pentium > Unit. >=20 > -d >=20 >=20 >> Cullen >>=20 >>=20 >> On 2/24/05 11:30 AM, "Francois Audet" wrote: >>=20 >>=20 >> We may need to explain some of the limitations of this. It seems to me >> that this mechanism would not be terribly appropriate for applications >> that aggregate a large number of clients onto a single platform. For >> example, this may be too computationally intensive for a large PSTN >> Gateway, or even a large Proxy. >>=20 >> Any ideas of how a UAS would make the decision to send the 419 without >> burdening the UAC? Should there be a supported/require header for this >> functionality, so that a UAC could "opt out"? >>=20 >>=20 >> =A0 >> -----Original Message----- >> From: =A0sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >> Cullen =A0Jennings >> Sent: Tuesday, February 22, 2005 16:46 >> To: =A0sip@ietf.org >> Subject: [Sip] =A0draft-jennings-sip-hashcash-01 >>=20 >>=20 >> I updated =A0this draft on "SIP Computational Puzzles" so it has enough >> detail to implement =A0it. (Previous version did not). It is in the >> drafts directory and also in HTML =A0form at: >>=20 >> http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip- >> hashcash-01.html >>=20 >> Cullen >>=20 >>=20 >>=20 >> _______________________________________________ >> Sip mailing list =A0https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >>=20 >>=20 >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 2 15:24:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22551 for ; Wed, 2 Mar 2005 15:24:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6aQ9-0001ee-GN for sip-web-archive@ietf.org; Wed, 02 Mar 2005 15:26:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6aFo-0000SF-Fo; Wed, 02 Mar 2005 15:15:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6aFm-0000R6-D3 for sip@megatron.ietf.org; Wed, 02 Mar 2005 15:15:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21118 for ; Wed, 2 Mar 2005 15:15:27 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6aGz-0001Kg-7G for sip@ietf.org; Wed, 02 Mar 2005 15:16:45 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 02 Mar 2005 12:28:11 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j22KFCq8016649; Wed, 2 Mar 2005 12:15:12 -0800 (PST) Received: from cisco.com (che-vpn-cluster-1-154.cisco.com [10.86.240.154]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APN00353; Wed, 2 Mar 2005 15:15:15 -0500 (EST) Message-ID: <42261ED3.6060006@cisco.com> Date: Wed, 02 Mar 2005 15:15:15 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Orit Levin Subject: Re: [Sip] a middle ground approach for knowing AOR of a gruu References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Henning Schulzrinne X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Content-Transfer-Encoding: 7bit Roughly what Orit proposes (using a uri parameter on the AoR) was my original preference way back at the beginning of gruu discussions. I think it would satisfy henning's desire for transparency if we explicitly standardize the particular parameter name used for this purpose. I think there remains a need to *allow* gruus that *don't* expose the associated AoR. There are options here for that: - use a bogus user part, with the parameter containing the key info - use no user part at all, with the parameter containing the key info - continue as has been suggested till now - encode the key info into an opaque user part. Using any of these we would end up with at least two forms - one where the AoR is recoverable, and another where it is not. I prefer a non-recoverable form where it is very clear this is a gruu, but that recovery of the AoR is not intended. Of the above, that would be a uri with no user part, and a parameter. E.g. - - Which form is used by any given gruu provider can remain a private matter. (I'm not too wild about "instance" as the parameter name.) Paul Orit Levin wrote: > What would be wrong with having a GRUU always formatted as the user AOR > with an additional URL parameter carrying the value "making it a GRUU" > and understood by the user domain/registrar only? > > Instead of: > sip:jdrosen.instance.00sd8ggdgdasd===asd9@cisco.com > > Make it: > > > Orit. > > >>-----Original Message----- >>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >>Behalf Of Henning Schulzrinne >>Sent: Thursday, February 24, 2005 5:44 AM >>To: Jonathan Rosenberg >>Cc: sip@ietf.org >>Subject: Re: [Sip] a middle ground approach for knowing AOR of a gruu >> >>I find this sub-optimal from a general design point of view. >>I thought we have had a general preference for being explicit >>about semantics, rather than overloading other elements or >>mechanisms. (See discussions on INFO and other similar >>topics.) I think many of the proposed labeling mechanisms >>would work and supporting at least one, even if somewhat >>arbitrarily selected, will get us to do the right thing in >>the majority of cases. >> >>This is particularly important since this is not just a local >>matter, i.e., other parties not familiar with the conventions >>of the sending side will need to be able to robustly extract >>this information. >> >>Jonathan Rosenberg wrote: >> >>>We had a long discussion in another thread about whether or >> >>not we had >> >>>an additional requirement to allow the recipient of a GRUU >> >>to be able >> >>>to determine the AOR associated with that gruu. This seemed >> >>to be an >> >>>issue for systems that generate call logs or bills, since >> >>you'll have >> >>>these entries that are meaningless. >>> >>>Though I didnt make any changes to gruu in order to meet this >>>requirement, there may be a simple approach that we can >> >>provide that >> >>>fits with the current gruu mechanism. >>> >>>The spec is clear that there are no constraints on how a domain >>>constructs a gruu. The appendix includes a few sample algorithms >>>(though I'll note one of them is broken...). As such, there >> >>is nothing >> >>>wrong with a domain constructing a gruu by including the >> >>instance ID >> >>>and AOR in the clear in the user part of the URI: >>> >>>sip:jdrosen.instance.00sd8ggdgdasd===asd9@cisco.com >>> >>>for example. Thus, we could list such a technique as a viable >>>approach, and recommend that a particular means of encoding >> >>the URI be >> >>>used in order to allow other entities to extract the aor. >>> >>>Thus, we would have a way for the recipient of a domain to >> >>get a hint >> >>>about the possible AOR (no guarantee though), without changing the >>>mechanism at all. >>> >>>Would that represent a reasonable compromise? >>> >>>Thanks, >>>Jonathan R. >> >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol Use >>sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 2 15:31:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23291 for ; Wed, 2 Mar 2005 15:31:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6aWL-0001ss-8q for sip-web-archive@ietf.org; Wed, 02 Mar 2005 15:32:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6aUz-0004CZ-9o; Wed, 02 Mar 2005 15:31:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6aUt-0004CM-M3 for sip@megatron.ietf.org; Wed, 02 Mar 2005 15:31:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23274 for ; Wed, 2 Mar 2005 15:31:05 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6aW7-0001sK-CO for sip@ietf.org; Wed, 02 Mar 2005 15:32:24 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 02 Mar 2005 12:34:14 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,131,1107763200"; d="scan'208"; a="164615051:sNHT8051362128" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j22KSlTM024187; Wed, 2 Mar 2005 12:28:47 -0800 (PST) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 2 Mar 2005 12:28:47 -0800 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 02 Mar 2005 12:28:42 -0800 Subject: Re: [Sip] draft-jennings-sip-hashcash-01 From: Cullen Jennings To: Henning Schulzrinne , Michael Thomas Message-ID: In-Reply-To: <42260D2E.50503@cs.columbia.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Mar 2005 20:28:47.0317 (UTC) FILETIME=[6FD34850:01C51F66] X-Spam-Score: 1.1 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , Francois Audet X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Presumable these services would be white listed and use Identity. On 3/2/05 10:59 AM, "Henning Schulzrinne" wrote: > Also, applications like "reverse 911" (community emergency alert > systems) would be severely hampered by such approaches. With verifiable > source domains and domain-level trust mechanisms, I think we have better > tools at hand that don't require the 'make everyone suffer' approach. > > Michael Thomas wrote: >> The big problem I have with hashcash is the advent of >> zombie armies. With them in mind, about them only >> thing you do is punish legitimate UA's with itsy-bitsy >> CPU's, and leave the spammers essentially unaffected >> with their near limitless CPU resources. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 2 16:03:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26463 for ; Wed, 2 Mar 2005 16:03:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6b1A-0002q4-8K for sip-web-archive@ietf.org; Wed, 02 Mar 2005 16:04:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6awG-0001Ug-84; Wed, 02 Mar 2005 15:59:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6awD-0001UD-JO for sip@megatron.ietf.org; Wed, 02 Mar 2005 15:59:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25925 for ; Wed, 2 Mar 2005 15:59:19 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6axR-0002ZS-59 for sip@ietf.org; Wed, 02 Mar 2005 16:00:38 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 02 Mar 2005 14:15:06 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,131,1107734400"; d="asc'?scan'208"; a="230842755:sNHT46102968" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j22Kx8ZV002641; Wed, 2 Mar 2005 12:59:09 -0800 (PST) Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j22Kr8h0009500; Wed, 2 Mar 2005 12:53:08 -0800 From: Michael Thomas To: Cullen Jennings In-Reply-To: References: Organization: Cisco Systems Message-Id: <1109797147.22395.19.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 02 Mar 2005 12:59:08 -0800 IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1109796788.597347"; x:"432200"; a:"rsa-sha1"; b:"nofws:11153"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"d+J1K6ZcRsZlOAAkNnMpyRJr+BXzI6O14xd7pvUNVGGsAuIrzVmRbvCM2pmBH5vVdS9nNcZp" "Cu1JWdt6OIWlAHYPiZGWpHt0HEBYpfbcLpa5u8egp5nSNHklG8sHbmjCRAMgnKJ+NhXIob2gkra" "SGMIPin1MxofDz6TMGAOymoU="; c:"Subject: Re: jennings-sip-hashcash - does it help - does it work"; c:"From: Michael Thomas "; c:"Date: Wed, 02 Mar 2005 12:59:08 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: abda3837e791065a13ac6f11cf8e625a Cc: "sip@ietf.org" , Francois Audet , Dan Wing Subject: [Sip] Re: jennings-sip-hashcash - does it help - does it work X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0564228930==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a1dc446dc7ac353b90b60743d0e479e3 --===============0564228930== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-C6p0Zh0AFAvKXUTq34/v" --=-C6p0Zh0AFAvKXUTq34/v Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I think you're forgetting to factor in the harm done by such a scheme in whether it's useful or not. That is: what is the percentage of false positives who simply decide to tell your hashcash enabled box to shove it rather than putting their phone into toaster mode for 20 seconds? And then you next need to factor in whether you're actually causing harm to your intended victims. As I said, the advent for free CPU resources for the bad guys and very finite CPU resources for small=20 embedded widgets doesn't seem like you're going to=20 make very worthwhile dent in things. The same is pretty much true with challenge response schemes for email: you need to factor in the number of people who will simply decide that the onerous work you're putting them through is not worth the effort, and... chalk up another false positive. From an enterprise standpoint, I think it's even worse: the false positive rate -- at least at Cisco, but probably elsewhere -- needs to be *very* small. Lastly, I'd be concerned about the transition model here. Not everything is going implement this right away: how do differentiate non-implementers from purposeful non-implementors? Is it realistic to just say no to non-implementors? Especially when you consider that as a PSTN replacement there is a general expectation of call success rather than call failure (unlike, say, IM). Mike On Wed, 2005-03-02 at 12:10, Cullen Jennings wrote: > Long email, but I think it is worth reading..... >=20 > There have been several comments that this draft does not work. This is o= f > course true - I will go on to prove why it is impossible for anything "to > work" then I will explain why I think this helps even though it does not > work. >=20 > The problem we are trying to solve is to let people with no previous > relationship contact us and yet not get contacts that we find undesirable= . > How much is a bad guy willing to spend? Can we make that greater than the > amount a good guy can reasonable spend? >=20 > Let's consider how much bad guys will spend. Founders of acquired startup= s > are often contacted by random financial companies to help manage their ne= w > riches. These people offer to fly from New York to San Jose and spend hou= rs > taking to you. They are clearly willing to spend in the order of 100s of > dollars to contact you. This happens to a very narrow and targeted market= . > LL Bean is willing to paper mail a gloss catalog to house will reasonable > looking demographics. This is order $1. People are willing to send Viagra > emails to random email addresses and hope they work. As the costs go down= , > the volume goes up. >=20 > Let's consider how much good guys will spend. Some student in Fiji wants = to > send me an email asking my about my draft. Doubt he will spend much but I > would like to get that email. There s no way he will spend the 100s of > dollars.=20 >=20 > So what's our goal here, it's simple - as you raise the cost, you reduce > both the good and bad people that are willing to contact you. My assumpti= on > would be to make the cost very low such that anyone that had the most > pathetic CPU could still contact you in say 10 seconds. A key part of thi= s > draft is the person receiving the communications can set this at will. No= w > what will this do to bad guys - well I argue it will raise their costs. W= ill > it stop the financial advisors, not a hope of it, will it stop the people > that do telemarketing today, nope, will it stop Viagra adds, it might. Th= e > expected return on those is low, will is stop a single users from ringing > every Vonage phone is in 5 seconds before any operator or system can reac= t > at 2 am and making Vonage a service that people turn off - probably. It's > classic type I/type II error problem and the receiver gets to choose how = to > balance these two errors. >=20 > As I clearly say in the SPAM draft - whitelists are the best thing. After > that, we need to consider multiple other options - this is one of them. >=20 > In general there are two camps on why this won't work. One is the bad guy= s > CPU is way way faster than good guys. I think I addressed this above. The > other camps is that the bad guy has an army of zombie PC and basically ha= s > infinite CPU time and my argument above is bogus. The Luarie/Clayton "Pro= of > of Work Proves not to work" paper is the crescendo of this flawed argumen= t. > To understand the problem with this paper, you A needs to assume white > lists, and B need to look at a macro not the micro argument. Yes it is tr= ue, > some bad guy will have an ton of zombies and get all their stuff thought. > However, our goal is not to stop messages from any single one person but = to > reduce the overall number of bad messages received. I agree with Mike tha= t > the Zombie issue is far more worrying to me about the viability of this > approach than the relative speeds of various CPU issues. >=20 > If you assume that some percentage of the machines in the world each year > get owned and used as a zombie. Let's say that a given machine has 1% of > having this happen to it in a year and it manages to send zombie traffic = for > 24 hours before it gets shut down and that mechanism here limits it to 10 > messages per second. In this case, each machine on the internet will rece= ive > an average of about 1 bad msg per hour. If you assume there are more user= s > than machine, this looks appealing. If you assume that msg sending > technology detects users that are sending lots of messages and shuts them > down in less than 24 ours, it gets better, if you live in the wonderful > world of hope that OS might get better or users might pick better OS so > there are less zombies, like gets better. The next one is a hard explanat= ion > to make mathematical models around but it is true. The people that have t= he > best financial incentive to send bad guy messages, do not what to be subj= ect > to the legal and reputation problems of using zombies to get their messag= e > across. =20 >=20 > So in summary, White Listing is your first and best defense. Make sure th= e > Identity work gets done soon. Caller Identity is critical for this - get > that work done. However, white list can not be "your first, last and only > line of defense" - we have to have something else or give up getting > messages from people with no previous direct or indirect relationship. > Hashcash can not work in stopping all bad messages - that is not the goal= - > the goal is to raise the cost thus decrease the number of times it makes > economic sense to send bad messages. It does assume that the bad guy will > have more CPU than the good guy - and the zombie attacks will be a way to > still send lots of messages. However, this will still reduce the number o= f > bad messages - how much - no ones knows. In fact no one will ever know > because there is no way to do a controlled experiment. >=20 > Is it perfect - no. Will it make things better - yes. Noticeably better -= no > one knows. Does someone have a better plan - right now the only think tha= t > limits the rate I can ring every SIP phone in the world is proxies gettin= g > overloaded. And of course that most sip phones are not connected to the > public internet and this is one of the reasons why. There are some other > approaches as we outlined in the spam draft. They have different pro's an= d > cons - we probably need to do most of them. >=20 >=20 > Cullen >=20 >=20 > PS - this conversation is more about the spam draft than the hashcash dra= ft. >=20 > On 2/25/05 5:31 PM, "Dan Wing" wrote: >=20 > >=20 > > On Feb 25, 2005, at 8:03 AM, Cullen Jennings wrote: > >=20 > >>=20 > >> The idea would be to have a very skewed amount of computation to help > >> rate limit attacks. Whatever amount of computation is "reasonable" for > >> a valid client to do, an attacker is going to be able to apply a lot > >> more computation to the problem. However, this still limits the number > >> of messages the attacker can do and thus raises the cost. I discuss > >> this some what in the SPAM draft. > >>=20 > >> This could all happen in different ways. Imagine a case where my > >> enterprise proxy compute the puzzles on behalf of my phone when I call > >> another domain. Say in a large enterprise, it has 10,000 people and > >> during a busy hour makes 10 calls per second that are to an address > >> external to the domain. Of these only 2 are not whitelists. If the > >> enterprise proxy was willing to spend say 3GHz worth of CPU at > >> computing challenges for these 2cps, well that is a pretty hefty > >> amount of hash that could be required. > >>=20 > >> Another ways is perhaps all the UAC are willing to do about the amount > >> of hashing that 1 second of G.729 compression would take. It's hard to > >> imagine that most UAs (even large GWs) could not do this. This would > >> limit the rate of attack of a single computer to in the 100s of > >> messages per second. This is a lot less hashing that the example above > >> but contrast this to what is possible today. Today I can send in the > >> order of 100,000 message per second. Increasing the cost of an attack > >> by 1000 is good. It slows it down and give you time to trace the > >> source and cut it off before it is everywhere. It makes is less worth > >> while to advertise products that a very very small percentage of the > >> receivers would buy. > >>=20 > >> As discussed in the SPAM draft, you would always want to use white > >> lists first then if the person was not on the white list fallback to > >> something else like this. > >=20 > > Unstated in either document is the assumption that every legitimate > > caller and every spammer has, at their disposal, one and only one > > machine that has the CPU capacity of a modern off-the-shelf PC -- "1 > > Pentium Unit". If a legitimate user has less, or a spammer has more, I > > don't see hashcash being very valuable. > >=20 > > If a legitimate caller has less than 1 Pentium Unit, it seems that > > person is SOL -- they either upgrade their UA, upgrade their SIP proxy > > to solve the puzzle for them, buy puzzle-solving MIPS from someone > > else, or simply not complete a call to someone with a difficult > > challenge? > >=20 > > I do agree that hashcash makes spamming more expensive, but > > significantly more expensive. Today, email spammers own botnets which > > are used to send email spam. Tomorrow, SIP spammers can modify those > > same botnets to solve hashcash puzzles _and_ send (SIP or email) spam > > -- afterall, it isn't computationally-expensive to send email spam > > (it's mostly bandwidth), so each PC can do a computational puzzle in > > addition to its normal spam duties. And the PCs that a spammer 'owns', > > which can't send spam due to a clueful ISP, can still solve hashcash > > puzzles on behalf of a SIP spammer. > >=20 > > And ven without a botnet of PCs, a spammer can buy a workstation with > > substantially more than 1 Pentium Unit. And I expect spammers will > > write software running on off-the-shelf speciality hardware, such as > > graphics accelerators, to solve hashcash puzzles faster than 1 Pentium > > Unit. > >=20 > > -d > >=20 > >=20 > >> Cullen > >>=20 > >>=20 > >> On 2/24/05 11:30 AM, "Francois Audet" wrote: > >>=20 > >>=20 > >> We may need to explain some of the limitations of this. It seems to me > >> that this mechanism would not be terribly appropriate for applications > >> that aggregate a large number of clients onto a single platform. For > >> example, this may be too computationally intensive for a large PSTN > >> Gateway, or even a large Proxy. > >>=20 > >> Any ideas of how a UAS would make the decision to send the 419 without > >> burdening the UAC? Should there be a supported/require header for this > >> functionality, so that a UAC could "opt out"? > >>=20 > >>=20 > >> =20 > >> -----Original Message----- > >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > >> Cullen Jennings > >> Sent: Tuesday, February 22, 2005 16:46 > >> To: sip@ietf.org > >> Subject: [Sip] draft-jennings-sip-hashcash-01 > >>=20 > >>=20 > >> I updated this draft on "SIP Computational Puzzles" so it has enough > >> detail to implement it. (Previous version did not). It is in the > >> drafts directory and also in HTML form at: > >>=20 > >> http://scm.sipfoundry.org/rep/ietf-drafts/fluffy/draft-jennings-sip- > >> hashcash-01.html > >>=20 > >> Cullen > >>=20 > >>=20 > >>=20 > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > >>=20 > >>=20 > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip --=-C6p0Zh0AFAvKXUTq34/v Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUAQiYpG7MsDAj/Eq++AQJ/kAP+KkMhaonTMqEE45h/+Z0pN3KuUkoMfx/I L1+bdnTSXlhq6op419a5OdWttH9d6jz2djUDfP5UmIGvpJ+wUPUvd2et69V5BwN/ r5ZCZUtnB4tIwAWd0ekGxMN8T3BuyoAaVodem+rB9gsO8JDlO6v399UIMvCe5xyZ UCbM/11Oc7Q= =H3hg -----END PGP SIGNATURE----- --=-C6p0Zh0AFAvKXUTq34/v-- --===============0564228930== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0564228930==-- From sip-bounces@ietf.org Wed Mar 2 16:04:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21604 for ; Wed, 2 Mar 2005 15:18:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6aJZ-0001Oe-B1 for sip-web-archive@ietf.org; Wed, 02 Mar 2005 15:19:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6aGN-0000X4-Ih; Wed, 02 Mar 2005 15:16:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6aGM-0000WR-62 for sip@megatron.ietf.org; Wed, 02 Mar 2005 15:16:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21255 for ; Wed, 2 Mar 2005 15:16:03 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6aHY-0001LN-CV for sip@ietf.org; Wed, 02 Mar 2005 15:17:21 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 02 Mar 2005 21:34:51 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j22KFplu017503; Wed, 2 Mar 2005 21:15:52 +0100 (MET) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 2 Mar 2005 12:15:50 -0800 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 02 Mar 2005 12:15:46 -0800 Subject: Re: [Sip] draft-jennings-sip-hashcash-01 From: Cullen Jennings To: Jonathan Rosenberg Message-ID: In-Reply-To: <4225924C.6030100@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 02 Mar 2005 20:15:50.0697 (UTC) FILETIME=[A0EC7990:01C51F64] X-Spam-Score: 1.1 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit On 3/2/05 2:15 AM, "Jonathan Rosenberg" wrote: > 1. The mechanism interacts badly with forking at the moment. One problem > is HERFP. If I have a mix of endpoints, some of which support this (and > thus send a 419), and others that don't (and thus ring the phone), then > you'll end up always completing the call on the endpoints that don't > support the extension. Good point. I think will mention this in the draft but clearly I won't attempt to solve the well studied HERFP problem. As a separate issues, some day the WG should discuss the limitations of the "If it hurts don't do it" solution to the HERFP problem. > > 2. THe mechanism doesn't provide a way for a proxy to aggregate multiple > Puzzle headers from forked branches. It needs to do something like > WWW-Authenticate where a proxy collects these from the various 419 and > places all of them in the 419 forwarded upstream. That will also require > something akin to realm, that allows a UA/proxy to pull out its own puzzle. Oops. Excellent point. Thanks, will fix this. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 2 16:24:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28576 for ; Wed, 2 Mar 2005 16:24:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6bLk-0003Rd-NR for sip-web-archive@ietf.org; Wed, 02 Mar 2005 16:25:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6bHz-0006ul-9c; Wed, 02 Mar 2005 16:21:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6bHx-0006uc-Ok for sip@megatron.ietf.org; Wed, 02 Mar 2005 16:21:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28337 for ; Wed, 2 Mar 2005 16:21:47 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6bJB-0003NA-0z for sip@ietf.org; Wed, 02 Mar 2005 16:23:06 -0500 Received: from lion.cs.columbia.edu (IDENT:ixyysLWqX5tDzpjdFK2cHwJeahQX8GP8@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j22LLiir000773 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Wed, 2 Mar 2005 16:21:45 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id j22LLiRn013767 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 2 Mar 2005 16:21:44 -0500 Message-ID: <42262E63.2030606@cs.columbia.edu> Date: Wed, 02 Mar 2005 16:21:39 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] draft-jennings-sip-hashcash-01 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit They could, but are unlikely to be, simply because people won't remember to put all of the services they subscribed to into their whitelists, particularly ones that they are not going to hear from regularly. Even if the large majority of people were to whitelist the service, a modest fraction of forgetful users would significantly slow down the system as it would have to deal with thousands of destinations. (Similar considerations, with less of life-and-death flavor, apply to all kinds of notification systems, from airline flight notification to school closings.) Depending on where the hashcash is computed, one would have to do the whitelisting on every new device. We can't even synchronize cell phone address books reliably... Before we recommend that we waste computing resources across the Internet, with dubious performance, it seems appropriate to investigate socially more responsible alternatives. Cullen Jennings wrote: > Presumable these services would be white listed and use Identity. > > > On 3/2/05 10:59 AM, "Henning Schulzrinne" wrote: > > >>Also, applications like "reverse 911" (community emergency alert >>systems) would be severely hampered by such approaches. With verifiable >>source domains and domain-level trust mechanisms, I think we have better >>tools at hand that don't require the 'make everyone suffer' approach. >> >>Michael Thomas wrote: >> >>>The big problem I have with hashcash is the advent of >>>zombie armies. With them in mind, about them only >>>thing you do is punish legitimate UA's with itsy-bitsy >>>CPU's, and leave the spammers essentially unaffected >>>with their near limitless CPU resources. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 2 17:56:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07612 for ; Wed, 2 Mar 2005 17:56:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6cmX-0005ga-Ei for sip-web-archive@ietf.org; Wed, 02 Mar 2005 17:57:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6cl2-0000eL-KP; Wed, 02 Mar 2005 17:55:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6cl1-0000eG-85 for sip@megatron.ietf.org; Wed, 02 Mar 2005 17:55:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07609 for ; Wed, 2 Mar 2005 17:55:52 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6cmF-0005gO-DW for sip@ietf.org; Wed, 02 Mar 2005 17:57:12 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 02 Mar 2005 16:11:40 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,131,1107734400"; d="scan'208"; a="230881096:sNHT19891760" Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j22MtgZV006617; Wed, 2 Mar 2005 14:55:42 -0800 (PST) Received: from [161.44.55.123] (dhcp-161-44-55-123.cisco.com [161.44.55.123]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AIE65048; Wed, 2 Mar 2005 14:55:41 -0800 (PST) Message-ID: <4226446D.5040207@cisco.com> Date: Wed, 02 Mar 2005 17:55:41 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Thomas References: <1109797147.22395.19.camel@thomasm-lnx.cisco.com> In-Reply-To: <1109797147.22395.19.camel@thomasm-lnx.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , "sip@ietf.org" , Francois Audet , Dan Wing Subject: [Sip] Re: jennings-sip-hashcash - does it help - does it work X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit inline. Michael Thomas wrote: > Lastly, I'd be concerned about the transition > model here. Not everything is going implement this > right away: how do differentiate non-implementers from > purposeful non-implementors? Is it realistic to just > say no to non-implementors? Especially when you consider > that as a PSTN replacement there is a general expectation > of call success rather than call failure (unlike, say, > IM). Transition is a big deal, I agree. I think here, the answer is that if the caller claims that they don't do hashcash, you probably need to fall back into other mechanisms for dealing with anti-spam, such as the consent framework or a reputation system. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 2 19:42:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18507 for ; Wed, 2 Mar 2005 19:42:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6eRe-00084h-Cc for sip-web-archive@ietf.org; Wed, 02 Mar 2005 19:44:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6ePB-000655-LM; Wed, 02 Mar 2005 19:41:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6ePA-00064x-JT for sip@megatron.ietf.org; Wed, 02 Mar 2005 19:41:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18366 for ; Wed, 2 Mar 2005 19:41:24 -0500 (EST) Received: from grads.ece.mcmaster.ca ([130.113.10.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6eQP-00082U-In for sip@ietf.org; Wed, 02 Mar 2005 19:42:46 -0500 Received: from [192.168.2.8] ([130.113.184.38]) by grads.ece.mcmaster.ca (8.12.8/8.12.8) with ESMTP id j230fBF4004087 for ; Wed, 2 Mar 2005 19:41:11 -0500 Message-ID: <42265D4D.8090702@grads.ece.mcmaster.ca> Date: Wed, 02 Mar 2005 19:41:49 -0500 From: "M.N.A.Smadi" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Subject: [Sip] REFER request X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit hi; if we have A<->B then A refer B to C, who is going to be charged for the cost of the new call (namely, B<->C) thanks m.smadi _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 2 22:38:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03159 for ; Wed, 2 Mar 2005 22:38:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6hBj-0003A3-Jo for sip-web-archive@ietf.org; Wed, 02 Mar 2005 22:39:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6h3v-00028Y-FQ; Wed, 02 Mar 2005 22:31:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6h3t-00028O-1a for sip@megatron.ietf.org; Wed, 02 Mar 2005 22:31:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02379 for ; Wed, 2 Mar 2005 22:31:38 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6h59-0002x0-OM for sip@ietf.org; Wed, 02 Mar 2005 22:33:01 -0500 Received: from [127.0.0.1] (IDENT:U2FsdGVkX1/RffPGwFHovILxBRClUsCmb/NgnN7Fz2s@razor.cs.columbia.edu [128.59.16.8]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j233VVh3002959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 2 Mar 2005 22:31:32 -0500 (EST) Message-ID: <42268511.4080708@cs.columbia.edu> Date: Wed, 02 Mar 2005 22:31:29 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ken Carlberg Subject: Re: [Sip] New Resource Priority Draft (-06) References: <200503021904.OAA14879@ietf.org> In-Reply-To: <200503021904.OAA14879@ietf.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CHILD_PORN_NOT_1 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, "'James M. Polk'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Ken Carlberg wrote: > Only for the sake of clarity, you may want to change "resource priority" > values in the last sentence above to " 'Resource-Priority' header values" > as you have done at the start of the 10'th paragraph. It probably helps > the reader a bit more in distinguishing the two fields Reworded. > > > o Section 3.1 The 'Resource-Priority' Header Field: (end of 2'nd para) > > >There is no protocol requirement that all requests within a SIP > >dialog or session use the 'Resource-Priority' header field. Local > >administrative policy MAY mandate the inclusion of the 'Resource- > >Priority' header field in all requests. Implementations of this > >specification MUST allow inclusion to be either by explicit user > >request or automatic. > > The last sentence seems to be dangling a bit with the word "automatic". > Would it be fair ato assume that your intention was to say > "...automatically by SIP entities"? In any case, a little > clarification is probably needed. Indeed; wording changed. > > > o Section 4.3 OPTIONS Request with Resource-Priority (2'nd paragraph) > > >Note that according to RFC 3261, proxies reached with a Max-Forwards > >value of zero answer the OPTIONS request, allowing a UAC to discover > >the capabilities of both proxy and user agent servers. > > Should the phrase "value of zero answer" be "value of zero MAY answer"? Agreed; reworded for clarity. > > -ken > > ps, many thanks for effort in this latest draft Thanks for your comments. Henning _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 3 01:08:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15014 for ; Thu, 3 Mar 2005 01:08:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6jX6-0006AD-KL for sip-web-archive@ietf.org; Thu, 03 Mar 2005 01:10:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6jQA-0008Ia-Up; Thu, 03 Mar 2005 01:02:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6jQ8-0008I0-8F for sip@megatron.ietf.org; Thu, 03 Mar 2005 01:02:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14643 for ; Thu, 3 Mar 2005 01:02:47 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6jRQ-000621-CR for sip@ietf.org; Thu, 03 Mar 2005 01:04:09 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 02 Mar 2005 22:04:03 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j2362RYY028098; Wed, 2 Mar 2005 22:02:36 -0800 (PST) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 2 Mar 2005 22:02:30 -0800 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 02 Mar 2005 21:47:23 -0800 From: Cullen Jennings To: Robert Sparks , "sip@ietf.org" Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Mar 2005 06:02:31.0026 (UTC) FILETIME=[95F46D20:01C51FB6] X-Spam-Score: 1.1 (+) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Subject: [Sip] time formula in sip-nit-future-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit I prefer Alternative A to B. I can see how you got the formula you got but I think it is too pessimistic. I would change the formula to 64*T1 - (2*HE + IPD)*(n_Via-1) Where HE is the estimate of average hop time. And I would default HE = 0.1 (this is a VoIP grade network) IPD= 0.2 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 3 01:09:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15096 for ; Thu, 3 Mar 2005 01:09:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6jXs-0006Bn-G1 for sip-web-archive@ietf.org; Thu, 03 Mar 2005 01:10:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6jQ8-0008I5-SR; Thu, 03 Mar 2005 01:02:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6jQ6-0008Hu-FI for sip@megatron.ietf.org; Thu, 03 Mar 2005 01:02:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14640 for ; Thu, 3 Mar 2005 01:02:45 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6jRO-00061y-Jx for sip@ietf.org; Thu, 03 Mar 2005 01:04:07 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 02 Mar 2005 22:08:23 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,131,1107763200"; d="scan'208"; a="164716703:sNHT23017100" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j2362RYW028098; Wed, 2 Mar 2005 22:02:34 -0800 (PST) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 2 Mar 2005 22:02:30 -0800 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 02 Mar 2005 21:43:07 -0800 From: Cullen Jennings To: "sip@ietf.org" , Orit Levin Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Mar 2005 06:02:30.0557 (UTC) FILETIME=[95ACDCD0:01C51FB6] X-Spam-Score: 1.1 (+) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Subject: [Sip] Comment on refer-with-norefersub-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit It seems like in any case where you put a Require with the option tag, it results in far more traffic and less chance of interoperability than creating the subscription and instantly ending it. I think you should say that the tag is not allowed in a Require. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 3 01:09:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15136 for ; Thu, 3 Mar 2005 01:09:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6jY2-0006CG-UL for sip-web-archive@ietf.org; Thu, 03 Mar 2005 01:11:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6jPa-0008H2-L3; Thu, 03 Mar 2005 01:02:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6jPX-0008Gx-78 for sip@megatron.ietf.org; Thu, 03 Mar 2005 01:02:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14602 for ; Thu, 3 Mar 2005 01:02:10 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6jQp-00061S-9V for sip@ietf.org; Thu, 03 Mar 2005 01:03:32 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 02 Mar 2005 22:07:48 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,131,1107763200"; d="scan'208"; a="164716620:sNHT19312148" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j2361wYO027982; Wed, 2 Mar 2005 22:01:58 -0800 (PST) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 2 Mar 2005 22:01:57 -0800 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 02 Mar 2005 22:01:52 -0800 Subject: Re: [Sip] Agenda for SIP at IETF 62 From: Cullen Jennings To: Dean Willis , "sip@ietf.org" Message-ID: In-Reply-To: <314075180f0439b805dd396a7ac1a868@softarmor.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Mar 2005 06:01:58.0041 (UTC) FILETIME=[824B5090:01C51FB6] X-Spam-Score: 1.1 (+) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Cc: Rohan Mahy , "gonzalo.camarillo@ericsson.com" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit On 2/28/05 7:55 AM, "Dean Willis" wrote: > draft-ietf-sip-refer-with-feature-param-01.txt I can't find this draft. Why is it on the agenda? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 3 01:11:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15560 for ; Thu, 3 Mar 2005 01:11:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6jZs-0006KB-Sd for sip-web-archive@ietf.org; Thu, 03 Mar 2005 01:12:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6jQG-0008JK-BW; Thu, 03 Mar 2005 01:02:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6jQA-0008IV-Kf for sip@megatron.ietf.org; Thu, 03 Mar 2005 01:02:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14651 for ; Thu, 3 Mar 2005 01:02:49 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6jRT-000621-KN for sip@ietf.org; Thu, 03 Mar 2005 01:04:11 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 02 Mar 2005 22:04:11 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j2362RYg028098; Wed, 2 Mar 2005 22:02:43 -0800 (PST) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 2 Mar 2005 22:02:32 -0800 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 02 Mar 2005 21:52:39 -0800 From: Cullen Jennings To: Rohan Mahy Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Mar 2005 06:02:32.0057 (UTC) FILETIME=[9691BE90:01C51FB6] X-Spam-Score: 1.1 (+) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" Subject: [Sip] sip-connect-reuse-03 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit I think I finally figured out what my disconnect with all this is. This assumes that DNS is secure. It's not. Solutions that do not assume DNS is secure can not take advantage of the load balancing properties that SRV provides. You have pointed out this is a problem with some my proposals and I agree. Do we need to pick our poisons or can we adapt this to get the best of both? Cullen _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 3 01:11:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15651 for ; Thu, 3 Mar 2005 01:11:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6jZz-0006Kc-OP for sip-web-archive@ietf.org; Thu, 03 Mar 2005 01:13:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6jQC-0008J0-OO; Thu, 03 Mar 2005 01:02:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6jQ9-0008II-UD for sip@megatron.ietf.org; Thu, 03 Mar 2005 01:02:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14646 for ; Thu, 3 Mar 2005 01:02:49 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6jRS-000621-2m for sip@ietf.org; Thu, 03 Mar 2005 01:04:11 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 02 Mar 2005 22:04:07 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j2362RYc028098; Wed, 2 Mar 2005 22:02:39 -0800 (PST) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Wed, 2 Mar 2005 22:02:32 -0800 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 02 Mar 2005 21:57:53 -0800 From: Cullen Jennings To: "James M. Polk" , Henning Schulzrinne Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 03 Mar 2005 06:02:33.0041 (UTC) FILETIME=[9727E410:01C51FB6] X-Spam-Score: 1.3 (+) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" Subject: [Sip] resource-priority-06 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.3 (+) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit I found section 4.9 sort of confusing and worrisome. It is probably fine and I am just not understanding it. In the 3rd para, when you say protected by S/MIME do you mean it is *only* in an encrypted sipfrag or do you mean there is a copy of it in a signed AIB. I understand the proxy may want to see the header or even change it but seems like signing would still be OK. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 3 03:28:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19335 for ; Thu, 3 Mar 2005 03:28:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6liR-0000oc-IK for sip-web-archive@ietf.org; Thu, 03 Mar 2005 03:29:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6lbG-00084J-Lk; Thu, 03 Mar 2005 03:22:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6lb5-0007xY-CZ for sip@megatron.ietf.org; Thu, 03 Mar 2005 03:22:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18664 for ; Thu, 3 Mar 2005 03:22:13 -0500 (EST) Received: from penguin.ericsson.se ([193.180.251.47]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6lcO-0000d1-V3 for sip@ietf.org; Thu, 03 Mar 2005 03:23:37 -0500 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j238MCh5015513 for ; Thu, 3 Mar 2005 09:22:12 +0100 (MET) Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Mar 2005 09:23:01 +0100 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id ; Thu, 3 Mar 2005 09:22:12 +0100 Message-ID: From: "Peter Hedman (LD/EAB)" To: "'Jonathan Rosenberg'" Subject: RE: [SIP] SDP in OPTIONS Date: Thu, 3 Mar 2005 09:21:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 03 Mar 2005 08:23:01.0842 (UTC) FILETIME=[371CDB20:01C51FCA] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: sip@ietf.org, "'James M. Polk'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Thanks for your comments. 3GPP is discussing use cases where the capabilities of the remote UAs should be known prior to sending the INVITE, i.e. to be able to present a set of possibilities to the user. E.g. if there is an existing non-SIP communication between two users (e.g. CS call), SIP could be used to learn the capabilities of the remote UA. Different mechanisms have been discussed e.g. use of Presence or using INVITE with inactive media. The initial use of OPTIONS was favourable. To avoid sending 2 pair of request/reponse exchanges for a large amount of e.g. CS calls it would be beneficial to optimize the procedure to one request/response exchange. Of course, the intention has always been to do this in a backward compatible manner. Some comments inline. BR, Peter > From: Jonathan Rosenberg [mailto:jdrosen@cisco.com] > Sent: den 2 mars 2005 10:58 > OPTIONS is meant to solicit the capabilities of the UAS, > including SIP > things (Allow, Accept, Accept-Encoding) and media things (through the > SDP in the body). It was not meant to be a way to do some kind of > capability negotiation. [Peter] Agree, there should not be a negotiation. > Indeed, a UAS should reject an OPTIONS request > with a body unless the body was marked as optional using the > Content-Disposition header field. [Peter] Agree, as require is default... > Putting an SDP in the body of an > OPTIONS request, even with an optional content-disposition, > feels like a > misuse of OPTIONS to me. [Peter] I can't judge whether it is a misuse, but it seems like SIP is able to handle such an optimisation. > > That said, I don't understand the specific problem 3gpp is looking to > solve by including a body in an OPTIONS request. Can you > elaborate on that? > > Thanks, > Jonathan R. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 3 04:19:29 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26623 for ; Thu, 3 Mar 2005 04:19:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6mVp-0002i3-Mo for sip-web-archive@ietf.org; Thu, 03 Mar 2005 04:20:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6mUM-0001ow-K0; Thu, 03 Mar 2005 04:19:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6mUJ-0001or-R2 for sip@megatron.ietf.org; Thu, 03 Mar 2005 04:19:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26613 for ; Thu, 3 Mar 2005 04:19:18 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6mVe-0002hb-Iw for sip@ietf.org; Thu, 03 Mar 2005 04:20:42 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j239J8pX029774 for ; Thu, 3 Mar 2005 03:19:09 -0600 (CST) Received: from lucent.com (tomhiller.lra.lucent.com [192.11.173.57]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j239J7s26616; Thu, 3 Mar 2005 03:19:08 -0600 (CST) Message-ID: <4226D688.60104@lucent.com> Date: Thu, 03 Mar 2005 03:19:04 -0600 From: Tom Hiller Organization: Lucent Technologies User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: "sip@ietf.org" Subject: Re: [Sip] Comment on refer-with-norefersub-01 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cullen, Does this mean the mobile has to receive an immediate notification due the REFER, then send a SUBSCRIBE to kill the implicit subscription, and then get yet another notification? In practice, people draw message flows, count SIP requests and responses and other messages on a per "call" basis, and then tally a total. In wireless it is sometimes important to minimize the number of messages per "call". "norefersub" reduces the number of messages when one doesn't need the implicit subscription because the user learns the notification information via existing subscriptions or via other ways. Also, some wireless spectrum is costly, and in some cases there is a potential for lengthy SIP notification packets to interfere with RTP packet flow due to lack of over-the-air connection bandwidth. There is also a possible service impact of not being able transmit another message while sending a SUBSCRIBE to instantly end a subscription. OMA has extensively incorporated "norefersub" into draft baselines (i.e., includes the option tag "norefersub" in the Require header). These draft baselines are now being readied for publication. OMA requires the "norefersub" option tag in the Require header. If I am misunderstanding the point of your comment, could you expand further? - Tom Cullen Jennings wrote: > It seems like in any case where you put a Require with the option tag, it > results in far more traffic and less chance of interoperability than > creating the subscription and instantly ending it. > > I think you should say that the tag is not allowed in a Require. > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 3 06:20:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08561 for ; Thu, 3 Mar 2005 06:20:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6oP2-0005Pt-1V for sip-web-archive@ietf.org; Thu, 03 Mar 2005 06:22:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6oNV-0005P0-Db; Thu, 03 Mar 2005 06:20:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3Yho-0005uZ-TY; Tue, 22 Feb 2005 07:00:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20532; Tue, 22 Feb 2005 06:59:48 -0500 (EST) Received: from eagle.ericsson.se ([193.180.251.53]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3Z49-00026M-MD; Tue, 22 Feb 2005 07:23:05 -0500 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by eagle.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j1MBxjO6010861; Tue, 22 Feb 2005 12:59:45 +0100 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Tue, 22 Feb 2005 13:00:27 +0100 Received: by esealnt612.al.sw.ericsson.se with Internet Mail Service (5.5.2657.72) id <1ZVXPC48>; Tue, 22 Feb 2005 12:59:45 +0100 Message-ID: From: "Lars-Erik Jonsson (LU/EAB)" To: "'Carsten Bormann'" Date: Tue, 22 Feb 2005 12:58:56 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 22 Feb 2005 12:00:27.0684 (UTC) FILETIME=[19529E40:01C518D6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 03 Mar 2005 06:20:22 -0500 Cc: sip@ietf.org, "'Lepine, Jean-Pierre'" , rohc@ietf.org, sipping@ietf.org Subject: [Sip] RE: [rohc] SigComp with EPIC compression for SIP messages X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable Carsten, I agree that it represents a useful example of what the UDVM can do. However, my point was basically that all the other algorithms covered are both well-known and clearly defined elsewhere, i.e. there are references to give to the reader. The EPIC algorithm is thus an = exception, and therefore I think the document should at least make clearer that there is no well specified/standardised algorithm to refer to. At one point, I know we said this document was not supposed to define = algorithms, but only cover well-known algorithms and show how to implement them in the UDVM. With that criteria, I do not think the EPIC example belongs there, but of course we can change the scope of the document, if people agree that is desirable.=20 BR /L-E (with chair hat on) > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: den 22 februari 2005 12:40 > To: Lars-Erik Jonsson (LU/EAB) > Cc: Carsten Bormann; rohc@ietf.org; sip@ietf.org; sipping@ietf.org; > 'Lepine, Jean-Pierre' > Subject: Re: [rohc] SigComp with EPIC compression for SIP messages >=20 >=20 > On Feb 21 2005, at 08:50 Uhr, Lars-Erik Jonsson (LU/EAB) wrote: >=20 > > The SigComp user guide did (I am not sure about the new=20 > version just=20 > > released) refer to EPIC, which is probably=A0a mistake as=20 > algorithms are=20 > > not specified in that document, and there is no reference=20 > > available=A0for an EPIC algorithm. >=20 > I'm not sure it's a mistake, as a reader skilled in the art=20 > can deduct=20 > what this all is about from the UDVM code given. > (If I were giving this to my students, they would complain about the=20 > cruelty of the assignment, though...) > Even if you are not interested in the details of hierarchical=20 > huffman,=20 > the code is still useful as a demonstration of the UDVM's=20 > capabilities. >=20 > Gruesse, Carsten >=20 >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 3 06:32:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10666 for ; Thu, 3 Mar 2005 06:32:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6oaR-0005tn-B9 for sip-web-archive@ietf.org; Thu, 03 Mar 2005 06:33:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6oNX-0005PX-89; Thu, 03 Mar 2005 06:20:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4R3a-00009h-3s for sip@megatron.ietf.org; Thu, 24 Feb 2005 17:02:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27345 for ; Thu, 24 Feb 2005 17:01:59 -0500 (EST) Message-Id: <200502242201.RAA27345@ietf.org> Received: from [208.248.239.14] (helo=mail.cmguc.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4R3Z-0005qA-6f for sip@ietf.org; Thu, 24 Feb 2005 17:02:02 -0500 Received: (qmail 24250 invoked from network); 24 Feb 2005 21:58:36 -0000 Received: from unknown (HELO usglal054747) ([10.239.70.179]) (envelope-sender ) by 0 (qmail-ldap-1.03) with SMTP for ; 24 Feb 2005 21:58:36 -0000 From: "Louis Alexander" To: "'Fatih Ey|p NAR'" , "'Ban Zie'" , Subject: RE: [Sip] midcall signalling Date: Thu, 24 Feb 2005 17:00:32 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Thread-index: AcUauOUbQkoFbQG0SdGJHsnr347b3QAAzxHg In-reply-to: <20050224214447.28346.qmail@web52804.mail.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 03 Mar 2005 06:20:22 -0500 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Of course, plain old inband dtmf (the DTMF tones encoded as audio packets, NOT 2833 tones) is still legal as well :) --Louis -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Fatih Ey|p NAR Sent: Thursday, February 24, 2005 4:45 PM To: Ban Zie; sip@ietf.org Subject: Re: [Sip] midcall signalling SIP DMTF signalling is done with INFO messages or with RTP messages, the media protocol. This is defined in http://www.ietf.org/rfc/rfc2833.txt - IETF RFC 2833 --- Ban Zie wrote: > hello, > is there 100% agreement / concensus on how midcall > signalling data is to be carried in sip ? > when 2 SIP UA's are alrady in conversation, then if > one user presses some keys on his keypad, are they > transmitted as DTMF on RTP, or how exactly is it > done ? > cheers, > bzie. > -- > ___________________________________________________________ > Sign-up for Ads Free at Mail.com > http://promo.mail.com/adsfreejump.htm > > > _______________________________________________ > Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP > Protocol > Use sip-implementors@cs.columbia.edu for questions > on current sip > Use sipping@ietf.org for new developments on the > application of sip > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 3 06:35:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11153 for ; Thu, 3 Mar 2005 06:35:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6odD-00060p-Qf for sip-web-archive@ietf.org; Thu, 03 Mar 2005 06:36:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6oNU-0005Oq-Ej; Thu, 03 Mar 2005 06:20:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3YPG-0003mZ-Fe; Tue, 22 Feb 2005 06:40:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18556; Tue, 22 Feb 2005 06:40:37 -0500 (EST) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3Ylc-0001XU-Pc; Tue, 22 Feb 2005 07:03:54 -0500 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id j1MBeRlF013089; Tue, 22 Feb 2005 12:40:28 +0100 (MET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <342416f8d4a1b156c89fea65dfe0c9f0@tzi.org> Content-Transfer-Encoding: quoted-printable From: Carsten Bormann Date: Tue, 22 Feb 2005 12:40:26 +0100 To: "Lars-Erik Jonsson (LU/EAB)" X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 03 Mar 2005 06:20:22 -0500 Cc: sip@ietf.org, "'Lepine, Jean-Pierre'" , Carsten Bormann , rohc@ietf.org, sipping@ietf.org Subject: [Sip] Re: [rohc] SigComp with EPIC compression for SIP messages X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable On Feb 21 2005, at 08:50 Uhr, Lars-Erik Jonsson (LU/EAB) wrote: > The SigComp user guide did (I am not sure about the new version just=20= > released) refer to EPIC, which is probably=A0a mistake as algorithms = are=20 > not specified in that document, and there is no reference=20 > available=A0for an EPIC algorithm. I'm not sure it's a mistake, as a reader skilled in the art can deduct=20= what this all is about from the UDVM code given. (If I were giving this to my students, they would complain about the=20 cruelty of the assignment, though...) Even if you are not interested in the details of hierarchical huffman,=20= the code is still useful as a demonstration of the UDVM's capabilities. Gruesse, Carsten _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 3 06:42:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12245 for ; Thu, 3 Mar 2005 06:42:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6okL-0006H9-E2 for sip-web-archive@ietf.org; Thu, 03 Mar 2005 06:44:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6oNY-0005Pe-5f; Thu, 03 Mar 2005 06:20:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D66pu-00005G-QE for sip@megatron.ietf.org; Tue, 01 Mar 2005 07:50:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19933 for ; Tue, 1 Mar 2005 07:50:48 -0500 (EST) Received: from fmmailgate05.web.de ([217.72.192.243]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D66qr-00024d-FP for sip@ietf.org; Tue, 01 Mar 2005 07:51:50 -0500 Received: by fmmailgate05.web.de (8.12.10/8.12.10/webde Linux 0.7) with SMTP id j21CoTBc011211; Tue, 1 Mar 2005 13:50:29 +0100 Received: from [212.126.216.226] by freemailng2202.web.de with HTTP; Tue, 01 Mar 2005 13:50:24 +0100 Date: Tue, 01 Mar 2005 13:50:24 +0100 Message-Id: <16366754@web.de> MIME-Version: 1.0 From: "Markus Hofmann" To: "IdnaniAjaykumar-AIDNANI1" , sip-implementors@cs.columbia.edu, "'sip@ietf.org'" Precedence: fm-user Organization: http://freemail.web.de/ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 03 Mar 2005 06:20:22 -0500 Subject: [Sip] Re: [Sip-implementors] Section 17.1.1.2, RFC 3261 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Hi Ajay, in my understanding you have only two possibilities to finish this situation. After TimerA is stopped, TimerB lost its control functionality. If Timer B expires no state will change. The first possibility is that the user from UAC stopps the situation by sending a CANCEL (hanging up if a phone). UAS will response to the CANCEL with a 200 OK and a 487 Request Terminated for the INVITE. UAC answers with an ACK. By the other possiblity there must be a proxy between. If Timer C expires the proxy sends a 408 to the UAC which answers with an ACK and the proxy sends a CANCEL to the UAS. The behaviour of the UAS is the same as above, only the proxy is answering now with an ACK. I think this are the only two possiblities. Greeting Markus Idnani Ajaykumar-AIDNANI1 schrieb am 28.02.05 20:08:50: > > Hi All, > > I was reading section 17.1.1.2 of RFC 3261 and I had some basic questions, so I thought I will ask the experts. > > 1. What is the UAC supposed to do when it is in the Proceeding state and it does not receive any final response? The text in section 17.1.1.2 does talk about this case. Also when I look at the flow in Firgure 5, there seems to be no timer attached to get out of the 'Proceeding' state. There is one attached to 'Calling' (Timer B) and 'Completed' (Timer D) states, but none to 'Proceeding' state. So are we saying that once you get into Proceeding state and the other end fails for some reason, the UAC is stuck. > > Or is the figure inaccurate and it should really show a Timer B associated with one of the arrows coming out of that state? In which case my questions would be does a provisional response reset this timer? Otherwise an INVITE transaction would be constrained to 32secs assuming a T1 of 500ms (i.e. a call should go from 'Calling' to 'Completed' in 32secs! > > Appreciate your responses. > > Thank you. > - Ajay > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@cs.columbia.edu > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 3 06:42:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12256 for ; Thu, 3 Mar 2005 06:42:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6okL-0006HA-ED for sip-web-archive@ietf.org; Thu, 03 Mar 2005 06:44:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6oNW-0005PQ-Ap; Thu, 03 Mar 2005 06:20:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3aLl-0007k4-Ry; Tue, 22 Feb 2005 08:45:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00958; Tue, 22 Feb 2005 08:45:15 -0500 (EST) Received: from imh.informatik.uni-bremen.de ([134.102.224.4] helo=informatik.uni-bremen.de) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3aiC-0005Ov-Ob; Tue, 22 Feb 2005 09:08:32 -0500 Received: from [IPv6:::1] (imh [134.102.224.4]) by informatik.uni-bremen.de (8.12.11/8.12.11) with ESMTP id j1MDixf9004526; Tue, 22 Feb 2005 14:45:01 +0100 (MET) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <080ee8e812ad798aac5aca120e1fc6e1@tzi.org> Content-Transfer-Encoding: 7bit From: Carsten Bormann Date: Tue, 22 Feb 2005 14:44:57 +0100 To: "Lars-Erik Jonsson (LU/EAB)" X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: by AMaViS/Sophos at informatik.uni-bremen.de X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 03 Mar 2005 06:20:22 -0500 Cc: sip@ietf.org, "'Lepine, Jean-Pierre'" , Carsten Bormann , rohc@ietf.org, sipping@ietf.org Subject: [Sip] Re: [rohc] SigComp with EPIC compression for SIP messages X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit On Feb 22 2005, at 12:58 Uhr, Lars-Erik Jonsson (LU/EAB) wrote: > At one > point, I know we said this document was not supposed to define > algorithms, > but only cover well-known algorithms and show how to implement them in > the UDVM. I did not remember the second half (well-known algorithms only) of that -- then it indeed would be a mistake to keep the EPIC-inspired hierarchical huffman in there. (It is more interesting than other potential examples because I believe it did influence the UDVM design a bit. Maybe we can preserve the material by moving it to an appendix?) Gruesse, Carsten _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 3 06:56:58 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13910 for ; Thu, 3 Mar 2005 06:56:57 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6oyH-0006iA-0U for sip-web-archive@ietf.org; Thu, 03 Mar 2005 06:58:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6ow3-0006Un-Lo; Thu, 03 Mar 2005 06:56:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6ow1-0006To-Cg for sip@megatron.ietf.org; Thu, 03 Mar 2005 06:56:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13830 for ; Thu, 3 Mar 2005 06:56:02 -0500 (EST) Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D6oxM-0006gv-I9 for sip@ietf.org; Thu, 03 Mar 2005 06:57:29 -0500 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 3 Mar 2005 11:55:55 +0000 X-Mailer: exmh version 2.7.0 06/18/2004 with version: MH 6.8.3 #25[UCI] From: "Piers O'Hanlon" X-url: http://www.ucl.ac.uk To: "James M. Polk" Subject: Re: [Sip] New Resource Priority Draft (-06) In-reply-to: Your message of "Fri, 25 Feb 2005 11:47:50 CST." <4.3.2.7.2.20050225112723.035dd6b0@localhost> Date: Thu, 03 Mar 2005 11:55:54 +0000 Message-ID: <23805.1109850954@cs.ucl.ac.uk> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: sip@ietf.org, P.OHanlon@cs.ucl.ac.uk X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Hi, This draft (06) is looking better - I have a few comments: 1) The explanation of the use Accept-RP in last para of section 3.3 differs from that in section 4.3 (ie. It doesn't mentioned the inclusion of an Accept-RP hdr in a 420 response) 2) Section 4.3 should probably mention the inclusion of the 'resource-priority' option tag in a "Supported" header in the response. 3) In section 4.4.1 I'm not sure if it's entirely correct to state that 'proxies do not manage sessions'? Isn't it possible that a proxy may actually implement the preemption? Thanks, Piers. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 3 08:41:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23648 for ; Thu, 3 Mar 2005 08:41:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6qbT-0000am-WE for sip-web-archive@ietf.org; Thu, 03 Mar 2005 08:43:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6qZi-0005LC-4v; Thu, 03 Mar 2005 08:41:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6qZe-0005Kl-3S for sip@megatron.ietf.org; Thu, 03 Mar 2005 08:41:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23619 for ; Thu, 3 Mar 2005 08:41:04 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6qb0-0000aL-8B for sip@ietf.org; Thu, 03 Mar 2005 08:42:31 -0500 Received: from oh0012exch001p.wins.lucent.com (h135-7-157-6.lucent.com [135.7.157.6]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j23Df2F1010324 for ; Thu, 3 Mar 2005 07:41:03 -0600 (CST) Received: by oh0012exch001p.cb.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 3 Mar 2005 08:41:02 -0500 Message-ID: <4C37CF2D8DF07E4CA6357BAD5EB9A5D7189FC39A@oh0012exch004u.cb.lucent.com> From: "Shekar, Nagesh Soma (Shekar)** CTR **" To: "'M.N.A.Smadi'" , sip@ietf.org Subject: RE: [Sip] REFER request Date: Thu, 3 Mar 2005 08:41:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 With traditional telephony, the party that initiated the transfer would be charged for transferred leg of the call. In this case that would be A. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > M.N.A.Smadi > Sent: Wednesday, March 02, 2005 7:42 PM > To: sip@ietf.org > Subject: [Sip] REFER request > > > hi; > > if we have A<->B then A refer B to C, who is going to be > charged for the > cost of the new call (namely, B<->C) > > thanks > m.smadi > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 3 09:05:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25752 for ; Thu, 3 Mar 2005 09:05:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6qyD-0001BA-Te for sip-web-archive@ietf.org; Thu, 03 Mar 2005 09:06:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6qui-0000YC-TV; Thu, 03 Mar 2005 09:02:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6quh-0000Y7-O2 for sip@megatron.ietf.org; Thu, 03 Mar 2005 09:02:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25376 for ; Thu, 3 Mar 2005 09:02:49 -0500 (EST) Received: from mailhost1.aepona.com ([194.46.24.5]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6qw2-00014h-Vn for sip@ietf.org; Thu, 03 Mar 2005 09:04:16 -0500 Received: from magnus ([10.10.12.185]) by mailhost1.aepona.com with esmtp (Exim 4.24) id 1D6quS-0006gn-1g; Thu, 03 Mar 2005 14:02:36 +0000 Message-ID: <422718FB.9070501@aepona.com> Date: Thu, 03 Mar 2005 14:02:35 +0000 From: David Monahan User-Agent: Mozilla Thunderbird 0.9 (X11/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Shekar, Nagesh Soma (Shekar)** CTR **" Subject: Re: [Sip] REFER request References: <4C37CF2D8DF07E4CA6357BAD5EB9A5D7189FC39A@oh0012exch004u.cb.lucent.com> In-Reply-To: <4C37CF2D8DF07E4CA6357BAD5EB9A5D7189FC39A@oh0012exch004u.cb.lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit I would expect the service provider to decide who and how they are going to charge for a particular service. Rgds, David Shekar, Nagesh Soma (Shekar)** CTR ** wrote: > With traditional telephony, the party that initiated the transfer > would be charged for transferred leg of the call. In this case > that would be A. > > >>-----Original Message----- >>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of >>M.N.A.Smadi >>Sent: Wednesday, March 02, 2005 7:42 PM >>To: sip@ietf.org >>Subject: [Sip] REFER request >> >> >>hi; >> >>if we have A<->B then A refer B to C, who is going to be >>charged for the >>cost of the new call (namely, B<->C) >> >>thanks >>m.smadi _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 3 09:25:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28118 for ; Thu, 3 Mar 2005 09:25:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6rI1-0001hP-5I for sip-web-archive@ietf.org; Thu, 03 Mar 2005 09:26:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6rDn-00057v-TF; Thu, 03 Mar 2005 09:22:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6rDl-00057c-6Q for sip@megatron.ietf.org; Thu, 03 Mar 2005 09:22:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27727 for ; Thu, 3 Mar 2005 09:22:28 -0500 (EST) Received: from v-mail.vsnl.com ([202.54.117.17] helo=vmail.vsnl.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6rF4-0001bD-E9 for sip@ietf.org; Thu, 03 Mar 2005 09:23:55 -0500 Received: from shailender ([127.0.0.1]) by vmail.vsnl.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0ICS00LBU592RR@vmail.vsnl.com> for sip@ietf.org; Thu, 03 Mar 2005 19:52:15 +0530 (IST) Received: from ([tataelxsi.co.in (203.197.169.124)]) by vmail.vsnl.com (InterScan E-Mail VirusWall Unix); Thu, 03 Mar 2005 19:52:15 +0530 (IST) Date: Thu, 03 Mar 2005 19:53:00 +0530 From: Shailender P Subject: RE: [Sip] REFER request In-reply-to: <422718FB.9070501@aepona.com> To: "'David Monahan'" , "'Shekar, Nagesh Soma (Shekar)** CTR **'" Message-id: <000001c51ffc$82901ef0$663ca8c0@telxsi.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7BIT Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7BIT If B is refered to C by A, then B invites C and establishes and new call, then informs A. Typically, after knowing B is connected to C, A sends bye to B and disconnects the call. In this scenario I guess B will be charged. I guess in redirection (call re-direct) A would be charged. -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of David Monahan Sent: Thursday, March 03, 2005 7:33 PM To: Shekar, Nagesh Soma (Shekar)** CTR ** Cc: sip@ietf.org Subject: Re: [Sip] REFER request I would expect the service provider to decide who and how they are going to charge for a particular service. Rgds, David Shekar, Nagesh Soma (Shekar)** CTR ** wrote: > With traditional telephony, the party that initiated the transfer > would be charged for transferred leg of the call. In this case > that would be A. > > >>-----Original Message----- >>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of >>M.N.A.Smadi >>Sent: Wednesday, March 02, 2005 7:42 PM >>To: sip@ietf.org >>Subject: [Sip] REFER request >> >> >>hi; >> >>if we have A<->B then A refer B to C, who is going to be >>charged for the >>cost of the new call (namely, B<->C) >> >>thanks >>m.smadi _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 3 10:02:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01773 for ; Thu, 3 Mar 2005 10:02:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6rrj-0002SV-S9 for sip-web-archive@ietf.org; Thu, 03 Mar 2005 10:03:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6rpS-00049K-1k; Thu, 03 Mar 2005 10:01:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6rpP-000497-GP for sip@megatron.ietf.org; Thu, 03 Mar 2005 10:01:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01709 for ; Thu, 3 Mar 2005 10:01:25 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6rqm-0002R2-3Q for sip@ietf.org; Thu, 03 Mar 2005 10:02:53 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 03 Mar 2005 07:07:25 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,133,1107763200"; d="scan'208"; a="164807742:sNHT22313680" Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j23F1EYO013255; Thu, 3 Mar 2005 07:01:14 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-49.cisco.com [10.86.240.49]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AIF07005; Thu, 3 Mar 2005 07:01:12 -0800 (PST) Message-ID: <422726B7.5000904@cisco.com> Date: Thu, 03 Mar 2005 10:01:11 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peter Hedman (LD/EAB)" Subject: Re: [SIP] SDP in OPTIONS References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, "'James M. Polk'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit inline. Peter Hedman (LD/EAB) wrote: > Thanks for your comments. > > 3GPP is discussing use cases where the capabilities of the remote UAs > should be known prior to sending the INVITE, i.e. to be able to > present a set of possibilities to the user. E.g. if there is an > existing non-SIP communication between two users (e.g. CS call), SIP > could be used to learn the capabilities of the remote UA. > > Different mechanisms have been discussed e.g. use of Presence or > using INVITE with inactive media. The initial use of OPTIONS was > favourable. Either presence or OPTIONS would work. Presence is clearly better if the user is someone you already are subscribing to. Prescaps will give you much the same information you will get from an OPTIONS, though it won't tell you the list of supported codecs. > To avoid sending 2 pair of request/reponse exchanges for > a large amount of e.g. CS calls it would be beneficial to optimize > the procedure to one request/response exchange. As I mentioned, doing that is not an appropriate use of OPTIONS. The OPTIONS request body is NOT meant to convey the capabilities of the requester. >> Putting an SDP in the body of an OPTIONS request, even with an >> optional content-disposition, feels like a misuse of OPTIONS to me. >> > > [Peter] I can't judge whether it is a misuse, but it seems like SIP > is able to handle such an optimisation. Its not a match for the semantics of the method. Quoting RFC 3261: 11 Querying for Capabilities The SIP method OPTIONS allows a UA to query another UA or a proxy server as to its capabilities. This allows a client to discover information about the supported methods, content types, extensions, codecs, etc. without "ringing" the other party. For example, before Nowhere in there does it talk about OPTIONS being used to inform the other side of its capabilities. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 3 10:19:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04773 for ; Thu, 3 Mar 2005 10:19:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6s8K-0002vr-Nw for sip-web-archive@ietf.org; Thu, 03 Mar 2005 10:21:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6s6P-00082H-4t; Thu, 03 Mar 2005 10:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6s6N-00082C-4q for sip@megatron.ietf.org; Thu, 03 Mar 2005 10:18:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04672 for ; Thu, 3 Mar 2005 10:18:57 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6s7k-0002up-4B for sip@ietf.org; Thu, 03 Mar 2005 10:20:25 -0500 Received: from [127.0.0.1] (IDENT:U2FsdGVkX1+EmaovtTnziMWymRB0V0C3ai5yFGhdEDU@razor.cs.columbia.edu [128.59.16.8]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j23FIqh3013694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Mar 2005 10:18:54 -0500 (EST) Message-ID: <42272AD8.3060103@cs.columbia.edu> Date: Thu, 03 Mar 2005 10:18:48 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , "James M. Polk" Subject: [Sip] Re: resource-priority-06 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit http://www.cs.columbia.edu/sip/draft/resource-priority/draft-ietf-sip-resource-priority-07.html contains my running version trying to incorporate suggestions. It also updates the S/MIME-related section. Please let me me know if that helps or not. Cullen Jennings wrote: > I found section 4.9 sort of confusing and worrisome. It is probably fine and > I am just not understanding it. In the 3rd para, when you say protected by > S/MIME do you mean it is *only* in an encrypted sipfrag or do you mean there > is a copy of it in a signed AIB. > > I understand the proxy may want to see the header or even change it but > seems like signing would still be OK. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 3 11:05:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09900 for ; Thu, 3 Mar 2005 11:05:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6sqT-00040x-VX for sip-web-archive@ietf.org; Thu, 03 Mar 2005 11:06:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6skt-0007Vb-RK; Thu, 03 Mar 2005 11:00:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6skr-0007VO-A1 for sip@megatron.ietf.org; Thu, 03 Mar 2005 11:00:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09415 for ; Thu, 3 Mar 2005 11:00:46 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6smC-0003uI-1f for sip@ietf.org; Thu, 03 Mar 2005 11:02:15 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 03 Mar 2005 09:16:40 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,133,1107734400"; d="asc'?scan'208"; a="231083773:sNHT38448424" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j23G0Uq8000991; Thu, 3 Mar 2005 08:00:30 -0800 (PST) Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j23FsTRR017377; Thu, 3 Mar 2005 07:54:29 -0800 Subject: Re: [Sip] sip-connect-reuse-03 From: Michael Thomas To: Cullen Jennings In-Reply-To: References: Organization: Cisco Systems Message-Id: <1109865632.22395.58.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 03 Mar 2005 08:00:32 -0800 IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1109865270.17648"; x:"432200"; a:"rsa-sha1"; b:"nofws:1563"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"YO78g00g7R1p+jJiYhlV/DPbcYBH9MEcqyhOGFYVnwwxsCV2LdiiFIDUb121rLFJiT/Er/nD" "XAS7ebABJ0LceClFujw4lYNtcv7s0tlu7kCBXiBt4nns7ml60fDtubEvqLjlpKngiOznQqbf4nc" "qn4AcMKAkiNQoO5NWOCd+Vq0="; c:"Subject: Re: [Sip] sip-connect-reuse-03"; c:"From: Michael Thomas "; c:"Date: Thu, 03 Mar 2005 08:00:32 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: "sip@ietf.org" , Rohan Mahy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1416370394==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 --===============1416370394== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-F8W4PY9Yd+m8u2ScxHm1" --=-F8W4PY9Yd+m8u2ScxHm1 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Wed, 2005-03-02 at 21:52, Cullen Jennings wrote: > I think I finally figured out what my disconnect with all this is. This > assumes that DNS is secure. It's not. Solutions that do not assume DNS is > secure can not take advantage of the load balancing properties that SRV > provides. You have pointed out this is a problem with some my proposals a= nd > I agree.=20 >=20 > Do we need to pick our poisons or can we adapt this to get the best of bo= th? Define "secure". We need to be careful to not go overboard when evaluating solutions. The root zone is not signed, that is true, but that doesn't necessarily disqualify DNS from having a part in a "secure" solution. If you're _directly_ using DNS as a trust anchor you obviously have to be very careful about the security tradeoffs, but if you're using DNS to just lead you to another trust anchor (eg, SRV to=20 something with TLS server certs), the risks are fewer. The other thing to keep in mind is that DNSsec is still (unfortunately) a solution in search of a problem. Or at least a problem whose energy barrier is low enough to convince people that signing their zones is worthwhile. In some respects, putting _more_ stuff on the shoulders of DNS may in fact be a greater good if it finally leads to signing those zones. Mike --=-F8W4PY9Yd+m8u2ScxHm1 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUAQic0oLMsDAj/Eq++AQKqoAP+N9s67xdx+IH+Qjwgs/MggN6LTd06TJGA /Bi3CqqMDsk9JuaOrbZqVJ9bOckyEt8C106RGWjBL7NyQlcTxzl1f+wxoHGFOJkg ruKSw/KDnEKXA4W/SRKsYhGO8kkaRxo1QdZhXXH9+2ND7pd5D4hpieibYJT1IxmQ +2uULWig1K4= =pbS0 -----END PGP SIGNATURE----- --=-F8W4PY9Yd+m8u2ScxHm1-- --===============1416370394== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1416370394==-- From sip-bounces@ietf.org Thu Mar 3 11:51:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16924 for ; Thu, 3 Mar 2005 11:51:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6tZQ-0005S7-Ss for sip-web-archive@ietf.org; Thu, 03 Mar 2005 11:53:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6tT0-0001nd-4x; Thu, 03 Mar 2005 11:46:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6tSx-0001mv-Nv for sip@megatron.ietf.org; Thu, 03 Mar 2005 11:46:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16359 for ; Thu, 3 Mar 2005 11:46:21 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6tUL-0005Hw-AI for sip@ietf.org; Thu, 03 Mar 2005 11:47:50 -0500 Received: from [192.168.2.101] ([12.5.186.26]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.12.11) with ESMTP id j23GmHl0001546 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 3 Mar 2005 10:48:19 -0600 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6af8e44b4d82f351579589816f489e0a@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [Sip] Agenda for SIP at IETF 62 Date: Thu, 3 Mar 2005 10:46:21 -0600 To: Cullen Jennings X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , Rohan Mahy , "gonzalo.camarillo@ericsson.com" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit On Mar 3, 2005, at 12:01 AM, Cullen Jennings wrote: > On 2/28/05 7:55 AM, "Dean Willis" wrote: > >> draft-ietf-sip-refer-with-feature-param-01.txt > > I can't find this draft. Why is it on the agenda? > > I'll look into it. -- dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 3 11:54:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17175 for ; Thu, 3 Mar 2005 11:54:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6tcU-0005W0-Km for sip-web-archive@ietf.org; Thu, 03 Mar 2005 11:56:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6tWF-0002KG-PV; Thu, 03 Mar 2005 11:49:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6tWD-0002JP-47 for sip@megatron.ietf.org; Thu, 03 Mar 2005 11:49:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16803 for ; Thu, 3 Mar 2005 11:49:42 -0500 (EST) Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6tXa-0005Ou-CW for sip@ietf.org; Thu, 03 Mar 2005 11:51:11 -0500 Received: from g8pbr.blf01.telekom.de by tcmail31.dmz.telekom.de with ESMTP for sip@ietf.org; Thu, 3 Mar 2005 17:49:09 +0100 Received: by G8PBR.blf01.telekom.de with Internet Mail Service (5.5.2653.19) id ; Thu, 3 Mar 2005 17:49:27 +0100 Message-Id: From: "Jesske, R" To: sip@ietf.org Date: Thu, 3 Mar 2005 17:49:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [Sip] Reason Header; protocol? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Dear all, it was identified that in addition to ITU-T ETSI has also defined Cause Codes like cause 24. How should I interpret the Reason element protocol=Q850. The cause code is only used by ETSI and is not doubled. Two options are possible: 1. define a new value for Protocol=ETSI 2. to use the existing protocol=Q850 What is your opinion. Thank you Best Regards Roland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 3 12:10:11 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19222 for ; Thu, 3 Mar 2005 12:10:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6trQ-00063F-Hw for sip-web-archive@ietf.org; Thu, 03 Mar 2005 12:11:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6tmt-00061G-1m; Thu, 03 Mar 2005 12:06:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6tmr-0005zT-0n for sip@megatron.ietf.org; Thu, 03 Mar 2005 12:06:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18646 for ; Thu, 3 Mar 2005 12:06:54 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6toF-0005uT-EX for sip@ietf.org; Thu, 03 Mar 2005 12:08:23 -0500 Received: from [192.168.2.101] ([12.5.186.26]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.12.11) with ESMTP id j23H8un4001693 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 3 Mar 2005 11:08:56 -0600 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <16446cc8bcd8848c09b1ba6a17217525@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Thu, 3 Mar 2005 11:07:00 -0600 To: Cullen Jennings X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, Orit Levin , Jon Peterson , Allison Mankin Subject: [Sip] What happened to draft-ietf-sip-refer-with-feature-params-01, and more on refer extensions X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: 7bit Here's what appears to have happened to draft-ietf-sip-refer-with-feature-param-00, and by extension -01. The secretariat dropped -00 because I originally tried to authorize two postings with one email, and I didn't follow through far enough on picking it back up -- although I did try. So, the version -01 draft was probably automatically rejected. The email record is below, should you be both curious and morbid. Path forward: The features draft hasn't gotten enough list attention to warrant extended discussion at this time. Following the meeting, Orit will resubmit draft-ietf-sip-refer-with-feature-params-01 as draft-ietf-sip-refer-features-00 and we'll go from there. Note the name change, which should reduce the confusion somewhat. I hope. Given Cullen's recently raised issue with norefersub, we will use the IETF 62 agenda time to finish that discussion. I hope that we will reach a final conclusion on norefersub during that time. -- Dean "There's no way to win at this game. We just keep blasting aliens until we run out of quarters and die." Begin forwarded message: > From: Dean Willis > Date: November 9, 2004 2:03:08 PM CST > To: Dinara Suleymanova > Cc: Orit Levin , rohan@ekabal.com > Subject: Re: . . . draft-ietf-sip-refer-with-feature-param-00 > > > My apologies, I had meant the original approval to apply to both > draft-ietf-sip-refer-with-feature-param-00 and > draft-ietf-sip-refer-with-norefersub-00, and it may have been taken > only as an approval of draft-ietf-sip-refer-with-norefersub-00. > > Please accept this seperate email as an approval for publication of > draft-ietf-sip-refer-with-feature-param-00. > > Thanks! > > -- > Dean Willis > SIP co-chair > > Dean Willis wrote: > >> Dinara Suleymanova wrote: >> >>> Please resend them each draft in a separate e-mail. >>> And can not find any approval for your drafts >>> from the wg chairs. >>> >>> >>> >> Here's a copy of my original approval sent Thursday, October 21 at >> 10:28 AM CDT: >> >> Message-ID: <4177D586.10604@softarmor.com> >> Date: Thu, 21 Oct 2004 10:28:06 -0500 >> From: Dean Willis >> User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) >> X-Accept-Language: en-us, en >> MIME-Version: 1.0 >> To: Dinara Suleymanova >> CC: Orit Levin , Internet-Drafts@ietf.org, >> rohan@ekabal.com, iesg@ietf.org, bfuller@foretec.com >> Subject: Re: Draft' Submission: >> draft-ietf-sip-refer-with-norefersub-00 >> References: >> > -52.redmond.corp.microsoft.com> >> <6.1.0.6.2.20041021110550.01d1e110@odin.ietf.org> >> In-Reply-To: <6.1.0.6.2.20041021110550.01d1e110@odin.ietf.org> >> Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> Content-Transfer-Encoding: 7bit >> >> >> Whoops. My bad. Sorry. >> >> Approved. >> >> -- >> Dean Willis >> SIP Co-Chair >> >> Dinara Suleymanova wrote: >> >>> Dear Orit, >>> >>> You Internet-Draft with the filename >>> draft-ietf-sip-refer-with-norefersub-00 >>> was received before the cut-off date for the version -00s draft >>> submissions. >>> However, all working group documents with version -00s must be >>> approved >>> by the working group chair before being posted. >>> >>> We have not received approval to post this draft as a working group >>> document. >>> >>> Please ask the wg chair to send his/her approval ASAP. If we receive >>> the approval >>> before Friday, October 22nd at 12:00 pm et, then we will post your >>> draft. >>> >>> Thanks. >>> >>> Dinara Suleymanova >>> >>> >>> >> >> >> > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 3 13:24:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26978 for ; Thu, 3 Mar 2005 13:24:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6v1R-0007ya-59 for sip-web-archive@ietf.org; Thu, 03 Mar 2005 13:26:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6uxQ-0007C6-UP; Thu, 03 Mar 2005 13:21:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6uxP-00079t-Ff for sip@megatron.ietf.org; Thu, 03 Mar 2005 13:21:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26766 for ; Thu, 3 Mar 2005 13:21:52 -0500 (EST) Received: from figas.ekabal.com ([204.61.215.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6uyn-0007vW-Sf for sip@ietf.org; Thu, 03 Mar 2005 13:23:23 -0500 Received: from [192.168.0.15] (S01060050baa8032f.vc.shawcable.net [24.85.92.32] (may be forged)) (authenticated) by figas.ekabal.com (8.11.6/8.11.6) with ESMTP id j23ILoK22435; Thu, 3 Mar 2005 10:21:50 -0800 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0e08adb332df8674836078a7a2920043@ekabal.com> Content-Transfer-Encoding: 7bit From: Rohan Mahy Date: Thu, 3 Mar 2005 09:08:54 -0800 To: SIP WG X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: Rohan Mahy Subject: [Sip] WGLC for draft-ietf-sipping-certs-01 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Hi Folks, I would like to officially begin Working Group Last Call for: draft-ietf-sipping-certs-01.txt Due to my mistake, this draft is titled "sipping" instead of "sip". (We have a milestone for this in SIP). This document will be renamed to be a SIP document after the blackout. Please send comments to the *SIP* list. This WGLC will end on April 8th, 2005. thanks and sorry for the confusion, -rohan _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 3 14:48:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06338 for ; Thu, 3 Mar 2005 14:48:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6wKG-0001cp-4I for sip-web-archive@ietf.org; Thu, 03 Mar 2005 14:49:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6wHJ-0006Kq-Fo; Thu, 03 Mar 2005 14:46:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6wHH-0006Kl-UK for sip@megatron.ietf.org; Thu, 03 Mar 2005 14:46:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06227 for ; Thu, 3 Mar 2005 14:46:30 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6wIf-0001aE-ET for sip@ietf.org; Thu, 03 Mar 2005 14:47:59 -0500 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j23JkFB21596; Thu, 3 Mar 2005 14:46:15 -0500 (EST) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id <1J5BN41H>; Thu, 3 Mar 2005 14:46:07 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF01A71139@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "'Cullen Jennings'" , "'Jonathan Rosenberg'" Subject: RE: [Sip] draft-jennings-sip-hashcash-01 Date: Thu, 3 Mar 2005 14:46:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.8 (/) X-Scan-Signature: d16ce744298aacf98517bc7c108bd198 Cc: "'sip@ietf.org'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1928937812==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1928937812== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C52029.A0B613FD" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C52029.A0B613FD Content-Type: text/plain As a separate note, shouldn't we try to solve the HERFP problem? > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Cullen Jennings > Sent: Wednesday, March 02, 2005 12:16 > To: Jonathan Rosenberg > Cc: sip@ietf.org > Subject: Re: [Sip] draft-jennings-sip-hashcash-01 > > > On 3/2/05 2:15 AM, "Jonathan Rosenberg" wrote: > > > 1. The mechanism interacts badly with forking at the moment. One > > problem is HERFP. If I have a mix of endpoints, some of > which support > > this (and thus send a 419), and others that don't (and thus > ring the > > phone), then you'll end up always completing the call on > the endpoints > > that don't support the extension. > > Good point. I think will mention this in the draft but > clearly I won't attempt to solve the well studied HERFP > problem. As a separate issues, some day the WG should discuss > the limitations of the "If it hurts don't do it" solution to > the HERFP problem. > > > > > 2. THe mechanism doesn't provide a way for a proxy to aggregate > > multiple Puzzle headers from forked branches. It needs to > do something > > like WWW-Authenticate where a proxy collects these from the various > > 419 and places all of them in the 419 forwarded upstream. That will > > also require something akin to realm, that allows a > UA/proxy to pull > > out its own puzzle. > > Oops. Excellent point. Thanks, will fix this. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current > sip Use sipping@ietf.org for new developments on the > application of sip > > ------_=_NextPart_001_01C52029.A0B613FD Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [Sip] draft-jennings-sip-hashcash-01

As a separate note, shouldn't we try to solve the = HERFP problem?


> -----Original Message-----
> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] = On
> Behalf Of Cullen Jennings
> Sent: Wednesday, March 02, 2005 12:16
> To: Jonathan Rosenberg
> Cc: sip@ietf.org
> Subject: Re: [Sip] = draft-jennings-sip-hashcash-01
>
>
> On 3/2/05 2:15 AM, "Jonathan = Rosenberg" <jdrosen@cisco.com> wrote:
>
> > 1. The mechanism interacts badly with = forking at the moment. One
> > problem is HERFP. If I have a mix of = endpoints, some of
> which support
> > this (and thus send a 419), and others = that don't (and thus
> ring the
> > phone), then you'll end up always = completing the call on
> the endpoints
> > that don't support the extension.
>
> Good point. I think will mention this in the = draft but
> clearly I won't attempt to solve the well = studied HERFP
> problem. As a separate issues, some day the WG = should discuss
> the limitations of the "If it hurts don't = do it" solution to
> the HERFP problem.
>
> >
> > 2. THe mechanism doesn't provide a way for = a proxy to aggregate
> > multiple Puzzle headers from forked = branches. It needs to
> do something
> > like WWW-Authenticate where a proxy = collects these from the various
> > 419 and places all of them in the 419 = forwarded upstream. That will
> > also require something akin to realm, that = allows a
> UA/proxy to pull
> > out its own puzzle.
>
> Oops. Excellent point. Thanks, will fix this. =
>
>
> = _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core = SIP Protocol
> Use sip-implementors@cs.columbia.edu for = questions on current
> sip Use sipping@ietf.org for new developments = on the
> application of sip
>
>

------_=_NextPart_001_01C52029.A0B613FD-- --===============1928937812== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1928937812==-- From sip-bounces@ietf.org Thu Mar 3 15:42:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13445 for ; Thu, 3 Mar 2005 15:42:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6xAq-0002xI-Mn for sip-web-archive@ietf.org; Thu, 03 Mar 2005 15:43:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6x7C-0007aG-B3; Thu, 03 Mar 2005 15:40:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6x7A-0007a9-Jf for sip@megatron.ietf.org; Thu, 03 Mar 2005 15:40:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13247 for ; Thu, 3 Mar 2005 15:40:06 -0500 (EST) Received: from hoemail2.lucent.com ([192.11.226.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6x8Y-0002uQ-FR for sip@ietf.org; Thu, 03 Mar 2005 15:41:37 -0500 Received: from il0015exch001h.wins.lucent.com (h135-1-23-83.lucent.com [135.1.23.83]) by hoemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j23Ke3OG008422 for ; Thu, 3 Mar 2005 14:40:03 -0600 (CST) Received: by il0015exch001h.ih.lucent.com with Internet Mail Service (5.5.2657.72) id ; Thu, 3 Mar 2005 14:40:02 -0600 Message-ID: From: "Chaidez, Fidencio (Fidencio)" To: "'Jesske, R'" , sip@ietf.org Subject: RE: [Sip] Reason Header; protocol? Date: Thu, 3 Mar 2005 14:40:00 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Roland, In the U.S., in the ATIS T1.679 specification (which is the U.S. equivalent to the ITU-T Q.1912.5 spec), cause values that were ANSI specific (i.e. coding standard = "ANSI" in ISUP), the value of "ANSI" was specified for the protocol component of the Reason header. Note that for cause values using the coding standard of Q.850, the protocol component of the Reason header remained as "Q.850". Unfortunately, the protocol value of "ANSI" has not been registered with IANA yet (It should be). For consistency with ATIS, my suggestion would be to use a protocol value of "ETSI", in your case. Regards, Fidencio -----Original Message----- From: Jesske, R [mailto:R.Jesske@t-com.net] Sent: Thursday, March 03, 2005 10:49 AM To: sip@ietf.org Subject: [Sip] Reason Header; protocol? Dear all, it was identified that in addition to ITU-T ETSI has also defined Cause Codes like cause 24. How should I interpret the Reason element protocol=Q850. The cause code is only used by ETSI and is not doubled. Two options are possible: 1. define a new value for Protocol=ETSI 2. to use the existing protocol=Q850 What is your opinion. Thank you Best Regards Roland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 3 22:21:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17031 for ; Thu, 3 Mar 2005 22:21:09 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D73Om-0002Ti-5V for sip-web-archive@ietf.org; Thu, 03 Mar 2005 22:22:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D73MZ-0003jX-6i; Thu, 03 Mar 2005 22:20:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D73MY-0003h1-5Q for sip@megatron.ietf.org; Thu, 03 Mar 2005 22:20:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16990 for ; Thu, 3 Mar 2005 22:20:23 -0500 (EST) Received: from opus.cs.columbia.edu ([128.59.20.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D73O1-0002Sr-6s for sip@ietf.org; Thu, 03 Mar 2005 22:21:58 -0500 Received: from [127.0.0.1] (IDENT:U2FsdGVkX18am4az4zU6MvK2I9xEmsYSeOd53FiabI8@razor.cs.columbia.edu [128.59.16.8]) (authenticated bits=0) by opus.cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j243Jvh3021463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 3 Mar 2005 22:20:07 -0500 (EST) Message-ID: <4227D3D1.2060001@cs.columbia.edu> Date: Thu, 03 Mar 2005 22:19:45 -0500 From: Henning Schulzrinne Organization: Columbia University User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Piers O'Hanlon" Subject: Re: [Sip] New Resource Priority Draft (-06) References: <23805.1109850954@cs.ucl.ac.uk> In-Reply-To: <23805.1109850954@cs.ucl.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__C230066_P3_5 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, "James M. Polk" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Piers O'Hanlon wrote: > Hi, > > This draft (06) is looking better - I have a few comments: > > 1) The explanation of the use Accept-RP in last para of section 3.3 > differs from that in section 4.3 (ie. It doesn't mentioned the > inclusion of an Accept-RP hdr in a 420 response) A remnant of earlier versions; fixed. 420 is just for 'unsupported' and thus couldn't be returned in 420. > > 2) Section 4.3 should probably mention the inclusion of the > 'resource-priority' option tag in a "Supported" header in the > response. This is standard SIP behavior, but I guess it doesn't hurt to call it out. > > 3) In section 4.4.1 I'm not sure if it's entirely correct to state > that 'proxies do not manage sessions'? Isn't it possible that a proxy > may actually implement the preemption? I don't see how a proxy can implement preemption. It has no way to send a BYE to the preempted session, for example (and does not see any media packets). > > Thanks, > > Piers. > > > > _______________________________________________ Sip mailing list > https://www1.ietf.org/mailman/listinfo/sip This list is for NEW > development of the core SIP Protocol Use > sip-implementors@cs.columbia.edu for questions on current sip Use > sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 3 22:55:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19286 for ; Thu, 3 Mar 2005 22:55:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D73ve-00037y-5l for sip-web-archive@ietf.org; Thu, 03 Mar 2005 22:56:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D73sC-00080a-Bf; Thu, 03 Mar 2005 22:53:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D73sA-00080V-4l for sip@megatron.ietf.org; Thu, 03 Mar 2005 22:53:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19132 for ; Thu, 3 Mar 2005 22:53:03 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D73td-00034T-N2 for sip@ietf.org; Thu, 03 Mar 2005 22:54:39 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-3.cisco.com with ESMTP; 03 Mar 2005 21:09:02 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,134,1107734400"; d="scan'208"; a="231279044:sNHT9538822814" Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j243qmYO017586; Thu, 3 Mar 2005 19:52:49 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-1.cisco.com [10.86.240.1]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AIF66762; Thu, 3 Mar 2005 19:52:47 -0800 (PST) Message-ID: <4227DB8E.7000900@cisco.com> Date: Thu, 03 Mar 2005 22:52:46 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francois Audet Subject: Re: [Sip] draft-jennings-sip-hashcash-01 References: <1ECE0EB50388174790F9694F77522CCF01A71139@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF01A71139@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: "'Cullen Jennings'" , "'sip@ietf.org'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Sigh.... probably. Its been on my todo list forever, and its one of these things where the cure may be worse than the disease. But perhaps others have a better idea how to fix it than I did. That solution was discussed here: http://www.jdrosen.net/papers/draft-rosenberg-sip-unify-00.txt -Jonathan R. Francois Audet wrote: > As a separate note, shouldn't we try to solve the HERFP problem? > > > > -----Original Message----- > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > > Behalf Of Cullen Jennings > > Sent: Wednesday, March 02, 2005 12:16 > > To: Jonathan Rosenberg > > Cc: sip@ietf.org > > Subject: Re: [Sip] draft-jennings-sip-hashcash-01 > > > > > > On 3/2/05 2:15 AM, "Jonathan Rosenberg" wrote: > > > > > 1. The mechanism interacts badly with forking at the moment. One > > > problem is HERFP. If I have a mix of endpoints, some of > > which support > > > this (and thus send a 419), and others that don't (and thus > > ring the > > > phone), then you'll end up always completing the call on > > the endpoints > > > that don't support the extension. > > > > Good point. I think will mention this in the draft but > > clearly I won't attempt to solve the well studied HERFP > > problem. As a separate issues, some day the WG should discuss > > the limitations of the "If it hurts don't do it" solution to > > the HERFP problem. > > > > > > > > 2. THe mechanism doesn't provide a way for a proxy to aggregate > > > multiple Puzzle headers from forked branches. It needs to > > do something > > > like WWW-Authenticate where a proxy collects these from the various > > > 419 and places all of them in the 419 forwarded upstream. That will > > > also require something akin to realm, that allows a > > UA/proxy to pull > > > out its own puzzle. > > > > Oops. Excellent point. Thanks, will fix this. > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current > > sip Use sipping@ietf.org for new developments on the > > application of sip > > > > > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 4 10:10:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26484 for ; Fri, 4 Mar 2005 10:10:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7ETF-0004uQ-4l for sip-web-archive@ietf.org; Fri, 04 Mar 2005 10:12:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7EQH-0006nL-Mt; Fri, 04 Mar 2005 10:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7EQ8-0006mR-C8 for sip@megatron.ietf.org; Fri, 04 Mar 2005 10:08:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26235 for ; Fri, 4 Mar 2005 10:08:50 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7ERh-0004rx-VJ for sip@ietf.org; Fri, 04 Mar 2005 10:10:31 -0500 Received: from uk0006exch001h.wins.lucent.com (h135-86-145-57.lucent.com [135.86.145.57]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j24F8dO9010470 for ; Fri, 4 Mar 2005 09:08:40 -0600 (CST) Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <18T4FCNJ>; Fri, 4 Mar 2005 15:08:39 -0000 Message-ID: <475FF955A05DD411980D00508B6D5FB00C2903B7@en0033exch001u.uk.lucent.com> From: "Drage, Keith (Keith)" To: "'Shailender P'" , "'David Monahan'" , "Shekar, Nagesh Soma (Shekar)** CTR **" Subject: RE: [Sip] REFER request Date: Fri, 4 Mar 2005 15:08:36 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 This is an assumption of one particular charging model for one particular environment. Moreover it is based on the existing PSTN charging model where you were paying for the provision of a piece of copper between the two endpoints. The same rules do not necessarily apply anymore. There are not specifications that I am aware of that state anybody should be charged in any particular manner. regards Keith > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > Shailender P > Sent: 03 March 2005 14:23 > To: 'David Monahan'; 'Shekar, Nagesh Soma (Shekar)** CTR **' > Cc: sip@ietf.org > Subject: RE: [Sip] REFER request > > > If B is refered to C by A, then B invites C and establishes > and new call, > then informs A. Typically, after knowing B is connected to C, > A sends bye to > B and disconnects the call. In this scenario I guess B will > be charged. I > guess in redirection (call re-direct) A would be charged. > > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > David Monahan > Sent: Thursday, March 03, 2005 7:33 PM > To: Shekar, Nagesh Soma (Shekar)** CTR ** > Cc: sip@ietf.org > Subject: Re: [Sip] REFER request > > > I would expect the service provider to decide who and how > they are going > to charge for a particular service. > > Rgds, > David > > Shekar, Nagesh Soma (Shekar)** CTR ** wrote: > > With traditional telephony, the party that initiated the transfer > > would be charged for transferred leg of the call. In this case > > that would be A. > > > > > >>-----Original Message----- > >>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > >>M.N.A.Smadi > >>Sent: Wednesday, March 02, 2005 7:42 PM > >>To: sip@ietf.org > >>Subject: [Sip] REFER request > >> > >> > >>hi; > >> > >>if we have A<->B then A refer B to C, who is going to be > >>charged for the > >>cost of the new call (namely, B<->C) > >> > >>thanks > >>m.smadi > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 4 10:32:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28855 for ; Fri, 4 Mar 2005 10:32:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7Eot-0005OR-KZ for sip-web-archive@ietf.org; Fri, 04 Mar 2005 10:34:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7EmY-0003EE-SK; Fri, 04 Mar 2005 10:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7EmV-0003Du-Oe for sip@megatron.ietf.org; Fri, 04 Mar 2005 10:31:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28809 for ; Fri, 4 Mar 2005 10:31:57 -0500 (EST) Received: from mailhost.iperia.com ([204.57.52.4] helo=iperia.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7Eo4-0005Mj-WE for sip@ietf.org; Fri, 04 Mar 2005 10:33:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] REFER request Date: Fri, 4 Mar 2005 10:31:34 -0500 Message-ID: <8019F8581B5FC14DBD94BAF86844868E54B7DC@viridis.IPeria.local> Thread-topic: [Sip] REFER request Thread-index: AcUgzHuWiFds0SQoScKMfkhYyLGltwAAeQFQ From: "Gordon Ledgard" To: "Drage, Keith \(Keith\)" , "Shailender P" , "David Monahan" , "Shekar, Nagesh Soma \(Shekar\)** CTR **" X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: quoted-printable Indeed. Whether redirected or refered, ALL these examples are valid: 1) B may be paying for a service of which A is an agent. B is charged. 2) A may be a service in which B is a non-paying member. A is charged. 3) B may be trying to find C thru C's agent, A. C is charged. Gordon -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Drage, Keith (Keith) Sent: Friday, March 04, 2005 10:09 AM To: 'Shailender P'; 'David Monahan'; Shekar, Nagesh Soma (Shekar)** CTR ** Cc: sip@ietf.org Subject: RE: [Sip] REFER request This is an assumption of one particular charging model for one particular environment.=20 Moreover it is based on the existing PSTN charging model where you were paying for the provision of a piece of copper between the two endpoints. The same rules do not necessarily apply anymore. There are not specifications that I am aware of that state anybody should be charged in any particular manner. regards Keith > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > Shailender P > Sent: 03 March 2005 14:23 > To: 'David Monahan'; 'Shekar, Nagesh Soma (Shekar)** CTR **' > Cc: sip@ietf.org > Subject: RE: [Sip] REFER request >=20 >=20 > If B is refered to C by A, then B invites C and establishes=20 > and new call, > then informs A. Typically, after knowing B is connected to C,=20 > A sends bye to > B and disconnects the call. In this scenario I guess B will=20 > be charged. I > guess in redirection (call re-direct) A would be charged. >=20 >=20 > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > David Monahan > Sent: Thursday, March 03, 2005 7:33 PM > To: Shekar, Nagesh Soma (Shekar)** CTR ** > Cc: sip@ietf.org > Subject: Re: [Sip] REFER request >=20 >=20 > I would expect the service provider to decide who and how=20 > they are going > to charge for a particular service. >=20 > Rgds, > David >=20 > Shekar, Nagesh Soma (Shekar)** CTR ** wrote: > > With traditional telephony, the party that initiated the transfer > > would be charged for transferred leg of the call. In this case > > that would be A. > > > > > >>-----Original Message----- > >>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > >>M.N.A.Smadi > >>Sent: Wednesday, March 02, 2005 7:42 PM > >>To: sip@ietf.org > >>Subject: [Sip] REFER request > >> > >> > >>hi; > >> > >>if we have A<->B then A refer B to C, who is going to be > >>charged for the > >>cost of the new call (namely, B<->C) > >> > >>thanks > >>m.smadi >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 4 10:34:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29118 for ; Fri, 4 Mar 2005 10:34:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7Eqs-0005TH-AY for sip-web-archive@ietf.org; Fri, 04 Mar 2005 10:36:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7EmU-0003Dj-RN; Fri, 04 Mar 2005 10:31:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7EmT-0003DU-2x for sip@megatron.ietf.org; Fri, 04 Mar 2005 10:31:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28798 for ; Fri, 4 Mar 2005 10:31:54 -0500 (EST) Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D7Eo0-0005Ml-Ku for sip@ietf.org; Fri, 04 Mar 2005 10:33:36 -0500 Received: from sonic.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 4 Mar 2005 15:29:30 +0000 X-Mailer: exmh version 2.7.0 06/18/2004 with version: MH 6.8.3 #25[UCI] From: "Piers O'Hanlon" X-url: http://www.ucl.ac.uk To: Henning Schulzrinne Subject: Re: [Sip] New Resource Priority Draft (-06) In-reply-to: Your message of "Thu, 03 Mar 2005 22:19:45 EST." <4227D3D1.2060001@cs.columbia.edu> Date: Fri, 04 Mar 2005 15:29:29 +0000 Message-ID: <11910.1109950169@cs.ucl.ac.uk> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: sip@ietf.org, P.OHanlon@cs.ucl.ac.uk, "James M. Polk" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 > This is standard SIP behavior, but I guess it doesn't hurt to call it out. > Sure. > > > > 3) In section 4.4.1 I'm not sure if it's entirely correct to state > > that 'proxies do not manage sessions'? Isn't it possible that a proxy > > may actually implement the preemption? > > I don't see how a proxy can implement preemption. It has no way to send > a BYE to the preempted session, for example (and does not see any media > packets). > Ah ok - I was thinking about entities in the network that might implement the preemption - strictly one would probably need to use something like a B2BUA? Piers. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 4 11:10:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02282 for ; Fri, 4 Mar 2005 11:10:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7FPc-0006Il-HX for sip-web-archive@ietf.org; Fri, 04 Mar 2005 11:12:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7FJZ-0001EG-Ay; Fri, 04 Mar 2005 11:06:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7FJX-0001EA-DY for sip@megatron.ietf.org; Fri, 04 Mar 2005 11:06:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01730 for ; Fri, 4 Mar 2005 11:06:05 -0500 (EST) Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7FL7-0006Ae-L2 for sip@ietf.org; Fri, 04 Mar 2005 11:07:46 -0500 Received: from lion.cs.columbia.edu (IDENT:3RB0KMAxgU0EsCNP4qe9CDiklroWCNPK@lion.cs.columbia.edu [128.59.16.120]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id j24G4hir010662 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NOT); Fri, 4 Mar 2005 11:04:43 -0500 (EST) Received: from [128.59.16.206] (chairpc.win.cs.columbia.edu [128.59.16.206]) (authenticated bits=0) by lion.cs.columbia.edu (8.12.9/8.12.9) with ESMTP id j24G4eRn010178 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 4 Mar 2005 11:04:41 -0500 Message-ID: <42288713.709@cs.columbia.edu> Date: Fri, 04 Mar 2005 11:04:35 -0500 From: Henning Schulzrinne User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Piers O'Hanlon" Subject: Re: [Sip] New Resource Priority Draft (-06) References: <11910.1109950169@cs.ucl.ac.uk> In-Reply-To: <11910.1109950169@cs.ucl.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PerlMx-Spam: Gauge=IIIIIII, Probability=7%, Report='__CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, "James M. Polk" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit > Ah ok - I was thinking about entities in the network that might > implement the preemption - strictly one would probably need to use > something like a B2BUA? Yes. > > Piers. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 4 11:46:45 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04609 for ; Fri, 4 Mar 2005 11:46:45 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7FyV-0006yk-87 for sip-web-archive@ietf.org; Fri, 04 Mar 2005 11:48:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7Fw8-0007m2-Ve; Fri, 04 Mar 2005 11:46:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7Fw7-0007lt-A8 for sip@megatron.ietf.org; Fri, 04 Mar 2005 11:45:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04579 for ; Fri, 4 Mar 2005 11:45:56 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7Fxi-0006xw-2o for sip@ietf.org; Fri, 04 Mar 2005 11:47:38 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 04 Mar 2005 08:44:06 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,135,1107763200"; d="scan'208"; a="165242226:sNHT20774564" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j24GhtYO010837; Fri, 4 Mar 2005 08:43:55 -0800 (PST) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 4 Mar 2005 08:43:55 -0800 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 04 Mar 2005 08:43:50 -0800 Subject: Re: [SIP] SDP in OPTIONS From: Cullen Jennings To: Jonathan Rosenberg , "Peter Hedman (LD/EAB)" Message-ID: In-Reply-To: <422726B7.5000904@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 04 Mar 2005 16:43:55.0502 (UTC) FILETIME=[5AE730E0:01C520D9] X-Spam-Score: 1.1 (+) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , "'James M. Polk'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit I'm unclear on what exactly you want to accomplish here but if it is. Is it: A is going to call B. A wants to find out the media capabilities of B then allow the user of device A to make some choice before B starts alerting. If so, you might consider pre conditions of some sort. Anyways, I'd be curios to better understand what it is 3GPP wants to accomplish here. Cullen On 3/3/05 7:01 AM, "Jonathan Rosenberg" wrote: > inline. > > Peter Hedman (LD/EAB) wrote: > >> Thanks for your comments. >> >> 3GPP is discussing use cases where the capabilities of the remote UAs >> should be known prior to sending the INVITE, i.e. to be able to >> present a set of possibilities to the user. E.g. if there is an >> existing non-SIP communication between two users (e.g. CS call), SIP >> could be used to learn the capabilities of the remote UA. >> >> Different mechanisms have been discussed e.g. use of Presence or >> using INVITE with inactive media. The initial use of OPTIONS was >> favourable. > > Either presence or OPTIONS would work. Presence is clearly better if the > user is someone you already are subscribing to. Prescaps will give you > much the same information you will get from an OPTIONS, though it won't > tell you the list of supported codecs. > > >> To avoid sending 2 pair of request/reponse exchanges for >> a large amount of e.g. CS calls it would be beneficial to optimize >> the procedure to one request/response exchange. > > As I mentioned, doing that is not an appropriate use of OPTIONS. The > OPTIONS request body is NOT meant to convey the capabilities of the > requester. > >>> Putting an SDP in the body of an OPTIONS request, even with an >>> optional content-disposition, feels like a misuse of OPTIONS to me. >>> >> >> [Peter] I can't judge whether it is a misuse, but it seems like SIP >> is able to handle such an optimisation. > > Its not a match for the semantics of the method. Quoting RFC 3261: > > 11 Querying for Capabilities > > The SIP method OPTIONS allows a UA to query another UA or a proxy > server as to its capabilities. This allows a client to discover > information about the supported methods, content types, extensions, > codecs, etc. without "ringing" the other party. For example, before > > > Nowhere in there does it talk about OPTIONS being used to inform the > other side of its capabilities. > > -Jonathan R. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 4 12:14:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07063 for ; Fri, 4 Mar 2005 12:14:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7GPe-0007jE-9o for sip-web-archive@ietf.org; Fri, 04 Mar 2005 12:16:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7GNb-0004rp-Mb; Fri, 04 Mar 2005 12:14:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7GNa-0004rk-6w for sip@megatron.ietf.org; Fri, 04 Mar 2005 12:14:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07042 for ; Fri, 4 Mar 2005 12:14:19 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7GPA-0007ib-Cm for sip@ietf.org; Fri, 04 Mar 2005 12:16:02 -0500 Received: from [64.101.149.215] ([64.101.149.215]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.12.11) with ESMTP id j24HGA1w005553 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 4 Mar 2005 11:16:11 -0600 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <691036734f127593420fbdd947642d3c@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Subject: Re: [SIP] SDP in OPTIONS Date: Fri, 4 Mar 2005 11:14:15 -0600 To: Cullen Jennings X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , "Peter Hedman \(LD/EAB\)" , "'James M. Polk'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit On Mar 4, 2005, at 10:43 AM, Cullen Jennings wrote: > > I'm unclear on what exactly you want to accomplish here but if it is. > Is it: > > A is going to call B. A wants to find out the media capabilities of B > then > allow the user of device A to make some choice before B starts > alerting. > > If so, you might consider pre conditions of some sort. Anyways, I'd be > curios to better understand what it is 3GPP wants to accomplish here. > > Just guessing, but I suspect A wants to find out if it has any codecs (and perhaps transports, aka v6) in common with B, or is going to need to route through a transcoder application instead, BEFORE alerting B. So, preconditions would appear to work. We should have built this protocol around a two-stage (or n-stage, where n >1, I suppose) commit model from day 1. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 4 12:32:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09693 for ; Fri, 4 Mar 2005 12:32:32 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7Ggo-0008IO-Op for sip-web-archive@ietf.org; Fri, 04 Mar 2005 12:34:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7Ge9-0000LV-S1; Fri, 04 Mar 2005 12:31:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7Ge7-0000IB-Rc for sip@megatron.ietf.org; Fri, 04 Mar 2005 12:31:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09326 for ; Fri, 4 Mar 2005 12:31:24 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7Gfj-0008Dy-BR for sip@ietf.org; Fri, 04 Mar 2005 12:33:07 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 04 Mar 2005 09:31:27 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,135,1107763200"; d="scan'208"; a="165265844:sNHT20852336" Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j24HVFYO027708; Fri, 4 Mar 2005 09:31:15 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-1.cisco.com [10.86.240.1]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AIF95614; Fri, 4 Mar 2005 09:31:14 -0800 (PST) Message-ID: <42289B61.7000905@cisco.com> Date: Fri, 04 Mar 2005 12:31:13 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [SIP] SDP in OPTIONS References: <691036734f127593420fbdd947642d3c@softarmor.com> In-Reply-To: <691036734f127593420fbdd947642d3c@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , "sip@ietf.org" , "Peter Hedman \(LD/EAB\)" , "'James M. Polk'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Dean Willis wrote: > > On Mar 4, 2005, at 10:43 AM, Cullen Jennings wrote: > >> >> I'm unclear on what exactly you want to accomplish here but if it is. >> Is it: >> >> A is going to call B. A wants to find out the media capabilities of B >> then >> allow the user of device A to make some choice before B starts alerting. >> >> If so, you might consider pre conditions of some sort. Anyways, I'd be >> curios to better understand what it is 3GPP wants to accomplish here. >> >> > Just guessing, but I suspect A wants to find out if it has any codecs > (and perhaps transports, aka v6) in common with B, or is going to need > to route through a transcoder application instead, BEFORE alerting B. Endpoint A doesnt need to include its SDP in the OPTIONS request to figure this out. It get can the capabilities from endpoint B from the OPTIONS response and compare with its own. If there is something in common, it can make the call. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 4 12:54:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13526 for ; Fri, 4 Mar 2005 12:54:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7H2C-0000xv-Vn for sip-web-archive@ietf.org; Fri, 04 Mar 2005 12:56:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7Gti-0003Ei-EU; Fri, 04 Mar 2005 12:47:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7Gth-0003EY-1W for sip@megatron.ietf.org; Fri, 04 Mar 2005 12:47:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11549 for ; Fri, 4 Mar 2005 12:47:30 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7GvI-0000La-W3 for sip@ietf.org; Fri, 04 Mar 2005 12:49:13 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 04 Mar 2005 11:03:22 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,135,1107734400"; d="scan'208"; a="231463130:sNHT20658954" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j24HkxTO001990; Fri, 4 Mar 2005 09:47:02 -0800 (PST) Received: from cisco.com ([161.44.79.169]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APO47664; Fri, 4 Mar 2005 12:46:59 -0500 (EST) Message-ID: <42289F0F.9030206@cisco.com> Date: Fri, 04 Mar 2005 12:46:55 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis Subject: Re: [SIP] SDP in OPTIONS References: <691036734f127593420fbdd947642d3c@softarmor.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , "sip@ietf.org" , "Peter Hedman \(LD/EAB\)" , "'James M. Polk'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit I don't *know* what they are trying to achieve. But I've been scratching my head trying to figure out what they could possibly be up to. Based on other things I have seen mentioned, I think possibly they need the SDP in the options in order to route the request to the appropriate application, and so get the answer that is appropriate to what they intend to do. So perhaps they need to see the SDP to choose the PTT application rather than the IM application or the video application. If so, this points up another problem with routing based on SDP. Paul Dean Willis wrote: > > On Mar 4, 2005, at 10:43 AM, Cullen Jennings wrote: > >> >> I'm unclear on what exactly you want to accomplish here but if it is. >> Is it: >> >> A is going to call B. A wants to find out the media capabilities of B >> then >> allow the user of device A to make some choice before B starts alerting. >> >> If so, you might consider pre conditions of some sort. Anyways, I'd be >> curios to better understand what it is 3GPP wants to accomplish here. >> >> > Just guessing, but I suspect A wants to find out if it has any codecs > (and perhaps transports, aka v6) in common with B, or is going to need > to route through a transcoder application instead, BEFORE alerting B. > > So, preconditions would appear to work. > > We should have built this protocol around a two-stage (or n-stage, where > n >1, I suppose) commit model from day 1. > > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 4 18:23:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17668 for ; Fri, 4 Mar 2005 18:23:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7MAp-0000uM-Cn for sip-web-archive@ietf.org; Fri, 04 Mar 2005 18:25:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7M6K-0007tF-4c; Fri, 04 Mar 2005 18:20:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7M6H-0007sx-LA for sip@megatron.ietf.org; Fri, 04 Mar 2005 18:20:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17183 for ; Fri, 4 Mar 2005 18:20:50 -0500 (EST) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7M7w-0000n0-IA for sip@ietf.org; Fri, 04 Mar 2005 18:22:36 -0500 Received: from nhmail2.needham.brooktrout.com (nhmail2.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j24NEehH006963; Fri, 4 Mar 2005 18:14:40 -0500 (EST) Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Mar 2005 18:10:45 -0500 Message-ID: From: Eric Burger To: Louis Alexander , sip@ietf.org Subject: RE: [Sip] midcall signalling Date: Fri, 4 Mar 2005 18:10:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Yes and no. *Transporting* DTMF as RFC2833 or coded dual-tone multi-frequency is always legal. However, the subject of the query is "midcall signaling". Signaling is not transport. The only method of signaling midcall events in SIP is KPML. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of > Louis Alexander > Sent: Thursday, February 24, 2005 5:01 PM > To: 'Fatih Ey|p NAR'; 'Ban Zie'; sip@ietf.org > Subject: RE: [Sip] midcall signalling > > > Of course, plain old inband dtmf (the DTMF tones encoded as > audio packets, > NOT 2833 tones) is still legal as well :) > > --Louis > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Fatih > Ey|p NAR > Sent: Thursday, February 24, 2005 4:45 PM > To: Ban Zie; sip@ietf.org > Subject: Re: [Sip] midcall signalling > > SIP DMTF signalling is done with INFO messages or with > RTP messages, the media protocol. This is defined in > http://www.ietf.org/rfc/rfc2833.txt - IETF RFC 2833 > > > --- Ban Zie wrote: > > > hello, > > is there 100% agreement / concensus on how midcall > > signalling data is to be carried in sip ? > > when 2 SIP UA's are alrady in conversation, then if > > one user presses some keys on his keypad, are they > > transmitted as DTMF on RTP, or how exactly is it > > done ? > > cheers, > > bzie. > > -- > > > ___________________________________________________________ > > Sign-up for Ads Free at Mail.com > > http://promo.mail.com/adsfreejump.htm > > > > > > _______________________________________________ > > Sip mailing list > > https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP > > Protocol > > Use sip-implementors@cs.columbia.edu for questions > > on current sip > > Use sipping@ietf.org for new developments on the > > application of sip > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email > ______________________________________________________________________ > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 4 18:24:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17733 for ; Fri, 4 Mar 2005 18:24:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7MBH-0000v7-5O for sip-web-archive@ietf.org; Fri, 04 Mar 2005 18:26:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7M6L-0007tR-EX; Fri, 04 Mar 2005 18:20:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7M6I-0007t7-8h for sip@megatron.ietf.org; Fri, 04 Mar 2005 18:20:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17186 for ; Fri, 4 Mar 2005 18:20:51 -0500 (EST) Received: from salvelinus.brooktrout.com ([204.176.205.6]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7M7x-0000n0-3S for sip@ietf.org; Fri, 04 Mar 2005 18:22:37 -0500 Received: from nhmail2.needham.brooktrout.com (nhmail2.brooktrout.com [204.176.205.242]) by salvelinus.brooktrout.com (8.12.5/8.12.5) with ESMTP id j24NEghH006964; Fri, 4 Mar 2005 18:14:42 -0500 (EST) Received: by nhmail2.brooktrout.com with Internet Mail Service (5.5.2653.19) id ; Fri, 4 Mar 2005 18:10:47 -0500 Message-ID: From: Eric Burger To: Ban Zie Subject: RE: [Sip] midcall signalling Date: Fri, 4 Mar 2005 18:10:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Do you want midcall signaling or DTMF transport? If you need reliable, application-layer conveyance of signaling, then KPML is the right answer. See http://www.ietf.org/internet-drafts/draft-ietf-sipping-app-interaction-frame work-04.txt for a very detailed explanation why. If all you need is unreliable transport of tones, use RFC2833 or the tones themselves. Note this has nothing to do with topology. KPML is, in fact, purely for UA-UA communications. It just happens there is a use case where one of the UA's is an IP or TDM gateway. > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On > Behalf Of Ban > Zie > Sent: Friday, February 25, 2005 9:40 AM > To: Mariano Stokle > Cc: sip@ietf.org; Louis Alexander > Subject: Re: [Sip] midcall signalling > > > Hello Mariano: > > > You should also check > > http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-07.txt > > I quickly skimmed thru this I-D, and it appears to me that > this is more likely to be associated as a Event delivery > medium between and IVR / G/w / Transcoder and a SIP > AppServer. In my scenario, i.e. UA <----> UA, this doesn't > seem reasonable thing to do. Here the second-UA is like a > Telephonic credit-card payment gateway. > > -z > -- > ___________________________________________________________ > Sign-up for Ads Free at Mail.com > http://promo.mail.com/adsfreejump.htm > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 4 23:39:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13996 for ; Fri, 4 Mar 2005 23:39:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7R65-0007Zq-0b for sip-web-archive@ietf.org; Fri, 04 Mar 2005 23:41:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7R3V-0006Xe-SV; Fri, 04 Mar 2005 23:38:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7R32-0006W7-M9 for sip@megatron.ietf.org; Fri, 04 Mar 2005 23:37:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13900 for ; Fri, 4 Mar 2005 23:37:49 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7R4i-0007X0-Sq for sip@ietf.org; Fri, 04 Mar 2005 23:39:38 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-1.cisco.com with ESMTP; 04 Mar 2005 20:52:18 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,137,1107763200"; d="scan'208"; a="617924576:sNHT21402540" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j254bdTM010941; Fri, 4 Mar 2005 20:37:39 -0800 (PST) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 4 Mar 2005 20:37:39 -0800 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 04 Mar 2005 20:37:35 -0800 Subject: Re: [Sip] Comment on refer-with-norefersub-01 From: Cullen Jennings To: Tom Hiller Message-ID: In-Reply-To: <4226D688.60104@lucent.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Mar 2005 04:37:39.0913 (UTC) FILETIME=[103DBB90:01C5213D] X-Spam-Score: 1.1 (+) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Content-Transfer-Encoding: 7bit I think your are misunderstanding. I don't think it means this at all It means the UAC sends it with the tag but no require. If UAS supports it, great. If the UAS does not support it then the refer still works and a NOTIFY is sent which the UAC promptly ends. Now consider what would have happened if we did have the require. UAC would send the refer, it would fail. The the UAC would send refer without the tag. Then the UAS would send Notify, then the UAC would cancel the subscription. It seems the first is case better for wireless - what am I missing here. On 3/3/05 1:19 AM, "Tom Hiller" wrote: > Cullen, > > > Does this mean the mobile has to receive an immediate notification due > the REFER, then send a SUBSCRIBE to kill the implicit subscription, and > then get yet another notification? > > In practice, people draw message flows, count SIP requests and responses > and other messages on a per "call" basis, and then tally a total. In > wireless it is sometimes important to minimize the number of messages > per "call". "norefersub" reduces the number of messages when one > doesn't need the implicit subscription because the user learns the > notification information via existing subscriptions or via other ways. > > Also, some wireless spectrum is costly, and in some cases there is a > potential for lengthy SIP notification packets to interfere with RTP > packet flow due to lack of over-the-air connection bandwidth. There is > also a possible service impact of not being able transmit another > message while sending a SUBSCRIBE to instantly end a subscription. > > OMA has extensively incorporated "norefersub" into draft baselines > (i.e., includes the option tag "norefersub" in the Require header). > These draft baselines are now being readied for publication. OMA > requires the "norefersub" option tag in the Require header. > > If I am misunderstanding the point of your comment, could you expand > further? > > > - Tom > > Cullen Jennings wrote: > >> It seems like in any case where you put a Require with the option tag, it >> results in far more traffic and less chance of interoperability than >> creating the subscription and instantly ending it. >> >> I think you should say that the tag is not allowed in a Require. >> >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 4 23:57:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15831 for ; Fri, 4 Mar 2005 23:57:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7RNb-00081n-EH for sip-web-archive@ietf.org; Fri, 04 Mar 2005 23:59:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7RJt-00012Z-HY; Fri, 04 Mar 2005 23:55:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7RJq-00012U-SR for sip@megatron.ietf.org; Fri, 04 Mar 2005 23:55:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15625 for ; Fri, 4 Mar 2005 23:55:11 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7RLU-0007yD-Ie for sip@ietf.org; Fri, 04 Mar 2005 23:56:57 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 04 Mar 2005 22:11:23 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,137,1107734400"; d="scan'208"; a="231643078:sNHT20880532" Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j254swTM013102; Fri, 4 Mar 2005 20:54:59 -0800 (PST) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 4 Mar 2005 20:54:59 -0800 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 04 Mar 2005 20:54:54 -0800 Subject: Re: [Sip] midcall signalling From: Cullen Jennings To: Ban Zie Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Mar 2005 04:54:59.0198 (UTC) FILETIME=[7BB409E0:01C5213F] X-Spam-Score: 1.1 (+) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , Eric Burger X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Content-Transfer-Encoding: 7bit This whole thread is somewhat misleading. If you want to get DTMF from one UA to the other UA that it is talking to, your bar none best bet is 2833. This was the original problem stated - it is what almost all SIP devices do today. It is how most people at IETF recommend solving this problem. It generally it works better than solutions that leave the DTMF tones in the encoded audio. KPML is meant for a different problem. On 3/4/05 3:10 PM, "Eric Burger" wrote: > Do you want midcall signaling or DTMF transport? > > If you need reliable, application-layer conveyance of signaling, then KPML > is the right answer. See > http://www.ietf.org/internet-drafts/draft-ietf-sipping-app-interaction-frame > work-04.txt > for a very detailed explanation why. > > If all you need is unreliable transport of tones, use RFC2833 or the tones > themselves. > > Note this has nothing to do with topology. KPML is, in fact, purely for > UA-UA communications. It just happens there is a use case where one of the > UA's is an IP or TDM gateway. > >> -----Original Message----- >> From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On >> Behalf Of Ban >> Zie >> Sent: Friday, February 25, 2005 9:40 AM >> To: Mariano Stokle >> Cc: sip@ietf.org; Louis Alexander >> Subject: Re: [Sip] midcall signalling >> >> >> Hello Mariano: >> >>> You should also check >>> http://www.ietf.org/internet-drafts/draft-ietf-sipping-kpml-07.txt >> >> I quickly skimmed thru this I-D, and it appears to me that >> this is more likely to be associated as a Event delivery >> medium between and IVR / G/w / Transcoder and a SIP >> AppServer. In my scenario, i.e. UA <----> UA, this doesn't >> seem reasonable thing to do. Here the second-UA is like a >> Telephonic credit-card payment gateway. >> >> -z >> -- >> ___________________________________________________________ >> Sign-up for Ads Free at Mail.com >> http://promo.mail.com/adsfreejump.htm >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Mar 5 00:04:10 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16421 for ; Sat, 5 Mar 2005 00:04:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7RUF-0008Km-1Y for sip-web-archive@ietf.org; Sat, 05 Mar 2005 00:05:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7RPQ-0001sY-Ck; Sat, 05 Mar 2005 00:01:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7RPN-0001sP-5f for sip@megatron.ietf.org; Sat, 05 Mar 2005 00:00:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16144 for ; Sat, 5 Mar 2005 00:00:54 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7RR4-0008Fn-Sz for sip@ietf.org; Sat, 05 Mar 2005 00:02:43 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 04 Mar 2005 21:02:33 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j2550iYO024664; Fri, 4 Mar 2005 21:00:45 -0800 (PST) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 4 Mar 2005 21:00:45 -0800 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 04 Mar 2005 21:00:41 -0800 Subject: Re: [SIP] SDP in OPTIONS From: Cullen Jennings To: Paul H Kyzivat , Dean Willis Message-ID: In-Reply-To: <42289F0F.9030206@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Mar 2005 05:00:45.0531 (UTC) FILETIME=[4A2242B0:01C52140] X-Spam-Score: 1.1 (+) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , "Peter Hedman \(LD/EAB\)" , "'James M. Polk'" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 7bit Well, since this is such a fun guessing game... How about this solution A sends INVITE with all it's codec to B. B say nope to all of them. A decided that A must need a transcoder. A sends to B2BUA style transcoder, called T, and T calls B offering all it's codecs. I'm willing to bet this will have less post dial delay on your average call that does not need a transocder than sending an option before very call. On 3/4/05 9:46 AM, "Paul Kyzivat" wrote: > I don't *know* what they are trying to achieve. But I've been scratching > my head trying to figure out what they could possibly be up to. Based on > other things I have seen mentioned, I think possibly they need the SDP > in the options in order to route the request to the appropriate > application, and so get the answer that is appropriate to what they > intend to do. So perhaps they need to see the SDP to choose the PTT > application rather than the IM application or the video application. > > If so, this points up another problem with routing based on SDP. > > Paul > > Dean Willis wrote: >> >> On Mar 4, 2005, at 10:43 AM, Cullen Jennings wrote: >> >>> >>> I'm unclear on what exactly you want to accomplish here but if it is. >>> Is it: >>> >>> A is going to call B. A wants to find out the media capabilities of B >>> then >>> allow the user of device A to make some choice before B starts alerting. >>> >>> If so, you might consider pre conditions of some sort. Anyways, I'd be >>> curios to better understand what it is 3GPP wants to accomplish here. >>> >>> >> Just guessing, but I suspect A wants to find out if it has any codecs >> (and perhaps transports, aka v6) in common with B, or is going to need >> to route through a transcoder application instead, BEFORE alerting B. >> >> So, preconditions would appear to work. >> >> We should have built this protocol around a two-stage (or n-stage, where >> n >1, I suppose) commit model from day 1. >> >> >> -- >> Dean >> >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sat Mar 5 01:12:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21188 for ; Sat, 5 Mar 2005 01:12:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7SYP-0001GD-3S for sip-web-archive@ietf.org; Sat, 05 Mar 2005 01:14:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7SUp-00039U-6I; Sat, 05 Mar 2005 01:10:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7SUl-00039M-VT for sip@megatron.ietf.org; Sat, 05 Mar 2005 01:10:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21014 for ; Sat, 5 Mar 2005 01:10:35 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7SWQ-0001CQ-EY for sip@ietf.org; Sat, 05 Mar 2005 01:12:19 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 04 Mar 2005 22:12:04 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j256AFTM022825; Fri, 4 Mar 2005 22:10:15 -0800 (PST) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 4 Mar 2005 22:10:15 -0800 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Fri, 04 Mar 2005 22:10:09 -0800 Subject: Re: [Sip] a middle ground approach for knowing AOR of a gruu From: Cullen Jennings To: Jonathan Rosenberg , "sip@ietf.org" Message-ID: In-Reply-To: <421D6367.8050703@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 05 Mar 2005 06:10:15.0126 (UTC) FILETIME=[FF67F760:01C52149] X-Spam-Score: 1.1 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit On 2/23/05 9:17 PM, "Jonathan Rosenberg" wrote: > We had a long discussion in another thread about whether or not we had > an additional requirement to allow the recipient of a GRUU to be able to > determine the AOR associated with that gruu. This seemed to be an issue > for systems that generate call logs or bills, since you'll have these > entries that are meaningless. I'm confused on why these system need to contact to be meaningful and what devices they are using today that make the contact meaningful for a billing system. The billing (and logging system) I have seen have seemed to be more interested in From, PAI, Call-ID, Time, and request URI. I'm still lost on the need for this. It will further confuse the UA / user resource confusion that we already have. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 6 02:18:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10665 for ; Sun, 6 Mar 2005 02:18:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7q3Y-0007Ef-3d for sip-web-archive@ietf.org; Sun, 06 Mar 2005 02:20:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7pzZ-0006Cq-WD; Sun, 06 Mar 2005 02:15:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7pzX-0006Ch-AK for sip@megatron.ietf.org; Sun, 06 Mar 2005 02:15:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08554 for ; Sun, 6 Mar 2005 02:15:53 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7q1T-0007AD-3D for sip@ietf.org; Sun, 06 Mar 2005 02:17:55 -0500 Received: from [127.0.0.1] (adam@magus.nostrum.com [10.10.10.2]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j267Fo9A038030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Mar 2005 01:15:52 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <422AAE23.5040403@nostrum.com> Date: Sun, 06 Mar 2005 01:15:47 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Hiller Subject: Re: [Sip] Comment on refer-with-norefersub-01 References: <4226D688.60104@lucent.com> In-Reply-To: <4226D688.60104@lucent.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Tom Hiller wrote: > Does this mean the mobile has to receive an immediate notification due > the REFER, then send a SUBSCRIBE to kill the implicit subscription, > and then get yet another notification? No; if you read REFER, the preferred method of killing the subscription is to send a 481 response to the first NOTIFY. /a _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 6 02:26:39 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14598 for ; Sun, 6 Mar 2005 02:26:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7qBs-0007S6-V4 for sip-web-archive@ietf.org; Sun, 06 Mar 2005 02:28:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7q55-0007da-Th; Sun, 06 Mar 2005 02:21:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7q4v-0007Vz-GD for sip@megatron.ietf.org; Sun, 06 Mar 2005 02:21:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13805 for ; Sun, 6 Mar 2005 02:21:27 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7q6r-0007Ja-8c for sip@ietf.org; Sun, 06 Mar 2005 02:23:29 -0500 Received: from [127.0.0.1] (adam@magus.nostrum.com [10.10.10.2]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j267LQgM038426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Mar 2005 01:21:27 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <422AAF73.2000305@nostrum.com> Date: Sun, 06 Mar 2005 01:21:23 -0600 From: Adam Roach User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach Subject: Re: [Sip] Comment on refer-with-norefersub-01 References: <4226D688.60104@lucent.com> <422AAE23.5040403@nostrum.com> In-Reply-To: <422AAE23.5040403@nostrum.com> X-Enigmail-Version: 0.89.5.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , Tom Hiller X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Whoops; I spoke too quickly. I thought this was documented in REFER; apparently, it's just something we spoke about putting in there, but it must not have made the final cut. Anyway, the general flow (prior to the norefersub extension) for a terminal that didn't care about the subscription is something like: |--REFER-->| |<---2xx---| |<-NOTIFY--| |----481-->| Kills subscription; see section 3.2.2 of RFC 3265 /a Adam Roach wrote: > Tom Hiller wrote: > >> Does this mean the mobile has to receive an immediate notification >> due the REFER, then send a SUBSCRIBE to kill the implicit >> subscription, and then get yet another notification? > > > > No; if you read REFER, the preferred method of killing the > subscription is to send a 481 response to the first NOTIFY. > > /a > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 6 12:11:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27358 for ; Sun, 6 Mar 2005 12:11:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7zJW-0007ZU-6R for sip-web-archive@ietf.org; Sun, 06 Mar 2005 12:13:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7zDU-0001d3-6D; Sun, 06 Mar 2005 12:06:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7zDS-0001cw-Mn for sip@megatron.ietf.org; Sun, 06 Mar 2005 12:06:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26861 for ; Sun, 6 Mar 2005 12:06:51 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7zFT-0007Q5-Kl for sip@ietf.org; Sun, 06 Mar 2005 12:09:00 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 06 Mar 2005 09:06:46 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j26H6hYO000113 for ; Sun, 6 Mar 2005 09:06:43 -0800 (PST) Received: from [130.129.135.77] (che-vpn-cluster-1-253.cisco.com [10.86.240.253]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AIH65764; Sun, 6 Mar 2005 09:06:41 -0800 (PST) Message-ID: <422B0FC1.3030306@cisco.com> Date: Sun, 06 Mar 2005 09:12:17 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Content-Transfer-Encoding: 7bit Subject: [Sip] comments on draft-peterson-message-identity X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: 7bit Sorry I've only finally gotten around to giving this a detailed read. I'm sending these comments to the sip list because the draft is up for discussion there. Firstly, this is an excellent, excellent document. A thorough treatment of the design issues involved in identity assertions in messaging systems. I really hope it moves forward to RFC, though I think its probably outside of the scope of the sip related groups. Some high level comments. I was disappointed that there wasn't a more thorough discussion on verification assertions. Its mentioned in passing in appendix B, but I think its likely to be an essential part of the story. Indeed, it interacts substantially with the online/offline arguments around keys by reference or by value. If an "always online" server like a mail server does the verification, and passes the verification assertion by-value, the identity assertions can be by reference, and offline messaging can still be provided. As such, I think this topic really needs to be expanded and many of the issues discussed: a. what kind of information is passed to the end user b. what is the behavior if the identity assertion fails - does the message get passed with some kind of indication of failure, or is it discarded? c. how is the verification assertion secured? Another topic not treated is who inserts the identity assertion. If its a domain assertion, does the domain insert it, or is the assertion passed to the originator? This reflects the design choices between older versions of the sip-identity draft and the new one. Section 8 - reference integrity. There is a general principle here that I think is missing. The reference indicators should be selected to include information that would need to be modified by an impersonator desiring to replay the message, in order for that attack to be useful. If a field is something that an impersonator would be happy to leave alone, as they could accomplish their attack without changing it, it is useless as a reference indicator. 8.1: the information that is conveyed in the message for indicating the dynamic reference indicators, must itself be a reference indicator for security purposes For replication - there isn't unlimited flexibility on what part of the message content can form the reference indicators. It has to include a minimum set of information, else the identity assertion becomes weakened. Section 8.2: usage of date as a reference indicator - this requires rougly syncrhonized time between sender and receiver. Can sometimes be a problem. Also gets complicated unless the sending dates are expressed in UTC. If they are expressed in other timezones, then conversions are needed and this can get really complicated. Section 8.3: when you are talking about keys by reference or by value, you mention the possible need for the message originator to obtain keys. I was uncertain of why it would need to do this - is this for storage of private keys ala sacred? I think you mean only for the purposes of including keys by reference on behalf of the domain provider. Should spell this out up front in the paragraph where it is discussed. Section 10: there is another solution here for anonymization, which is that the anonymization service is provided by my normal provider, but is done using a large number of domains they have registered. The relationship of these domains to my provider would not be discernable form the domain names, and furthermore, the provider could ensure that other data sources could not be used to correlate the domain name with the service provider. > Another important form of privacy relates to preventing > intermediaries responsible for message transfer from reading the > identity assertion. Encryption of assertions entails a very > different key distribution problem than identity. In order to send > an encrypted message to a recipient, the recipient must possess a > corresponding decryption key. This key needs to be shared, in some > fashion, with the identity provider before the identity provider can > encrypt the assertion for that recipient. The problem is complicated you need to be clear here on terms. When you say "intermediary" in the beginning, you mean intermediaries BESIDES the identity provider. The identity provider is also an intermediary between the originator and recipient. > Accordingly, an assertion must cover more than just the originator's > name. It must cover enough additional information that the assertion > cannot be replayed in a substantially message. substantially similar Appendix C: colons need to be placed after each hangText value; it is hard to separate it from the text that follows. Your definition of third party assertions in appendix D rules out a common case; third party call control in SIP. In that case, the sender of the message may be the domain of the user, but the message is originated by a device or agent acting on behalf of the user, not the user themselves. Though, perhaps this distinction is meaningless.... Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 6 14:31:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14012 for ; Sun, 6 Mar 2005 14:31:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D81VY-000368-Bd for sip-web-archive@ietf.org; Sun, 06 Mar 2005 14:33:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D81T3-00019U-NO; Sun, 06 Mar 2005 14:31:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D81T2-00019P-7b for sip@megatron.ietf.org; Sun, 06 Mar 2005 14:31:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13986 for ; Sun, 6 Mar 2005 14:31:06 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D81V3-00035Q-5A for sip@ietf.org; Sun, 06 Mar 2005 14:33:14 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 06 Mar 2005 12:47:39 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,139,1107734400"; d="scan'208"; a="231908716:sNHT29499916" Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j26JUsZV015941 for ; Sun, 6 Mar 2005 11:30:54 -0800 (PST) Received: from [130.129.135.77] (che-vpn-cluster-2-4.cisco.com [10.86.242.4]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AIH67655; Sun, 6 Mar 2005 11:30:52 -0800 (PST) Message-ID: <422B5A6C.8060505@cisco.com> Date: Sun, 06 Mar 2005 14:30:52 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 0c92ca299e0607fbf0058472806b19df Content-Transfer-Encoding: 7bit Subject: [Sip] comments on draft-ietf-sip-identity X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: a3962d9f28f80f517c050a4675f65235 Content-Transfer-Encoding: 7bit Enclosed are comments on draft-ietf-sip-identity-04. I did a very detailed review, and so many of my comments are nits. To spare everyone the trouble of reading the comments to look for more interesting issues (and I assume almost no one will), here are some of the more important comments: * display name handling I'm concerned that the treatment of the From display name. The current spec allows an authentication service to verify it (at MAY strength), and it can reject it if it doesnt like it. But, there is no signature that covers it, and no way for a verifier to know if the authentication service allowed it to pass. I'm worried that, although we believe that the URI is the important form of identity to worry about, real people will be more concerned with the display name. The mechanism may, as a result, be extremely misleading, because users are still free to completely spoof the display name. I'd like to consider adding the display name to the signature, under the constraints that, if done, it require the domain to tell the client the display names it can insert, so as to avoid all of these equivalence nightmares for internationalized names. * authorization policies - how to know if a domain is supporting this mechanism? The spec recommends that a verifier look at the domain name, and if it knows that it supports this mechanism, reject the request if its not in use. However, this is very difficult to know ahead of time, requiring exactly the same kind of closed network topology that we are trying to get away from in this draft. As such, I think some kind of companion technique for "checking if domain X is using sip-identity" is needed. It need not be defined here, but it seems crucial to successful deployment of this. * privacy interactions There are some interactions with SIP privacy (rfc3323) that require more consideration. Specifically, 3323 recommends that endpoints use a From field of anonymous.invalid, which would render this specification impotent when used in conjunction with rfc3323. I think a revision of rfc3323 is probably needed, but this spec has to make sure that the avenue is open for that. * sips URI scheme meaning just TLS The spec proposes the usage of a sips URI in the Identity-Info header field to mean that a client should open a TLS connection to the server, get its certs, and close the connection. I think this is a misuse of the SIPS URI. * why sips/https - not just http? and mandatory scheme The Identity-Info header field is supposed to contain only a sips or https URI, not just vanilla HTTP. What is the problem in using just vanilla HTTP? Also, I think we need to defined a baseline mandatory-to-impelement scheme. * applicability to register The draft specifies that the mechanism isn't applicable to REGISTER, but I think there are valid use cases and I dont see why it doesnt work. * tel URI handling Some strange behavior is specified for the cases where the From header field has a tel URI. I think that is really at odds with a domain-based identity assertion scheme, and I think that requests with tel URI in the From shouldn't be signed by an identity service without a proper way to determine the owning domain for that number. * only domain certs, or user certs? The text is somewhat unclear on whether it is possible for this mechanism to be used when endpoints act as the authentication service, using a cert that contains a user identity (i.e., a subjectAltName of user@domain). Is this allowed or not? * unclear subordination rules The verifier rules around namespace subordination are a bit unclear. We should make strong statements about what a verifier should do under various cases, and still leave the door open for other techniques in the future. Detailed comments: abstract > This document recommends practices and conventions for > identifying end users in SIP messages, and proposes a way to > distribute cryptographically-secure authenticated identities. this kind of statement makes it sound like is more of a BCP. I'd prefer something like, "This document defines a mechanism for securely identifying originators of SIP messages. It does so by defining two new SIP header fields, Identity, for conveying a signature used for validating the identity, and Identity-Info, for conveying a reference to the certificate of the signer." > However, few SIP user agents today support the end-user certificates > necessary to authenticate themselves via TLS or S/MIME, and this statement is misleading. It makes it sound like, if UA's would just support TLS, then we wouldn't need this spec. Its not true on two counts - an increasing number of UA are supporting TLS, and TLS doesn't suffice here due to its use as a hop-by-hop mechanism. > An example > of the former would be a presence service that compares the identity > of potential subscribers to a whitelist before determining whether it > should begin sending presence notifications. In both of these cases, I think this is better phrased as, "...whether it should accept or reject the subscription". > All RFC3261-compliant SIP user agents support a means of > authenticating themselves to a SIP registrar, commonly with a shared > secret; Digest authentication, which MUST be supported by SIP user > agents, is typically used for this purpose. this sentence is awkward. Suggest, "All RFC3261 compliant user agents support digest, which utilizes a shared secret, as a means for authenticating themselves to a SIP registrar." > The address-of-record URI used for registration is also the URI with > which a UA commonly populates the From header of requests in order to terminology nit: "header" refers to top part of a sip message that contains all of the header fields. The term you want her eis "From header field". > The identity > mechanism specified in this document derives from the following > principle: if you can prove you are eligible to register in a domain > under a particular address-of-record, you are proving that you are > capable of legitimately receiving requests for that > address-of-record, and accordingly, when you place that > address-of-record in the From header field of a SIP request other > than a registration (like an INVITE), you are providing a 'return > address' where you can legitimately be reached. In other words, if this definition would appear to rule out inclusion of anonymous identities in the From header field. This mistake is made many times through the document; I don't point it out again, but please look for all instances. > Accordingly, this document specifies a means of sharing a > cryptographic assurance of end-user SIP identity in an interdomain > context which is based on the concept of an 'authentication service' > and a new SIP header, the Identity header. Note that the scope of Though the mechanism here is targeted for inter-domain, it also works intra-domain (and quite well, in fact). I think you need to highlight this. > This specification allows either a user agent or a proxy server to > act as an authentication service. To maximize end-to-end security, I dont think the term "authentication service" has yet been defined in this doc. You should do that before using the term. > o The mechanism must allow a UAC to provide a strong cryptographic > identity assurance in a request that can be verified by a proxy > server or UAS. The UAC isn't providing the assurance at all. Suggest, "The mechanism must provide a strong cryptographic identity assurance in a request that can be verified by a proxy server or UAS". > The mechanism must be capable of protecting the integrity of SIP > message bodies (to ensure that media offers and answers are linked > to the signaling identity). I don't think this is a requirement in and of itself; I believe it is a derived requirement from the previous replay-prevention requirement. That is, integrity of the body is ESSENTIAL for replay protection. It is not present as a feature of the identity mechanism just because we threw it in as a requirement. > It must be possible, in cases where a request has been retargeted > to a different AoR than the one designated in the To header field, > for the UAC to ascertain the AoR to which the request has been > sent. I think you mean UAS. > The authentication service authenticates Alice (possibly by sending a > Digest authentication challenge) and validates that she is authorized > to populate the value of the From header field (which may be Alice's > AoR, or it may be some other value that the policy of the proxy of course alice is authorized to populate the value of the header field; it has to be done by a UAC. I think you mean, "... and validates that she is authorized to assert the identity that has been placed into the From header field. This value may be Alice's AOR, or it may be....." > When Bob's domain receives the request, it verifies the signature > provided in the Identity header, and thus can authenticate that the > domain indicated by the host portion of the AoR in the From header > field authenticated the user, and permitted them to assert that From > header field value. I think "authenticate" is the wrong verb in the beginning of this sentence. I think "verify" is more correct. Also, this verification can also be done by the UAS, you should mention that. > instantiated by a proxy server or a user agent. Any entity that > instantiates the authentication service role MUST possess the private > key of a domain certificate, and MUST be capable of authenticating > one or more SIP users that can register in that domain. Commonly, Hmm, doesnt this definition rule out a user with a certificate for themselvs (I.e., one for which the subjectAltName is "sip:jdrosen@example.com") from being an authentication service? I thought we were going to still allow this. > Then it computes a signature > over the canonical form of several headers and all the bodies, and > inserts this signature into the message. all the bodies? There is only one body of a SIP message. It may be multipart, and thus there are many body parts. > The authentication service authenticates the identity of the message > sender and validates that the identity given in the message can > legitimately be asserted by the sender. Then it computes a signature > over the canonical form of several headers and all the bodies, and > inserts this signature into the message. I dont like this paragraph, actually, because its sort of an informative overwiew paragraph, and the actual steps are in fact spelled out in detail in the sections that follow. You need to be very precise about the sequencing of steps and what happens at each step. I suggest breaking this seciton into sub-sections or numbered steps for each activity, much like the way proxy behavior is specified in rfc3261. > o If the authentication service is instantiated by a SIP > intermediary (proxy server), it may challenge the request with a > 407 response code using the Digest authentication scheme (or > viewing a Proxy-Authentication header sent in the request which > was sent in anticipation of a challenge using cached credentials, > as described in RFC 3261 Section 22.3). > o If the authentication service is instantiated by a SIP user agent, > a user agent can be said to authenticate its user on the grounds > that the user can provision the user agent with the private key of > the domain, or by preferably by providing a password that unlocks > said private key. please add: * If the authentication service is instantiated by a SIP intermediary (proxy server), and that proxy server is maintaining a TLS connection with the client, over which the proxy had previously authenticated itself using digest authentication, the identity value obtained from that previous authentication step can be reused without an additional digest challenge. > Authorization of the use of a particular username in the From header > field is a matter of local policy for the authorization service, one what is an authorization service? I think you mean authentication service. > n this latter case, a domain might > maintain a mapping between the values in the 'username' parameter of > Proxy-Authorization and a set of one or more SIP URIs which might > legitimately be asserted for that 'username'. you are sort of dancing around this, but I think its OK to explicitly say that, for example, the username can correspond to the private identity as defined in 3gpp, in which case the From field can contain any of the public identities associated with that private identity. > exceptions to such policies might arise for cases like anonymity; if > the AoR asserted in the From header field is anonymous (per RFC3323 > [3]), then the proxy should authenticate that the user is a valid > user in the domain and insert the signature over the From header > field as usual. That isn't going to work. RFC3323 recommends the usage of anonymous.invalid as the domain in the From field. Doing so is incompatible with this specification. I think there are many remedies to that, and the full treatment of privacy with usage of sip-identity is probably outside of the scope of this draft (indeed, I believe a revision of rfc3323 is probably in order). However, you should at least point out that any anonmyziation mechanism that works with sip-identity requires the domain in the From field to be a domain over which the authentication service is responsible. > As such, authentication services MAY check the display-name as well, > and compare it to a list of acceptable display-names that may be used > by the sender; You need to say a little more here, I think, given the IDN nightmare that could arise here. In particular, I think you need to say that such policies will really only work in conjunction with systems in which valid display name values are provided to users ahead of time, such that the authentication service can validate the display name using basic case sensitive string comparisons, and do not require any kind of canonicalization of the display name. This means that a user can't just "type in" their display name. I think you may need to at least mention the amazingly hard question of how a domain can figure out that sip:alice@example.com is actually "Alice Smith". > if the display-name does not meet policy constraints, > the authentication service MUST return a 403 'Inappropriate > Display-Name' response code. Hmm. Not sure this is the right response code. This is a situation in which the UA may be able to automatically retry the request (for example, omitting a display name). 403 is appropriate when their is no remedy that can easily be taken. I fear a new response code is needed. > Third, the authentication service MUST form the identity signature > and add an Identity header to the request containing this signature. you need to say how this is done here, else point to the section that defines how the signature is computed. > Retargeting, the alteration by intermediaries of the Request-URI of a > SIP request, can cause a few wrinkles for the Identity mechanism when > it is applied to requests sent in the backwards direction within a > dialog. this definition isn't right. You don't ever get retargeting for mid-dialog requests since the r-uri corresponds to the remote target of the dialog, and is unchagned the whole way through. I think what you mean is: "Retargeting is defined as the alteration of the Request-URI by intermediaries to point to another URI that corresponds to a user that cannot authenticate itself with the identity present in the request URI. By this definition, retargeting excludes translation of the request URI to a registered contact of an endpoint that has authenticated itself as that user. When a dialog-forming request is retargeted, it introduces a few wrinkles for requests sent in the reverse direction of that dialog." > When a request is retargeted, it may reach a SIP endpoint whose user > is not identified by the URI designated in the To header field value. > The value in the To header field of a dialog-forming request is used > as the From header field of requests sent in the backwards direction > > > > Peterson & Jennings Expires August 17, 2005 [Page 9] > > Internet-Draft SIP Identity February 2005 > > > during the dialog, and is accordingly the header that would be signed > by an authentication service for requests sent in the backwards > direction. actually, there are many nasty cases where the To field will contain an identity that doesnt correspond to a valid identity of the recipient. Consider, for example, cases where users dial a phone number, and the To header field contains the dial sequence as a SIP URI in the domain of the originator. Or its an alias of some sort. Or a tel URI. You should mention these cases. > The mechanism in this draft cannot aid in determining whether or not > the unanticipated party is an appropriate target of this request and, > accordingly, solving this problem is outside the scope of this draft. > If, however, it were possible for the sender of the dialog-forming > request to anticipate that retargeting had occurred, and to gain some > kind of assurance of the new target of the request before any > requests in the backwards direction were received, this would open up > some new approaches to authorization policy. this paragraph seems repetitive with the previous paragraph. > Ultimately, the > authentication service provides an Identity header for requests in > the backwards dialog when the user is authorized to assert the > identity given in the From header field, and if they are not, an > Identity header is not provided. well, thats interesting. It means that the draft DOES provide a connected identity service - but only if the connected identity corresponds to the user you called in some cases. > If an Identity header is not > present in a request, and one is required by local policy (for > example, based on a global policy, a per-sending-domain policy, or a > per-sending-user policy), then a 428 'Use Identity Header' response > MUST be sent. There is of course a gaping hole here, which is how a receiving domain is supposed to know that a domain is using this draft, and thus should expect the Identity header field in requests from that domain. One answer is if it is known due to trusted peer relationships. Of course, in such a case, you probably don't need sip-identity and P-A-ID would do. I'd love to see a draft developed that allows for a domain to be able to determine whether the originating domain is using this mechanism. Some kind of dialback approach or a DNS solution could work. I think its arguably out of scope for this draft, but this draft needs to acknowledge this issue and perhaps state that such a mechanism is outside the scope of this document. I'd also say that a global policy on this is probably incredibly unrealistic. Given it doesnt exist today, how could you phase in this mechanism with such a policy? If its an appropriate policy only once this has been ubiquitously deployed, that should be stated. > If the URI scheme in the Identity-Info > header cannot be dereferenced, then a 436 'Bad Identity-Info' > response MUST be returned. I think you need to specify a baseline mandatory-to-implement scheme here. Suggest http. > Subsequently, the recipient MUST verify the signature in the Identity > header, and compare the identity of the signer (the subjectAltName of > the certificate) with the domain portion of the URI in the From > header field of the request as described in Section 14. again, this rules out per-user certificates. > If a verifier determines that the signature on the message does not > correspond to the text of the message, then a 428 'Invalid Identity what do you mean by "text of the message"? I would normally think this means the content in a text/plain body, such as one used in MESSAGE. But i dont think thats what you mean. > This mechanism can be applied opportunistically to existing SIP > deployments; accordingly, it requires no change to SIP user agent > behavior in order for it to be effective. However, because this > mechanism does not provide integrity protection between the UAC and > the authentication service, a UAC SHOULD implement some means of > providing this integrity. there are lots of security features needed in sip not provided by this spec. Why is integrity between UAC and auth service important? I think its to protect the From from modification by attackers? Need to point that out if thats what you mean. > When a UAC sends a request, it MUST accurately populate the header > field that asserts its identity (for a SIP request, this is the From > header field). this text seems like it alludes to the fact that there might be other ways for conveying its identity. I dont think so. So you should be more crisp here - "When a UAC sends a request, it MUST accurately populate the From header field with a value corresponding to an identity that it believes it is authorized to claim. This value MAY include a display name, in such a case where the domain administrator has provided the UAC with display names it considers valid." > In a request it MUST set the URI portion of its From > header to match a SIP, SIPS or TEL URI AoR under which the UAC can > register (including anonymous URIs, as described in RFC 3323 [3]). except that RFC 3261 requires the To header field of a REGISTEr to be only a sip or sip URI, not a tel URI. > The UAC MUST also be capable of sending requests, including mid-call > requests, through an 'outbound' proxy (the authentication service). > The best way to accomplish this is using pre-loaded Route headers and > loose routing. UAC implementations MUST provide a way of > provisioning pre-loaded Route headers in order for this mechanism to > work for mid-call requests in the backwards direction of a dialog. Hmm. Normally, pre-loaded route headers (including ones learned through Service Route) do not apply to mid-dialog requests. The route set learned from the dialog is used instead of any such route set (though I think this may not be spelled out clearly anywhere). I'm not sure this requirement is needed anyway, since text above says that we aren't really providing identity for mid-dialog requests in the reverse direction anyway. I would remove it, and merely mention that a consequence is that if an authentication service is not on the path of the original request, identity for mid-dialog requests in the reverse direction won't be provided. > Identity-Info header contains a URI from which its certificate can be > acquired. Details are provided in section Section 10. double section > Even if a proxy server does not > act as an authentication service, it MAY verify the existence of an > Identity before it makes a forwarding decision for a request. verifying existence is not interesting. Its validating the identity. > For the purposes of identifying mid-dialog requests, proxy servers > that instantiate the authentication service role MUST Record-Route > themselves in dialog-forming requests. per above, I don't think this is needed. > This document specifies two new SIP headers: Identity and > Identity-Info. Each of these headers can appear only once in a SIP > message. > > Identity = "Identity" HCOLON signed-identity-digest > signed-identity-digest = LDQUOT 32LHEX RDQUOT > > Identity-Info = "Identity-Info" HCOLON ident-info > ident-info = LAQUOT absoluteURI RAQUOT this is pedantic - but the first paragraph should state that the two which follow define the grammar for these new header fields. I'll note that you have not allowed for extensibility in either header field. I think that is a mistake. You should use standard extension header syntax and allow header field parameters for both. > o The AoR of the UA sending the message, or the 'identity field'. > For a request, this is the addr-spec from the From header field. you should point out that this includes any header field parameters. > The Date header field, with exactly one space each for each SP and > the weekday and month items case set as shown in BNF in 3261. The careful here! The case as described in the BNF is case insensitive, since the BNF rules specify that quoted strings imply case insensitive. I think you mean to say, "RFC 3261 specifies that the BNF for weekday and month are a choice amongst a set of tokens. The RFC 2234 rules for the BNF specify that tokens are case sensitive. However, when used to construct the canonical string defined here, the first letter of each week and month MUST be capitalized, and the remaining two letter must be lowercase. This matches the capitalization provided in the definition of each token." You need to be this pedantic in order to get this to interoperate... > headers from the message-body, but does include everything that > follows that CRLF. If the message has no body, then message-body > will be empty, and the final colon will not be followed by any > additional characters. I suggest you explicitly talk about multipart and what it means for this. > signing this string with sha1WithRSAEncryption as described in RFC > 3370 and base64 encode the results as specified in RFC 3548. Put the > result in the Identity header. you need normative refs for these two. Hmm. 3548 is informational.... > The Identity-Info header MUST contain either an HTTPS URI or a SIPS > URI. why secure? Why does it matter? > If it is a SIPS URI, then the > authentication service intends for a user agent that wishes to fetch > the certificate to form a TLS connection to that URI, acquire the > certificate during normal TLS negotiation, and close the connection. blech! That is a definite misuse of the sips URI scheme. > The > REGISTER method uses Contact header fields in very unusual ways that > complicate its applicability to this mechanism. Accordingly, the > Identity and Identity-Info header MUST NOT appear in REGISTER or > CANCEL. I agree with CANCEL, but not REGISTER. Usage of this with register is essential for 3gpp-like architectures where there is a separation between the proxy instantiating the authentication servce (a p-cscf or similar edge proxy) and the registrar (s-cscf or home proxy). We've recognized these kinds of architectures in many places. In that case, we need a way to convey the authenticated identity to the registrar from the edge proxy. This mechanism seems fine for that, in that the registrar is just a UAS that just happens to lie in the same domain as the requestor. I don't understand why this cannot work for REGISTER. > The examples in this section illustrate the use of the Identity > header in the context of a SIP transaction. Implementations MUST > verify their compliance with these examples, i.e.: this is a bizarre normative requirement; normally we specify behaviors of software/hardware against behaviors, not behaviors of people against our specs. If so, we could do things like, "All implementors MUST read this specification, and MUST mail a check for US $100 to Mr. Jon Peterson...." ;) > 11. Compliance Tests and Examples these example messages don't contain some of the things we are recommending people to use, like Accept, Allow, and the various capability declaration headers. Also it would be great if there were ladder diagrams for these flows. > described in this document. Telephone numbers commonly appear in the > username portion of a SIP URI (e.g., > 'sip:+17005551008@chicago.example.com'). this is missing the ;user=phone > That username conforms to > the syntax of the TEL URI scheme (RFC2806bis [9]). now published as rfc 3966. > Implementations that intend to send their requests > through an authentication service MUST put telephone numbers in the > From header field into SIP or SIPS URIs, if possible. "if possible" makes this a SHOULD. > Verifiers SHOULD NOT accept > > > > Peterson & Jennings Expires August 17, 2005 [Page 21] > > Internet-Draft SIP Identity February 2005 > > > signatures over From header TEL URIs in the absence of some > pre-provisioned relationship with the signing domain that authorizes > this usage of TEL URIs. wow. I don't like this at all. It seems to invalidate many of the assumptions on which this specification is built. I would rather not provide identity for these use cases. > 13. Privacy Considerations > > The identity mechanism presented in this draft is compatible with the > standard SIP practices for privacy described in RFC3323 [3]. not really; per above 3323 says to use anonymous.invalid. > Note, however, that an authentication service must possess a > certificate corresponding to the host portion of the addr-spec of the > From header field of any request that it signs; accordingly, using > domains like 'invalid.net' may not be possible for privacy services > that also act as authentication services. may not be possible? Won't be possible. > 13. Privacy Considerations what I think is missing from the discussion here, as it relates to rfc3323, is that this specification does not actually introduce ANY information into the sip message that has privacy implications, beyond what is already in the message. It adds a signature and a URL for fetching a cert; the domain presumably matches the one in the From field, so no additional identifying information is provided. > This document describes a mechanism which provides a signature over > the Contact, Date, Call-ID, CSeq, To, and From header fields of SIP > messages. actually, just requests. The spec sometimes uses "messages" and sometimes "requests". It should consistently use requests. > request targets. Providing the To header field in the Identity > signature servers two purposes: first, serves > Implementations MUST also record Call-IDs received in > valid requests containing an Identity header, and MUST remember those > Call-IDs for at least the duration of a single Date interval (i.e. > commonly 3600 seconds). while reasonable, this also belongs up above in a section on UA behavior, as it is likely to be lost in the security considerations section. Generally, I like these sections to summarize stuff that has already been stated previously in specification. > Accordingly, if an Identity header is > replayed within the Date interval, receivers will recognize that it > is invalid because of a Call-ID duplication; you need to have a normative statement somewhere above that says that a verifier should check the date and the callid, and specify exactly what to check. Also, is the requirement for validation one for a UA or any verifier? That is, should a proxy be doing the call-id checks? That could be a lot of data. > The Contact header field is included to tie the Identity header to a > particular device instance that generated the request. s/device/user agent > However, a > signature over the topmost Via header does not prevent attacks of > this nature, since the attacker could leave the topmost Via intact > and merely insert a new Via header field directly after it, which > would cause responses to be routed to the attacker's host "on their > way" to the valid host, which has exactly the same end result. not quite; remember that normal sip routing rules cause the response to go to the source IP of the request AND the port present in the Via header field. This is unless rport is in use, in which case the response goes back to the source port too. The implication is that it is not possible to redirect responses unless the Via is modified, unless the originator supported rport. It still doesn't make sense to include Via, for other reasons you describe. > sending user agent and the authentication service, it could not > prevent an attacker from adding a Via hop after the authentication > > service, and accordingly pre-empting responses. It is necessary for > the proper operation of SIP for subsequent intermediaries to be extra line inserted > While there are conceivably attacks that an > adversary could mount against SIP systems that rely too heavily on > the display-name in their user interface, this argues for intelligent > interface design, not changes to the protocol. I am concerned that in a universe of aol style identifiers like jdr88@aol.com, the display name plays a larger role in identification than you might think. Certainly it is extensively used in the pstn. I think we should consider further whether or not the signature should include the display name. > However, it is likely that applications building on > the Identity header could leverage this integrity protection, > especially body integrity, to provide further security services. I don't know what this means exactly. > Therefore, it is RECOMMENDED that UASs receiving signed requests > notify end users if there is ANY discrepancy between the > subjectAltName of the signer's certificate and the host portion of > the identity within the From header field. If the domain name in the > subject of the certificate is subordinate t what happens if the verifier is a proxy? No notification is possible. Also, to be frank, I think that normative statements around UI behaviors are a mistake. The average user will NOT know what to do in these cases. IETF folks are profoundly unqualified to figure out what is the right UI interaction. > If the domain name in the > subject of the certificate is subordinate to the domain name in the > identity URI, then verifiers may consider this a minor discrepancy. this is a relatively weak statement. What is the normative guidance here on subordination? I think it needs to be clearly addressed, and it should be addressed in the section on verifiers. > provided by a certificate authority operated by the federation. It > is STRONGLY RECOMMENDED that self-signed domain certificates should while I agree with the sentiment, usage of capitalized STRONGLY is not defined in RFC 2119. > Header Name: Identity > Compact Form: y > Header Name: Identity-Info > Compact Form: (none) according to sip-guidelines, compact forms should be requested for both, since both are mandatory (or are we out of letters?) > It is used when a verifier received a SIP request that > lacks an Identity header as a response indicating that the request > should be re-sent with an Identity header. this sentence is awkward -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 6 15:01:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16862 for ; Sun, 6 Mar 2005 15:01:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D81ys-0003rZ-1P for sip-web-archive@ietf.org; Sun, 06 Mar 2005 15:04:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D81uo-0004ge-8L; Sun, 06 Mar 2005 14:59:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D81um-0004gZ-Pq for sip@megatron.ietf.org; Sun, 06 Mar 2005 14:59:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16601 for ; Sun, 6 Mar 2005 14:59:46 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D81wp-0003oA-DA for sip@ietf.org; Sun, 06 Mar 2005 15:01:55 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 06 Mar 2005 11:59:41 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j26JxaYO017818; Sun, 6 Mar 2005 11:59:37 -0800 (PST) Received: from [130.129.135.77] (che-vpn-cluster-2-4.cisco.com [10.86.242.4]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AIH68089; Sun, 6 Mar 2005 11:59:35 -0800 (PST) Message-ID: <422B6126.4000401@cisco.com> Date: Sun, 06 Mar 2005 14:59:34 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] Draft defining the Accept-Disposition header field References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , Paul H Kyzivat , "gonzalo.camarillo@ericsson.com" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit inline. Cullen Jennings wrote: > >>The solution proposed in the draft follows the definition of the >>existing Allow and Accept header fields in the sense that they do not >>provide cross header information: Allow tells you which methods are >>supported and Accept which MIME types, but there is no info about which >>MIME type is acceptable for which method. We need to decide if this is >>good enough or if we want to introduce some level of cross header >>information in the solution. > > > I think we should consider if we need this at all or if we are trying to do > something with disposition that just should not be done in the MIME level > but should be done in the SIP level I agree with Cullen on this assessment. I don't understand the specific use case that is being addressed here. I understand the problem in theory, but in practice, I suspect that a particular extension (which would have assocaited types and dispositions) will be supported in its entirety or not at all. As a result, the Supported header field would suffice. A new MIME header is needed only when it seems like there is some new disposition defined that is sensible to be used outside of support for a particular extension and its associated types. I don't know of such a case. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 6 21:50:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26752 for ; Sun, 6 Mar 2005 21:50:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D88Me-0005Ou-QS for sip-web-archive@ietf.org; Sun, 06 Mar 2005 21:53:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D88FM-0004IM-2K; Sun, 06 Mar 2005 21:45:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D88FK-0004IH-C3 for sip@megatron.ietf.org; Sun, 06 Mar 2005 21:45:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26166 for ; Sun, 6 Mar 2005 21:45:23 -0500 (EST) Received: from imr2.ericy.com ([198.24.6.3]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D88HQ-0005FQ-El for sip@ietf.org; Sun, 06 Mar 2005 21:47:36 -0500 Received: from eamrcnt751.exu.ericsson.se (eamrcnt751.exu.ericsson.se [138.85.133.52]) by imr2.ericy.com (8.12.10/8.12.10) with ESMTP id j272jDbj009915; Sun, 6 Mar 2005 20:45:13 -0600 (CST) Received: from [138.85.176.199] (rmt176199.am.ericsson.se [138.85.176.199]) by eamrcnt751.exu.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id GFFNKTVR; Sun, 6 Mar 2005 20:45:12 -0600 Message-ID: <422BC034.9030305@ericsson.com> Date: Mon, 07 Mar 2005 04:45:08 +0200 X-Sybari-Trust: 7ec888e6 b8ec86c7 c4dfc578 00000139 From: Gonzalo Camarillo User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] Draft defining the Accept-Disposition header field References: <422B6126.4000401@cisco.com> In-Reply-To: <422B6126.4000401@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , sip@ietf.org, Paul H Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit Hi, I am thinking of URI-list services that support the "recipient-list" disposition type. Servers need a way to signal support for this disposition type and report errors when they do not understand it. We have several options to do that. One is to do it at the SIP level, defining option tags that would imply support for this disposition type for different methods. Something like an invite-uri-list-service option tag, a message-uri-list-service option tag, etc... Another alternative would be to use a similar mechanism as the one defined in the draft. I would like to explore this possibility... we may decide that it is not the way to go, but disposition types are currently under-defined in SIP, and it is good to spend some time thinking about their implications... In any event, my main concern is to resolve the URI-list problem, one way or another. Thanks, Gonzalo Jonathan Rosenberg wrote: > inline. > > Cullen Jennings wrote: > > > >>>The solution proposed in the draft follows the definition of the >>>existing Allow and Accept header fields in the sense that they do not >>>provide cross header information: Allow tells you which methods are >>>supported and Accept which MIME types, but there is no info about > > which > >>>MIME type is acceptable for which method. We need to decide if this is >>>good enough or if we want to introduce some level of cross header >>>information in the solution. >> >> >>I think we should consider if we need this at all or if we are trying > > to do > >>something with disposition that just should not be done in the MIME > > level > >>but should be done in the SIP level > > > I agree with Cullen on this assessment. I don't understand the specific > use case that is being addressed here. I understand the problem in > theory, but in practice, I suspect that a particular extension (which > would have assocaited types and dispositions) will be supported in its > entirety or not at all. As a result, the Supported header field would > suffice. > > A new MIME header is needed only when it seems like there is some new > disposition defined that is sensible to be used outside of support for a > > particular extension and its associated types. I don't know of such a > case. > > -Jonathan R. > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 6 23:52:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07683 for ; Sun, 6 Mar 2005 23:52:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8AGi-0008AM-KN for sip-web-archive@ietf.org; Sun, 06 Mar 2005 23:55:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8ADz-0007GV-JG; Sun, 06 Mar 2005 23:52:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8ADt-0007Es-JZ for sip@megatron.ietf.org; Sun, 06 Mar 2005 23:52:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07527 for ; Sun, 6 Mar 2005 23:52:02 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8AG0-00087q-Pr for sip@ietf.org; Sun, 06 Mar 2005 23:54:17 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 06 Mar 2005 22:08:41 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,140,1107734400"; d="scan'208"; a="231978340:sNHT20723348" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j274pqZV013540; Sun, 6 Mar 2005 20:51:53 -0800 (PST) Received: from cisco.com (che-vpn-cluster-1-149.cisco.com [10.86.240.149]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APP25282; Sun, 6 Mar 2005 23:51:51 -0500 (EST) Message-ID: <422BDDE7.5040304@cisco.com> Date: Sun, 06 Mar 2005 23:51:51 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] Draft defining the Accept-Disposition header field References: <422B6126.4000401@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , "sip@ietf.org" , "gonzalo.camarillo@ericsson.com" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit I think there are two related problems here: 1) A UAS receives a request. That request is of message type M and contains a body part with content-type T and content-disposition D. The UAS can't do the combination of [M,T,D] but it can handle [M,T,D'] and [M,T',D]. What kind of response should it return? (There are of course lots of permutations of this. There is currently no response that accurately reflects the situation. I'm not sure how detailed it needs to be, but it would be good if the response made sense. Note that the problem already exists with content-type: a UA may report in options that it supports type application/sdp. But what if you send it a MESSAGE with a body of type application/sdp? Does it report back that it no longer supports that type? 2) A UAC wants to know in advance what a UAS is capable of in order to plan out the features it will enable, or the kinds of call flows it will attempt to implement a feature. (Perhaps it is a feature like list exploding, or specifying how to alert, that can be controlled via body parts with specific dispositions.) It may want to send an OPTIONS and get something back in the response that helps. The larger problem is that content-disposition is underspecified in 3261. Were we to specify it more completely there may be less of a problem to deal with here. Paul Jonathan Rosenberg wrote: > inline. > > Cullen Jennings wrote: > > >> >>> The solution proposed in the draft follows the definition of the >>> existing Allow and Accept header fields in the sense that they do not >>> provide cross header information: Allow tells you which methods are >>> supported and Accept which MIME types, but there is no info about which >>> MIME type is acceptable for which method. We need to decide if this is >>> good enough or if we want to introduce some level of cross header >>> information in the solution. >> >> >> >> I think we should consider if we need this at all or if we are trying >> to do >> something with disposition that just should not be done in the MIME level >> but should be done in the SIP level > > > I agree with Cullen on this assessment. I don't understand the specific > use case that is being addressed here. I understand the problem in > theory, but in practice, I suspect that a particular extension (which > would have assocaited types and dispositions) will be supported in its > entirety or not at all. As a result, the Supported header field would > suffice. > > A new MIME header is needed only when it seems like there is some new > disposition defined that is sensible to be used outside of support for a > particular extension and its associated types. I don't know of such a case. > > -Jonathan R. > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 7 11:49:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07035 for ; Mon, 7 Mar 2005 11:49:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8LSo-0008PH-NP for sip-web-archive@ietf.org; Mon, 07 Mar 2005 11:52:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8LNO-0001M9-Ck; Mon, 07 Mar 2005 11:46:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8LNM-0001Lx-7e for sip@megatron.ietf.org; Mon, 07 Mar 2005 11:46:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06624 for ; Mon, 7 Mar 2005 11:46:33 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8LPY-0008J7-Ua for sip@ietf.org; Mon, 07 Mar 2005 11:48:54 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 07 Mar 2005 09:01:29 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,143,1107763200"; d="scan'208"; a="618053607:sNHT20620592" Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j27GkNuC023680; Mon, 7 Mar 2005 08:46:23 -0800 (PST) Received: from [130.129.135.77] (che-vpn-cluster-2-52.cisco.com [10.86.242.52]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AIH97522; Mon, 7 Mar 2005 08:46:22 -0800 (PST) Message-ID: <422C855E.9030604@cisco.com> Date: Mon, 07 Mar 2005 11:46:22 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] Comment on refer-with-norefersub-01 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , Orit Levin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Interesting; I have argued that it doesn't belong in Supported either. The reason is that supported just means, "hey, I understand this extension, in case you may want to use it". It does not mean, "I want you to exhibit behavior X, but are not requiring you to do it". Generally, I think the decision about whether or not the subscription is created is to be chosen by the entity sending the REFER; that is the point of this spec. If that is the case, it is not appropriate to put the option tag into Supported. The closest thing to "I want you to exihibit behavior X, but are not requiring you to do it", is to define a header field that describes the behavior: CreateSub: yes and then have no Require header for this if it can be safely ignored, which as Cullen is arguing is better for wireless. -Jonathan R. Cullen Jennings wrote: > It seems like in any case where you put a Require with the option tag, it > results in far more traffic and less chance of interoperability than > creating the subscription and instantly ending it. > > I think you should say that the tag is not allowed in a Require. > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 7 13:52:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21137 for ; Mon, 7 Mar 2005 13:52:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8NNe-0003RN-B4 for sip-web-archive@ietf.org; Mon, 07 Mar 2005 13:55:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8NKq-000118-IM; Mon, 07 Mar 2005 13:52:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8NKp-00010m-00 for sip@megatron.ietf.org; Mon, 07 Mar 2005 13:52:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21081 for ; Mon, 7 Mar 2005 13:52:05 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8NN2-0003PW-GG for sip@ietf.org; Mon, 07 Mar 2005 13:54:26 -0500 Received: from [130.129.133.64] (wireless-130-129-133-64.ietf62.ietf.org [130.129.133.64]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j27Iodik017118 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 7 Mar 2005 12:50:48 -0600 (CST) (envelope-from rjsparks@nostrum.com) In-Reply-To: <422C855E.9030604@cisco.com> References: <422C855E.9030604@cisco.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <674d742cb82fb0e4f6a3d6602dce9814@nostrum.com> Content-Transfer-Encoding: 7bit From: Robert Sparks Subject: Re: [Sip] Comment on refer-with-norefersub-01 Date: Mon, 7 Mar 2005 12:50:39 -0600 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , "sip@ietf.org" , Orit Levin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit The original proposal was indeed to _REQUIRE_ that no subscription be created. This is what we built this extensibility mechanism for - the extra round trip it comes with _IF_ you are willing to accept the REFER with a subscription is the cost of the extensibility mechanism we defined (Cullen's objection is based on the assumption that you always will). RjS On Mar 7, 2005, at 10:46 AM, Jonathan Rosenberg wrote: > Interesting; I have argued that it doesn't belong in Supported either. > The reason is that supported just means, "hey, I understand this > extension, in case you may want to use it". It does not mean, "I want > you to exhibit behavior X, but are not requiring you to do it". > Generally, I think the decision about whether or not the subscription > is created is to be chosen by the entity sending the REFER; that is > the point of this spec. If that is the case, it is not appropriate to > put the option tag into Supported. > > The closest thing to "I want you to exihibit behavior X, but are not > requiring you to do it", is to define a header field that describes > the behavior: > > CreateSub: yes > > and then have no Require header for this if it can be safely ignored, > which as Cullen is arguing is better for wireless. > > -Jonathan R. > > Cullen Jennings wrote: > >> It seems like in any case where you put a Require with the option >> tag, it >> results in far more traffic and less chance of interoperability than >> creating the subscription and instantly ending it. >> I think you should say that the tag is not allowed in a Require. >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 7 17:27:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11363 for ; Mon, 7 Mar 2005 17:27:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8Qjn-0008W2-2D for sip-web-archive@ietf.org; Mon, 07 Mar 2005 17:30:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8Qdy-0006AJ-Dg; Mon, 07 Mar 2005 17:24:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8Qdv-0006AB-SA for sip@megatron.ietf.org; Mon, 07 Mar 2005 17:24:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11129 for ; Mon, 7 Mar 2005 17:24:01 -0500 (EST) Received: from omzesmtp02.mci.com ([199.249.17.9]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8QgB-0008QD-8h for sip@ietf.org; Mon, 07 Mar 2005 17:26:24 -0500 Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0ID000DLL67OGS@firewall.mci.com> for sip@ietf.org; Mon, 07 Mar 2005 22:23:49 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0ID00080167DK0@dgismtp03.mcilink.com>; Mon, 07 Mar 2005 22:23:48 +0000 (GMT) Received: from usashfe001.mcilink.com ([153.39.73.77]) by dgismtp03.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0ID00086N67GDP@dgismtp03.mcilink.com>; Mon, 07 Mar 2005 22:23:40 +0000 (GMT) Received: from usashms001.mcilink.com ([153.39.82.129]) by usashfe001.mcilink.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 07 Mar 2005 22:23:40 +0000 Date: Mon, 07 Mar 2005 22:23:40 +0000 From: "Johnston, Alan" Subject: RE: [Sip] Comment on refer-with-norefersub-01 To: Cullen Jennings , Tom Hiller Message-id: <40AF35183B110B4899DD3221904B6B580111E66A@usashms001.mcilink.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Content-class: urn:content-classes:message Thread-topic: [Sip] Comment on refer-with-norefersub-01 Thread-index: AcUhPWM09vph8kciRMy/OXbTC1SGkgCDbvcg X-OriginalArrivalTime: 07 Mar 2005 22:23:40.0308 (UTC) FILETIME=[506EFD40:01C52364] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: quoted-printable Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3 Content-Transfer-Encoding: quoted-printable In most cases (at least for common ones such as transfer and remote call control), the UA issuing the REFER has had some kind of SIP message exchange with the REFER recipient. As a result, the UA will know based on a previously received Supported header whether the recipient supports the extension before it sends the REFER with Require. True, this doesn't cover all cases, but these cases seem like the most common ones that would want to use this feature. In other words, the main reason for suppressing the subscription is that the UA has another method of finding out the result of the REFER, and the number of messages is trying to be minimized. Thanks, Alan Johnston sip:alan@sipstation.com > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On=20 > Behalf Of Cullen Jennings > Sent: Friday, March 04, 2005 10:38 PM > To: Tom Hiller > Cc: sip@ietf.org > Subject: Re: [Sip] Comment on refer-with-norefersub-01 >=20 >=20 >=20 > I think your are misunderstanding. I don't think it means this at all >=20 > It means the UAC sends it with the tag but no require. If UAS=20 > supports it, great. If the UAS does not support it then the=20 > refer still works and a NOTIFY is sent which the UAC promptly ends. >=20 > Now consider what would have happened if we did have the require. >=20 > UAC would send the refer, it would fail. The the UAC would=20 > send refer without the tag. Then the UAS would send Notify,=20 > then the UAC would cancel the subscription.=20 >=20 > It seems the first is case better for wireless - what am I=20 > missing here. >=20 >=20 >=20 > On 3/3/05 1:19 AM, "Tom Hiller" wrote: >=20 > > Cullen, > >=20 > >=20 > > Does this mean the mobile has to receive an immediate=20 > notification due=20 > > the REFER, then send a SUBSCRIBE to kill the implicit subscription,=20 > > and then get yet another notification? > >=20 > > In practice, people draw message flows, count SIP requests and=20 > > responses and other messages on a per "call" basis, and=20 > then tally a=20 > > total. In wireless it is sometimes important to minimize=20 > the number of=20 > > messages per "call". "norefersub" reduces the number of=20 > messages when=20 > > one doesn't need the implicit subscription because the user=20 > learns the=20 > > notification information via existing subscriptions or via=20 > other ways. > >=20 > > Also, some wireless spectrum is costly, and in some cases=20 > there is a=20 > > potential for lengthy SIP notification packets to interfere=20 > with RTP=20 > > packet flow due to lack of over-the-air connection=20 > bandwidth. There is=20 > > also a possible service impact of not being able transmit another=20 > > message while sending a SUBSCRIBE to instantly end a subscription. > >=20 > > OMA has extensively incorporated "norefersub" into draft baselines=20 > > (i.e., includes the option tag "norefersub" in the Require header).=20 > > These draft baselines are now being readied for publication. OMA=20 > > requires the "norefersub" option tag in the Require header. > >=20 > > If I am misunderstanding the point of your comment, could=20 > you expand=20 > > further? > >=20 > >=20 > > - Tom > >=20 > > Cullen Jennings wrote: > >=20 > >> It seems like in any case where you put a Require with the option=20 > >> tag, it results in far more traffic and less chance of=20 > >> interoperability than creating the subscription and=20 > instantly ending=20 > >> it. > >>=20 > >> I think you should say that the tag is not allowed in a Require. > >>=20 > >>=20 > >>=20 > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol Use=20 > >> sip-implementors@cs.columbia.edu for questions on current sip Use=20 > >> sipping@ietf.org for new developments on the application of sip > >=20 > >=20 > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on=20 > current sip Use=20 > > sipping@ietf.org for new developments on the application of sip >=20 >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current=20 > sip Use sipping@ietf.org for new developments on the=20 > application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 7 20:44:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05624 for ; Mon, 7 Mar 2005 20:44:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8ToU-0006E5-2i for sip-web-archive@ietf.org; Mon, 07 Mar 2005 20:47:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8Tl5-0005Hl-KM; Mon, 07 Mar 2005 20:43:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8Tl3-0005He-Sb for sip@megatron.ietf.org; Mon, 07 Mar 2005 20:43:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05597 for ; Mon, 7 Mar 2005 20:43:36 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8TnL-0006DH-C5 for sip@ietf.org; Mon, 07 Mar 2005 20:46:00 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 07 Mar 2005 17:58:33 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,145,1107763200"; d="scan'208"; a="618180868:sNHT19006890" Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j281hOZV023437 for ; Mon, 7 Mar 2005 17:43:25 -0800 (PST) Received: from [130.129.134.128] (che-vpn-cluster-2-241.cisco.com [10.86.242.241]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AIJ27109; Mon, 7 Mar 2005 17:43:23 -0800 (PST) Message-ID: <422D033B.2070708@cisco.com> Date: Mon, 07 Mar 2005 20:43:23 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Subject: [Sip] target dialog draft X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Here is a URL for the target dialog draft that I wrote in response to Rohan's email on the app interaction draft. It defines a way for a REFER to define a target dialog with which it is associated: http://www.jdrosen.net/papers/draft-rosenberg-sip-target-dialog-00.txt Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 8 09:53:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00037 for ; Tue, 8 Mar 2005 09:53:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8g7p-0006Mj-8Q for sip-web-archive@ietf.org; Tue, 08 Mar 2005 09:56:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8g39-0007xy-5A; Tue, 08 Mar 2005 09:51:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8g37-0007w7-B4 for sip@megatron.ietf.org; Tue, 08 Mar 2005 09:51:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29758 for ; Tue, 8 Mar 2005 09:51:03 -0500 (EST) Received: from grads.ece.mcmaster.ca ([130.113.10.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8g5T-0006HH-Kb for sip@ietf.org; Tue, 08 Mar 2005 09:53:34 -0500 Received: from [192.168.2.8] ([130.113.184.38]) by grads.ece.mcmaster.ca (8.12.8/8.12.8) with ESMTP id j28EoEF4017230 for ; Tue, 8 Mar 2005 09:50:15 -0500 Message-ID: <422DBBEC.7070807@grads.ece.mcmaster.ca> Date: Tue, 08 Mar 2005 09:51:24 -0500 From: "M.N.A.Smadi" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Subject: [Sip] When does the RTP start X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit hi; in a INVITE/200 OK/ACK sequence, does the standard indicate when does the rtp flaw exactly start at both ends? thanks _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 8 10:00:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01537 for ; Tue, 8 Mar 2005 10:00:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8gEa-0006bM-13 for sip-web-archive@ietf.org; Tue, 08 Mar 2005 10:02:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8gBV-0000qI-I5; Tue, 08 Mar 2005 09:59:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8gBS-0000oY-Rf for sip@megatron.ietf.org; Tue, 08 Mar 2005 09:59:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01475 for ; Tue, 8 Mar 2005 09:59:40 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8gDr-0006aH-4v for sip@ietf.org; Tue, 08 Mar 2005 10:02:12 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 08 Mar 2005 10:15:39 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,147,1107752400"; d="scan'208"; a="39654186:sNHT19543184" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j28ExS1j015249; Tue, 8 Mar 2005 09:59:29 -0500 (EST) Received: from cisco.com (che-vpn-cluster-2-73.cisco.com [10.86.242.73]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APQ24394; Tue, 8 Mar 2005 09:59:27 -0500 (EST) Message-ID: <422DBDD0.4050207@cisco.com> Date: Tue, 08 Mar 2005 09:59:28 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M.N.A.Smadi" Subject: Re: [Sip] When does the RTP start References: <422DBBEC.7070807@grads.ece.mcmaster.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit It doesn't specify when it *does* start. But it does specify when it *could* start: - the offerer should be prepared to receive as soon as it sends the first message containing an offer - the answerer may begin to send as soon as it receives the offer - the answerer should be prepared to receive as soon as it sends the message containing an answer - the offerer may begin to send as soon as it receives an answer These are general rules, and can be modified in some circumstances. For instance: - preconditions can delay things - some media types have different rules. (But that doesn't apply to RTP, unless you consider RTP over TCP.) Paul M.N.A.Smadi wrote: > hi; > > in a INVITE/200 OK/ACK sequence, does the standard indicate when does > the rtp flaw exactly start at both ends? > > > thanks > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 8 14:52:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07772 for ; Tue, 8 Mar 2005 14:52:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8knU-0006FF-IR for sip-web-archive@ietf.org; Tue, 08 Mar 2005 14:55:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8khX-0004Yu-8d; Tue, 08 Mar 2005 14:49:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8khT-0004YD-Mx; Tue, 08 Mar 2005 14:49:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07021; Tue, 8 Mar 2005 14:49:01 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8kjv-00060M-Mt; Tue, 08 Mar 2005 14:51:35 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1D8khS-00020C-Q1; Tue, 08 Mar 2005 14:49:02 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Tue, 08 Mar 2005 14:49:02 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: sip@ietf.org Subject: [Sip] Last Call: 'An Extension to the Session Initiation Protocol for Request History Information' to Proposed Standard X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 The IESG has received a request from the Session Initiation Protocol WG to consider the following document: - 'An Extension to the Session Initiation Protocol for Request History Information ' 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 any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-03-22. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-history-info-06.txt _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 8 18:52:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03047 for ; Tue, 8 Mar 2005 18:52:29 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8oXb-0004L7-F0 for sip-web-archive@ietf.org; Tue, 08 Mar 2005 18:55:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8oRm-0008Uh-DF; Tue, 08 Mar 2005 18:49:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8oRj-0008UN-Rb; Tue, 08 Mar 2005 18:49:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02887; Tue, 8 Mar 2005 18:49:00 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8oUC-0004H3-Gz; Tue, 08 Mar 2005 18:51:37 -0500 Received: from [130.129.132.139] (wireless-130-129-132-139.ietf62.ietf.org [130.129.132.139]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.12.11) with ESMTP id j28Np5qD026611 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 8 Mar 2005 17:51:06 -0600 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <7db20c68a1d29ce3e0b0b845cce558e8@softarmor.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: sipping WG , Simple WG , XCON-IETF , sip@ietf.org From: Dean Willis Date: Tue, 8 Mar 2005 17:49:14 -0600 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Subject: [Sip] Reminder: OMA (Open Mobile Alliance) Ad-Hoc Meeting on 3/9/05 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Just a reminder, and please pardon the wide distribution. But I've gotten enough requests for a repeat to arguably justify it . . . There is an ad-hoc meeting at IETF 62 to discuss issues and common interests with the Open Mobile Alliance, or OMA. OMA is currently building mobile systems specifications for things like push-to-talk and mobile presence using the output of our works, as well as others. We''ll discuss a little of how OMA is using our protocols and discuss some drafts that The meeting will be in the Rochester room on the 3rd floor of the Minneapolis Hilton from 1730-1930 on Wednesday March 9, 2005. The room supposedly seats 70. The preliminary counts showed about 40 people might attend. Cisco (an OMA board member) has ordered box meals for 45 people (with a few vegetarian). If you show up late, you'll probably want to bring your own snack. Thanks, -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 9 06:53:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21288 for ; Wed, 9 Mar 2005 06:53:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8zmz-00051h-Ii for sip-web-archive@ietf.org; Wed, 09 Mar 2005 06:55:46 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8zik-0006Gr-Fk; Wed, 09 Mar 2005 06:51:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8zii-0006Gm-4a for sip@megatron.ietf.org; Wed, 09 Mar 2005 06:51:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21146 for ; Wed, 9 Mar 2005 06:51:17 -0500 (EST) From: innovation.interops@wipro.com Received: from wip-ec-wd.wipro.com ([203.101.113.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8zlH-0004yR-B8 for sip@ietf.org; Wed, 09 Mar 2005 06:54:00 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 671DA2052D for ; Wed, 9 Mar 2005 17:14:15 +0530 (IST) Received: from blr-ec-bh1.wipro.com (unknown [10.200.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 480A120522 for ; Wed, 9 Mar 2005 17:14:15 +0530 (IST) Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Mar 2005 17:21:08 +0530 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 9 Mar 2005 17:21:02 +0530 Message-ID: <0966EC230D8BDA4EB06F57075C4DBF8FFDEFB4@blr-k1-msg.wipro.com> Thread-Topic: RFC 3265 REFRESHING SUBSCRIPTIONS - Example Thread-Index: AcUknkTHnSuHZXIWRJCENWgXuO4TmQ== To: X-OriginalArrivalTime: 09 Mar 2005 11:51:08.0158 (UTC) FILETIME=[4803F9E0:01C5249E] X-Spam-Score: 0.4 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [Sip] RFC 3265 REFRESHING SUBSCRIPTIONS - Example X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0732943832==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 This is a multi-part message in MIME format. --===============0732943832== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5249E.44CA001D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5249E.44CA001D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all, =20 Can any one give an example for this scenario on refreshing = Subscriptions? =20 While receiving Subscription refresh reuquest.The notifier updates the = expiration time for the subscription. As with the initial subscription, = the server MAY shorten the amount of time until expiration, but MUST NOT = increase it.=20 =20 Regds and Thanks ------_=_NextPart_001_01C5249E.44CA001D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello all,
=0A=
 
=0A=
Can any one give an example for this = scenario on =0A= refreshing Subscriptions?
=0A=
 
=0A=
=0A=

While receiving Subscription refresh reuquest.The notifier = updates the =0A= expiration time for the =0A= subscription.  As with the = initial =0A= subscription, the server MAY =0A= shorten the amount of time until expiration, but MUST = NOT increase it.

=0A=

 

=0A=

Regds =0A= and Thanks

------_=_NextPart_001_01C5249E.44CA001D-- --===============0732943832== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0732943832==-- From sip-bounces@ietf.org Wed Mar 9 07:10:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23971 for ; Wed, 9 Mar 2005 07:10:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D904E-0005U7-27 for sip-web-archive@ietf.org; Wed, 09 Mar 2005 07:13:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D900G-00080c-Kd; Wed, 09 Mar 2005 07:09:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D900E-00080X-Vm for sip@megatron.ietf.org; Wed, 09 Mar 2005 07:09:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23811 for ; Wed, 9 Mar 2005 07:09:23 -0500 (EST) Received: from ixe-nat1.juniper.net ([193.110.54.36] helo=up-smtp.jnpr.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D902o-0005Rx-Ki for sip@ietf.org; Wed, 09 Mar 2005 07:12:08 -0500 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Mar 2005 12:09:12 +0000 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 9 Mar 2005 07:09:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] When does the RTP start Date: Wed, 9 Mar 2005 07:09:09 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C28D380C9@proton.jnpr.net> Thread-Topic: [Sip] When does the RTP start Thread-Index: AcUj75SaZHeyHvpER2eQAJIIMNWyqQAsF1gg From: "Reinaldo Penno" To: "Paul Kyzivat" , "M.N.A.Smadi" X-OriginalArrivalTime: 09 Mar 2005 12:09:10.0701 (UTC) FILETIME=[CD42EDD0:01C524A0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: quoted-printable Interesting, just yesterday I was dealing with a similar situation. Would this be true for re-INVITES (and maybe UPDATES) as well? I mean, should a client (a.k.a INVITEE) be prepared to receive in a different port, etc as soon as the re-INVITE is issued? This means that for a period of time the client would be listening on all ports associated with both SDP specifications...? Regards, Reinaldo=20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Tuesday, March 08, 2005 9:59 AM To: M.N.A.Smadi Cc: IETF SIP List Subject: Re: [Sip] When does the RTP start It doesn't specify when it *does* start. But it does specify when it=20 *could* start: - the offerer should be prepared to receive as soon as it sends the first message containing an offer - the answerer may begin to send as soon as it receives the offer - the answerer should be prepared to receive as soon as it sends the message containing an answer - the offerer may begin to send as soon as it receives an answer These are general rules, and can be modified in some circumstances. For=20 instance: - preconditions can delay things - some media types have different rules. (But that doesn't apply to RTP, unless you consider RTP over TCP.) Paul M.N.A.Smadi wrote: > hi; >=20 > in a INVITE/200 OK/ACK sequence, does the standard indicate when does=20 > the rtp flaw exactly start at both ends? >=20 >=20 > thanks >=20 > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip >=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 9 11:50:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23976 for ; Wed, 9 Mar 2005 11:50:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D94Qm-0004Nr-Nh for sip-web-archive@ietf.org; Wed, 09 Mar 2005 11:53:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D94I0-0007aj-7g; Wed, 09 Mar 2005 11:44:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D94Hx-0007Zv-01 for sip@megatron.ietf.org; Wed, 09 Mar 2005 11:44:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23064 for ; Wed, 9 Mar 2005 11:43:58 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D94Ka-000497-1U for sip@ietf.org; Wed, 09 Mar 2005 11:46:44 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 09 Mar 2005 08:44:28 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,151,1107763200"; d="scan'208"; a="166108736:sNHT20312722" Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j29GhuTM010614; Wed, 9 Mar 2005 08:43:56 -0800 (PST) Received: from [130.129.134.128] (che-vpn-cluster-2-206.cisco.com [10.86.242.206]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AIK69435; Wed, 9 Mar 2005 08:43:54 -0800 (PST) Message-ID: <422F27CA.2040104@cisco.com> Date: Wed, 09 Mar 2005 11:43:54 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Reinaldo Penno Subject: Re: [Sip] When does the RTP start References: <9BD5D7887235424FA97DFC223CAE3C28D380C9@proton.jnpr.net> In-Reply-To: <9BD5D7887235424FA97DFC223CAE3C28D380C9@proton.jnpr.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: IETF SIP List , Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Reinaldo Penno wrote: > Interesting, just yesterday I was dealing with a similar situation. > > Would this be true for re-INVITES (and maybe UPDATES) as well? Yes. > > I mean, should a client (a.k.a INVITEE) be prepared to receive in a > different port, etc as soon as the re-INVITE is issued? This means that > for a period of time the client would be listening on all ports > associated with both SDP specifications...? Yes. This is all treated in RFC 3264. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 9 11:57:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24924 for ; Wed, 9 Mar 2005 11:57:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D94Xp-0004ga-CI for sip-web-archive@ietf.org; Wed, 09 Mar 2005 12:00:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D94TK-0001mU-Mb; Wed, 09 Mar 2005 11:55:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D94TI-0001m7-N1 for sip@megatron.ietf.org; Wed, 09 Mar 2005 11:55:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24686 for ; Wed, 9 Mar 2005 11:55:41 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D94Vs-0004b5-VB for sip@ietf.org; Wed, 09 Mar 2005 11:58:28 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 09 Mar 2005 10:12:48 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,151,1107734400"; d="scan'208"; a="233131649:sNHT21952176" Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j29GtRuC014189 for ; Wed, 9 Mar 2005 08:55:27 -0800 (PST) Received: from [130.129.134.128] (che-vpn-cluster-2-206.cisco.com [10.86.242.206]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AIK70556; Wed, 9 Mar 2005 08:55:28 -0800 (PST) Message-ID: <422F2A80.6010604@cisco.com> Date: Wed, 09 Mar 2005 11:55:28 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Subject: [Sip] gruu and record-route stripping X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit At the SIP meeting, I presented several open issues around GRUU. One of them was the record-route looping problem. I showed the following picture: (1) + (2) + (3): initial INVITE (4) - (9): mid-dialog request (1) +-----------+ (2) +-----------+ (3) +-----------+ ---->| |------->| |-------->| | (4) | | (5) | | | | ---->| Home |------->| Edge | | User | | Proxy | (7) | Proxy | (8) | Agent | +-->| |------->| |-------->| | | +-----------+ +-----------+ +-----------+ | | | | +------------------------------+ (6) The problem arises when a call (1) arrives at a domain that has split its proxy into several logical proxies, each of which record-route. If the home and edge proxies record route the INVITE, and the UA puts a GRUU into the Contact of its 200 OK, a re-INVITE will do a loop (messages 4-8) before reaching the UA. While not an error, its inefficient. The current draft proposes this be solved by having the edge proxy strip its record-route from the 200 OK to the original INVITE. Note that each proxy, when there are more than one, could strip the RR header if it wants, and only those proxies would appear on second pass through the loop. The idea of removing a record-route header field from the 200 OK gave some folks heartburn. Note that rfc3261 allows a proxy to modify its record-route, but doesn't talk about removing it. I had started to discuss a possible remedy for this, whereby a proxy could know, when the original INVITE arrives, whether or not the UA to which it is targeted understands gruu. As it turns out, this won't help at all. Even if the edge proxy knows, at the time the original INVITE is received, that the UA supports GRUU, it still has to insert a record-route into the request in order to have outbound requests from the UA go through it at all. Unless it removes that RR from the response, mid-dialog requests towards the UA will go through that proxy twice. As such, I am pretty much convinced that there is no choice but to remove the record-route from the 200 OK if a proxy wants to avoid this loop. Can we proceed with that? Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 9 11:59:27 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25172 for ; Wed, 9 Mar 2005 11:59:27 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D94ZZ-0004l4-SI for sip-web-archive@ietf.org; Wed, 09 Mar 2005 12:02:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D94Ty-0001uA-BX; Wed, 09 Mar 2005 11:56:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D94Tx-0001u2-1H for sip@megatron.ietf.org; Wed, 09 Mar 2005 11:56:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24739 for ; Wed, 9 Mar 2005 11:56:22 -0500 (EST) Received: from ixe-nat1.juniper.net ([193.110.54.36] helo=up-smtp.jnpr.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D94WZ-0004c2-Bg for sip@ietf.org; Wed, 09 Mar 2005 11:59:08 -0500 Received: from pi-smtp.jnpr.net ([10.10.2.36]) by up-smtp.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 9 Mar 2005 16:56:11 +0000 Received: from proton.jnpr.net ([10.10.2.37]) by pi-smtp.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 9 Mar 2005 11:56:10 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] When does the RTP start Date: Wed, 9 Mar 2005 11:56:09 -0500 Message-ID: <9BD5D7887235424FA97DFC223CAE3C28D38122@proton.jnpr.net> Thread-Topic: [Sip] When does the RTP start Thread-Index: AcUkxzLs5F1RvOMHTWuD5GFsIDA+JgAAR7Ag From: "Reinaldo Penno" To: "Jonathan Rosenberg" X-OriginalArrivalTime: 09 Mar 2005 16:56:10.0482 (UTC) FILETIME=[E50CFD20:01C524C8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable Cc: IETF SIP List , Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Yep, section 8.3.1.=20 Thanks, Reinaldo -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@cisco.com]=20 Sent: Wednesday, March 09, 2005 11:44 AM To: Reinaldo Penno Cc: Paul Kyzivat; M.N.A.Smadi; IETF SIP List Subject: Re: [Sip] When does the RTP start Reinaldo Penno wrote: > Interesting, just yesterday I was dealing with a similar situation. >=20 > Would this be true for re-INVITES (and maybe UPDATES) as well? Yes. >=20 > I mean, should a client (a.k.a INVITEE) be prepared to receive in a > different port, etc as soon as the re-INVITE is issued? This means that > for a period of time the client would be listening on all ports > associated with both SDP specifications...? Yes. This is all treated in RFC 3264. -Jonathan R. --=20 Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 9 12:13:35 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27101 for ; Wed, 9 Mar 2005 12:13:35 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D94nE-0005HM-M6 for sip-web-archive@ietf.org; Wed, 09 Mar 2005 12:16:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D94gK-0004T6-Qe; Wed, 09 Mar 2005 12:09:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D94gI-0004T1-R5 for sip@megatron.ietf.org; Wed, 09 Mar 2005 12:09:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26376 for ; Wed, 9 Mar 2005 12:09:07 -0500 (EST) Received: from voyager.coretrek.no ([212.33.142.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D94it-00053W-Oe for sip@ietf.org; Wed, 09 Mar 2005 12:11:54 -0500 Received: from localhost (localhost [127.0.0.1]) by voyager.coretrek.no (Postfix) with ESMTP id BC263A97F6; Wed, 9 Mar 2005 18:08:58 +0100 (CET) Received: from [130.129.132.244] (wireless-130-129-132-244.ietf62.ietf.org [130.129.132.244]) by voyager.coretrek.no (Postfix) with ESMTP id EE794A97EE; Wed, 9 Mar 2005 18:08:56 +0100 (CET) In-Reply-To: <422F2A80.6010604@cisco.com> References: <422F2A80.6010604@cisco.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] gruu and record-route stripping Date: Wed, 9 Mar 2005 18:08:55 +0100 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: by AMaViS perl-11 (CoreTrek clamav patch 1) X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: 7bit Stripping the record-route will remove (5)(6)(7)(8) and cause the re-invite to go directly from the home proxy for the UAS. I don't know if this is desirable. The Edge proxy is there for a reason. What we really want to eliminate is (6) and (7) and keep (5) and (8). Would the home proxy be violating anything if it re-writes the Request-URI before it sends out (5)? (I know I suggested this before but don't remember the rebuttal). Regards, Hisham On Mar 9, 2005, at 5:55 PM, Jonathan Rosenberg wrote: > At the SIP meeting, I presented several open issues around GRUU. One > of them was the record-route looping problem. I showed the following > picture: > > (1) + (2) + (3): initial INVITE > (4) - (9): mid-dialog request > > > > > > (1) +-----------+ (2) +-----------+ (3) +-----------+ > ---->| |------->| |-------->| | > (4) | | (5) | | | | > ---->| Home |------->| Edge | | User | > | Proxy | (7) | Proxy | (8) | Agent | > +-->| |------->| |-------->| | > | +-----------+ +-----------+ +-----------+ > | | > | | > +------------------------------+ > (6) > > The problem arises when a call (1) arrives at a domain that has split > its proxy into several logical proxies, each of which record-route. If > the home and edge proxies record route the INVITE, and the UA puts a > GRUU into the Contact of its 200 OK, a re-INVITE will do a loop > (messages 4-8) before reaching the UA. While not an error, its > inefficient. > > The current draft proposes this be solved by having the edge proxy > strip its record-route from the 200 OK to the original INVITE. Note > that each proxy, when there are more than one, could strip the RR > header if it wants, and only those proxies would appear on second pass > through the loop. > > The idea of removing a record-route header field from the 200 OK gave > some folks heartburn. Note that rfc3261 allows a proxy to modify its > record-route, but doesn't talk about removing it. > > I had started to discuss a possible remedy for this, whereby a proxy > could know, when the original INVITE arrives, whether or not the UA to > which it is targeted understands gruu. As it turns out, this won't > help at all. Even if the edge proxy knows, at the time the original > INVITE is received, that the UA supports GRUU, it still has to insert > a record-route into the request in order to have outbound requests > from the UA go through it at all. Unless it removes that RR from the > response, mid-dialog requests towards the UA will go through that > proxy twice. > > As such, I am pretty much convinced that there is no choice but to > remove the record-route from the 200 OK if a proxy wants to avoid this > loop. > > Can we proceed with that? > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 9 13:43:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05973 for ; Wed, 9 Mar 2005 13:43:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D96Cc-0007es-HM for sip-web-archive@ietf.org; Wed, 09 Mar 2005 13:46:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D969j-0003yO-Kq; Wed, 09 Mar 2005 13:43:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D969i-0003yF-2d for sip@megatron.ietf.org; Wed, 09 Mar 2005 13:43:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05952 for ; Wed, 9 Mar 2005 13:43:34 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D96CL-0007e5-RU for sip@ietf.org; Wed, 09 Mar 2005 13:46:22 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 09 Mar 2005 10:57:40 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j29IhOuC003777; Wed, 9 Mar 2005 10:43:25 -0800 (PST) Received: from cisco.com (che-vpn-cluster-2-101.cisco.com [10.86.242.101]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APR36247; Wed, 9 Mar 2005 13:43:23 -0500 (EST) Message-ID: <422F43CB.6090106@cisco.com> Date: Wed, 09 Mar 2005 13:43:23 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] gruu and record-route stripping References: <422F2A80.6010604@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit comment at end. Paul Jonathan Rosenberg wrote: > At the SIP meeting, I presented several open issues around GRUU. One of > them was the record-route looping problem. I showed the following picture: > > (1) + (2) + (3): initial INVITE > (4) - (9): mid-dialog request > > > > > > (1) +-----------+ (2) +-----------+ (3) +-----------+ > ---->| |------->| |-------->| | > (4) | | (5) | | | | > ---->| Home |------->| Edge | | User | > | Proxy | (7) | Proxy | (8) | Agent | > +-->| |------->| |-------->| | > | +-----------+ +-----------+ +-----------+ > | | > | | > +------------------------------+ > (6) > > The problem arises when a call (1) arrives at a domain that has split > its proxy into several logical proxies, each of which record-route. If > the home and edge proxies record route the INVITE, and the UA puts a > GRUU into the Contact of its 200 OK, a re-INVITE will do a loop > (messages 4-8) before reaching the UA. While not an error, its inefficient. > > The current draft proposes this be solved by having the edge proxy strip > its record-route from the 200 OK to the original INVITE. Note that each > proxy, when there are more than one, could strip the RR header if it > wants, and only those proxies would appear on second pass through the loop. > > The idea of removing a record-route header field from the 200 OK gave > some folks heartburn. Note that rfc3261 allows a proxy to modify its > record-route, but doesn't talk about removing it. > > I had started to discuss a possible remedy for this, whereby a proxy > could know, when the original INVITE arrives, whether or not the UA to > which it is targeted understands gruu. As it turns out, this won't help > at all. Even if the edge proxy knows, at the time the original INVITE is > received, that the UA supports GRUU, it still has to insert a > record-route into the request in order to have outbound requests from > the UA go through it at all. Is that necessarily true? The UA knows to include the EP in calls that it originates. If it always does so, then there is no problem. Of course there is the question of whether the EP can *know* this is the case. > Unless it removes that RR from the > response, mid-dialog requests towards the UA will go through that proxy > twice. > > As such, I am pretty much convinced that there is no choice but to > remove the record-route from the 200 OK if a proxy wants to avoid this > loop. > > Can we proceed with that? The end result of this is that the two ends have different route sets for the dialog. At least in this case that seems like a good thing. Whether it is needed depends on whether the EP has a way to know the UA will use it even if not R-R'd. I've lost track of the prior discussion. How again does the EP know it should remove itself from the R-R in the response? Does it do so based on a gruu option in the response? I want to be sure we aren't just depending on a different kind of magic to figure that out. The decision it has to make is: "the contact contains an address that when resolved within the dialog will result in the request being delivered to me, with a Route header containing exactly those entries that precede mine in the R-R header." I'm having trouble getting it clear in my head how many assumptions about the environment it must make to reach this conclusion. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 9 13:49:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06667 for ; Wed, 9 Mar 2005 13:49:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D96IT-0007rm-Oe for sip-web-archive@ietf.org; Wed, 09 Mar 2005 13:52:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D96EG-0004y8-JR; Wed, 09 Mar 2005 13:48:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D96EE-0004y0-Ni for sip@megatron.ietf.org; Wed, 09 Mar 2005 13:48:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06450 for ; Wed, 9 Mar 2005 13:48:15 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D96Gs-0007n0-PD for sip@ietf.org; Wed, 09 Mar 2005 13:51:03 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 09 Mar 2005 10:46:59 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,151,1107763200"; d="scan'208"; a="166158019:sNHT2867926482" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j29IkNYO015023; Wed, 9 Mar 2005 10:46:23 -0800 (PST) Received: from cisco.com (che-vpn-cluster-2-101.cisco.com [10.86.242.101]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APR36563; Wed, 9 Mar 2005 13:46:20 -0500 (EST) Message-ID: <422F447C.5000907@cisco.com> Date: Wed, 09 Mar 2005 13:46:20 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hisham Khartabil Subject: Re: [Sip] gruu and record-route stripping References: <422F2A80.6010604@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Content-Transfer-Encoding: 7bit Hisham Khartabil wrote: > Stripping the record-route will remove (5)(6)(7)(8) and cause the > re-invite to go directly from the home proxy for the UAS. I don't know > if this is desirable. The Edge proxy is there for a reason. What we > really want to eliminate is (6) and (7) and keep (5) and (8). My understanding is that Jonathan only meant that the one entry in the R-R referencing the EP itself would be stripped. > Would the home proxy be violating anything if it re-writes the > Request-URI before it sends out (5)? (I know I suggested this before but > don't remember the rebuttal). I think it was I who suggested that - with many reservations. I don't think there was a rebuttal. It doesn't feel like a good thing to do, but then none of these solutions seem like good things to do. Paul > Regards, > Hisham > > On Mar 9, 2005, at 5:55 PM, Jonathan Rosenberg wrote: > >> At the SIP meeting, I presented several open issues around GRUU. One >> of them was the record-route looping problem. I showed the following >> picture: >> >> (1) + (2) + (3): initial INVITE >> (4) - (9): mid-dialog request >> >> >> >> >> >> (1) +-----------+ (2) +-----------+ (3) +-----------+ >> ---->| |------->| |-------->| | >> (4) | | (5) | | | | >> ---->| Home |------->| Edge | | User | >> | Proxy | (7) | Proxy | (8) | Agent | >> +-->| |------->| |-------->| | >> | +-----------+ +-----------+ +-----------+ >> | | >> | | >> +------------------------------+ >> (6) >> >> The problem arises when a call (1) arrives at a domain that has split >> its proxy into several logical proxies, each of which record-route. If >> the home and edge proxies record route the INVITE, and the UA puts a >> GRUU into the Contact of its 200 OK, a re-INVITE will do a loop >> (messages 4-8) before reaching the UA. While not an error, its >> inefficient. >> >> The current draft proposes this be solved by having the edge proxy >> strip its record-route from the 200 OK to the original INVITE. Note >> that each proxy, when there are more than one, could strip the RR >> header if it wants, and only those proxies would appear on second pass >> through the loop. >> >> The idea of removing a record-route header field from the 200 OK gave >> some folks heartburn. Note that rfc3261 allows a proxy to modify its >> record-route, but doesn't talk about removing it. >> >> I had started to discuss a possible remedy for this, whereby a proxy >> could know, when the original INVITE arrives, whether or not the UA to >> which it is targeted understands gruu. As it turns out, this won't >> help at all. Even if the edge proxy knows, at the time the original >> INVITE is received, that the UA supports GRUU, it still has to insert >> a record-route into the request in order to have outbound requests >> from the UA go through it at all. Unless it removes that RR from the >> response, mid-dialog requests towards the UA will go through that >> proxy twice. >> >> As such, I am pretty much convinced that there is no choice but to >> remove the record-route from the 200 OK if a proxy wants to avoid this >> loop. >> >> Can we proceed with that? >> >> Thanks, >> Jonathan R. >> -- >> Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza >> Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 >> Cisco Systems >> jdrosen@cisco.com FAX: (973) 952-5050 >> http://www.jdrosen.net PHONE: (973) 952-5000 >> http://www.cisco.com >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 9 14:34:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10982 for ; Wed, 9 Mar 2005 14:34:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D96zK-0000Xs-NH for sip-web-archive@ietf.org; Wed, 09 Mar 2005 14:36:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D96qI-0002kO-0e; Wed, 09 Mar 2005 14:27:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D96qG-0002kF-04 for sip@megatron.ietf.org; Wed, 09 Mar 2005 14:27:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10229 for ; Wed, 9 Mar 2005 14:27:34 -0500 (EST) Received: from [12.47.48.6] (helo=mail1.sonimtech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D96ss-0000NO-3h for sip@ietf.org; Wed, 09 Mar 2005 14:30:20 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] RFC 3265 REFRESHING SUBSCRIPTIONS - Example Date: Wed, 9 Mar 2005 11:29:40 -0800 Message-ID: <6A72F4F5EC7C1541A3FD8CD6FEBE366410F470@mail1.sonimtech.com> Thread-Topic: RFC 3265 REFRESHING SUBSCRIPTIONS - Example Thread-Index: AcUknkTHnSuHZXIWRJCENWgXuO4TmQAO1I5w From: "Amit Idnani" To: X-Spam-Score: 0.3 (/) X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0009077132==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: e274a7d5658fb8b0d6fbc93f042d014b This is a multi-part message in MIME format. --===============0009077132== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C524DE.56C77BCD" This is a multi-part message in MIME format. ------_=_NextPart_001_01C524DE.56C77BCD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I believe you are referring to section 3.1.6.4 "Refreshing of = Subscriptions" of RFC 3265. =20 Assume, a UA1 to send a initial SIP SUBSCRIBE message with value of = Expires header set to 3600. The response may contain a value <=3D 3600 = (1800) in the sample flow below. =20 SUBSCRIBE sip:myPresenceList@myNetwork.com SIP/2.0 From: ;tag=3Dcl8674463231 To: Max-Forwards: 70 Via: SIP/2.0/UDP 192.168.1.1:7001;branch=3Dz9hG4bKzA5mqX7086623498662350 Call-ID: 23711cl@192.168.1.1 CSeq: 1 SUBSCRIBE Contact: Event: presence Expires: 3600 Content-Length:0 =20 =20 SIP/2.0 200 OK Record-Route: From: ;tag=3Dcl8674463231 To: ;tag=3Dpr1604765404 Via: SIP/2.0/UDP 192.168.1.1:7001;branch=3Dz9hG4bKzA5mqX7086623498662350 Call-ID:23711cl@192.168.1.1 CSeq:1 SUBSCRIBE Expires: 1800 Contact: Content-Length:0 =20 Now, when the client decides to refresh the subscription, it sends = another SUBSCRIBE request within the same dialog and may send Expires = with 1800 and be prepared to receive a value <=3D 1800 (900) in the = sample flow below. =20 SUBSCRIBE sip:prId-123@myPresenceServer.myNetwork.com SIP/2.0 From: ;tag=3Dcl8674463231 To: ;tag=3Dpr1604765404 Route: Via: SIP/2.0/UDP 192.168.1.1:7001;branch=3Dz9hG4bKzA5mqX7086623498662351 Call-ID: 23711cl@192.168.1.1 CSeq: 2 SUBSCRIBE Contact: Event: presence Expires: 1800 Content-Length:0 =20 =20 SIP/2.0 200 OK From: ;tag=3Dcl8674463231 To: ;tag=3Dpr1604765404 Via: SIP/2.0/UDP 192.168.1.1:7001;branch=3Dz9hG4bKzA5mqX7086623498662351 Call-ID:23711cl@192.168.1.1 CSeq:2 SUBSCRIBE Expires: 900 Contact: Content-Length:0 =20 =20 Hope it helps. Amit Idnani -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of = innovation.interops@wipro.com Sent: Wednesday, March 09, 2005 3:51 AM To: sip@ietf.org Subject: [Sip] RFC 3265 REFRESHING SUBSCRIPTIONS - Example Hello all, =20 Can any one give an example for this scenario on refreshing = Subscriptions? =20 While receiving Subscription refresh reuquest.The notifier updates the = expiration time for the subscription. As with the initial subscription, = the server MAY shorten the amount of time until expiration, but MUST NOT = increase it.=20 =20 Regds and Thanks ------_=_NextPart_001_01C524DE.56C77BCD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I=20 believe you are referring to section 3.1.6.4 "Refreshing = of=20 Subscriptions" of RFC 3265.
 
Assume, a UA1 to send a initial SIP SUBSCRIBE = message=20 with value of Expires header set to 3600. The response may contain a = value <=3D=20 3600 (1800) in the sample flow below.
 
SUBSCRIBE sip:myPresenceList@myNetwork.com=20 SIP/2.0
From:=20 <sip:myself@myNetwork.com>;tag=3Dcl8674463231
To:=20 <sip:myPresenceList@myNetwork.com>
Max-Forwards: 70
Via:=20 SIP/2.0/UDP=20 192.168.1.1:7001;branch=3Dz9hG4bKzA5mqX7086623498662350
Call-ID: = 23711cl@192.168.1.1
CSeq:=20 1 SUBSCRIBE
Contact:=20 <sip:myself@192.168.1.1:7001>
Event:=20 presence
Expires: = 3600
Content-Length:0
 
 
SIP/2.0 200 OK
Record-Route:<sip:myProxy@myNetwork.com;mad= dr=3D192.168.1.2;lr>
From:=20 <sip:myself@myNetwork.com>;tag=3Dcl8674463231<= /DIV>
To:=20 <sip:myPresenceList@myNetwork.com>;tag=3Dpr1604765404=
Via: SIP/2.0/UDP=20 192.168.1.1:7001;branch=3Dz9hG4bKzA5mqX7086623498662350
Call-ID:23711cl@192.168.1.1
CSeq:1=20 SUBSCRIBE
Expires: = 1800
Contact:<sip:prId-123@myPresenceServer.myNe= twork.com>
Content-Length:0
 
Now,=20 when the client decides to refresh the subscription, it sends another = SUBSCRIBE=20 request within the same dialog and may send Expires with 1800 and be = prepared to=20 receive a value <=3D 1800 (900) in the sample flow = below.
 
SUBSCRIBE = sip:prId-123@myPresenceServer.myNetwork.com=20 SIP/2.0
From:=20 <sip:myself@myNetwork.com>;tag=3Dcl8674463231
To:=20 <sip:myPresenceList@myNetwork.com>;tag=3Dpr1604765404=
Route:=20 <sip:myProxy@myNetwork.com;maddr=3D192.168.1.2;lr>
Via:=20 SIP/2.0/UDP=20 192.168.1.1:7001;branch=3Dz9hG4bKzA5mqX7086623498662351
Call-ID: = 23711cl@192.168.1.1
CSeq: 2 SUBSCRIBE
Contact:=20 <sip:myself@192.168.1.1:7001>
Event:=20 presence
Expires: = 1800
Content-Length:0
 
 
SIP/2.0 200 OK
From:=20 <sip:myself@myNetwork.com>;tag=3Dcl8674463231<= /DIV>
To:=20 <sip:myPresenceList@myNetwork.com>;tag=3Dpr1604765404=
Via: SIP/2.0/UDP=20 192.168.1.1:7001;branch=3Dz9hG4bKzA5mqX7086623498662351
Call-ID:23711cl@192.168.1.1
CSeq:2=20 SUBSCRIBE
Expires: = 900
Contact:<sip:prId-123@myPresenceServer.myNe= twork.com>
Content-Length:0
 
=
 
Hope=20 it helps.
Amit=20 Idnani
-----Original Message-----
From: = sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org]On Behalf Of=20 innovation.interops@wipro.com
Sent: Wednesday, March 09, = 2005=20 3:51 AM
To: sip@ietf.org
Subject: [Sip] RFC 3265=20 REFRESHING SUBSCRIPTIONS - Example

Hello = all,
 
Can any one give an example for this = scenario on=20 refreshing Subscriptions?
 

While receiving Subscription refresh reuquest.The notifier = updates the=20 expiration time for = the=20 subscription.  As with = the initial=20 subscription, the server=20 MAY shorten the amount of time until expiration, but MUST=20 NOT increase it.

 

Regds=20 and Thanks

------_=_NextPart_001_01C524DE.56C77BCD-- --===============0009077132== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0009077132==-- From sip-bounces@ietf.org Wed Mar 9 14:51:16 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12966 for ; Wed, 9 Mar 2005 14:51:16 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D97Fp-0000yu-QG for sip-web-archive@ietf.org; Wed, 09 Mar 2005 14:54:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D97Ch-0005JC-6T; Wed, 09 Mar 2005 14:50:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D97Cf-0005J7-Ox for sip@megatron.ietf.org; Wed, 09 Mar 2005 14:50:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12927 for ; Wed, 9 Mar 2005 14:50:43 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D97FK-0000yH-1O for sip@ietf.org; Wed, 09 Mar 2005 14:53:30 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 09 Mar 2005 12:06:01 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,151,1107763200"; d="scan'208"; a="618576460:sNHT23320736" Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j29JoXZV017705; Wed, 9 Mar 2005 11:50:33 -0800 (PST) Received: from [130.129.134.128] (che-vpn-cluster-2-121.cisco.com [10.86.242.121]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AIK91342; Wed, 9 Mar 2005 11:50:32 -0800 (PST) Message-ID: <422F5387.4060807@cisco.com> Date: Wed, 09 Mar 2005 14:50:31 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hisham Khartabil Subject: Re: [Sip] gruu and record-route stripping References: <422F2A80.6010604@cisco.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Hisham Khartabil wrote: > Stripping the record-route will remove (5)(6)(7)(8) and cause the > re-invite to go directly from the home proxy for the UAS. I don't know > if this is desirable. The Edge proxy is there for a reason. What we > really want to eliminate is (6) and (7) and keep (5) and (8). Right. This will still happen. If a proxy wants to be on the path for messages from the home proxy towards the client, it needs to put itself on the Path header field during the registration. It will be the Path header field that determines who gets hit for the second round of the loop. > > Would the home proxy be violating anything if it re-writes the > Request-URI before it sends out (5)? (I know I suggested this before but > don't remember the rebuttal). Rewrites it to what? To the client URI? That won't work, since the edge proxy will usually need to be in the path of the request from the network towards the client (for example, it is hold the TCP connection to the client). -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 9 15:03:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14252 for ; Wed, 9 Mar 2005 15:03:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D97S0-0001LS-Cj for sip-web-archive@ietf.org; Wed, 09 Mar 2005 15:06:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D97My-0006Zq-K9; Wed, 09 Mar 2005 15:01:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D97Mw-0006Zc-Qv for sip@megatron.ietf.org; Wed, 09 Mar 2005 15:01:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13873 for ; Wed, 9 Mar 2005 15:01:20 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D97Pa-0001Ed-LT for sip@ietf.org; Wed, 09 Mar 2005 15:04:07 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 09 Mar 2005 12:01:28 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j29K0kTM023669; Wed, 9 Mar 2005 12:00:46 -0800 (PST) Received: from [130.129.134.128] (che-vpn-cluster-2-121.cisco.com [10.86.242.121]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AIK92664; Wed, 9 Mar 2005 12:00:43 -0800 (PST) Message-ID: <422F55EA.8080207@cisco.com> Date: Wed, 09 Mar 2005 15:00:42 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] gruu and record-route stripping References: <422F2A80.6010604@cisco.com> <422F447C.5000907@cisco.com> In-Reply-To: <422F447C.5000907@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > > > Hisham Khartabil wrote: > >> Stripping the record-route will remove (5)(6)(7)(8) and cause the >> re-invite to go directly from the home proxy for the UAS. I don't know >> if this is desirable. The Edge proxy is there for a reason. What we >> really want to eliminate is (6) and (7) and keep (5) and (8). > > > My understanding is that Jonathan only meant that the one entry in the > R-R referencing the EP itself would be stripped. Yes. > >> Would the home proxy be violating anything if it re-writes the >> Request-URI before it sends out (5)? (I know I suggested this before >> but don't remember the rebuttal). > > > I think it was I who suggested that - with many reservations. I don't > think there was a rebuttal. It doesn't feel like a good thing to do, but > then none of these solutions seem like good things to do. I don't understand what rewrite you had in mind? -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 9 15:07:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14931 for ; Wed, 9 Mar 2005 15:07:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D97Vl-0001SZ-6b for sip-web-archive@ietf.org; Wed, 09 Mar 2005 15:10:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D97Le-0006SV-9I; Wed, 09 Mar 2005 15:00:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D97Lb-0006SO-VO for sip@megatron.ietf.org; Wed, 09 Mar 2005 14:59:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13746 for ; Wed, 9 Mar 2005 14:59:58 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D97OG-0001Ca-J0 for sip@ietf.org; Wed, 09 Mar 2005 15:02:45 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 09 Mar 2005 13:17:07 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,151,1107734400"; d="scan'208"; a="233219413:sNHT22461682" Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j29JxmZV022835; Wed, 9 Mar 2005 11:59:48 -0800 (PST) Received: from [130.129.134.128] (che-vpn-cluster-2-121.cisco.com [10.86.242.121]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AIK92496; Wed, 9 Mar 2005 11:59:34 -0800 (PST) Message-ID: <422F55A5.8080907@cisco.com> Date: Wed, 09 Mar 2005 14:59:33 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] gruu and record-route stripping References: <422F2A80.6010604@cisco.com> <422F43CB.6090106@cisco.com> In-Reply-To: <422F43CB.6090106@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Content-Transfer-Encoding: 7bit inline. Paul Kyzivat wrote: > comment at end. > > Paul > > Jonathan Rosenberg wrote: > >> At the SIP meeting, I presented several open issues around GRUU. One >> of them was the record-route looping problem. I showed the following >> picture: >> >> (1) + (2) + (3): initial INVITE >> (4) - (9): mid-dialog request >> >> >> >> >> >> (1) +-----------+ (2) +-----------+ (3) +-----------+ >> ---->| |------->| |-------->| | >> (4) | | (5) | | | | >> ---->| Home |------->| Edge | | User | >> | Proxy | (7) | Proxy | (8) | Agent | >> +-->| |------->| |-------->| | >> | +-----------+ +-----------+ +-----------+ >> | | >> | | >> +------------------------------+ >> (6) >> >> The problem arises when a call (1) arrives at a domain that has split >> its proxy into several logical proxies, each of which record-route. If >> the home and edge proxies record route the INVITE, and the UA puts a >> GRUU into the Contact of its 200 OK, a re-INVITE will do a loop >> (messages 4-8) before reaching the UA. While not an error, its >> inefficient. >> >> The current draft proposes this be solved by having the edge proxy >> strip its record-route from the 200 OK to the original INVITE. Note >> that each proxy, when there are more than one, could strip the RR >> header if it wants, and only those proxies would appear on second pass >> through the loop. >> >> The idea of removing a record-route header field from the 200 OK gave >> some folks heartburn. Note that rfc3261 allows a proxy to modify its >> record-route, but doesn't talk about removing it. >> >> I had started to discuss a possible remedy for this, whereby a proxy >> could know, when the original INVITE arrives, whether or not the UA to >> which it is targeted understands gruu. As it turns out, this won't >> help at all. Even if the edge proxy knows, at the time the original >> INVITE is received, that the UA supports GRUU, it still has to insert >> a record-route into the request in order to have outbound requests >> from the UA go through it at all. > > > Is that necessarily true? > > The UA knows to include the EP in calls that it originates. If it always > does so, then there is no problem. Of course there is the question of > whether the EP can *know* this is the case. Ah. So this relates to something else, which is, how does the client compute a route set for an outbound request? We now have several techniques for delivering route sets: 1. from record-routes in an intial request 2. from a route set delivered in a Service Route header field in a REGISTER response 3. from configuration that defines the default outbound proxies My view, and I doubt this is documented well anywhere, is that the following logic applies: 1. For any particular outbound request, the client uses the route set from the record-route if the request is a mid-dialog request 2. If the request is not a mid-dialog request, including REGISTER itself, the client uses the URIs learned from a service route if it received any 3. If the request is not a mid-dialog request, and the client has no route set from a Service-Route, it uses the default outbound proxy route set it learned from configuration What I want to avoid is mixing of route sets from multiple sources. I think that is a recipe for disaster. It sure would be nice if the above logic was documented somewhere, but it touches three different specs at least and as such doesnt' appear anywhere. > >> Unless it removes that RR from the response, mid-dialog requests >> towards the UA will go through that proxy twice. >> >> As such, I am pretty much convinced that there is no choice but to >> remove the record-route from the 200 OK if a proxy wants to avoid this >> loop. >> >> Can we proceed with that? > > > The end result of this is that the two ends have different route sets > for the dialog. At least in this case that seems like a good thing. > Whether it is needed depends on whether the EP has a way to know the UA > will use it even if not R-R'd. From above, I am saying it definitely wont unless it RR'd. > > I've lost track of the prior discussion. How again does the EP know it > should remove itself from the R-R in the response? Does it do so based > on a gruu option in the response? Yes. If the Supported header field in the response contains the "gruu" optiong tag. I want to be sure we aren't just > depending on a different kind of magic to figure that out. The decision > it has to make is: "the contact contains an address that when resolved > within the dialog will result in the request being delivered to me, with > a Route header containing exactly those entries that precede mine in the > R-R header." I'm having trouble getting it clear in my head how many > assumptions about the environment it must make to reach this conclusion. The proxy knows this if it inserted a Path header field in a REGISTER request from the client. It can know this when the R-URI of the INVITE which matches a contact which was in a REGISTER that the proxy inserted a Path into. If the proxy didnt insert itself into Path, but it needs to be in the final loop towards the client, even record-routing won't help, since the request will loop back around to the home proxy and then try to go directly to the client from there. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 9 15:36:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18129 for ; Wed, 9 Mar 2005 15:36:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D97xw-00027j-EF for sip-web-archive@ietf.org; Wed, 09 Mar 2005 15:39:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D97pC-0001r2-JQ; Wed, 09 Mar 2005 15:30:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D97pA-0001qH-Iv for sip@megatron.ietf.org; Wed, 09 Mar 2005 15:30:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17517 for ; Wed, 9 Mar 2005 15:30:30 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D97rp-0001wJ-N0 for sip@ietf.org; Wed, 09 Mar 2005 15:33:18 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 09 Mar 2005 12:30:55 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j29KU9YO028678; Wed, 9 Mar 2005 12:30:10 -0800 (PST) Received: from cisco.com (che-vpn-cluster-2-101.cisco.com [10.86.242.101]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APR48700; Wed, 9 Mar 2005 15:30:07 -0500 (EST) Message-ID: <422F5CCE.5010504@cisco.com> Date: Wed, 09 Mar 2005 15:30:06 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] gruu and record-route stripping References: <422F2A80.6010604@cisco.com> <422F447C.5000907@cisco.com> <422F55EA.8080207@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Paul Kyzivat wrote: >> Hisham Khartabil wrote: >>> Would the home proxy be violating anything if it re-writes the >>> Request-URI before it sends out (5)? (I know I suggested this before >>> but don't remember the rebuttal). >> >> I think it was I who suggested that - with many reservations. I don't >> think there was a rebuttal. It doesn't feel like a good thing to do, >> but then none of these solutions seem like good things to do. > > I don't understand what rewrite you had in mind? When the request arrives at the home proxy for the first time, while there are still Route headers, the home proxy might peek at the R-URI, recognize that it is responsible for it and that it is a GRUU, and translate the R-URI then and there. It would then go ahead and route the request based on the remaining Route header. This would do the job. I think it violates proxy rules, but I can't think of any harm that it does. But I have a feeling that maybe there is some harm that can result that I haven't thought of. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 9 16:30:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22283 for ; Wed, 9 Mar 2005 16:30:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D98o4-0003Ns-5X for sip-web-archive@ietf.org; Wed, 09 Mar 2005 16:33:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D98kW-0008UC-7x; Wed, 09 Mar 2005 16:29:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D98kU-0008U7-A2 for sip@megatron.ietf.org; Wed, 09 Mar 2005 16:29:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22166 for ; Wed, 9 Mar 2005 16:29:43 -0500 (EST) Received: from s-utl01-atpop.stsn.net ([72.254.128.17]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D98nA-0003Ln-2K for sip@ietf.org; Wed, 09 Mar 2005 16:32:32 -0500 Received: from s-utl01-atpop.stsn.net ([127.0.0.1]) by s-utl01-atpop.stsn.net (SMSSMTP 4.0.0.59) with SMTP id M2005030916292930943 ; Wed, 09 Mar 2005 16:29:29 -0500 Received: from [10.11.23.181] ([10.11.23.181]) by s-utl01-atpop.stsn.net (Kerio MailServer 6.0.6); Wed, 9 Mar 2005 16:29:27 -0500 In-Reply-To: <422F5387.4060807@cisco.com> References: <422F2A80.6010604@cisco.com> <422F5387.4060807@cisco.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <283d4cebea50548e21a053263445c867@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] gruu and record-route stripping Date: Wed, 9 Mar 2005 22:29:23 +0100 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 7bit On Mar 9, 2005, at 8:50 PM, Jonathan Rosenberg wrote: > > > Hisham Khartabil wrote: > >> Stripping the record-route will remove (5)(6)(7)(8) and cause the >> re-invite to go directly from the home proxy for the UAS. I don't >> know if this is desirable. The Edge proxy is there for a reason. What >> we really want to eliminate is (6) and (7) and keep (5) and (8). > > Right. This will still happen. If a proxy wants to be on the path for > messages from the home proxy towards the client, it needs to put > itself on the Path header field during the registration. It will be > the Path header field that determines who gets hit for the second > round of the loop. The path header determines who get hit the first time round. Record-Route headers that are inserted in the first invite determine who gets hit the second time round. > > >> Would the home proxy be violating anything if it re-writes the >> Request-URI before it sends out (5)? (I know I suggested this before >> but don't remember the rebuttal). > > Rewrites it to what? To the client URI? That won't work, since the > edge proxy will usually need to be in the path of the request from the > network towards the client (for example, it is hold the TCP connection > to the client). The home proxy re-writes the request-uri to the uri in the contact header the client registered with. The home proxy still routes the request to the next route header field. /Hisham > > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 9 16:40:06 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23463 for ; Wed, 9 Mar 2005 16:40:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D98xC-0003h0-Hz for sip-web-archive@ietf.org; Wed, 09 Mar 2005 16:42:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D98tJ-00020U-Dw; Wed, 09 Mar 2005 16:38:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D98tH-0001xV-OA for sip@megatron.ietf.org; Wed, 09 Mar 2005 16:38:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23320 for ; Wed, 9 Mar 2005 16:38:49 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D98vv-0003eC-NU for sip@ietf.org; Wed, 09 Mar 2005 16:41:37 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 09 Mar 2005 13:38:53 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,151,1107763200"; d="scan'208"; a="166231890:sNHT24674464" Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j29LcBq8025464 for ; Wed, 9 Mar 2005 13:38:12 -0800 (PST) Received: from [130.129.134.128] (che-vpn-cluster-1-180.cisco.com [10.86.240.180]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AIL02060; Wed, 9 Mar 2005 13:38:10 -0800 (PST) Message-ID: <422F6CC2.3060706@cisco.com> Date: Wed, 09 Mar 2005 16:38:10 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Content-Transfer-Encoding: 7bit Subject: [Sip] comments on connect-reuse X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Content-Transfer-Encoding: 7bit I think the draft needs to be very clear on its relationship to jennings-sipping-outbound. I think the delineation are: 1. connect-reuse focuses on proxy to proxy relationships, and as a result have a different trust model than client to proxy, which is the focus of the jennings draft 2. connect-reuse has both sides of the connection with entries in the DNS corresponding to them, not so for the jennings-outbound draft 3. the problem statement for connect-reuse is reducing connection overheads by reuse; its still possible to connect in the reverse direction there are probably others. I think section 2.2 should be removed entirely, at that is now addressed elsewhere. Connect-reuse actually says that this is so, but nonetheless includes this text that doesn't really belong here. > If the Transport layer had > some way to associate these connections, then request and responses > originated from either node could reuse existing connections as shown > below. > > +-----------+ +-----------+ > | | | | > | Node A | 8293 5061 | Node B | > | |<======================>| | > | | | | > +-----------+ +-----------+ but this is not the desired behavior. We talked about this at the last meeting. You want to load balance, so you can't just reuse an existing connection to node A, since then the other nodes in the the cluster on side A would never receive traffic. > When SIP entities use a connection oriented protocol to send a > request, they typically originate their connections from an ephemeral > port. The SIP protocol includes mechanisms which insure that expand SIP > but uses an ephemeral port (port 8293) for a new connection to Entity > B. These entities could be SIP User Agents or SIP Proxy Servers. need to carefully define entities here so as to not overlap with jennings-outbound > The SIP protocol includes mechanisms which insure that responses to a > request reuse the existing connection which is typically still ensure, not insure > This is especially > problematic for some common SIP call flows (for example, the > recommended example flow in figure number 4 in RFC3725 [9] (SIP > third-party call control) use many reINVITEs. s/use/that use > Similarly, when when an "outbound-only" user agent opens a connection > to only one proxy server in the same cluster, there is no way for > this user agent to receive incoming requests if the this particular > proxy goes down. In many scenarios, the user agent would not notice > the connection was unresponsive until it was time to refresh its SIP > registration. Some "outbound-only" user agents would like the > ability to open persistent connections to more than one proxy server > in a cluster, so that at least two proxy servers in the cluster can > forward incoming requests to the user agent. This requirements of > these "outbound-only" user agents are discussed in [1]. suggest removing this paragraph as well > 1. A connection sharing mechanism SHOULD allow SIP entities to reuse > existing connections for requests and responses originated from > either peer in the connection. i think its just requests. connection reuse for responses is specified in rfc3261 > There is no requirement to share a complete path for ordinary > connection reuse. Hop-by-hop connection sharing is more > appropriate. its also not a requirement to cure cancer. I don't think non-requirements belong. Also, suggest focusing on clarifying the requirements as different from sipping-outbound > 4. Behavior per sip-guidelines, you want to clearly specify behavior for transaction clients and transaction servers. The current text doesn't really differentiate, and is lacking important normative behaviors as a result. In fact, there are very few rfc2119 terms in here, though several important behaviors are specified. > connection stays up. > The SIP community recommends that servers keep connections up > unless they need to reclaim resources, and that clients keep > connections up as long as they are needed. Connection reuse works > best when the client and the server maintain their connections for why is this indented? > To implement connection aliases for explicit IP addresses and port > numbers, a SIP node could (for example) search an additional data > structure (the alias table) prior to opening a new connection, or > could modify the data structure in which it keeps active > connection state so that aliases, active connections, and > blacklisted nodes are all discovered when looking for an active > connection. can't parse this > transport is selected, an SRV lookup would ordinarily occur to find > the appropriate port number. it is used to find IP address and port. > In this case, the transport layer uses > a connection reuse alias instead of performing the SRV query. this means that the load balancing and prioritization propertise of the DNS entries are lost. I think this is not acceptable. Also, there are no normative statements about this behavior. > The Via sent-by address needs to be within the > scope protected by the certificate presented by the originator during > TLS mutual authentication and the received IP address needs be a > valid IP address for the sent-by host or hosts. In other words, the > sent-by address MUST be resolvable from the subjectAltName of the > originator certificate, and the received IP address MUST be > resolvable from the sent-by address. This is in addition to other > requirements for TLS authentication and authorization discussed in > SIP [3] and Locating SIP Servers [6]. > > Following this logic step-by-step: this first paragraph is sort of explanatory in nature, and it is followed by much more rigorous protocol specifications. However, this explanatory bit contains normative text that could be interpreted as being different than the specific behaviors in the steps that follow. In particular, "MUST be resolvable from the...". Suggest rewording the first paragraph to summarize the technique. > If the advertised address and the subjectAltName match exactly > then the certificate covers the address. need to specify matching rules. Also, what if the subjectAltName has another form besides a hostname? I believe they can contain all kinds of identifiers. > Use DNS to resolve if the advertised name is resolvable from the > subjectAltName (start by resolving the subjectAltName as if it > where a target URI according to the rules in RFC3263. That is, > if no port number is present perform an SRV lookup, then finally > resolve relevant address records). the stuff inside of the () is quite fundamental behavior. There is no reason it should be inside of (). As above, this resolution technique is dependent on the form of subjectAltName. You need to constrain it. Also, the processing in RFC3263 starts with a NAPTR lookup. You are going right to SRV. Also, you need to specify how to transform the subjectAltName into a SIP URI for purposes of doing rfc3263 processing, since that spec starts with a SIP URI as input. > Finally, Verify that the advertised address can resolve to the IP > address over which the connection was received. Note well: this rules this mechanism out if there is a NAT between them. Also, you need to define what it means to "resolve". Using rfc3263? How? using A records? > 4.2 Formal Syntax > > The following syntax specification uses the augmented Backus-Naur > Form (BNF) as described in RFC-2234 [7]. This document proposes to > extend via-params to include a new via-alias defined below. I am still not sure why the alias needs to be explicitly signaled. Why can't the receiving proxy merely make a decision on whether to do this? > The mechanism in this document can significantly improve the security > of SIP networks, in that it makes SIP over TLS (and the sips: scheme) > practical for devices which do not have a certificate rooted in a > well-known certificate authority. this needs to be removed > IANA Considerations > > This document adds a parameter to the SIP header field parameters > registry: you need to cite the URI that defines the registry > 8.1 Normative References > > [1] Jennings, C., Ed. and A. Hawrylyshen, Ed., "SIP Conventions for > Connection Usage", draft-jennings-sipping-outbound-00 (work in > progress), October 2004. why is this a normative requirement? > [2] Rosenberg, J., "Obtaining and Using Globally Routable User Agent > (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", > draft-ietf-sip-gruu-02 (work in progress), July 2004. same with this one Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 9 16:58:42 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24993 for ; Wed, 9 Mar 2005 16:58:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D99FC-00048X-2Z for sip-web-archive@ietf.org; Wed, 09 Mar 2005 17:01:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D999w-0004UT-PY; Wed, 09 Mar 2005 16:56:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D999u-0004UH-8E for sip@megatron.ietf.org; Wed, 09 Mar 2005 16:56:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24842 for ; Wed, 9 Mar 2005 16:55:59 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D99Ca-00044M-5i for sip@ietf.org; Wed, 09 Mar 2005 16:58:48 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 09 Mar 2005 13:53:49 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,151,1107763200"; d="scan'208"; a="166240605:sNHT21120208" Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j29Lr5TM007153; Wed, 9 Mar 2005 13:53:06 -0800 (PST) Received: from [130.129.134.128] (che-vpn-cluster-1-180.cisco.com [10.86.240.180]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AIL03991; Wed, 9 Mar 2005 13:52:36 -0800 (PST) Message-ID: <422F7024.1070101@cisco.com> Date: Wed, 09 Mar 2005 16:52:36 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hisham Khartabil Subject: Re: [Sip] gruu and record-route stripping References: <422F2A80.6010604@cisco.com> <422F5387.4060807@cisco.com> <283d4cebea50548e21a053263445c867@telio.no> In-Reply-To: <283d4cebea50548e21a053263445c867@telio.no> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: 7bit inline. Hisham Khartabil wrote: > > On Mar 9, 2005, at 8:50 PM, Jonathan Rosenberg wrote: > >> >> >> Hisham Khartabil wrote: >> >>> Stripping the record-route will remove (5)(6)(7)(8) and cause the >>> re-invite to go directly from the home proxy for the UAS. I don't >>> know if this is desirable. The Edge proxy is there for a reason. What >>> we really want to eliminate is (6) and (7) and keep (5) and (8). >> >> >> Right. This will still happen. If a proxy wants to be on the path for >> messages from the home proxy towards the client, it needs to put >> itself on the Path header field during the registration. It will be >> the Path header field that determines who gets hit for the second >> round of the loop. > > > The path header determines who get hit the first time round. > Record-Route headers that are inserted in the first invite determine who > gets hit the second time round. No. Not when you use a gruu in the Contact in the 200 OK of the original INVITE. The GRUU spec states that the values of the Path header field are used when you look up the gruu, just like they are used when you look up the AOR. > >> >> >>> Would the home proxy be violating anything if it re-writes the >>> Request-URI before it sends out (5)? (I know I suggested this before >>> but don't remember the rebuttal). >> >> >> Rewrites it to what? To the client URI? That won't work, since the >> edge proxy will usually need to be in the path of the request from the >> network towards the client (for example, it is hold the TCP connection >> to the client). > > > The home proxy re-writes the request-uri to the uri in the contact > header the client registered with. The home proxy still routes the > request to the next route header field. Its too late. By the time the request loops back to the home proxy, there are not more route header fields by definition. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 9 17:35:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27814 for ; Wed, 9 Mar 2005 17:35:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D99p5-0004uQ-Gl for sip-web-archive@ietf.org; Wed, 09 Mar 2005 17:38:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D99el-0008Vk-KB; Wed, 09 Mar 2005 17:27:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D99ek-0008Vc-8G for sip@megatron.ietf.org; Wed, 09 Mar 2005 17:27:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27141 for ; Wed, 9 Mar 2005 17:27:51 -0500 (EST) Received: from voyager.coretrek.no ([212.33.142.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D99hQ-0004hZ-9Y for sip@ietf.org; Wed, 09 Mar 2005 17:30:40 -0500 Received: from localhost (localhost [127.0.0.1]) by voyager.coretrek.no (Postfix) with ESMTP id DCF5AA97B3; Wed, 9 Mar 2005 23:27:43 +0100 (CET) Received: from [130.129.132.244] (wireless-130-129-132-244.ietf62.ietf.org [130.129.132.244]) by voyager.coretrek.no (Postfix) with ESMTP id 25476A97FD; Wed, 9 Mar 2005 23:27:42 +0100 (CET) In-Reply-To: <422F7024.1070101@cisco.com> References: <422F2A80.6010604@cisco.com> <422F5387.4060807@cisco.com> <283d4cebea50548e21a053263445c867@telio.no> <422F7024.1070101@cisco.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <656cee26afdfdb2a9c2619d1c53c1499@telio.no> Content-Transfer-Encoding: 7bit From: Hisham Khartabil Subject: Re: [Sip] gruu and record-route stripping Date: Wed, 9 Mar 2005 23:27:39 +0100 To: Jonathan Rosenberg X-Mailer: Apple Mail (2.619.2) X-Virus-Scanned: by AMaViS perl-11 (CoreTrek clamav patch 1) X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit On Mar 9, 2005, at 10:52 PM, Jonathan Rosenberg wrote: > inline. > > Hisham Khartabil wrote: > >> On Mar 9, 2005, at 8:50 PM, Jonathan Rosenberg wrote: >>> >>> >>> Hisham Khartabil wrote: >>> >>>> Stripping the record-route will remove (5)(6)(7)(8) and cause the >>>> re-invite to go directly from the home proxy for the UAS. I don't >>>> know if this is desirable. The Edge proxy is there for a reason. >>>> What we really want to eliminate is (6) and (7) and keep (5) and >>>> (8). >>> >>> >>> Right. This will still happen. If a proxy wants to be on the path >>> for messages from the home proxy towards the client, it needs to put >>> itself on the Path header field during the registration. It will be >>> the Path header field that determines who gets hit for the second >>> round of the loop. >> The path header determines who get hit the first time round. >> Record-Route headers that are inserted in the first invite determine >> who gets hit the second time round. > > No. Not when you use a gruu in the Contact in the 200 OK of the > original INVITE. > > The GRUU spec states that the values of the Path header field are used > when you look up the gruu, just like they are used when you look up > the AOR.. Ok, I wasn't aware of that detail, sorry. > > >>> >>> >>>> Would the home proxy be violating anything if it re-writes the >>>> Request-URI before it sends out (5)? (I know I suggested this >>>> before but don't remember the rebuttal). >>> >>> >>> Rewrites it to what? To the client URI? That won't work, since the >>> edge proxy will usually need to be in the path of the request from >>> the network towards the client (for example, it is hold the TCP >>> connection to the client). >> The home proxy re-writes the request-uri to the uri in the contact >> header the client registered with. The home proxy still routes the >> request to the next route header field. > > Its too late. By the time the request loops back to the home proxy, > there are not more route header fields by definition. The suggestion is for the home proxy to perform the re-writing the first time it receives the re-invite (flow 4 in your diagram), so flow 5 will contain the client-uri and not the gruu. But now that you make the point above, doing the re-write the first time around the re-invite arrives at the home proxy will cause 2 route headers pointing to the edge proxy to be in place, unless the home proxy is intelligent enough not to do that. Paul, maybe this is the harm that you had a feeling about? /Hisham > > -Jonathan R. > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 10 01:31:12 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10357 for ; Thu, 10 Mar 2005 01:31:12 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9HF9-0006Dr-6u for sip-web-archive@ietf.org; Thu, 10 Mar 2005 01:33:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9H8M-00020q-5B; Thu, 10 Mar 2005 01:26:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9H87-000201-9I for sip@megatron.ietf.org; Thu, 10 Mar 2005 01:26:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09879 for ; Thu, 10 Mar 2005 01:26:42 -0500 (EST) From: innovation.interops@wipro.com Received: from wip-ec-wd.wipro.com ([203.101.113.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9HAp-00067P-Kn for sip@ietf.org; Thu, 10 Mar 2005 01:29:34 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id C685920527 for ; Thu, 10 Mar 2005 11:49:35 +0530 (IST) Received: from blr-ec-bh2.wipro.com (unknown [10.200.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id A548320511 for ; Thu, 10 Mar 2005 11:49:35 +0530 (IST) Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Mar 2005 11:56:30 +0530 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Thu, 10 Mar 2005 11:56:28 +0530 Message-ID: <0966EC230D8BDA4EB06F57075C4DBF8FFDEFB8@blr-k1-msg.wipro.com> Thread-Topic: SUBSCRIBE NOTIFY REQUESTS WITHIN A DIALOG Thread-Index: AcUlOhe4UpCgd5JJQwerUJdSCqy9XA== To: X-OriginalArrivalTime: 10 Mar 2005 06:26:30.0138 (UTC) FILETIME=[189FBDA0:01C5253A] X-Spam-Score: 1.3 (+) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Subject: [Sip] SUBSCRIBE NOTIFY REQUESTS WITHIN A DIALOG X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0023005377==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c This is a multi-part message in MIME format. --===============0023005377== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5253A.17BAC49D" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5253A.17BAC49D Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all, =20 When a SUBSCRIBE NOTIFY's are being sent in an already established = dialog context say an INVITE. =20 What happens to the SUBSCRIBE-NOTIFY requests if the existing dialog = gets terminated by an unexpected BYE? =20 How is it normally handled? =20 Regds ------_=_NextPart_001_01C5253A.17BAC49D Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
=0A=
Hello all,
=0A=
 
=0A=
When = a SUBSCRIBE NOTIFY's are being =0A= sent in an already established dialog context say =0A= an INVITE.
=0A=
 
=0A=
What happens to the SUBSCRIBE-NOTIFY = requests if =0A= the existing dialog gets terminated by an unexpected BYE?
=0A=
 
=0A=
How is it normally handled?
=0A=
 
=0A=
Regds
------_=_NextPart_001_01C5253A.17BAC49D-- --===============0023005377== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0023005377==-- From sip-bounces@ietf.org Thu Mar 10 05:06:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27630 for ; Thu, 10 Mar 2005 05:06:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9KbY-00078J-Jb for sip-web-archive@ietf.org; Thu, 10 Mar 2005 05:09:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9KUR-0000El-49; Thu, 10 Mar 2005 05:01:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9KUO-0000EW-CM for sip@megatron.ietf.org; Thu, 10 Mar 2005 05:01:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26619 for ; Thu, 10 Mar 2005 05:01:53 -0500 (EST) Received: from [67.15.60.3] (helo=mail.aftek.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9KWZ-0006f2-Mg for sip@ietf.org; Thu, 10 Mar 2005 05:04:13 -0500 Received: (qmail 20799 invoked by uid 510); 10 Mar 2005 04:10:55 -0600 Received: from anuragk@aftek.com by plain.ev1servers.net by uid 508 with qmail-scanner-1.22-st-qms (clamdscan: 0.75.1. spamassassin: 2.63. Clear:RC:0(203.129.224.106):SA:0(-104.9/3.0):. Processed in 3.169819 secs); 10 Mar 2005 10:10:55 -0000 X-Spam-Status: No, hits=-104.9 required=3.0 X-Antivirus-MYDOMAIN-Mail-From: anuragk@aftek.com via plain.ev1servers.net X-Antivirus-MYDOMAIN: 1.22-st-qms (Clear:RC:0(203.129.224.106):SA:0(-104.9/3.0):. Processed in 3.169819 secs Process 20785) Received: from unknown (HELO ?10.0.0.169?) (anuragk@aftek.com@203.129.224.106) by mail.aftek.com with SMTP; 10 Mar 2005 04:10:52 -0600 Message-ID: <42301B63.4090606@aftek.com> Date: Thu, 10 Mar 2005 15:33:15 +0530 From: Anurag User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Subject: [Sip] Few questions X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Hello Everyone, I have got few questions from RFC 3261 which are bugging me, so any clarification is appreciated. 1. Why do we need 3 ids (Call-id, from-tag, to-tag) for recognizing the dialog. 2. How is cycle reqest can be found using branch parameter of VIA header. (ie signinficance of branch parameter and magic number) Thanks and Best Regards Anurag. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 10 06:38:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04211 for ; Thu, 10 Mar 2005 06:38:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9M2o-0002kJ-4C for sip-web-archive@ietf.org; Thu, 10 Mar 2005 06:41:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Lwm-0001eS-JR; Thu, 10 Mar 2005 06:35:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Lwj-0001eN-Ox for sip@megatron.ietf.org; Thu, 10 Mar 2005 06:35:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03782 for ; Thu, 10 Mar 2005 06:35:14 -0500 (EST) Received: from mailhost.iperia.com ([204.57.52.4] helo=iperia.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9LzV-0002Yj-Q2 for sip@ietf.org; Thu, 10 Mar 2005 06:38:11 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] SUBSCRIBE NOTIFY REQUESTS WITHIN A DIALOG Date: Thu, 10 Mar 2005 06:35:02 -0500 Message-ID: <8019F8581B5FC14DBD94BAF86844868E54B969@viridis.IPeria.local> Thread-topic: [Sip] SUBSCRIBE NOTIFY REQUESTS WITHIN A DIALOG Thread-index: AcUlOhe4UpCgd5JJQwerUJdSCqy9XAAKuqEw From: "Steve Gardell" To: , X-Spam-Score: 0.8 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0756684574==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f This is a multi-part message in MIME format. --===============0756684574== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C52565.33649F6C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C52565.33649F6C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The SUBSCRIBE establishes a dialog independent of the any INVITE dialogs that the endpoint might be involved with. NOTIFY's should be sent in the context of the SUBSCRIBE dialog. ________________________________ From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of innovation.interops@wipro.com Sent: Thursday, March 10, 2005 1:26 AM To: sip@ietf.org Subject: [Sip] SUBSCRIBE NOTIFY REQUESTS WITHIN A DIALOG Hello all, =20 When a SUBSCRIBE NOTIFY's are being sent in an already established dialog context say an INVITE. =20 What happens to the SUBSCRIBE-NOTIFY requests if the existing dialog gets terminated by an unexpected BYE? =20 How is it normally handled? =20 Regds ------_=_NextPart_001_01C52565.33649F6C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The SUBSCRIBE establishes a dialog independent = of the=20 any
INVITE dialogs that the endpoint might be = involved with.=20 NOTIFY's
should be sent in the context of the SUBSCRIBE=20 dialog.

From: sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org] On Behalf Of=20 innovation.interops@wipro.com
Sent: Thursday, March 10, = 2005 1:26=20 AM
To: sip@ietf.org
Subject: [Sip] SUBSCRIBE NOTIFY = REQUESTS=20 WITHIN A DIALOG

Hello all,
 
When = a SUBSCRIBE NOTIFY's are being=20 sent in an already established dialog context say=20 an INVITE.
 
What happens to the SUBSCRIBE-NOTIFY = requests if=20 the existing dialog gets terminated by an unexpected BYE?
 
How is it normally handled?
 
Regds
------_=_NextPart_001_01C52565.33649F6C-- --===============0756684574== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0756684574==-- From sip-bounces@ietf.org Thu Mar 10 11:03:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28830 for ; Thu, 10 Mar 2005 11:03:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9QAz-0007JN-F2 for sip-web-archive@ietf.org; Thu, 10 Mar 2005 11:06:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Q6Q-0006oC-2s; Thu, 10 Mar 2005 11:01:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Q6N-0006n9-Gp for sip@megatron.ietf.org; Thu, 10 Mar 2005 11:01:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28644 for ; Thu, 10 Mar 2005 11:01:29 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Q9D-0007AE-0Z for sip@ietf.org; Thu, 10 Mar 2005 11:04:27 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 10 Mar 2005 09:18:48 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,153,1107734400"; d="scan'208"; a="233549602:sNHT19787682" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j2AG1JZV028591; Thu, 10 Mar 2005 08:01:19 -0800 (PST) Received: from cisco.com (che-vpn-cluster-1-97.cisco.com [10.86.240.97]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APS10099; Thu, 10 Mar 2005 11:01:17 -0500 (EST) Message-ID: <42306F4D.1000403@cisco.com> Date: Thu, 10 Mar 2005 11:01:17 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] gruu and record-route stripping References: <422F2A80.6010604@cisco.com> <422F43CB.6090106@cisco.com> <422F55A5.8080907@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit I thought about this more. (How the EP knows it should remove itself from the R-R on the response to a dialog establishing request.) I think this is hard. What does it have to work with to make this determination? - the gruu option in the response - the value of the contact URI in the response - the R-URI from the request, or other info from the request (could be saved with transaction state if needed to make the decision) Jonathan Rosenberg wrote: > Paul Kyzivat wrote: >> I've lost track of the prior discussion. How again does the EP know it >> should remove itself from the R-R in the response? Does it do so based >> on a gruu option in the response? > > Yes. If the Supported header field in the response contains the "gruu" > optiong tag. > >> I want to be sure we aren't just >> depending on a different kind of magic to figure that out. The >> decision it has to make is: "the contact contains an address that when >> resolved within the dialog will result in the request being delivered >> to me, with a Route header containing exactly those entries that >> precede mine in the R-R header." I'm having trouble getting it clear >> in my head how many assumptions about the environment it must make to >> reach this conclusion. > > The proxy knows this if it inserted a Path header field in a REGISTER > request from the client. It can know this when the R-URI of the INVITE > which matches a contact which was in a REGISTER that the proxy inserted > a Path into. To do this it needs to determine the following things: - contact in response is gruu - that contact is bound to a path - path contains reference to this proxy How can it figure out these things? - contact is a gruu: can plausibly be discovered by examination of the contact as long as the registrar and the EP have an understanding of how this is done - that the contact is bound to a path and that the path contains a reference to this proxy: This seems to require that the EP keep state of its own relative to registrations that it has proxied. While possible, it doesn't seem like a very appealing approach. Possibly, it there is sufficient coordination between the home proxy and EP, some kind of identification of the proxies in the path could be encoded into the gruu itself, in a way that the EP could detect. This at least requires very close coordination. If it can be made to work at all, it probably won't work in all interesting cases. So my conclusion is that this only works for EPs that are "registration stateful". Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 10 11:15:50 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00480 for ; Thu, 10 Mar 2005 11:15:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9QN3-0007xb-JU for sip-web-archive@ietf.org; Thu, 10 Mar 2005 11:18:48 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9QHv-0000Ju-MK; Thu, 10 Mar 2005 11:13:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9QHt-0000Jl-7n for sip@megatron.ietf.org; Thu, 10 Mar 2005 11:13:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00152 for ; Thu, 10 Mar 2005 11:13:22 -0500 (EST) Received: from mailhost.iperia.com ([204.57.52.4] helo=iperia.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9QKi-0007nz-Sb for sip@ietf.org; Thu, 10 Mar 2005 11:16:21 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] gruu and record-route stripping Date: Thu, 10 Mar 2005 11:13:15 -0500 Message-ID: <8019F8581B5FC14DBD94BAF86844868E54B9B8@viridis.IPeria.local> Thread-topic: [Sip] gruu and record-route stripping Thread-index: AcUlipgOXb/d1jAISiyuwHnsAz4zzAAAP1hw From: "Gordon Ledgard" To: "Paul Kyzivat" , "Jonathan Rosenberg" X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: quoted-printable Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: quoted-printable I have to wonder: is logically splitting the functionality of the Home and Edge proxy a common enough scenario that it warrants mucking with RR just to stop this one-hop loop? Is the transmission/computation time that critical? And do you not now add in a whole new computational complexity on the UA side that defeats the savings? Gordon -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Thursday, March 10, 2005 11:01 AM To: Jonathan Rosenberg Cc: IETF SIP List Subject: Re: [Sip] gruu and record-route stripping I thought about this more. (How the EP knows it should remove itself=20 from the R-R on the response to a dialog establishing request.) I think this is hard. What does it have to work with to make this=20 determination? - the gruu option in the response - the value of the contact URI in the response - the R-URI from the request, or other info from the request (could be saved with transaction state if needed to make the decision) Jonathan Rosenberg wrote: > Paul Kyzivat wrote: >> I've lost track of the prior discussion. How again does the EP know it=20 >> should remove itself from the R-R in the response? Does it do so based=20 >> on a gruu option in the response?=20 >=20 > Yes. If the Supported header field in the response contains the "gruu" > optiong tag. > >> I want to be sure we aren't just >> depending on a different kind of magic to figure that out. The=20 >> decision it has to make is: "the contact contains an address that when=20 >> resolved within the dialog will result in the request being delivered >> to me, with a Route header containing exactly those entries that=20 >> precede mine in the R-R header." I'm having trouble getting it clear=20 >> in my head how many assumptions about the environment it must make to >> reach this conclusion. >=20 > The proxy knows this if it inserted a Path header field in a REGISTER=20 > request from the client. It can know this when the R-URI of the INVITE > which matches a contact which was in a REGISTER that the proxy inserted=20 > a Path into. To do this it needs to determine the following things: - contact in response is gruu - that contact is bound to a path - path contains reference to this proxy How can it figure out these things? - contact is a gruu: can plausibly be discovered by examination of the contact as long as the registrar and the EP have an understanding of how this is done - that the contact is bound to a path and that the path contains a reference to this proxy: This seems to require that the EP keep state of its own relative to registrations that it has proxied. While possible, it doesn't seem like a very appealing approach. Possibly, it there is sufficient coordination between the home proxy and EP, some kind of identification of the proxies in the path could be encoded into the gruu itself, in a way that the EP could detect. This at least requires very close coordination. If it can be made to work at all, it probably won't work in all interesting cases. So my conclusion is that this only works for EPs that are "registration=20 stateful". Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 10 11:39:09 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03295 for ; Thu, 10 Mar 2005 11:39:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Qjf-0000nW-6O for sip-web-archive@ietf.org; Thu, 10 Mar 2005 11:42:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9QZR-0003iZ-M0; Thu, 10 Mar 2005 11:31:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9QZQ-0003ht-Hf for sip@megatron.ietf.org; Thu, 10 Mar 2005 11:31:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02376 for ; Thu, 10 Mar 2005 11:31:29 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9QcG-0000Kk-3N for sip@ietf.org; Thu, 10 Mar 2005 11:34:28 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-5.cisco.com with ESMTP; 10 Mar 2005 08:31:52 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,154,1107763200"; d="scan'208"; a="166464208:sNHT9375451224" Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2AGVGuC028800; Thu, 10 Mar 2005 08:31:16 -0800 (PST) Received: from [130.129.134.128] (che-vpn-cluster-1-72.cisco.com [10.86.240.72]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AIL63064; Thu, 10 Mar 2005 08:31:14 -0800 (PST) Message-ID: <42307650.8040307@cisco.com> Date: Thu, 10 Mar 2005 11:31:12 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gordon Ledgard Subject: Re: [Sip] gruu and record-route stripping References: <8019F8581B5FC14DBD94BAF86844868E54B9B8@viridis.IPeria.local> In-Reply-To: <8019F8581B5FC14DBD94BAF86844868E54B9B8@viridis.IPeria.local> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: 7bit Cc: IETF SIP List , Paul Kyzivat X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Content-Transfer-Encoding: 7bit I think its a fairly common design. 3gpp, for example, has this split (the S-CSCF and the P-CSCF). I'm aware of multiple network deployments that have this topology as well. I don't think there is any extra work in the UA to make this work. What UA work do you see? -Jonathan R. Gordon Ledgard wrote: > > I have to wonder: is logically splitting the functionality of the Home > and Edge proxy a common enough scenario that it warrants mucking with RR > just to stop this one-hop loop? Is the transmission/computation time > that critical? > And do you not now add in a whole new computational complexity on the UA > side that defeats the savings? > > Gordon > > > > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Thursday, March 10, 2005 11:01 AM > To: Jonathan Rosenberg > Cc: IETF SIP List > Subject: Re: [Sip] gruu and record-route stripping > > I thought about this more. (How the EP knows it should remove itself > from the R-R on the response to a dialog establishing request.) > > I think this is hard. What does it have to work with to make this > determination? > - the gruu option in the response > - the value of the contact URI in the response > - the R-URI from the request, or other info from the request > (could be saved with transaction state if needed to make > the decision) > > > > Jonathan Rosenberg wrote: > >>Paul Kyzivat wrote: > > >>>I've lost track of the prior discussion. How again does the EP know > > it > >>>should remove itself from the R-R in the response? Does it do so > > based > >>>on a gruu option in the response? >> >>Yes. If the Supported header field in the response contains the "gruu" > > >>optiong tag. >> >> >>>I want to be sure we aren't just >>>depending on a different kind of magic to figure that out. The >>>decision it has to make is: "the contact contains an address that > > when > >>>resolved within the dialog will result in the request being delivered > > >>>to me, with a Route header containing exactly those entries that >>>precede mine in the R-R header." I'm having trouble getting it clear >>>in my head how many assumptions about the environment it must make to > > >>>reach this conclusion. >> >>The proxy knows this if it inserted a Path header field in a REGISTER >>request from the client. It can know this when the R-URI of the INVITE > > >>which matches a contact which was in a REGISTER that the proxy > > inserted > >>a Path into. > > > To do this it needs to determine the following things: > - contact in response is gruu > - that contact is bound to a path > - path contains reference to this proxy > > How can it figure out these things? > > - contact is a gruu: can plausibly be discovered by examination > of the contact as long as the registrar and the EP have an > understanding of how this is done > > - that the contact is bound to a path > and that the path contains a reference to this proxy: > > This seems to require that the EP keep state of its > own relative to registrations that it has proxied. > While possible, it doesn't seem like a very > appealing approach. > > Possibly, it there is sufficient coordination between > the home proxy and EP, some kind of identification > of the proxies in the path could be encoded into the > gruu itself, in a way that the EP could detect. This > at least requires very close coordination. If it can > be made to work at all, it probably won't work in > all interesting cases. > > So my conclusion is that this only works for EPs that are "registration > stateful". > > Paul > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 10 11:55:02 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05161 for ; Thu, 10 Mar 2005 11:55:02 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Qz2-0001hA-L3 for sip-web-archive@ietf.org; Thu, 10 Mar 2005 11:58:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Qqq-0007cb-UZ; Thu, 10 Mar 2005 11:49:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9Qqp-0007bB-9q for sip@megatron.ietf.org; Thu, 10 Mar 2005 11:49:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04565 for ; Thu, 10 Mar 2005 11:49:28 -0500 (EST) Received: from dida04.deis.unibo.it ([137.204.56.4] helo=evaristo.deis.unibo.it) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Qtd-0001Nx-VU for sip@ietf.org; Thu, 10 Mar 2005 11:52:27 -0500 Received: from [137.204.57.162] (deis162.deis.unibo.it [137.204.57.162]) by evaristo.deis.unibo.it (8.13.1/8.13.1) with ESMTP id j2AGnFQ7002938 for ; Thu, 10 Mar 2005 17:49:15 +0100 Message-ID: <42307A8C.50804@studio.unibo.it> Date: Thu, 10 Mar 2005 17:49:16 +0100 From: Luca Foschini User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Subject: [Sip] Question about SDP X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Hi all, I'm a newby, so please forgive me if my question is stupid. I would like to use SDP to initially exchange information about my client device while establishing a session. I know it's possible, by using SDP, to exchange available codecs, ports, mime types, etc. Nonetheless, I would like to exchange other information related to the hardware of the client device. In particular, the memory (RAM) the client want to dedicate to the session and information about its Wi-Fi card (assuming the client device has got one). Which SDP attribute could I use to express this kind of information? In case SDP is not the right choice what could I use to do this within the SIP framework? Thanks for your patience. Best regards, Luca _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 10 14:46:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24969 for ; Thu, 10 Mar 2005 14:46:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Tea-0002bF-Ql for sip-web-archive@ietf.org; Thu, 10 Mar 2005 14:49:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9TUG-0006Fn-K1; Thu, 10 Mar 2005 14:38:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9TUD-0006F5-2A; Thu, 10 Mar 2005 14:38:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23014; Thu, 10 Mar 2005 14:38:19 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9TX4-0001t4-MG; Thu, 10 Mar 2005 14:41:18 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1D9TUC-0003P7-EQ; Thu, 10 Mar 2005 14:38:20 -0500 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Thu, 10 Mar 2005 14:38:20 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: sip@ietf.org Subject: [Sip] Last Call: 'Actions addressing identified issues with the Session Initiation Protocol's non-INVITE Transaction' to Proposed Standard X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@ietf.org List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 The IESG has received a request from the Session Initiation Protocol WG to consider the following documents: - 'Actions addressing identified issues with the Session Initiation Protocol's non-INVITE Transaction ' as a Proposed Standard - 'Problems identified associated with the Session Initiation Protocol's non-INVITE Transaction ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2005-03-24. The file can be obtained via http://www.ietf.org/internet-drafts/draft-sparks-sip-nit-actions-03.txt http://www.ietf.org/internet-drafts/draft-sparks-sip-nit-problems-02.txt _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 11 14:19:20 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27707 for ; Fri, 11 Mar 2005 14:19:20 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9piQ-000533-B6 for sip-web-archive@ietf.org; Fri, 11 Mar 2005 14:22:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9pXD-0002cS-Bl; Fri, 11 Mar 2005 14:10:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9pXA-0002cE-QG; Fri, 11 Mar 2005 14:10:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26585; Fri, 11 Mar 2005 14:10:51 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9paE-0004TQ-KV; Fri, 11 Mar 2005 14:14:03 -0500 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id j2BJ9o615239; Fri, 11 Mar 2005 11:09:50 -0800 (PST) Message-Id: <200503111909.j2BJ9o615239@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 11 Mar 2005 11:09:50 -0800 X-ISI-4-39-6-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: sip@ietf.org, rfc-editor@rfc-editor.org Subject: [Sip] RFC 4032 on Update to the Session Initiation Protocol (SIP) Preconditions Framework X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: -14.6 (--------------) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e --NextPart A new Request for Comments is now available in online RFC libraries. RFC 4032 Title: Update to the Session Initiation Protocol (SIP) Preconditions Framework Author(s): G. Camarillo, P. Kyzivat Status: Standards Track Date: March 2005 Mailbox: Gonzalo.Camarillo@ericsson.com, pkyzivat@cisco.com Pages: 10 Characters: 20492 Updates: 3312 I-D Tag: draft-ietf-sip-rfc3312-update-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4032.txt This document updates RFC 3312, which defines the framework for preconditions in SIP. We provide guidelines for authors of new precondition types and describe how to use SIP preconditions in situations that involve session mobility. This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <050311110824.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc4032 --OtherAccess Content-Type: Message/External-body; name="rfc4032.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <050311110824.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Fri Mar 11 18:07:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16599 for ; Fri, 11 Mar 2005 18:07:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9tHP-0007kh-6d for sip-web-archive@ietf.org; Fri, 11 Mar 2005 18:10:51 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9t9C-0002ch-1r; Fri, 11 Mar 2005 18:02:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9t9A-0002bq-3l for sip@megatron.ietf.org; Fri, 11 Mar 2005 18:02:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15860 for ; Fri, 11 Mar 2005 18:02:17 -0500 (EST) Received: from grads.ece.mcmaster.ca ([130.113.10.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9tCE-0007Ss-W5 for sip@ietf.org; Fri, 11 Mar 2005 18:05:32 -0500 Received: from [192.168.2.8] ([130.113.184.38]) by grads.ece.mcmaster.ca (8.12.8/8.12.8) with ESMTP id j2BN1GF4017884 for ; Fri, 11 Mar 2005 18:01:16 -0500 Message-ID: <42322394.90504@grads.ece.mcmaster.ca> Date: Fri, 11 Mar 2005 18:02:44 -0500 From: "M.N.A.Smadi" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Subject: [Sip] NOTIFY context X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit hi can i use NOTIFY to exchange event dependent information between two user agents? by event dependent i mean something local to the two agents involved in the call or possible for a 3rd party call observer. thanks m.smadi _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 11 22:54:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10250 for ; Fri, 11 Mar 2005 22:54:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9xlK-000462-Vq for sip-web-archive@ietf.org; Fri, 11 Mar 2005 22:58:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9xeL-0005gA-8k; Fri, 11 Mar 2005 22:50:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9xeI-0005de-Tt for sip@megatron.ietf.org; Fri, 11 Mar 2005 22:50:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10006 for ; Fri, 11 Mar 2005 22:50:44 -0500 (EST) Received: from grads.ece.mcmaster.ca ([130.113.10.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9xhP-0003qA-Ok for sip@ietf.org; Fri, 11 Mar 2005 22:54:01 -0500 Received: from [192.168.2.8] ([130.113.184.38]) by grads.ece.mcmaster.ca (8.12.8/8.12.8) with ESMTP id j2C3nfF4020789 for ; Fri, 11 Mar 2005 22:49:41 -0500 Message-ID: <4232672D.5050901@grads.ece.mcmaster.ca> Date: Fri, 11 Mar 2005 22:51:09 -0500 From: "M.N.A.Smadi" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Subject: [Sip] locating registrars (SLP or multicast) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit hi; what is the standard procedure for locating registrar server. am reading about a procol that is called SLP but cannot seem to find an rfc for it. thanks m.smadi _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 11 23:51:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14060 for ; Fri, 11 Mar 2005 23:51:06 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9yds-0006kX-8L for sip-web-archive@ietf.org; Fri, 11 Mar 2005 23:54:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9yYd-000812-P9; Fri, 11 Mar 2005 23:48:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9yYU-000804-RV for sip@megatron.ietf.org; Fri, 11 Mar 2005 23:48:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA13927 for ; Fri, 11 Mar 2005 23:48:48 -0500 (EST) Received: from rproxy.gmail.com ([64.233.170.195]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9ybc-0006bm-ST for sip@ietf.org; Fri, 11 Mar 2005 23:52:06 -0500 Received: by rproxy.gmail.com with SMTP id a41so994815rng for ; Fri, 11 Mar 2005 20:48:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=pHL2j5qfqsKcqL8HLwF8kuLLFDoce7nCPmY2DmezwSlzZpOGjHU7UMN3lXn1L5ME19yKZtRRTFFi4d1AYx93yNctzPJMcE5tXQM3vjHP1dbu0vUwQPaubxI+cgFHOarFgwMYRS/9KHbB3p0Ogf6Olyt+B8hJa/iW0eO9WkGFo/w= Received: by 10.38.81.1 with SMTP id e1mr3296581rnb; Fri, 11 Mar 2005 20:22:05 -0800 (PST) Received: by 10.38.72.14 with HTTP; Fri, 11 Mar 2005 20:22:05 -0800 (PST) Message-ID: Date: Fri, 11 Mar 2005 22:22:05 -0600 From: yaronp To: "M.N.A.Smadi" Subject: Re: [Sip] locating registrars (SLP or multicast) In-Reply-To: <4232672D.5050901@grads.ece.mcmaster.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4232672D.5050901@grads.ece.mcmaster.ca> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yaronp List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Try "RFC 3263 - Session Initiation Protocol (SIP): Locating SIP Servers" and "Service Location Protocol, Version 2 (RFC 2608)" On Fri, 11 Mar 2005 22:51:09 -0500, M.N.A.Smadi wrote: > hi; > > what is the standard procedure for locating registrar server. am > reading about a procol that is called SLP but cannot seem to find an rfc > for it. > > thanks > m.smadi > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 13 08:00:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04636 for ; Sun, 13 Mar 2005 08:00:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DASkq-0007Ru-DS for sip-web-archive@ietf.org; Sun, 13 Mar 2005 08:03:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DASg8-00052J-9l; Sun, 13 Mar 2005 07:58:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DASg6-00052B-6L for sip@megatron.ietf.org; Sun, 13 Mar 2005 07:58:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04534 for ; Sun, 13 Mar 2005 07:58:41 -0500 (EST) Received: from tiere.net.avaya.com ([198.152.12.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DASjV-0007LA-Av for sip@ietf.org; Sun, 13 Mar 2005 08:02:14 -0500 Received: from tiere.net.avaya.com (localhost [127.0.0.1]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j2DCuR4X010922 for ; Sun, 13 Mar 2005 07:56:27 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tiere.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j2DCuP4X010902 for ; Sun, 13 Mar 2005 07:56:26 -0500 (EST) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 13 Mar 2005 14:57:44 +0200 Message-ID: Thread-Topic: Question about registration on behalf Thread-index: AcUk9FxAlewdaNbwQxmiHre2ElusIQC1Z7Ew From: "Galron, Dror \(Dror\)" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Subject: [Sip] Question about registration on behalf X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Question about registration on behalf: I need to implement a system which uses the 'registration on behalf' mechanism for the same domain.=20 1. What is the common practice for registration on behalf? 2. What is the authentication scheme? And how the two registrars know to authenticate the user? 3. Is it legal for the intermediate registrar to fake the authentication, presuming it knows the users passwords? Thanks, Dror=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 13 15:52:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09742 for ; Sun, 13 Mar 2005 15:52:04 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAa7h-0006iq-Ej for sip-web-archive@ietf.org; Sun, 13 Mar 2005 15:55:42 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAa11-0000yW-Vx; Sun, 13 Mar 2005 15:48:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAa10-0000yR-Hx for sip@megatron.ietf.org; Sun, 13 Mar 2005 15:48:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09450 for ; Sun, 13 Mar 2005 15:48:44 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAa4U-0006bp-IY for sip@ietf.org; Sun, 13 Mar 2005 15:52:23 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 13 Mar 2005 13:04:45 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,160,1107763200"; d="scan'208"; a="619138600:sNHT22058452" Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j2DKmZZV004467 for ; Sun, 13 Mar 2005 12:48:35 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-242.cisco.com [10.86.240.242]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AIN54056; Sun, 13 Mar 2005 12:48:33 -0800 (PST) Message-ID: <4234A721.9020207@cisco.com> Date: Sun, 13 Mar 2005 15:48:33 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: 7bit Subject: [Sip] GRUU, AORs, and identity, oh my! X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: 7bit Following the mostly inconclusive discussion during the SIP meeting on GRUUs, their relationship to identity, and the ability to extract the AOR from a GRUU, a few folks (including myself, Paul K., Rohan, Cullen and Jon P. for a bit) tried to sort it out and come up with a path forward that might be acceptable. The discussion was very fruitful and resulted in a proposal for a path forward that I think is good. If folks with an interest can respond, on the list or privately, if they think this is a good path, it would be great. I'd really like to wrap this work, a lot of things are dependent on it. Proposal: URIs have properties. Those properties are granted to the URI based on policies of the domain, and genreally those properties are not visible by inspection of the URI. There are a few properties in play here: The "AOR" property: A URI has the AOR property (i.e., is an AOR) if a domain will allow it to appear in the To header field of REGISTER request. The alias property: A URI is an alias if its treatment by the domain is identical to another URI. The GRUU property: A URI is hsa the GRUU property if it routes to a particular UA instance. The service treatment property: A URI has the service treatment property if the domain will apply applications, features, and services to calls made by, or made to, that URI, possibly based on associating that URI with a user that has "subscribed" to various features. The anonymous property: A URI has the anonymous property when it is not possible, by inspection of the URI, to discern the user with whom the URI is associated. The identity property: A URI is considered an identity when it is one that the domain will authorize as a valid value in the From header field of a request. A URI can have any combination of these properties. The URI returned by the registrar in the gruu Contact header field parameter of a REGISTER response is required to have the gruu property, and thats it. It would be RECOMMENDED that it also have the service treatment property, however, the specific services applied to that URI need not match those provided to the AOR with which the URI is associated; this is a domain policy decision. The spec would advise that it might be a good idea to apply features like screening (but not forwarding) for requests targeted to the GRUU. The domain could associate other properties with the URI, but that would be outside the scope of the GRUU spec. URIs with the GRUU property obtained in ways other than registrations (like a provisioned URI for a gateway) need not have the service treatment property either. It is fundamental that the domain be able to create the URI that has the GRUU property. It needs to be able to do this so it can be constructed in a way that allows the domain to be able to route it to the places it needs to be routed, and to have other properties which the domain would like to associate with the URI. It is thus essential that, when a client requires a URI with the GRUU property associated with one of its registered contacts, that it be obtained by having the domain hand the URI to the user agent. It is not acceptable for the UA to simply construct the URI (for example, by appending an instance parmeter to their AOR). For similar reasons, usage of the caller prefernces mechanisms to achieve the desired effect (route a call to a particular instance), does not work. It depends on someone else constructing a URI that interacts with domain processing logic for an AOR, to cause it to route to a particular instance. Given the variability in routing logic in a domain (for example, time based routing to only selected contacts), this doesn't work. Furthermore, there is a desire to be able to construct URIs that have the GRUU property by separating the URI into a component that identifies the AOR associated with the instance (when such an association exists), and a component that contains domain-generated context it uses to affect routing and processing of the URI so it goes to the specific instance. As argued above, it is essential that a domain be able to create and manage this context. Thus, such a separation can be achieved by creating a URI parameter that is analagous to the grid parameter, but for the domain provider. Call this the "opaque" URI parameter. That is, the grid parameter provides context to the UA, so that when it receives a request made to the URI, it can use the grid as context. The opaque URI parameter provides context to the domain, so that when the domain proxy receives a request made to the URI, it can use the opaque parameter as context. With this definition, the opaque parameter need not even be restricted to usage with gruus. The gruu property is NOT based on the presence of the opaque parameter. It is signaled through, for example, the Supported header field in an INVITE/200 OK, as defined today in the gruu specification. The opaque parameter allows a domain to hand out a URI that allows it to be correlated with an AOR, in that a recipient could extract the AOR from the URI (by stripping the opaque parameter). However, the way in which the URI is correlated with the AOR is up to domain policy. In the case of GRUU, the policy is that it routes to a particular instance. There is no requirement that a domain use the opaque parameter to provide a URI with GRUU properties. A domain that, for example, also requires the URI to have an anonymous property, may not be able to do that. Returning a URI in the gruu contact header field of the REGISTER response that uses the opaque parameter would be a MAY. Furthermore, the scope of the REGISTER mechanism in the gruu spec is concerned entirely with returning URIs with the gruu property. There is a need to ask a domain to mint URIs with other properties, such as anonmyous. Mechanisms for that kind of minting are outside the scope of the gruu spec. Because the domain can decide whether or not the URI returned in the REGISTER response has other properties, it might allow it to have the identity property, or it might not. There are no guarantees, and so, ouside of other mechanisms for signaling that the URI has the identity property, the recipient of the URI cannot assume it is a valid identity. Nothing can prevent the UA from trying, and thus inserting the GRUU into the From header field of an INVITE. Whether or not the domain would then insert the Identity header field would depend on domain policy. Based on this analysis, I would suggest updating the GRUU spec to include the above. I think it is not unreasonable to include the more abstract discussion on URI properties, including the definition of AOR, though I would prefer that the identity definition be moved into draft-ietf-sip-identity and thus a reference be provided from the GRUU spec. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 13 16:12:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11105 for ; Sun, 13 Mar 2005 16:12:42 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAaRh-0007ZD-Bl for sip-web-archive@ietf.org; Sun, 13 Mar 2005 16:16:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAaLE-0002z3-5w; Sun, 13 Mar 2005 16:09:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAaLC-0002xg-N4 for sip@megatron.ietf.org; Sun, 13 Mar 2005 16:09:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10928 for ; Sun, 13 Mar 2005 16:09:36 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAaOg-0007Sk-Ud for sip@ietf.org; Sun, 13 Mar 2005 16:13:15 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-2.cisco.com with ESMTP; 13 Mar 2005 13:24:30 -0800 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j2DL9RYO001474; Sun, 13 Mar 2005 13:09:27 -0800 (PST) Received: from [192.168.1.100] (che-vpn-cluster-1-242.cisco.com [10.86.240.242]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AIN54417; Sun, 13 Mar 2005 13:09:26 -0800 (PST) Message-ID: <4234AC06.5000609@cisco.com> Date: Sun, 13 Mar 2005 16:09:26 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] gruu and record-route stripping References: <422F2A80.6010604@cisco.com> <422F43CB.6090106@cisco.com> <422F55A5.8080907@cisco.com> <42306F4D.1000403@cisco.com> In-Reply-To: <42306F4D.1000403@cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Content-Transfer-Encoding: 7bit I've thought about this more, and have come up with several ways that the proxy can know whether or not the contact in the 200 OK is a GRUU that routes to a contact for which this proxy "pathed" (i.e., inserted a Path into a REGSITER with that contact). All of the approaches rely on the following trick. When the client sends a REGISTER message, a proxy on the path of the registration which inserts a Path, constructs that Path so that it contains an encoded form of the AOR, instance ID and contact URI. When an incoming request arrives for that user, it arrives at the home proxy. The home proxy translates the request URI, placing the contact URI into the r-uri, and inserting a Route header field containing the path URI from the edge proxy. This arrives at the edge proxy, which notes the Route header field value. It now knows the AOR, instance ID and contact URI for the user being reached. It then record-routes. When the 200 OK to the INVITE arrives, if the response has a Supported: gruu header field, it means that the response has a gruu in the Contact. The proxy notes that too. Now, the question the proxy has to answer is this. Does the GRUU in the Contact equal the one that the domain has associated with the AOR and instance ID noted by the proxy? I can think of a few ways to determine this: 1. The edge proxy can query the registrar with a REGISTER with no contacts, and a To equal to the AOR. The REGISTER response will indicate the gruu's and instance IDs. The edge proxy can then check this against the information it extracted from Route, and determine whether it had path'd this registration. 2. If the home and edge proxies are from the same vendor, the edge proxy can run the same algorithm used by the home proxy to create the gruu, and check it. A slightly different tact is this: 3. We mandate that, if a client supports gruu, not only does it place *a* gruu into the Contact of an INVITE or 200 OK, but further, it has to be *the* GRUU associated with the AOR and instance ID making/receiving the call. If this happened, it makes it really easy for a proxy to figure out whether to remove the record-route. It would use the same trick above, but need only shove the contact URI into the Path header field. The proxy can compare this to the request-URI of the incoming request. If they match, and if the 200 OK to the INVITE contained a supported: gruu, the proxy knows it can remove the record-route. Also, it occurs to me that we've been discussing all of this only in the context of incoming requests. But, for an outgoing request, its similar. the proxy has to avoid record-routing the request, and only place its RR into the response, when the caller has a GRUU in its contact field. -Jonathan R. Paul Kyzivat wrote: > I thought about this more. (How the EP knows it should remove itself > from the R-R on the response to a dialog establishing request.) > > I think this is hard. What does it have to work with to make this > determination? > - the gruu option in the response > - the value of the contact URI in the response > - the R-URI from the request, or other info from the request > (could be saved with transaction state if needed to make > the decision) > > > > Jonathan Rosenberg wrote: > >> Paul Kyzivat wrote: > > >>> I've lost track of the prior discussion. How again does the EP know >>> it should remove itself from the R-R in the response? Does it do so >>> based on a gruu option in the response? >> >> >> Yes. If the Supported header field in the response contains the "gruu" >> optiong tag. >> >>> I want to be sure we aren't just >>> depending on a different kind of magic to figure that out. The >>> decision it has to make is: "the contact contains an address that >>> when resolved within the dialog will result in the request being >>> delivered to me, with a Route header containing exactly those entries >>> that precede mine in the R-R header." I'm having trouble getting it >>> clear in my head how many assumptions about the environment it must >>> make to reach this conclusion. >> >> >> The proxy knows this if it inserted a Path header field in a REGISTER >> request from the client. It can know this when the R-URI of the INVITE >> which matches a contact which was in a REGISTER that the proxy >> inserted a Path into. > > > To do this it needs to determine the following things: > - contact in response is gruu > - that contact is bound to a path > - path contains reference to this proxy > > How can it figure out these things? > > - contact is a gruu: can plausibly be discovered by examination > of the contact as long as the registrar and the EP have an > understanding of how this is done > > - that the contact is bound to a path > and that the path contains a reference to this proxy: > > This seems to require that the EP keep state of its > own relative to registrations that it has proxied. > While possible, it doesn't seem like a very > appealing approach. > > Possibly, it there is sufficient coordination between > the home proxy and EP, some kind of identification > of the proxies in the path could be encoded into the > gruu itself, in a way that the EP could detect. This > at least requires very close coordination. If it can > be made to work at all, it probably won't work in > all interesting cases. > > So my conclusion is that this only works for EPs that are "registration > stateful". > > Paul > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 13 23:27:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11696 for ; Sun, 13 Mar 2005 23:27:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAhEZ-0004tX-PV for sip-web-archive@ietf.org; Sun, 13 Mar 2005 23:31:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAh99-0000r9-0M; Sun, 13 Mar 2005 23:25:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAh96-0000qL-Bl for sip@megatron.ietf.org; Sun, 13 Mar 2005 23:25:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11542 for ; Sun, 13 Mar 2005 23:25:33 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAhCe-0004lE-GD for sip@ietf.org; Sun, 13 Mar 2005 23:29:17 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 13 Mar 2005 20:41:38 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,160,1107763200"; d="scan'208"; a="619171802:sNHT22423088" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j2E4PNZV028680; Sun, 13 Mar 2005 20:25:24 -0800 (PST) Received: from cisco.com (che-vpn-cluster-2-3.cisco.com [10.86.242.3]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APT94657; Sun, 13 Mar 2005 23:25:22 -0500 (EST) Message-ID: <42351232.2070004@cisco.com> Date: Sun, 13 Mar 2005 23:25:22 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis , Rohan Mahy Content-Type: text/plain; charset=windows-1252; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id XAA11542 Cc: IETF SIP List Subject: [Sip] Draft Minutes: SIP WG - IETF-62 =?windows-1252?q?=96_March_7=2C_2?= =?windows-1252?q?005?= X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Content-Transfer-Encoding: quoted-printable Draft Minutes: SIP WG - IETF-62 =96 March 7, 2005 Scribe: Paul Kyzivat o GRUU Issues (draft-ietf-sip-gruu-03.txt) Jonathan Rosenberg It was pointed out that the UML diagram in the current version has some=20 incorrect cardinalities. Jonathan said he would fix. Jonathan explained=20 changes around support of SIPS GRUUs - it is now as good, and bad, as=20 3261 itself. Need to write a draft clarifying how to handle SIPS in 3261. The new version changed the handling when a new contact is registered=20 with the same instance id as an already registered contact. It now=20 automatically removes the earlier registration. The draft points out=20 this provides a convenient way to unregister any contact with a=20 particular instance id. It was pointed out by someone that this=20 "feature" will probably be broken by the extension elsewhere to allow=20 multiple contacts with same instance id. There was suggestion to soften=20 the description of this feature. Jonathan highlighted an issue of Record-Route between edge and home=20 proxies and looping around gruu. Concern was raised about rewriting the=20 R-R even though 3261 allows this in some cases. Discussed alternatives,=20 but didn=92t resolve. That is TBD - discuss on list. Discussed issue about getting AOR from gruu - why this is/isn=92t a need.= =20 Objections were raised to the proposed compromise in the draft. Various=20 other alternatives discussed. Cullen Jennings didn't see a compelling=20 reason for it. Paul Kyzivat said he no longer found this a need-=20 solutions other than GRUU were sufficient. Aki Niemi and Orit Levin=20 still expressed a desire for this feature. Dean, as chair, said we have=20 no requirement for this, and a domain can do it anyway if it wants. Discussed relationship of identity to gruu. Jon Peterson thought a gruu=20 isn=92t an identity. Discussion halted without resolution due to time.=20 Need to work this offline. o Non invite xactions (draft-sparks-sip-nit-future-01.txt) Robert Sparks Agreed not to pursue Alternative B. Agreed that the Timeleft alternative was also not worth pursuing. Success/failure caching: Robert said we didn=92t have a way to tell when=20 something becomes available. But Jonathan Rosenberg suggested that the=20 Jennings outbound draft (draft-jennings-sipping-outbound-01.txt)=20 provides a way to do this =96 via sending STUN keepalives. [ED: this is what I wrote, but it now doesn't make sense to me.] Something about a =93try again later=94 mechanism. Conclude the group do= es=20 want to continue to pursue a general mechanism for this. Robert Sparks=20 proposed using a blacklist for now. Rohan Mahy proposed replacing this=20 with a =93push to back=94 mechanism, because it works even if there is on= ly=20 one alternative. Rohan, as chair, asked to defer liveness testing to the=20 list. o REFER Extensions (draft-ietf-sip-refer-with-norefersub-01.txt) Orit Levin There was a question about how refer issuer knows if it can use this=20 feature. Various alternatives shown. Jonathan Rosenberg argued why using=20 Supported has wrong semantics. Sent team out of the room to work on this. Decision from the team: keep option tag, add header field used in=20 request to ask for the feature and in response to acknowledge it.=20 Discourage use of Require of the option. o Identity -- Request (draft-ietf-sip-identity-04.txt) =96 Jon Peterson Issue raised about what proxy should do if it gets one of the new=20 responses. Concluded that the identity server should be able to retry=20 the request with correction applied. And, if there is a forking proxy=20 beyond an identity server, it should choose recoverable errors to=20 forward back in order that identithy server may recover. Discussed the importance of signature including the display name.=20 Decided that signing over the display name will be done. There had been a special case that identity is not applied to REGISTER.=20 Jonathan Rosenberg showed case where it was useful. So it will be made=20 legal. o Identity -- Response (draft-peterson-message-identity-00.txt) Jon Peterson Jon presented alternative ways forward. Jonathan Rosenberg said major=20 threat is if someone fakes a connected party id, assuming we had that,=20 and that such is a requirement. Rohan Mahy thought History-Info is the=20 right solution and said he plans to write up something about it. o SIP Resource Priority (draft-ietf-sip-resource-priority-06.txt) James Polk James noted that this is two weeks shy of the 5th anniversary of this=20 draft. Version -07 to be published next week. They hope to WGLC it. o Accept-Disposition (draft-camarillo-sip-accept-diposition-00.txt) Gonzalo Camarillo Lots of discussion about this. Rather than pursue this approach, for the=20 application (exploder) that stimulated this draft there was a decision=20 to use an option tag to negotiate support for the needed combination of=20 features. Separately, there was interest by some (at least Gonzalo and Paul) in=20 starting to investigate the underspecification of Content-Disposition. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 14 01:58:19 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26906 for ; Mon, 14 Mar 2005 01:58:19 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAjaU-00025Q-JD for sip-web-archive@ietf.org; Mon, 14 Mar 2005 02:02:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAjWH-0000PK-2k; Mon, 14 Mar 2005 01:57:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAjWE-0000Ou-DA for sip@megatron.ietf.org; Mon, 14 Mar 2005 01:57:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26860 for ; Mon, 14 Mar 2005 01:57:36 -0500 (EST) From: innovation.interops@wipro.com Received: from wip-ec-wd.wipro.com ([203.101.113.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAjZm-00024W-IK for sip@ietf.org; Mon, 14 Mar 2005 02:01:20 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id A2E3C20524 for ; Mon, 14 Mar 2005 12:20:25 +0530 (IST) Received: from blr-ec-bh2.wipro.com (unknown [10.200.50.92]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 86F422051C for ; Mon, 14 Mar 2005 12:20:25 +0530 (IST) Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-ec-bh2.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 14 Mar 2005 12:27:25 +0530 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 14 Mar 2005 12:27:23 +0530 Message-ID: <0966EC230D8BDA4EB06F57075C4DBF8FFDEFBA@blr-k1-msg.wipro.com> Thread-Topic: PUSH TO TALK SERVICES Thread-Index: AcUoYxLwUKdAZLb+Rv6uaiklQVZtIQ== To: X-OriginalArrivalTime: 14 Mar 2005 06:57:25.0273 (UTC) FILETIME=[1405E090:01C52863] X-Spam-Score: 1.0 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [Sip] PUSH TO TALK SERVICES X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1573491230==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 This is a multi-part message in MIME format. --===============1573491230== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C52863.12F27615" This is a multi-part message in MIME format. ------_=_NextPart_001_01C52863.12F27615 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, =20 Is there a seperate spec published for SIP based Push-to-talk services? =20 Where can I find more information on the SIP based Push-to-talk = services? =20 Regds =20 ------_=_NextPart_001_01C52863.12F27615 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello,
=0A=
 
=0A=
Is there a seperate spec published for = SIP based =0A= Push-to-talk services?
=0A=
 
=0A=
Where can I find more information on = the SIP based =0A= Push-to-talk services?
=0A=
 
=0A=
Regds
=0A=
 
------_=_NextPart_001_01C52863.12F27615-- --===============1573491230== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1573491230==-- From sip-bounces@ietf.org Mon Mar 14 05:48:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12627 for ; Mon, 14 Mar 2005 05:48:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAnBD-00035A-7f for sip-web-archive@ietf.org; Mon, 14 Mar 2005 05:52:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAn3o-00045i-MV; Mon, 14 Mar 2005 05:44:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAn3m-00045W-SX for sip@megatron.ietf.org; Mon, 14 Mar 2005 05:44:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11552 for ; Mon, 14 Mar 2005 05:44:27 -0500 (EST) Received: from v-mail.vsnl.com ([202.54.117.17] helo=vmail.vsnl.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAn7M-0002iR-Qx for sip@ietf.org; Mon, 14 Mar 2005 05:48:14 -0500 Received: from rajeewsingh ([127.0.0.1]) by vmail.vsnl.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with SMTP id <0IDC004LP8HSC1@vmail.vsnl.com> for sip@ietf.org; Mon, 14 Mar 2005 16:14:17 +0530 (IST) Received: from ([tataelxsi.co.in (203.197.169.11)]) by vmail.vsnl.com (InterScan E-Mail VirusWall Unix); Mon, 14 Mar 2005 16:14:17 +0530 (IST) Date: Mon, 14 Mar 2005 16:14:54 +0530 From: Rajeew Kumar Singh Subject: RE: [Sip] PUSH TO TALK SERVICES In-reply-to: <0966EC230D8BDA4EB06F57075C4DBF8FFDEFBA@blr-k1-msg.wipro.com> To: innovation.interops@wipro.com, sip@ietf.org Message-id: <001301c52882$dc8dfec0$9e19320a@telxsi.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.3 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: rajeewsingh@tataelxsi.co.in List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1268542580==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 This is a multi-part message in MIME format. --===============1268542580== Content-type: multipart/alternative; boundary="Boundary_(ID_FqHvo6wcqSuIcD/eLJ/GYQ)" This is a multi-part message in MIME format. --Boundary_(ID_FqHvo6wcqSuIcD/eLJ/GYQ) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hi, Refer POC Release 2.0 specifications and 3GPP extensions for SIP required for POC Service Rajeew -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of innovation.interops@wipro.com Sent: Monday, March 14, 2005 12:27 PM To: sip@ietf.org Subject: [Sip] PUSH TO TALK SERVICES Hello, Is there a seperate spec published for SIP based Push-to-talk services? Where can I find more information on the SIP based Push-to-talk services? Regds --Boundary_(ID_FqHvo6wcqSuIcD/eLJ/GYQ) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hi,
Refer POC Release 2.0 specifications
and 3GPP extensions for SIP required for POC Service
Rajeew
 
-----Original Message-----
From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of innovation.interops@wipro.com
Sent: Monday, March 14, 2005 12:27 PM
To: sip@ietf.org
Subject: [Sip] PUSH TO TALK SERVICES

Hello,
 
Is there a seperate spec published for SIP based Push-to-talk services?
 
Where can I find more information on the SIP based Push-to-talk services?
 
Regds
 
--Boundary_(ID_FqHvo6wcqSuIcD/eLJ/GYQ)-- --===============1268542580== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1268542580==-- From sip-bounces@ietf.org Mon Mar 14 09:06:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03712 for ; Mon, 14 Mar 2005 09:06:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAqHH-0003Lv-8J for sip-web-archive@ietf.org; Mon, 14 Mar 2005 09:10:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAqAk-0003CC-F4; Mon, 14 Mar 2005 09:03:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAqAi-0003C2-J3 for sip@megatron.ietf.org; Mon, 14 Mar 2005 09:03:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03260 for ; Mon, 14 Mar 2005 09:03:51 -0500 (EST) Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAqEK-00039p-Rj for sip@ietf.org; Mon, 14 Mar 2005 09:07:38 -0500 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id j2EE8K2v003518 for ; Mon, 14 Mar 2005 07:08:20 -0700 (MST) Received: from il06exm13.corp.mot.com (il06exm13.corp.mot.com [10.0.111.13]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id j2EE3wxl003238 for ; Mon, 14 Mar 2005 08:03:58 -0600 (CST) Received: from bulb (bulb.corp.mot.com [10.14.25.99]) by il06exm13.corp.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id GFF300S8; Mon, 14 Mar 2005 08:03:47 -0600 Date: Mon, 14 Mar 2005 09:05:44 -0500 (EST) From: Srini Krishnamoorthy X-Sender: ksrini@bulb.corp.mot.com To: Rajeew Kumar Singh Subject: RE: [Sip] PUSH TO TALK SERVICES In-Reply-To: <001301c52882$dc8dfec0$9e19320a@telxsi.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ksrini@motorola.com List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Public docs are at:- http://www.openmobilealliance.org/tech/wg_committees/poc.html -Srini On Mon, 14 Mar 2005, Rajeew Kumar Singh wrote: rajeew>Hi, rajeew>Refer POC Release 2.0 specifications rajeew>and 3GPP extensions for SIP required for POC Service rajeew>Rajeew rajeew> rajeew> rajeew>-----Original Message----- rajeew>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of rajeew>innovation.interops@wipro.com rajeew>Sent: Monday, March 14, 2005 12:27 PM rajeew>To: sip@ietf.org rajeew>Subject: [Sip] PUSH TO TALK SERVICES rajeew> rajeew> rajeew>Hello, rajeew> rajeew>Is there a seperate spec published for SIP based Push-to-talk services? rajeew> rajeew>Where can I find more information on the SIP based Push-to-talk rajeew>services? rajeew> rajeew>Regds rajeew> rajeew> rajeew> -- Srini K Core Networks Division, Motorola _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 14 09:07:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03777 for ; Mon, 14 Mar 2005 09:07:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAqHo-0003NB-Ci for sip-web-archive@ietf.org; Mon, 14 Mar 2005 09:11:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAqBO-0003QL-Cv; Mon, 14 Mar 2005 09:04:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAqBM-0003Pw-4c for sip@megatron.ietf.org; Mon, 14 Mar 2005 09:04:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03336 for ; Mon, 14 Mar 2005 09:04:30 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAqEx-0003Aw-Ku for sip@ietf.org; Mon, 14 Mar 2005 09:08:17 -0500 Received: from [192.168.0.102] (c-24-1-68-89.client.comcast.net [24.1.68.89]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j2EE3oPZ032841 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 14 Mar 2005 08:03:51 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <4273b18ffec6821c5e4ebbbc6f1160af@nostrum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: sip-implementors@cs.columbia.edu, "sip@ietf.org WG" From: Robert Sparks Date: Mon, 14 Mar 2005 08:03:49 -0600 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Subject: [Sip] SIPIT 16 registration closes this Friday X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Registration for SIPIT 16 closes in four days. If you plan to attend but have not already registered, please do so as soon as you can. Information about the event is available at http://www.sipit.net and http://sipit16.jasomi.com Thanks, RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 14 09:54:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08346 for ; Mon, 14 Mar 2005 09:54:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAr1o-0005V7-A3 for sip-web-archive@ietf.org; Mon, 14 Mar 2005 09:58:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAquc-0005QT-O6; Mon, 14 Mar 2005 09:51:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAqub-0005QO-PP for sip@megatron.ietf.org; Mon, 14 Mar 2005 09:51:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07894 for ; Mon, 14 Mar 2005 09:51:15 -0500 (EST) Received: from grads.ece.mcmaster.ca ([130.113.10.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAqyD-0005JR-Hd for sip@ietf.org; Mon, 14 Mar 2005 09:55:03 -0500 Received: from [192.168.2.8] ([130.113.184.38]) by grads.ece.mcmaster.ca (8.12.8/8.12.8) with ESMTP id j2EEnxF4001364 for ; Mon, 14 Mar 2005 09:49:59 -0500 Message-ID: <4235A4FD.30708@grads.ece.mcmaster.ca> Date: Mon, 14 Mar 2005 09:51:41 -0500 From: "M.N.A.Smadi" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804 X-Accept-Language: en-us, en MIME-Version: 1.0 To: IETF SIP List Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Subject: [Sip] refer method X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit hi; i am reading some cisco doc and it seems that there are two types of refer requests: blind and attended. This categorization is not so clear in the refer rfc, is this categorization native to cisco or am i missing something? thanks m.smadi _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 14 13:52:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07190 for ; Mon, 14 Mar 2005 13:52:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAujP-0007q4-FR for sip-web-archive@ietf.org; Mon, 14 Mar 2005 13:55:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAubr-0005lw-9W; Mon, 14 Mar 2005 13:48:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAubo-0005le-7T for sip@megatron.ietf.org; Mon, 14 Mar 2005 13:48:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06860 for ; Mon, 14 Mar 2005 13:48:04 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAufU-0007fW-0D for sip@ietf.org; Mon, 14 Mar 2005 13:51:56 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j2EIlumo001651; Mon, 14 Mar 2005 12:47:56 -0600 (CST) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j2EIltb13045; Mon, 14 Mar 2005 12:47:55 -0600 (CST) Message-ID: <4235DC5B.6000504@lucent.com> Date: Mon, 14 Mar 2005 12:47:55 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] GRUU, AORs, and identity, oh my! References: <4234A721.9020207@cisco.com> In-Reply-To: <4234A721.9020207@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > If folks with an interest can respond, on the list or privately, > if they think this is a good path, it would be great. I'd really like > to wrap this work, a lot of things are dependent on it. Jonathan: Yes; good path forward. One comment and a clarification -- please see inline. > Proposal: > URIs have properties. Those properties are granted to the URI based on > policies of the domain, and genreally those properties are not visible > by inspection of the URI. There are a few properties in play here: [...] First, I see a new property of a URI: Routability. This property is rather implicit in the notion of a URI, and in fact, the GRUU property is a subset of this property (more below). Routability: A URI has a routability property in that it always routes to the domain that owns the URI. I see the GRUU as being a subset of this property, since a GRUU routes to a _specific_ instance within the domain that owns the URI. A URI itself allows the SIP mesh to route the request to the domain that owns the URI. Second, the wording below allows us to retrieve a AoR from a GRUU. Clarification follows below: > Furthermore, there is a desire to be able to construct URIs that have > the GRUU property by separating the URI into a component that > identifies the AOR associated with the instance (when such an > association exists), and a component that contains domain-generated > context it uses to affect routing and processing of the URI so it goes > to the specific instance. As argued above, it is essential that a > domain be able to create and manage this context. Thus, such a > separation can be achieved by creating a URI parameter that is > analagous to the grid parameter, but for the domain provider. Call > this the "opaque" URI parameter. That is, the grid parameter provides > context to the UA, so that when it receives a request made to the URI, > it can use the grid as context. The opaque URI parameter provides > context to the domain, so that when the domain proxy receives a > request made to the URI, it can use the opaque parameter as context. In practice, the "opaque" parameter will indeed be some opaque sequence of characters instead of an actual domain name...yes? Something like: sip:hha9s8d=-999a@example.com;opaque=fx45d-pe2" It is up to the resolving domain proxy to figure out which AoR "fx45d-pe2" belongs to. > Based on this analysis, I would suggest updating the GRUU spec to > include the above. Sounds fine. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 14 14:27:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10368 for ; Mon, 14 Mar 2005 14:27:50 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAvHw-0000rn-Sg for sip-web-archive@ietf.org; Mon, 14 Mar 2005 14:31:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAvD4-0002gc-St; Mon, 14 Mar 2005 14:26:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAvD2-0002gB-6T for sip@megatron.ietf.org; Mon, 14 Mar 2005 14:26:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10256 for ; Mon, 14 Mar 2005 14:26:34 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAvGh-0000pa-0t for sip@ietf.org; Mon, 14 Mar 2005 14:30:24 -0500 Received: from [10.200.201.36] (wirelessdata-167-248.mycingular.net [66.102.167.248]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.12.11) with ESMTP id j2EJRbOS011566 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Mon, 14 Mar 2005 13:27:50 -0600 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <81e99172b231d646f3a239e02ea4759c@softarmor.com> Content-Transfer-Encoding: 7bit From: Dean Willis Date: Mon, 14 Mar 2005 13:25:51 -0600 To: sip@ietf.org X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: Allison Mankin , Rohan Mahy , "'James M. Polk'" , Henning Schulzrinne Subject: [Sip] New WGLC for Resource Priority X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit We had a previous round of last call on this draft, but it was heavily revised so we should probably do it again. Working group last call for draft-ietf-sip-resource-priority-07.txt begins immediately and will conclude no later than Monday, March 28, 2005. Please post comments to both the authors and the list. -- Dean _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 14 18:35:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07093 for ; Mon, 14 Mar 2005 18:35:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAz9n-00043B-T7 for sip-web-archive@ietf.org; Mon, 14 Mar 2005 18:39:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAywe-0001ci-OR; Mon, 14 Mar 2005 18:25:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAywZ-0001Wu-Mr; Mon, 14 Mar 2005 18:25:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04631; Mon, 14 Mar 2005 18:25:48 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAz0I-0002x3-4S; Mon, 14 Mar 2005 18:29:42 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DAywY-0005x6-ID; Mon, 14 Mar 2005 18:25:50 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 14 Mar 2005 18:25:50 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: sip mailing list , sip chair , Internet Architecture Board , sip chair , RFC Editor Subject: [Sip] Protocol Action: 'The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP)' to Proposed Standard X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d The IESG has approved the following document: - 'The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP) ' as a Proposed Standard This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. Technical Summary This document specifies the use of SCTP (RFC 2960) as the transport for SIP (RFC 3261). SCTP was designed for the transport of SS7 signaling messages, and a number of the features it supports might be useful in SIP implementations. Note that this is not a proposal that SCTP be adopted as the primary or preferred transport for SIP, rather it just describes how to add SCTP and SCTP/TLS to SIP's available transports. Working Group Summary The working group had consensus to advance the draft to Proposed Standard. Protocol Quality An implementation of SIP over SCTP in Linux has been developed. Review of this specification for the IESG was by Allison Mankin. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 14 19:03:31 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09678 for ; Mon, 14 Mar 2005 19:03:31 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAzan-0005IR-OG for sip-web-archive@ietf.org; Mon, 14 Mar 2005 19:07:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAzVJ-0002b3-6y; Mon, 14 Mar 2005 19:01:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAzVH-0002aX-8M for sip@megatron.ietf.org; Mon, 14 Mar 2005 19:01:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09364 for ; Mon, 14 Mar 2005 19:01:40 -0500 (EST) From: Pierre.Lacour@alcatel.fr Received: from smail.alcatel.fr ([64.208.49.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAzYy-0005CC-UB for sip@ietf.org; Mon, 14 Mar 2005 19:05:34 -0500 Received: from frmail15.netfr.alcatel.fr (frmail15.netfr.alcatel.fr [155.132.251.15]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j2F00B9N031334 for ; Tue, 15 Mar 2005 01:01:30 +0100 To: sip@ietf.org Message-ID: Date: Tue, 15 Mar 2005 01:00:29 +0100 X-MIMETrack: Serialize by Router on FRMAIL15/FR/ALCATEL(Release 5.0.12HF788 | September 23, 2004) at 03/15/2005 01:01:30 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.3 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [Sip] Pierre LACOUR/FR/ALCATEL is out of the office. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 I will be out of the office starting 14/03/2005 and will not return until 31/03/2005. I will respond to your message when I return _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 14 22:26:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28130 for ; Mon, 14 Mar 2005 22:26:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DB2lh-0005nL-3H for sip-web-archive@ietf.org; Mon, 14 Mar 2005 22:30:54 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DB2gW-00030g-Ts; Mon, 14 Mar 2005 22:25:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DB2gV-00030b-8j for sip@megatron.ietf.org; Mon, 14 Mar 2005 22:25:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28021 for ; Mon, 14 Mar 2005 22:25:28 -0500 (EST) Received: from grads.ece.mcmaster.ca ([130.113.10.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DB2kE-0005hD-Q7 for sip@ietf.org; Mon, 14 Mar 2005 22:29:24 -0500 Received: from grads.ece.mcmaster.ca (localhost.localdomain [127.0.0.1]) by grads.ece.mcmaster.ca (8.12.8/8.12.8) with ESMTP id j2F3OCF4014834 for ; Mon, 14 Mar 2005 22:24:12 -0500 Received: from localhost (smadim2@localhost) by grads.ece.mcmaster.ca (8.12.8/8.12.8/Submit) with ESMTP id j2F3OBNp014830 for ; Mon, 14 Mar 2005 22:24:12 -0500 Date: Mon, 14 Mar 2005 22:24:11 -0500 (EST) From: Mohammed Smadi To: sip@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Sip] double checking of the REFER method X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 hi; if we have an active session A<->B (initiated by A), then A sends REFER to B so that we end up with B<->C. Say that neither A nor B send a BYE to each other (i.e. session remains on hold), then either one of A and B can send a re-INVITE to reactivate the previous session. Is this right? or does A only have that privilige since it was the one which initiated the session originally? thanks M.Smadi _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 14 22:28:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28377 for ; Mon, 14 Mar 2005 22:28:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DB2nK-0005qQ-84 for sip-web-archive@ietf.org; Mon, 14 Mar 2005 22:32:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DB2i3-00038o-65; Mon, 14 Mar 2005 22:27:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DB2i1-00038j-HO for sip@megatron.ietf.org; Mon, 14 Mar 2005 22:27:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28165 for ; Mon, 14 Mar 2005 22:27:03 -0500 (EST) Received: from grads.ece.mcmaster.ca ([130.113.10.170]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DB2lk-0005nH-VC for sip@ietf.org; Mon, 14 Mar 2005 22:30:58 -0500 Received: from grads.ece.mcmaster.ca (localhost.localdomain [127.0.0.1]) by grads.ece.mcmaster.ca (8.12.8/8.12.8) with ESMTP id j2F3PkF4014859 for ; Mon, 14 Mar 2005 22:25:46 -0500 Received: from localhost (smadim2@localhost) by grads.ece.mcmaster.ca (8.12.8/8.12.8/Submit) with ESMTP id j2F3PkiG014855 for ; Mon, 14 Mar 2005 22:25:46 -0500 Date: Mon, 14 Mar 2005 22:25:46 -0500 (EST) From: Mohammed Smadi To: sip@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Sip] general rfc question X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab hi; i need someone to help me understand the concept of an rfc? Everyone is referring to SIP rfc as the standard, or that is how it is being used when it comes to implementing software. Now, there is alot of rfc's which are very tightly coupled together, especially the ones which have to do with conferencing and transfer. Are these just ideas or are they standards, or what is exactly the status of these documents, given the fact that some of them have expiry dates? sorry if this is out of the scope of the group but it is instrumental that i understand how the process works. any help is appreciated m.smadi _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 15 03:01:38 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13463 for ; Tue, 15 Mar 2005 03:01:38 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DB73X-0000Z7-8d for sip-web-archive@ietf.org; Tue, 15 Mar 2005 03:05:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DB6xr-0000Bv-7Q; Tue, 15 Mar 2005 02:59:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DB6xn-0000Al-LJ for sip@megatron.ietf.org; Tue, 15 Mar 2005 02:59:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA13010 for ; Tue, 15 Mar 2005 02:59:37 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DB71a-0000Tu-9f for sip@ietf.org; Tue, 15 Mar 2005 03:03:34 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-4.cisco.com with ESMTP; 15 Mar 2005 00:00:02 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2F7xFuC008304; Mon, 14 Mar 2005 23:59:15 -0800 (PST) Received: from [10.71.0.148] (che-vpn-cluster-2-73.cisco.com [10.86.242.73]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AIO60907; Mon, 14 Mar 2005 23:59:13 -0800 (PST) Message-ID: <42362C37.1060301@cisco.com> Date: Mon, 14 Mar 2005 19:28:39 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [Sip] GRUU, AORs, and identity, oh my! References: <4234A721.9020207@cisco.com> <4235DC5B.6000504@lucent.com> In-Reply-To: <4235DC5B.6000504@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.6 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Content-Transfer-Encoding: 7bit inline. Vijay K. Gurbani wrote: > Jonathan Rosenberg wrote: > >> If folks with an interest can respond, on the list or privately, if >> they think this is a good path, it would be great. I'd really like to >> wrap this work, a lot of things are dependent on it. > > > Jonathan: > > Yes; good path forward. One comment and a clarification -- please > see inline. > >> Proposal: >> URIs have properties. Those properties are granted to the URI based on >> policies of the domain, and genreally those properties are not visible >> by inspection of the URI. There are a few properties in play here: > > [...] > > First, I see a new property of a URI: Routability. This property > is rather implicit in the notion of a URI, and in fact, the GRUU > property is a subset of this property (more below). > > Routability: A URI has a routability property in that it always > routes to the domain that owns the URI. This is nearly a tautology; RFC 3263 causes a URI to be resolved to a host that serves the domain in the domain part. > > I see the GRUU as being a subset of this property, since a > GRUU routes to a _specific_ instance within the domain that > owns the URI. A URI itself allows the SIP mesh to route > the request to the domain that owns the URI. > > Second, the wording below allows us to retrieve a AoR from a GRUU. > Clarification follows below: > >> Furthermore, there is a desire to be able to construct URIs that have >> the GRUU property by separating the URI into a component that >> identifies the AOR associated with the instance (when such an >> association exists), and a component that contains domain-generated >> context it uses to affect routing and processing of the URI so it goes >> to the specific instance. As argued above, it is essential that a >> domain be able to create and manage this context. Thus, such a >> separation can be achieved by creating a URI parameter that is >> analagous to the grid parameter, but for the domain provider. Call >> this the "opaque" URI parameter. That is, the grid parameter provides >> context to the UA, so that when it receives a request made to the URI, >> it can use the grid as context. The opaque URI parameter provides >> context to the domain, so that when the domain proxy receives a >> request made to the URI, it can use the opaque parameter as context. > > > In practice, the "opaque" parameter will indeed be some opaque > sequence of characters instead of an actual domain name...yes? > Something like: > > sip:hha9s8d=-999a@example.com;opaque=fx45d-pe2" The idea is that it would be something like this: sip:vkg@lucent.com;opaque="asd998ggfdgsafl000---" that is, the AOR is still exposed in the user@domain part. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 15 07:01:24 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05326 for ; Tue, 15 Mar 2005 07:01:24 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBAnb-0002HD-Me for sip-web-archive@ietf.org; Tue, 15 Mar 2005 07:05:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBAiv-0001Bj-Ry; Tue, 15 Mar 2005 07:00:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBAit-0001Bb-UE for sip@megatron.ietf.org; Tue, 15 Mar 2005 07:00:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05255 for ; Tue, 15 Mar 2005 07:00:28 -0500 (EST) From: innovation.interops@wipro.com Received: from wip-ec-wd.wipro.com ([203.101.113.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBAmh-0002FS-8p for sip@ietf.org; Tue, 15 Mar 2005 07:04:29 -0500 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 930782055B for ; Tue, 15 Mar 2005 17:23:12 +0530 (IST) Received: from blr-ec-bh1.wipro.com (unknown [10.200.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 785332052C for ; Tue, 15 Mar 2005 17:23:12 +0530 (IST) Received: from blr-k1-msg.wipro.com ([10.117.50.99]) by blr-ec-bh1.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Mar 2005 17:30:13 +0530 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 15 Mar 2005 17:30:13 +0530 Message-ID: <0966EC230D8BDA4EB06F57075C4DBF8FFDEFBB@blr-k1-msg.wipro.com> Thread-Topic: draft-ietf-sip-session-timer-15.txt - Proxy Behaviour Thread-Index: AcUpVot872MVTAOQRAe6GO/0nZjprg== To: X-OriginalArrivalTime: 15 Mar 2005 12:00:13.0937 (UTC) FILETIME=[8BCDBE10:01C52956] X-Spam-Score: 1.1 (+) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Sip] draft-ietf-sip-session-timer-15.txt - Proxy Behaviour X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1252827927==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da This is a multi-part message in MIME format. --===============1252827927== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C52956.8B8AB213" This is a multi-part message in MIME format. ------_=_NextPart_001_01C52956.8B8AB213 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all, =20 Any example or explanation for the below statement from = draft-ietf-sip-session-timer-15.txt would be appreciated. =20 "The proxy computes the session expiration as the time when the 2xx response is forwarded upstream, plus the session interval. This session expiration MUST update any existing session expiration for the session" =20 Thanks in advance ------_=_NextPart_001_01C52956.8B8AB213 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A=
Dear all,
=0A=
 
=0A=
Any example or explanation for the below = statement from =0A= draft-ietf-sip-session-timer-15.txt would be appreciated.
=0A=
 
=0A=
   "The proxy = computes the =0A= session expiration as the time when the 2xx
   response is =0A= forwarded upstream, plus the session interval.  = This
   =0A= session expiration MUST update any existing session expiration =0A= for
   the session"
=0A=
 
=0A=
Thanks in advance
------_=_NextPart_001_01C52956.8B8AB213-- --===============1252827927== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1252827927==-- From sip-bounces@ietf.org Tue Mar 15 09:02:43 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17529 for ; Tue, 15 Mar 2005 09:02:43 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBCh1-00083I-J6 for sip-web-archive@ietf.org; Tue, 15 Mar 2005 09:06:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBCaq-0007hI-UL; Tue, 15 Mar 2005 09:00:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBCao-0007hD-KE for sip@megatron.ietf.org; Tue, 15 Mar 2005 09:00:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17288 for ; Tue, 15 Mar 2005 09:00:17 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBCee-0007u9-RS for sip@ietf.org; Tue, 15 Mar 2005 09:04:17 -0500 Received: from mgw-x2.nokia.com ([131.228.20.22]) by mx2.foretec.com with esmtp (Exim 4.24) id 1DBCao-00069z-4n for sip@ietf.org; Tue, 15 Mar 2005 09:00:18 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j2FE06U06011; Tue, 15 Mar 2005 16:00:06 +0200 (EET) X-Scanned: Tue, 15 Mar 2005 15:59:16 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j2FDxGnX021501; Tue, 15 Mar 2005 15:59:16 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 003133vU; Tue, 15 Mar 2005 15:59:10 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j2FDxAU03031; Tue, 15 Mar 2005 15:59:10 +0200 (EET) Received: from [172.21.35.34] ([172.21.35.34]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 15 Mar 2005 15:58:51 +0200 Message-ID: <4236EA1B.2080401@nokia.com> Date: Tue, 15 Mar 2005 15:58:51 +0200 From: Aki Niemi User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Jonathan Rosenberg Subject: Re: [Sip] GRUU, AORs, and identity, oh my! References: <4234A721.9020207@cisco.com> In-Reply-To: <4234A721.9020207@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Mar 2005 13:58:51.0903 (UTC) FILETIME=[1E7128F0:01C52967] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit ext Jonathan Rosenberg wrote: --snip > Based on this analysis, I would suggest updating the GRUU spec to > include the above. I think it is not unreasonable to include the more > abstract discussion on URI properties, including the definition of > AOR, though I would prefer that the identity definition be moved into > draft-ietf-sip-identity and thus a reference be provided from the GRUU > spec. I agree with the analysis and this seems like a good way forward. Cheers, Aki _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 15 12:25:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24143 for ; Tue, 15 Mar 2005 12:17:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBFdS-0001Gx-Tg for sip-web-archive@ietf.org; Tue, 15 Mar 2005 12:15:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBEql-0002F9-AQ; Tue, 15 Mar 2005 11:24:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAs0X-0001up-OW for sip@megatron.ietf.org; Mon, 14 Mar 2005 11:01:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17111 for ; Mon, 14 Mar 2005 11:01:27 -0500 (EST) Received: from web41203.mail.yahoo.com ([66.218.93.36]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DAs45-0008Qe-4o for sip@ietf.org; Mon, 14 Mar 2005 11:05:16 -0500 Received: (qmail 84094 invoked by uid 60001); 14 Mar 2005 16:01:07 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=K8HMFyz2PcQrkh9yWrmQMKHI+F3SOv/5FAGttzgaekwvkjveH7Ax3Z06Jd6oiUbXj9y2ezsbhuk5eQ4D5ZvRYDDJqSAaZdTTcb/St6SsHgPbfchV3vQiBYvmu/Q+0cbH7wtVprQCmeoMBItnYc0Dd/QeMnSfgjvHNk4N3YE2n4o= ; Message-ID: <20050314160107.84092.qmail@web41203.mail.yahoo.com> Received: from [209.157.158.178] by web41203.mail.yahoo.com via HTTP; Mon, 14 Mar 2005 08:01:07 PST Date: Mon, 14 Mar 2005 08:01:07 -0800 (PST) From: Joel Dodson Subject: Re: [Sip] refer method To: "M.N.A.Smadi" , IETF SIP List In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d X-Mailman-Approved-At: Tue, 15 Mar 2005 11:24:52 -0500 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Hi m.smadi, blind and attended refer to two different types of call transfers. REFER is used in each case. See http://www.ietf.org/internet-drafts/draft-ietf-sipping-cc-transfer-03.txt for the various uses of REFER in call transfer. Joel --- "M.N.A.Smadi" wrote: > hi; > > i am reading some cisco doc and it seems that there are two types of > refer requests: blind and attended. This categorization is not so > clear > in the refer rfc, is this categorization native to cisco or am i > missing > something? > > thanks > m.smadi > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 15 12:36:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26649 for ; Tue, 15 Mar 2005 12:35:10 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBG0Z-0005pP-UN for sip-web-archive@ietf.org; Tue, 15 Mar 2005 12:39:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBFw0-0007iG-Rp; Tue, 15 Mar 2005 12:34:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBFvz-0007hw-C1 for sip@megatron.ietf.org; Tue, 15 Mar 2005 12:34:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25945 for ; Tue, 15 Mar 2005 12:34:17 -0500 (EST) Received: from tierw.net.avaya.com ([198.152.13.100]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBFu2-0004ga-5g for sip@ietf.org; Tue, 15 Mar 2005 12:32:23 -0500 Received: from tierw.net.avaya.com (localhost [127.0.0.1]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j2FHHtvn017913 for ; Tue, 15 Mar 2005 12:17:55 -0500 (EST) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by tierw.net.avaya.com (Switch-3.1.2/Switch-3.1.0) with ESMTP id j2FHF6vn013661 for ; Tue, 15 Mar 2005 12:16:41 -0500 (EST) X-MIMEOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Mar 2005 19:24:02 +0200 Message-ID: Thread-Topic: Question about registration on behalf Thread-index: AcUk9FxAlewdaNbwQxmiHre2ElusIQC1Z7Ew From: "Galron, Dror \(Dror\)" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Subject: [Sip] Question about registration on behalf X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: quoted-printable Question about registration on behalf: I need to implement a system which uses the 'registration on behalf' mechanism for the same domain.=20 1. What is the common practice for registration on behalf? 2. What is the authentication scheme? And how the two registrars know to authenticate the user? 3. Is it legal for the intermediate registrar to fake the authentication, presuming it knows the users passwords? Thanks, Dror=20 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 15 14:12:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07374 for ; Tue, 15 Mar 2005 14:12:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBHL1-0005yF-JB for sip-web-archive@ietf.org; Tue, 15 Mar 2005 14:04:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBHCG-00055G-U0; Tue, 15 Mar 2005 13:55:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBHCE-00054j-AT for sip@megatron.ietf.org; Tue, 15 Mar 2005 13:55:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04530 for ; Tue, 15 Mar 2005 13:55:08 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBHC8-0004hV-K9 for sip@ietf.org; Tue, 15 Mar 2005 13:55:09 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j2FIourC015521; Tue, 15 Mar 2005 12:50:56 -0600 (CST) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j2FIotQ27339; Tue, 15 Mar 2005 12:50:55 -0600 (CST) Message-ID: <42372E8F.4090405@lucent.com> Date: Tue, 15 Mar 2005 12:50:55 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] GRUU, AORs, and identity, oh my! References: <4234A721.9020207@cisco.com> <4235DC5B.6000504@lucent.com> <42362C37.1060301@cisco.com> In-Reply-To: <42362C37.1060301@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: vkg> Routability: A URI has a routability property in that it always vkg> routes to the domain that owns the URI. jdr> jdr> This is nearly a tautology; RFC 3263 causes a URI to be resolved to a jdr> host that serves the domain in the domain part. Yes, I realize that routing is intrinsic to a URI. However, I still think that routing to a domain versus routing to a specific instance within the domain may be different properties. The latter (a GRUU) is a subset of the former. vkg> In practice, the "opaque" parameter will indeed be some opaque vkg> sequence of characters instead of an actual domain name...yes? vkg> Something like: vkg> sip:hha9s8d=-999a@example.com;opaque=fx45d-pe2" jdr> jdr> The idea is that it would be something like this: jdr> sip:vkg@lucent.com;opaque="asd998ggfdgsafl000---" jdr> that is, the AOR is still exposed in the user@domain part. Initially I thought that the opaque parameter will aid in extracting the AoR from the GRUU (since the WG has thrashed on that particular problem), but based on above, this appears not to be the case (the AoR is already available). So, what is the use of the opaque parameter? I re-read your email and it says that the opaque parameter "...contains a domain-generated context [used] to affect routing and processing of the URI so it goes to the specific instance." Isn't that what a GRUU is for as well? What happens when a GRUU contains an opaque parameter as in my example above? I guess the question is, what is the use case that has motivated the opaque parameter? Thanks, - vijay Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 15 15:20:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14762 for ; Tue, 15 Mar 2005 15:20:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBIaz-0004qY-UR for sip-web-archive@ietf.org; Tue, 15 Mar 2005 15:24:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBISj-0001Kg-Mk; Tue, 15 Mar 2005 15:16:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBISe-0001JR-ND for sip@megatron.ietf.org; Tue, 15 Mar 2005 15:16:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13737 for ; Tue, 15 Mar 2005 15:16:12 -0500 (EST) Received: from nylon.softarmor.com ([66.135.38.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBIOi-0003fo-Eh for sip@ietf.org; Tue, 15 Mar 2005 15:12:13 -0500 Received: from [171.71.227.36] (dhcp-171-71-227-36.cisco.com [171.71.227.36]) (authenticated bits=0) by nylon.softarmor.com (8.13.1/8.12.11) with ESMTP id j2FKABMG015029 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Tue, 15 Mar 2005 14:10:12 -0600 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dean Willis Date: Tue, 15 Mar 2005 14:08:29 -0600 To: sip@ietf.org X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Cc: Andrew Allen , Rohan Mahy , Allison Mankin Subject: [Sip] P-Alerting-Mode to standards track? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit One of the consensus points that seemed to emerge during the recent meeting was around the proposed P-Alerting-Mode header. We appear to have decided that we really do need a standard (NOT a P-header) way to ask a UAS to "auto answer", whether for a diagnostic loopback or push-to-talk application. There also seems to be a consensus that this should be done with a header, rather than a request parameter or other mechanism. So, it has been proposed that this header be withdrawn from the P-header "informational" draft, and re-documented on standards track. If we pursue this path, it should be noted that we would need to do it very quickly, as OMA has real needs for this functionality ASAP. I'll volunteer to help Andrew get it whipped into shape, unless somebody else wants to throw themselves on it. It seems like a relative no-brainer, just an exercise in documentation. So, poll for consensus: Does anybody strongly object to the development of a standard header for requesting auto-answer of a request? Second poll: Do we see any reasons why this couldn't be done fairly quickly, such as obvious dependencies on ongoing work that I've just missed? Thanks, -- Dean Willis SIP WG chair _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 15 16:13:26 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20094 for ; Tue, 15 Mar 2005 16:13:26 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBJPu-0008DT-VR for sip-web-archive@ietf.org; Tue, 15 Mar 2005 16:17:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBJK8-0004Gb-9k; Tue, 15 Mar 2005 16:11:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBJK6-0004GR-IP for sip@megatron.ietf.org; Tue, 15 Mar 2005 16:11:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19922 for ; Tue, 15 Mar 2005 16:11:28 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBJNz-0008AB-Ir for sip@ietf.org; Tue, 15 Mar 2005 16:15:32 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 15 Mar 2005 16:11:21 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2FLBHjI002427; Tue, 15 Mar 2005 16:11:18 -0500 (EST) Received: from cisco.com (dhcp-171-71-213-85.cisco.com [171.71.213.85]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APV38853; Tue, 15 Mar 2005 16:11:16 -0500 (EST) Message-ID: <42374F73.2010800@cisco.com> Date: Tue, 15 Mar 2005 16:11:15 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [Sip] GRUU, AORs, and identity, oh my! References: <4234A721.9020207@cisco.com> <4235DC5B.6000504@lucent.com> <42362C37.1060301@cisco.com> <42372E8F.4090405@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: > vkg> In practice, the "opaque" parameter will indeed be some opaque > vkg> sequence of characters instead of an actual domain name...yes? > vkg> Something like: > vkg> sip:hha9s8d=-999a@example.com;opaque=fx45d-pe2" > jdr> > jdr> The idea is that it would be something like this: > jdr> sip:vkg@lucent.com;opaque="asd998ggfdgsafl000---" > jdr> that is, the AOR is still exposed in the user@domain part. > > Initially I thought that the opaque parameter will aid in > extracting the AoR from the GRUU (since the WG has thrashed > on that particular problem), but based on above, this appears > not to be the case (the AoR is already available). > > So, what is the use of the opaque parameter? I re-read your > email and it says that the opaque parameter "...contains a > domain-generated context [used] to affect routing and processing > of the URI so it goes to the specific instance." Isn't that what > a GRUU is for as well? > > What happens when a GRUU contains an opaque parameter as in my > example above? I guess the question is, what is the use case > that has motivated the opaque parameter? I think you are not getting the point. In the above, a gruu (at least this form of gruu) *is* an AoR *augmented* with the opaque parameter. The AoR is recoverable from this form of gruu by removing the opaque parameter. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 15 16:33:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22764 for ; Tue, 15 Mar 2005 16:33:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBJjQ-0001Vq-EK for sip-web-archive@ietf.org; Tue, 15 Mar 2005 16:37:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBJd7-00011c-IY; Tue, 15 Mar 2005 16:31:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBJd5-00011V-Qx for sip@megatron.ietf.org; Tue, 15 Mar 2005 16:31:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21963 for ; Tue, 15 Mar 2005 16:31:05 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBJgz-000176-0p for sip@ietf.org; Tue, 15 Mar 2005 16:35:10 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j2FLTsUd003620; Tue, 15 Mar 2005 15:29:55 -0600 (CST) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j2FLTsQ10671; Tue, 15 Mar 2005 15:29:54 -0600 (CST) Message-ID: <423753D2.7060108@lucent.com> Date: Tue, 15 Mar 2005 15:29:54 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] GRUU, AORs, and identity, oh my! References: <4234A721.9020207@cisco.com> <4235DC5B.6000504@lucent.com> <42362C37.1060301@cisco.com> <42372E8F.4090405@lucent.com> <42374F73.2010800@cisco.com> In-Reply-To: <42374F73.2010800@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > I think you are not getting the point. In the above, a gruu (at least > this form of gruu) *is* an AoR *augmented* with the opaque parameter. > The AoR is recoverable from this form of gruu by removing the opaque > parameter. Paul: Of course I see that; however, I thought that the opaque parameter was an answer to a problem that the WG has thrashed about, namely, how to recover an AoR from a GRUU. Not all GRUUs will be of the nice form sip:user@domain. For those that are, removing the opaque parameter to get the AoR is a no-brainer -- the AoR is staring at you right in the face. So I see little utility in adding an opaque parameter to such an AoR. Hence my question -- what was the use case that motivated the opaque parameter. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 15 17:24:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27218 for ; Tue, 15 Mar 2005 17:24:08 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBKWM-0004mR-7e for sip-web-archive@ietf.org; Tue, 15 Mar 2005 17:28:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBKKa-0001TH-QA; Tue, 15 Mar 2005 17:16:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBKKV-0001Sl-EA; Tue, 15 Mar 2005 17:15:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26380; Tue, 15 Mar 2005 17:15:56 -0500 (EST) Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBKOQ-0004BY-4d; Tue, 15 Mar 2005 17:20:02 -0500 Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DBKKU-0004YQ-KZ; Tue, 15 Mar 2005 17:15:58 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Tue, 15 Mar 2005 17:15:58 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: sip mailing list , sip chair , Internet Architecture Board , sip chair , RFC Editor Subject: [Sip] Document Action: 'Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP)' to Informational RFC X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f The IESG has approved the following document: - 'Guidelines for Authors of Extensions to the Session Initiation Protocol (SIP) ' as an Informational RFC This document is the product of the Session Initiation Protocol Working Group. The IESG contact persons are Allison Mankin and Jon Peterson. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 15 17:54:52 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29922 for ; Tue, 15 Mar 2005 17:54:52 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBL05-0006gw-Lg for sip-web-archive@ietf.org; Tue, 15 Mar 2005 17:58:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBKrg-0004Pn-AU; Tue, 15 Mar 2005 17:50:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBKre-0004Pi-6A for sip@megatron.ietf.org; Tue, 15 Mar 2005 17:50:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29573 for ; Tue, 15 Mar 2005 17:50:11 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBKvY-0006Ku-2t for sip@ietf.org; Tue, 15 Mar 2005 17:54:17 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 15 Mar 2005 18:07:30 -0500 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,166,1107752400"; d="scan'208"; a="40628918:sNHT20673332" Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2FMo1jI029524; Tue, 15 Mar 2005 17:50:02 -0500 (EST) Received: from cisco.com (dhcp-171-71-213-85.cisco.com [171.71.213.85]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id APV49732; Tue, 15 Mar 2005 17:49:59 -0500 (EST) Message-ID: <42376695.6050808@cisco.com> Date: Tue, 15 Mar 2005 17:49:57 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [Sip] GRUU, AORs, and identity, oh my! References: <4234A721.9020207@cisco.com> <4235DC5B.6000504@lucent.com> <42362C37.1060301@cisco.com> <42372E8F.4090405@lucent.com> <42374F73.2010800@cisco.com> <423753D2.7060108@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Vijay, OK, we must really be talking past one another. The opaque parameter is what the proxy uses to recognize this is a gruu rather than just an AoR: - AoR: sip:alice@atlanta.com - Gruu: sip:alice@atlanta.com;opaque="xyzzy" There could be another form of gruu that is anonymized. If so the point would be that one should not be able to recover the AoR from it. Paul Vijay K. Gurbani wrote: > Paul Kyzivat wrote: > >> I think you are not getting the point. In the above, a gruu (at least >> this form of gruu) *is* an AoR *augmented* with the opaque parameter. >> The AoR is recoverable from this form of gruu by removing the opaque >> parameter. > > > Paul: > > Of course I see that; however, I thought that the opaque > parameter was an answer to a problem that the WG has > thrashed about, namely, how to recover an AoR from a GRUU. > > Not all GRUUs will be of the nice form sip:user@domain. > For those that are, removing the opaque parameter to get the > AoR is a no-brainer -- the AoR is staring at you right in > the face. So I see little utility in adding an opaque > parameter to such an AoR. > > Hence my question -- what was the use case that motivated > the opaque parameter. > > - vijay _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 16 10:32:25 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01461 for ; Wed, 16 Mar 2005 10:32:25 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBaZb-00038d-Bi for sip-web-archive@ietf.org; Wed, 16 Mar 2005 10:36:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBaUF-0002c1-84; Wed, 16 Mar 2005 10:31:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBaUC-0002bt-Tr for sip@megatron.ietf.org; Wed, 16 Mar 2005 10:31:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01267 for ; Wed, 16 Mar 2005 10:31:02 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBaYF-0002xr-KQ for sip@ietf.org; Wed, 16 Mar 2005 10:35:16 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j2GFTqVt008292; Wed, 16 Mar 2005 09:29:52 -0600 (CST) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j2GFTp823930; Wed, 16 Mar 2005 09:29:51 -0600 (CST) Message-ID: <423850EF.50506@lucent.com> Date: Wed, 16 Mar 2005 09:29:51 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Kyzivat Subject: Re: [Sip] GRUU, AORs, and identity, oh my! References: <4234A721.9020207@cisco.com> <4235DC5B.6000504@lucent.com> <42362C37.1060301@cisco.com> <42372E8F.4090405@lucent.com> <42374F73.2010800@cisco.com> <423753D2.7060108@lucent.com> <42376695.6050808@cisco.com> In-Reply-To: <42376695.6050808@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Paul Kyzivat wrote: > Vijay, > > OK, we must really be talking past one another. The opaque parameter is > what the proxy uses to recognize this is a gruu rather than just an AoR: Oh, ok. So, the opaque parameter is a context saved by the proxy that will allow it to match the gruu to an AoR. A gruu routes to a particular instance, but the opaque serves to map the gruu to a particular AoR in the proxy's domain. > - AoR: sip:alice@atlanta.com > - Gruu: sip:alice@atlanta.com;opaque="xyzzy" > > There could be another form of gruu that is anonymized. If so the point > would be that one should not be able to recover the AoR from it. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 16 15:16:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03525 for ; Wed, 16 Mar 2005 15:16:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBf0b-0003EP-FG for sip-web-archive@ietf.org; Wed, 16 Mar 2005 15:20:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBeu9-0006qK-VF; Wed, 16 Mar 2005 15:14:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBeu7-0006q2-Mw for sip@megatron.ietf.org; Wed, 16 Mar 2005 15:14:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03118 for ; Wed, 16 Mar 2005 15:14:05 -0500 (EST) From: Udit_Goyal@3com.com Received: from plmler1.mail.eds.com ([199.228.142.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBeyC-00039m-Oy for sip@ietf.org; Wed, 16 Mar 2005 15:18:22 -0500 Received: from plmlir1.mail.eds.com (plmlir1-2.mail.eds.com [199.228.142.131]) by plmler1.mail.eds.com (8.13.2/8.12.10) with ESMTP id j2GKE4HP021705 for ; Wed, 16 Mar 2005 20:14:04 GMT Received: from plmlir1.mail.eds.com (localhost [127.0.0.1]) by plmlir1.mail.eds.com (8.13.2/8.12.10) with ESMTP id j2GKE0fc002964 for ; Wed, 16 Mar 2005 14:14:00 -0600 Received: from usut001.3com.com ([205.142.126.149]) by plmlir1.mail.eds.com (8.13.2/8.12.10) with ESMTP id j2GKDxIF002953 for ; Wed, 16 Mar 2005 14:13:59 -0600 MIME-Version: 1.0 To: sip@ietf.org X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: Date: Wed, 16 Mar 2005 15:19:19 -0500 X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.0.3|September 26, 2003) at 03/16/2005 12:13:59 PM, Serialize complete at 03/16/2005 12:13:59 PM X-Spam-Score: 0.8 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [Sip] Multiple 2xx responses forking proxy X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0641254736==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.3 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 This is a multipart message in MIME format. --===============0641254736== Content-Type: multipart/alternative; boundary="=_alternative 006F200185256FC6_=" This is a multipart message in MIME format. --=_alternative 006F200185256FC6_= Content-Type: text/plain; charset="US-ASCII" Hi, As per RFC 3261, a forking proxy on receiving 2xx response will send CANCEL for the remaining client transactions. However, it may happend that during this time another 2xx response is received, then what should be the proxy behaviour, should it forward it to the UA as it is mentioned in RFC that all the 2xx responses should be forwarded immediatle, will it do it statelessly? And if UAC receives multiple 200 responses, how it should behave, because from user's perspective he dials a single destination but there are multiple dialogs established, but he cant be connected to everybody... is it like UAC will terminate the dialogs after the first dialog is established by checking that it came from same destination (because of same To header) but different tags.. Thanks, Udit --=_alternative 006F200185256FC6_= Content-Type: text/html; charset="US-ASCII"
Hi,

As per RFC 3261, a forking proxy on receiving 2xx response will send CANCEL for the remaining client transactions.
However, it may happend that during this time another 2xx response is received, then what should be the proxy behaviour,
should it forward it to the UA as it is mentioned in RFC that all the 2xx responses should be forwarded immediatle, will it do
it statelessly?

And if UAC receives multiple 200 responses, how it should behave, because from user's perspective he dials a single destination but
there are multiple dialogs established, but he cant be connected to everybody...
is it like UAC will terminate the dialogs after the first dialog is established by checking that it came from same destination (because of
same To header) but different tags..

Thanks,
Udit


--=_alternative 006F200185256FC6_=-- --===============0641254736== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0641254736==-- From sip-bounces@ietf.org Wed Mar 16 15:55:18 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08993 for ; Wed, 16 Mar 2005 15:55:18 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBfc6-0005qa-QI for sip-web-archive@ietf.org; Wed, 16 Mar 2005 15:59:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBfTm-0007gi-3f; Wed, 16 Mar 2005 15:50:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBfTh-0007g6-OQ; Wed, 16 Mar 2005 15:50:53 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07787; Wed, 16 Mar 2005 15:50:51 -0500 (EST) Message-Id: <200503162050.PAA07787@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 16 Mar 2005 15:50:51 -0500 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-resource-priority-07.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 --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 Working Group of the IETF. Title : Communications Resource Priority for the Session Initiation Protocol (SIP) Author(s) : H. Schulzrinne, J. Polk Filename : draft-ietf-sip-resource-priority-07.txt Pages : 36 Date : 2005-3-16 This document defines two new SIP header fields for communicating resource priority, namely "Resource-Priority" and "Accept-Resource- Priority". The "Resource-Priority" header field can influence the behavior of SIP user agents, such as telephone gateways and IP telephones, and Session Initiation Protocol (SIP) proxies. It does not directly influence the forwarding behavior of IP routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-resource-priority-07.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-resource-priority-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-resource-priority-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-3-16161151.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-resource-priority-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-resource-priority-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-16161151.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart-- From sip-bounces@ietf.org Wed Mar 16 17:37:51 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06899 for ; Wed, 16 Mar 2005 17:37:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBhDN-0000CJ-Sa for sip-web-archive@ietf.org; Wed, 16 Mar 2005 17:42:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBh85-0005f8-SI; Wed, 16 Mar 2005 17:36:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBh84-0005f3-2S for sip@megatron.ietf.org; Wed, 16 Mar 2005 17:36:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06787 for ; Wed, 16 Mar 2005 17:36:37 -0500 (EST) Received: from [12.47.48.6] (helo=mail1.sonimtech.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBhCB-00009f-Bf for sip@ietf.org; Wed, 16 Mar 2005 17:40:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Sip] Multiple 2xx responses forking proxy Date: Wed, 16 Mar 2005 14:38:51 -0800 Message-ID: <6A72F4F5EC7C1541A3FD8CD6FEBE366410F476@mail1.sonimtech.com> Thread-Topic: [Sip] Multiple 2xx responses forking proxy Thread-Index: AcUqZXzubCxGX/2FTkeKvwmuZ/LLCwAEhAhw From: "Amit Idnani" To: X-Spam-Score: 0.8 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1172638988==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 This is a multi-part message in MIME format. --===============1172638988== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C52A78.ED6ED59A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C52A78.ED6ED59A Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Udit, =20 An RFC-3261 compliant UAC should be prepared to receive multiple 2xx = response for an INVITE request that it sends out. Each 2xx response is = distinguished by the tag parameter in the To header header (making them = different dialogs). =20 The appearance to the end user is purely an implementation choice where = you can terminate all but the first dialog established by sending an ACK = for the 2xx followed by a BYE request within that particular dialog. =20 Hope it helps. =20 Amit Idnani =20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of = Udit_Goyal@3com.com Sent: Wednesday, March 16, 2005 12:19 PM To: sip@ietf.org Subject: [Sip] Multiple 2xx responses forking proxy Hi,=20 As per RFC 3261, a forking proxy on receiving 2xx response will send = CANCEL for the remaining client transactions.=20 However, it may happend that during this time another 2xx response is = received, then what should be the proxy behaviour,=20 should it forward it to the UA as it is mentioned in RFC that all the = 2xx responses should be forwarded immediatle, will it do=20 it statelessly?=20 And if UAC receives multiple 200 responses, how it should behave, = because from user's perspective he dials a single destination but=20 there are multiple dialogs established, but he cant be connected to = everybody...=20 is it like UAC will terminate the dialogs after the first dialog is = established by checking that it came from same destination (because of=20 same To header) but different tags..=20 Thanks,=20 Udit=20 ------_=_NextPart_001_01C52A78.ED6ED59A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Udit,
 
An = RFC-3261=20 compliant UAC should be prepared to receive multiple 2xx response for an = INVITE=20 request that it sends out. Each 2xx response is distinguished by the tag = parameter in the To header header (making them different=20 dialogs).
 
The = appearance to=20 the end user is purely an implementation choice where you can terminate = all but=20 the first dialog established by sending an ACK for the 2xx followed by a = BYE=20 request within that particular dialog.
 
Hope = it=20 helps.
 
Amit=20 Idnani
 
-----Original Message-----
From: = sip-bounces@ietf.org=20 [mailto:sip-bounces@ietf.org]On Behalf Of=20 Udit_Goyal@3com.com
Sent: Wednesday, March 16, 2005 = 12:19=20 PM
To: sip@ietf.org
Subject: [Sip] Multiple 2xx = responses=20 forking proxy


Hi,=20

As per RFC 3261, a forking = proxy on=20 receiving 2xx response will send CANCEL for the remaining client=20 transactions.
However, it = may happend=20 that during this time another 2xx response is received, then what = should be=20 the proxy behaviour,
should it forward=20 it to the UA as it is mentioned in RFC that all the 2xx responses = should be=20 forwarded immediatle, will it do
it=20 statelessly?

And if = UAC receives=20 multiple 200 responses, how it should behave, because from user's = perspective=20 he dials a single destination but
there are multiple dialogs established, but he cant be = connected to=20 everybody...
is it like = UAC will=20 terminate the dialogs after the first dialog is established by = checking that=20 it came from same destination (because of
same To header) but different tags..

Thanks,
Udit


------_=_NextPart_001_01C52A78.ED6ED59A-- --===============1172638988== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1172638988==-- From sip-bounces@ietf.org Thu Mar 17 04:50:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02072 for ; Thu, 17 Mar 2005 04:50:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBrhw-0006MJ-Uk for sip-web-archive@ietf.org; Thu, 17 Mar 2005 04:54:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBrch-0007PR-Hq; Thu, 17 Mar 2005 04:48:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBrce-0007Nd-AH for sip@megatron.ietf.org; Thu, 17 Mar 2005 04:48:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01970 for ; Thu, 17 Mar 2005 04:48:53 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBrgr-0006Gl-DS for sip@ietf.org; Thu, 17 Mar 2005 04:53:17 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 17 Mar 2005 01:48:47 -0800 Received: from mira-sjc5-d.cisco.com (IDENT:mirapoint@mira-sjc5-d.cisco.com [171.71.163.28]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2H9mfLX017126; Thu, 17 Mar 2005 01:48:41 -0800 (PST) Received: from [10.10.10.53] (ams-clip-vpn-dhcp57.cisco.com [10.61.64.57]) by mira-sjc5-d.cisco.com (MOS 3.4.6-GR) with ESMTP id AIQ53068; Thu, 17 Mar 2005 01:48:41 -0800 (PST) Message-ID: <42395277.5090801@cisco.com> Date: Thu, 17 Mar 2005 04:48:39 -0500 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20040910 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" Subject: Re: [Sip] GRUU, AORs, and identity, oh my! References: <4234A721.9020207@cisco.com> <4235DC5B.6000504@lucent.com> <42362C37.1060301@cisco.com> <42372E8F.4090405@lucent.com> In-Reply-To: <42372E8F.4090405@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit inline. Vijay K. Gurbani wrote: > Jonathan Rosenberg wrote: > vkg> Routability: A URI has a routability property in that it always > vkg> routes to the domain that owns the URI. > jdr> > jdr> This is nearly a tautology; RFC 3263 causes a URI to be resolved to a > jdr> host that serves the domain in the domain part. > > Yes, I realize that routing is intrinsic to a URI. However, I > still think that routing to a domain versus routing to a specific > instance within the domain may be different properties. The > latter (a GRUU) is a subset of the former. This doesnt make sense to me. All URIs resolve to their domains. GRUUs have the property that, within the domain, they route to an instance. Thus, the only property here worth noting is the gruu property. > > vkg> In practice, the "opaque" parameter will indeed be some opaque > vkg> sequence of characters instead of an actual domain name...yes? > vkg> Something like: > vkg> sip:hha9s8d=-999a@example.com;opaque=fx45d-pe2" > jdr> > jdr> The idea is that it would be something like this: > jdr> sip:vkg@lucent.com;opaque="asd998ggfdgsafl000---" > jdr> that is, the AOR is still exposed in the user@domain part. > > Initially I thought that the opaque parameter will aid in > extracting the AoR from the GRUU (since the WG has thrashed > on that particular problem), but based on above, this appears > not to be the case (the AoR is already available). I don't follow you here. The GRUU looks like this: sip:vkg@lucent.com;opaque="asd998ggfdgsafl000---" to extract the AOR, you remove the opaque parameter. > > So, what is the use of the opaque parameter? I re-read your > email and it says that the opaque parameter "...contains a > domain-generated context [used] to affect routing and processing > of the URI so it goes to the specific instance." Isn't that what > a GRUU is for as well? Yes. The point is that the GRUU is created by adding the opaque parameter to the AOR. > > What happens when a GRUU contains an opaque parameter as in my > example above? I guess the question is, what is the use case > that has motivated the opaque parameter? To extract the AOR from the GRUU. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Director, Service Provider VoIP Architecture Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 17 10:31:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12670 for ; Thu, 17 Mar 2005 10:31:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBx2R-0004oH-5V for sip-web-archive@ietf.org; Thu, 17 Mar 2005 10:35:55 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBwvV-0008O6-Ns; Thu, 17 Mar 2005 10:28:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBwvU-0008O1-B9 for sip@megatron.ietf.org; Thu, 17 Mar 2005 10:28:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12132 for ; Thu, 17 Mar 2005 10:28:41 -0500 (EST) Received: from ihemail1.lucent.com ([192.11.222.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBwzk-0004d1-LE for sip@ietf.org; Thu, 17 Mar 2005 10:33:08 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j2HFRWmo017888; Thu, 17 Mar 2005 09:27:32 -0600 (CST) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j2HFRV528432; Thu, 17 Mar 2005 09:27:31 -0600 (CST) Message-ID: <4239A1E3.9050807@lucent.com> Date: Thu, 17 Mar 2005 09:27:31 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [Sip] GRUU, AORs, and identity, oh my! References: <4234A721.9020207@cisco.com> <4235DC5B.6000504@lucent.com> <42362C37.1060301@cisco.com> <42372E8F.4090405@lucent.com> <42395277.5090801@cisco.com> In-Reply-To: <42395277.5090801@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: IETF SIP List X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > This doesnt make sense to me. All URIs resolve to their domains. GRUUs > have the property that, within the domain, they route to an instance. > Thus, the only property here worth noting is the gruu property. Jonathan: I see it as a property that the URIs resolve to their domain names; rfc3986 in fact makes no mention of routability per se, and notes that "...Nor should it be assumed that a system using URIs will access the resource identified: in many cases, URIs are used to denote resources without any intention that they be accessed." We have build SIP systems around the fact that we will access (i.e. route to) the URI and identify a domain (AoR) versus a specific endpoint (gruu) for the URI. But this is all academic; as the editor of the GRUU I-D, it is your choice to accept my argument or not. Not accepting it will not be the end of the world, just like accepting it will not drastically change the world ;-) > I don't follow you here. The GRUU looks like this: > > sip:vkg@lucent.com;opaque="asd998ggfdgsafl000---" > > to extract the AOR, you remove the opaque parameter. I think after an email exchange with Paul K. (which you may probably have read by now) on the WG mailing list, I see the reason for the opaque parameter. I did post my understanding of its usage (see http://www1.ietf.org/mail-archive/web/sip/current/msg11295.html); if that understanding is flawed, do let me know. Thanks, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 17 10:49:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15088 for ; Thu, 17 Mar 2005 10:49:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBxJd-0005Np-Gf for sip-web-archive@ietf.org; Thu, 17 Mar 2005 10:53:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBxEw-0003ON-Lx; Thu, 17 Mar 2005 10:48:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBxEt-0003Nt-KU; Thu, 17 Mar 2005 10:48:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14977; Thu, 17 Mar 2005 10:48:44 -0500 (EST) Received: from magus.nostrum.com ([69.5.195.2] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBxJ8-0005MP-5G; Thu, 17 Mar 2005 10:53:11 -0500 Received: from [192.168.0.102] (c-24-1-68-89.client.comcast.net [24.1.68.89]) (authenticated bits=0) by magus.nostrum.com (8.12.11/8.12.11) with ESMTP id j2HFmO8g074698 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 17 Mar 2005 09:48:25 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <53e36b1e49efc2bca92cb66ae812eeb3@nostrum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: "'sipping WG'" , sip-implementors@cs.columbia.edu, "sip@ietf.org WG" From: Robert Sparks Date: Thu, 17 Mar 2005 09:48:23 -0600 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Subject: [Sip] SIPIT 16 registration closes tomorrow X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit If you are planning to attend SIPIT 16 and have not yet registered, please do so now. Registration closes tomorrow (Friday 3/18). Information about the event and links to the registration pages are at http://www.sipit.net and http://sipit16.jasomi.com. Thanks, RjS _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 17 12:57:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00384 for ; Thu, 17 Mar 2005 12:57:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBzKC-00014a-La for sip-web-archive@ietf.org; Thu, 17 Mar 2005 13:02:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBzEZ-0007yo-N3; Thu, 17 Mar 2005 12:56:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBzEY-0007yi-3W for sip@megatron.ietf.org; Thu, 17 Mar 2005 12:56:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00161 for ; Thu, 17 Mar 2005 12:56:30 -0500 (EST) Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBzIo-00010G-8Z for sip@ietf.org; Thu, 17 Mar 2005 13:00:59 -0500 Received: from localhost.localdomain (mail.pingtel.com [192.168.253.2]) by mail.pingtel.com (Postfix) with ESMTP id 9D2776C01C; Thu, 17 Mar 2005 12:56:30 -0500 (EST) Subject: Re: [Sip] general rfc question From: Scott Lawrence To: Mohammed Smadi In-Reply-To: References: Content-Type: text/plain Organization: Pingtel Corp. http://www.pingtel.com/ Date: Thu, 17 Mar 2005 12:56:30 -0500 Message-Id: <1111082190.4866.71.camel@sukothai.pingtel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 (2.0.3-0.mozer.1) Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit On Mon, 2005-03-14 at 22:25 -0500, Mohammed Smadi wrote: > hi; > > i need someone to help me understand the concept of an rfc? Everyone is > referring to SIP rfc as the standard, or that is how it is being used when > it comes to implementing software. Now, there is alot of rfc's which are > very tightly coupled together, especially the ones which have to do with > conferencing and transfer. Are these just ideas or are they standards, or > what is exactly the status of these documents, given the fact that some of > them have expiry dates? A good place to start is: http://www.ietf.org/rfc/rfc2026.txt RFCs don't have expiry dates - Internet Drafts do. Incidentally, there has been quite a lot of discussion of this problem of how to track the status of various documents and how they relate to one another. The NEWTRK working group [1] has some interesting proposals about all this. [1] http://www.ietf.org/html.charters/newtrk-charter.html -- Scott Lawrence Consulting Engineer Pingtel Corp. http://www.pingtel.com/ +1.781.938.5306 x162 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 17 13:06:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01286 for ; Thu, 17 Mar 2005 13:06:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBzSV-0001Ko-NY for sip-web-archive@ietf.org; Thu, 17 Mar 2005 13:10:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBzNg-0002OL-Pu; Thu, 17 Mar 2005 13:06:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBzNe-0002OD-Vt for sip@megatron.ietf.org; Thu, 17 Mar 2005 13:05:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01217 for ; Thu, 17 Mar 2005 13:05:55 -0500 (EST) Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DBzRv-0001Jc-Oz for sip@ietf.org; Thu, 17 Mar 2005 13:10:25 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id j2HI5kk7027696; Thu, 17 Mar 2005 12:05:46 -0600 (CST) Received: from [135.185.173.147] (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id j2HI5j507309; Thu, 17 Mar 2005 12:05:45 -0600 (CST) Message-ID: <4239C6FA.2090707@lucent.com> Date: Thu, 17 Mar 2005 12:05:46 -0600 From: "Vijay K. Gurbani" User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohammed Smadi Subject: Re: [Sip] general rfc question References: <1111082190.4866.71.camel@sukothai.pingtel.com> In-Reply-To: <1111082190.4866.71.camel@sukothai.pingtel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit > Incidentally, there has been quite a lot of discussion of this problem > of how to track the status of various documents and how they relate to > one another. The NEWTRK working group [1] has some interesting > proposals about all this. > > [1] http://www.ietf.org/html.charters/newtrk-charter.html See also http://tools.ietf.org, and in particular, http://tools.ietf.org/wg. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Wireless Networks Group/Internet Software and Services Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440 Naperville, Illinois 60566 Voice: +1 630 224 0216 _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 18 01:41:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07819 for ; Fri, 18 Mar 2005 01:41:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCBFT-0002VG-V1 for sip-web-archive@ietf.org; Fri, 18 Mar 2005 01:46:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCB6u-0008RX-3n; Fri, 18 Mar 2005 01:37:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCB6r-0008RK-1R for sip@megatron.ietf.org; Fri, 18 Mar 2005 01:37:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07511 for ; Fri, 18 Mar 2005 01:37:23 -0500 (EST) Received: from mxs2.siemens.at ([194.138.12.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCBAy-0002OE-OX for sip@ietf.org; Fri, 18 Mar 2005 01:41:57 -0500 Received: from vies1k7x.sie.siemens.at ([158.226.129.83]) by mxs2.siemens.at with ESMTP id j2I6YmSh029861 for ; Fri, 18 Mar 2005 07:34:48 +0100 Received: from smtp.prgpu.anfdata.cz ([158.226.129.97]) by vies1k7x.sie.siemens.at (8.12.11/8.12.1) with ESMTP id j2I6auY8001601 for ; Fri, 18 Mar 2005 07:36:57 +0100 Received: from [163.242.69.44] (pcb1034.brqhe.anfdata.cz [163.242.69.44]) by smtp.prgpu.anfdata.cz (Postfix) with ESMTP id 8938A268A8 for ; Fri, 18 Mar 2005 07:36:56 +0100 (CET) Message-ID: <423A7708.7000509@siemens.com> Date: Fri, 18 Mar 2005 07:36:56 +0100 From: Zdenek Pernica User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Subject: [Sip] IPv6 syntax of 'received' param of Via X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Hi, Current syntax of IPv6 in 'received' param of Via in RFC 3261 violates general syntax of 'generic-param': via-received = "received" EQUAL (IPv4address / IPv6address) since there is IPv6address instead of IPv6reference. 'via-received' is not a subset of 'generic-param', which only complicates parser implementation. via-received cannot be matched as 'generic-param' just only within Via context, otherwise could. Former syntax of via-received in RFC 2543 was fully generic-param compliant: via-received = "received" "=" host I think that syntax of 'received' should be: via-received = "received" EQUAL (IPv4address / IPv6reference) (for RFC2543 and generic-param compatibility, and context independency) Is there a mistake in RFC 3261 or is presented syntax meant seriously ? _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 18 13:03:53 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04689 for ; Fri, 18 Mar 2005 13:03:53 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCLtj-0008F9-8q for sip-web-archive@ietf.org; Fri, 18 Mar 2005 13:08:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCLmn-0005yT-Ly; Fri, 18 Mar 2005 13:01:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCLml-0005yG-Mw for sip@megatron.ietf.org; Fri, 18 Mar 2005 13:01:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04450 for ; Fri, 18 Mar 2005 13:01:20 -0500 (EST) From: tammi.nguyen@conexant.com Received: from cnxtsmtp9.conexant.com ([198.62.9.205] helo=mime-nb.bbnet.ad) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCLrE-00084w-Tr for sip@ietf.org; Fri, 18 Mar 2005 13:06:02 -0500 Received: Conexant Mail To: sip@ietf.org Message-ID: Date: Fri, 18 Mar 2005 10:02:01 -0800 X-MIMETrack: Serialize by Router on NBLNBkup1/Server/Conexant (Release 6.5.3|September 14, 2004) at 03/18/2005 10:02:05 AM MIME-Version: 1.0 X-Spam-Score: 1.1 (+) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Sip] Tammi K Nguyen/USA/Conexant is out of the office. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0050633354==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 --===============0050633354== Content-type: multipart/alternative; Boundary="0__=07BBE55BDFF0895A8f9e8a93df938690918c07BBE55BDFF0895A" Content-Disposition: inline --0__=07BBE55BDFF0895A8f9e8a93df938690918c07BBE55BDFF0895A Content-type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I will be out of the office starting 03/18/2005 and will not return until 03/21/2005. ********************** Legal Disclaimer **************************** "This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you." ********************************************************************** --0__=07BBE55BDFF0895A8f9e8a93df938690918c07BBE55BDFF0895A Content-type: text/html; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: 7bit

I will be out of the office starting 03/18/2005 and will not return until 03/21/2005.

********************** Legal Disclaimer ****************************

"This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you."

**********************************************************************

--0__=07BBE55BDFF0895A8f9e8a93df938690918c07BBE55BDFF0895A-- --===============0050633354== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0050633354==-- From sip-bounces@ietf.org Fri Mar 18 16:20:08 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08429 for ; Fri, 18 Mar 2005 16:20:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCOxe-0003OR-Ew for sip-web-archive@ietf.org; Fri, 18 Mar 2005 16:24:50 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCOhu-0006X8-4l; Fri, 18 Mar 2005 16:08:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCOhs-0006Wm-Fn for sip@megatron.ietf.org; Fri, 18 Mar 2005 16:08:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04071 for ; Fri, 18 Mar 2005 16:08:30 -0500 (EST) Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCOmN-0001n2-3e for sip@ietf.org; Fri, 18 Mar 2005 16:13:12 -0500 Received: from [135.207.17.145] (lt-khp.research.att.com [135.207.17.145]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id j2IL8L327536 for ; Fri, 18 Mar 2005 16:08:21 -0500 (EST) Message-ID: <423B4344.6010907@research.att.com> Date: Fri, 18 Mar 2005 16:08:20 -0500 From: "K. Hal Purdy" User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Content-Transfer-Encoding: 7bit Subject: [Sip] UAS behavior dealing with "merged" request after dialog establishment X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit I have a question about UAS behavior related to detecting "merged" requests *after* the initial request has already resulted in an established dialog. If a UAC sends a request that goes through a parallel forking proxy, multiple forked requests may ultimately reach the same UAS. This is a known scenario and is covered in section 8.2.2.2 of 3261: If the request has no tag in the To header field, the UAS core MUST check the request against ongoing transactions. If the From tag, Call-ID, and CSeq exactly match those associated with an ongoing transaction, but the request does not match that transaction (based on the matching rules in Section 17.2.3), the UAS core SHOULD generate a 482 (Loop Detected) response and pass it to the server transaction. However, if the UAS has already sent a 2xx response to the first request received, there is no longer any "ongoing transaction." From Section 17.2.1: If, while in the "Proceeding" state, the TU passes a 2xx response to the server transaction, the server transaction MUST pass this response to the transport layer for transmission. ... The server transaction MUST then transition to the "Terminated" state....Once the transaction is in the "Terminated" state, it MUST be destroyed immediately. Barring any additional work on the part of the UAS to detect this condition, it seems that a subsequent merged request might be treated as an initial INVITE transaction. This doesn't seem like a good idea. What should the UAS do, and where is this behavior covered in a RFC? More generally, what normative statements can be made about the responsibilities of UASs as regards enforcing the uniqueness of Call-IDs, branch parameters, etc? Regards, Hal Purdy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Fri Mar 18 17:58:05 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18865 for ; Fri, 18 Mar 2005 17:58:05 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCQUT-0007oK-Bc for sip-web-archive@ietf.org; Fri, 18 Mar 2005 18:02:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCQO9-0000Wo-HJ; Fri, 18 Mar 2005 17:56:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DCQO7-0000Sn-6b for sip@megatron.ietf.org; Fri, 18 Mar 2005 17:56:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18683 for ; Fri, 18 Mar 2005 17:56:11 -0500 (EST) Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DCQSb-0007ju-Su for sip@ietf.org; Fri, 18 Mar 2005 18:00:55 -0500 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j2IMu5AR018959; Sat, 19 Mar 2005 07:56:05 +0900 (JST) Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j2IMu4AJ012930; Sat, 19 Mar 2005 07:56:04 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j2IMu4Ut012927; Sat, 19 Mar 2005 07:56:04 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j2IMu3dS011717; Sat, 19 Mar 2005 07:56:04 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j2IMu3Me011714; Sat, 19 Mar 2005 07:56:03 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j2IMu3CG021808; Sat, 19 Mar 2005 07:56:03 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j2IMu2dM016959; Sat, 19 Mar 2005 07:56:03 +0900 (JST) Received: from img.m.ecl.ntt.co.jp (img0.m.ecl.ntt.co.jp [129.60.5.145]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id j2IMu2kH016956; Sat, 19 Mar 2005 07:56:02 +0900 (JST) Received: from lab.ntt.co.jp by img.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with SMTP id HAA05814; Sat, 19 Mar 2005 07:56:00 +0900 (JST) From: Kumiko Ono To: sip@ietf.org Date: Fri, 18 Mar 2005 17:55:49 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: TuruKame 3.65 (WinNT,501) Message-Id: <31C52C0DA09A65ono.kumiko@lab.ntt.co.jp> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: shida@ntt-at.com, kumiko@cs.columbia.edu, tachimoto.shinya@lab.ntt.co.jp Subject: [Sip] e2m security: error code X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit At the SIP meeting last Tuesday, we discussed two issues of e2m security. I would like to resolve the issue that had no consensus. Issue: An error response for proxy to a UAC for combined condition, requiring decryption (disclosure of message) and signature simultaneously. Followings are the options I presented at Minneapolis: Option1: A new error response Option2: An existing error response(493) with Warning header Option3: Existing error responses, one task at time At the meeting, we had a consensus that when UA signs the body it should place the signature inside of the encrypted body, which means the proxy has no way to know the existence of signature until it is able to decrypt the message. By using option 3, the proxy can ask for diclosure first, find out if the message has a signature attached, and respond with another error requesting signature when the message lacks it. This can be done and it is general procedure of proxy, but the number of messages exchanged will increases as it needs to respond twice when signature is not present. Option 1 and 2 will resolve the downside mentioned with usage of option 3. If the local security policy of the proxy requires both signature and disclosure, it can send error with combined reason, regardless of the possible existence of signature in the encrypted message. With option 1, we need to define a new error code, such as 496 "Undecipherable and signature required". The error condition assumes that the signature is lackin. Additionaly, once introducing a new code for combined reasons, we might need more new codes for other combinations. Therefore, I don't advocate option 1. With option 2, we need to define a three-digit warning-code. As section 20.43 in RFC3261 says, >The Warning header field isused to carry additional information about the status of a response. The currently-defined "warn-code"s are induced by the SDP. This leads me to think that we can set a new warn-code that is induced by non-SDP. However, section 27.2 restricts the possible failures resulting from a SDP problem. If the reasoning restriction is not too stringent, we can define the following new warn-code, such as 340. However, it is strange to introduce a new warn-code that has the same meaning as that of the existing error code. Therefore, I am okay to go with option 3, not option 2. Your feedback will be very much appreciated. Thanks, -- Kumiko Ono _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Sun Mar 20 23:55:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29975 for ; Sun, 20 Mar 2005 23:55:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDF1z-0007xI-Ue for sip-web-archive@ietf.org; Mon, 21 Mar 2005 00:00:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDEvR-0003z0-S3; Sun, 20 Mar 2005 23:54:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDEvQ-0003yi-1V for sip@megatron.ietf.org; Sun, 20 Mar 2005 23:54:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29899 for ; Sun, 20 Mar 2005 23:53:57 -0500 (EST) Received: from web40721.mail.yahoo.com ([66.218.92.59]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DDF0O-0007t5-Iy for sip@ietf.org; Sun, 20 Mar 2005 23:59:09 -0500 Received: (qmail 41458 invoked by uid 60001); 21 Mar 2005 04:53:49 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=PumS4A0bOEPePhfJC7hCUKQoMyc4dvkFzq2sNMSBwcEZbCopXO0Vh3NvCL2pq4YKgFA6hUg3EtSDpA8KSuoE9hdl98Zpr+Ww6D7k7+ydESZ7EWIQkCQtcxUJ4yubZtI8z/K8mli3Q/FmmJh/vD5Cp/glrIHYMmGFNCQ6GBHHXfU= ; Message-ID: <20050321045349.41456.qmail@web40721.mail.yahoo.com> Received: from [220.227.179.5] by web40721.mail.yahoo.com via HTTP; Sun, 20 Mar 2005 20:53:49 PST Date: Sun, 20 Mar 2005 20:53:49 -0800 (PST) From: Manish Joshi To: sip@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Sip] SIP and POTS like Voice Grade Services X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Hi All, The protocols like H.248 were developed with 'voice and telephony' being the basic target services unlike SIP and that might be the reason that H.248 has specific packages dedicated for services such as 'generic announcements, line tests, enhanced alerting, tone detection, enhanced analog etc. I do find some SIP drafts here and there detailing such services, but is there a dedicated SIP group working on this or standards published for providing these services using SIP ? The focus is to see how a residential gateway like equipment use SIP for these services and eliminate need for a 5ESS. TIA, Manish __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 21 16:03:23 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22785 for ; Mon, 21 Mar 2005 16:03:23 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDU8g-0001CR-KT for sip-web-archive@ietf.org; Mon, 21 Mar 2005 16:08:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDTku-0007fr-RO; Mon, 21 Mar 2005 15:44:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDTks-0007fm-PH for sip@megatron.ietf.org; Mon, 21 Mar 2005 15:44:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17530 for ; Mon, 21 Mar 2005 15:44:04 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDTpy-0007U0-TJ for sip@ietf.org; Mon, 21 Mar 2005 15:49:25 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 21 Mar 2005 12:43:54 -0800 X-IronPort-AV: i="3.91,107,1110182400"; d="asc'?scan'208"; a="238390211:sNHT1096547368" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j2LKhogE012151 for ; Mon, 21 Mar 2005 12:43:50 -0800 (PST) Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j2LKagJb008501 for ; Mon, 21 Mar 2005 12:36:42 -0800 From: Michael Thomas To: sip@ietf.org Organization: Cisco Systems Message-Id: <1111437831.12302.16.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Mon, 21 Mar 2005 12:43:51 -0800 IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1111437402.963581"; x:"432200"; a:"rsa-sha1"; b:"nofws:1802"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"q+QYvGO/GldPqGy3cVWH8MnRY4Lj+kOcfH+A29d2ZJDI6Ox6kY4WSMLsfoWOI65Ey4z1bvcj" "xG90jUaeRvEu7sb1e6MxztgEnsntuPgYU4MpaWVJoWPRu+aDE+0mMmICmZ+4Z27gC4YGNtMA+dC" "dW7TWYtymx9JmtGf9OAxkzd4="; c:"Subject: high level sip-identity comments"; c:"From: Michael Thomas "; c:"Date: Mon, 21 Mar 2005 12:43:51 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Subject: [Sip] high level sip-identity comments X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2013124375==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 --===============2013124375== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Fo6jYS+jF7yM3eFPqc1m" --=-Fo6jYS+jF7yM3eFPqc1m Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I did a slightly better cursory reading of sip-identity and have some questions. 1) The draft seems to conflate authentication and=20 authorization. That is, just because I have a certificate for something in a given domain doesn't mean that I'm authorized to speak on behalf of the domain. How is the receiver supposed to know if a given cert is authorized to sign, say, outgoing SIP messages? 2) There is reference to fetching the cert via the=20 IDENITY-INFO headers, but this seems to be really underspecified. What is the format of the request URI? Can it take GET/POST requests? Can GET/POST=20 send parameters? What is the format of the return value from the query? Since this draft is intended for inter-domain use where there can't be an expectation of a prior introduction, I don't think this can be handwaved. 3) I must have missed it, but I didn't see any discussion of header and body canonicalization. How is the hash that goes into the RSA signature constructed? Which headers? What is the order they are fed? Does whitespace count?=20 What about volatile headers like Via... how does the receiver know which headers to feed into the hash?=20 Likewise, are their extant weirdisms like in email that proxies, etc, munge headers and/or bodies? If so, then what? 4) As Jonathan also pointed out, there's no way to express whether a domain has a policy of "we sign everything". Unless that's available, you have a trivial bid down attack by simply not adding an Identity header to your SIP method of choice. I guess that's enough for now. Mike --=-Fo6jYS+jF7yM3eFPqc1m Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUAQj8yB7MsDAj/Eq++AQKZqwP/UfP1qMxIO3nVOlm/H0sI/ZegsPQccS35 kJ0hSQt9GepRTW7TpvSF6/1wO98Kv6x3dr/dRiPcByZMAspRitrACzyFRhj1rG4q 3YYBX061u5Ka9IT1KQxXbrWod56JWFmpKc4IpByM/Zcu23Ckcg7mgj8zNWIX3kBO eC6D3XieDnM= =NVCh -----END PGP SIGNATURE----- --=-Fo6jYS+jF7yM3eFPqc1m-- --===============2013124375== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2013124375==-- From sip-bounces@ietf.org Mon Mar 21 23:42:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07062 for ; Mon, 21 Mar 2005 23:42:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDbIo-0001RI-HC for sip-web-archive@ietf.org; Mon, 21 Mar 2005 23:47:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDbBC-0005a3-G2; Mon, 21 Mar 2005 23:39:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDbB0-0005Zy-VN for sip@megatron.ietf.org; Mon, 21 Mar 2005 23:39:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06915 for ; Mon, 21 Mar 2005 23:39:32 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDbGD-0001OX-8B for sip@ietf.org; Mon, 21 Mar 2005 23:44:57 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 21 Mar 2005 20:39:25 -0800 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j2M4dMgS002777; Mon, 21 Mar 2005 20:39:23 -0800 (PST) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Mar 2005 20:39:30 -0800 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 21 Mar 2005 20:39:21 -0800 Subject: Re: [Sip] high level sip-identity comments From: Cullen Jennings To: Michael Thomas , "sip@ietf.org" Message-ID: In-Reply-To: <1111437831.12302.16.camel@thomasm-lnx.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Mar 2005 04:39:30.0657 (UTC) FILETIME=[2345AD10:01C52E99] X-Spam-Score: 1.1 (+) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: Jon Peterson X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit Thanks for the read - few inline... On 3/21/05 12:43 PM, "Michael Thomas" wrote: > > I did a slightly better cursory reading of sip-identity > and have some questions. > > 1) The draft seems to conflate authentication and > authorization. That is, just because I have a certificate > for something in a given domain doesn't mean that I'm > authorized to speak on behalf of the domain. How is > the receiver supposed to know if a given cert is authorized > to sign, say, outgoing SIP messages? It seems that attributes about what a certificate can be used for are widely ignored so we have just gone with the idea that if you have the private key, then the assumptions is you are authorized to sign. The expectation that these attributes are checked when they are not seemed like more of a security risk than the alternative. Note the domain could choose separate domains for separate services - for example SIP could be sip.example.com while web was www.example.com > > 2) There is reference to fetching the cert via the > IDENITY-INFO headers, but this seems to be really > underspecified. What is the format of the request > URI? Can it take GET/POST requests? Can GET/POST > send parameters? What is the format of the return > value from the query? Since this draft is intended > for inter-domain use where there can't be an expectation > of a prior introduction, I don't think this can be > handwaved. agreed - got the message loud and clear from a few people. we will fix the text to clear up the confusion about how this can be done. > > 3) I must have missed it, but I didn't see any discussion > of header and body canonicalization. How is the hash > that goes into the RSA signature constructed? Which headers? > What is the order they are fed? Does whitespace count? > What about volatile headers like Via... how does the > receiver know which headers to feed into the hash? > Likewise, are their extant weirdisms like in email that > proxies, etc, munge headers and/or bodies? If so, then > what? > I think we tried to be very clear in what we hashed such that for the most part no canonicalization is necessary - that is why we specified specific sub fields from the BNF. Some things like the date we did have to provide some additional canonicalization text for. In the body, everything is bit for bit copied including. > 4) As Jonathan also pointed out, there's no way to express > whether a domain has a policy of "we sign everything". > Unless that's available, you have a trivial bid down > attack by simply not adding an Identity header to your > SIP method of choice. > Yep - agree. I thought we discussed this is the draft but perhaps I just wish we did :-) I don't see any solution to this other than for enough people to implement this that at some point in time it is practical to switch to requiring it. I know ideas involved using DNS to find out have been bounced around and perhaps future work could deal with that. They proposal I have heard so far mostly seem to rely on DNSSec. > I guess that's enough for now. Thanks, Cullen > > Mike > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Mon Mar 21 23:48:49 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07962 for ; Mon, 21 Mar 2005 23:48:49 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDbPC-0001lm-TP for sip-web-archive@ietf.org; Mon, 21 Mar 2005 23:54:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDbHk-0006nB-JL; Mon, 21 Mar 2005 23:46:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDbHe-0006n6-H0 for sip@megatron.ietf.org; Mon, 21 Mar 2005 23:46:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07664 for ; Mon, 21 Mar 2005 23:46:23 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDbMq-0001hR-Nw for sip@ietf.org; Mon, 21 Mar 2005 23:51:49 -0500 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 21 Mar 2005 20:46:17 -0800 Received: from vtg-um-e2k4.sj21ad.cisco.com (vtg-um-e2k4.cisco.com [171.70.93.57]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j2M4kE3S009700; Mon, 21 Mar 2005 20:46:14 -0800 (PST) Received: from [127.0.0.1] ([171.68.225.134]) by vtg-um-e2k4.sj21ad.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 21 Mar 2005 20:46:22 -0800 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 21 Mar 2005 20:46:12 -0800 Subject: Re: [Sip] P-Alerting-Mode to standards track? From: Cullen Jennings To: Dean Willis , "sip@ietf.org" Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 22 Mar 2005 04:46:22.0317 (UTC) FILETIME=[18A401D0:01C52E9A] X-Spam-Score: 1.1 (+) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: 7bit Cc: Andrew Allen , Rohan Mahy , Allison Mankin X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit On the requirement, I would like to have this functionality. On the mechanism, I would expect this to lead to a few discussions. On 3/15/05 12:08 PM, "Dean Willis" wrote: > > One of the consensus points that seemed to emerge during the recent > meeting was around the proposed P-Alerting-Mode header. We appear to > have decided that we really do need a standard (NOT a P-header) way to > ask a UAS to "auto answer", whether for a diagnostic loopback or > push-to-talk application. There also seems to be a consensus that this > should be done with a header, rather than a request parameter or other > mechanism. > > So, it has been proposed that this header be withdrawn from the > P-header "informational" draft, and re-documented on standards track. > > If we pursue this path, it should be noted that we would need to do it > very quickly, as OMA has real needs for this functionality ASAP. I'll > volunteer to help Andrew get it whipped into shape, unless somebody > else wants to throw themselves on it. It seems like a relative > no-brainer, just an exercise in documentation. > > So, poll for consensus: Does anybody strongly object to the development > of a standard header for requesting auto-answer of a request? > > Second poll: Do we see any reasons why this couldn't be done fairly > quickly, such as obvious dependencies on ongoing work that I've just > missed? > > > Thanks, > > -- > Dean Willis > SIP WG chair > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 22 11:43:00 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03366 for ; Tue, 22 Mar 2005 11:43:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDmYQ-0002CJ-Hx for sip-web-archive@ietf.org; Tue, 22 Mar 2005 11:48:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDmJ8-0000Nm-4Z; Tue, 22 Mar 2005 11:32:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDmJ6-0000Mk-Aj for sip@megatron.ietf.org; Tue, 22 Mar 2005 11:32:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01940 for ; Tue, 22 Mar 2005 11:32:38 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDmOO-0001Zc-IZ for sip@ietf.org; Tue, 22 Mar 2005 11:38:09 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 22 Mar 2005 08:32:30 -0800 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j2MGWSZV015439; Tue, 22 Mar 2005 08:32:28 -0800 (PST) Received: from thomasm-lnx.cisco.com (thomasm-lnx.cisco.com [171.71.96.50]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j2MGPFXd014671; Tue, 22 Mar 2005 08:25:15 -0800 Subject: Re: [Sip] high level sip-identity comments From: Michael Thomas To: Cullen Jennings In-Reply-To: References: Organization: Cisco Systems Message-Id: <1111509146.14289.59.camel@thomasm-lnx.cisco.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Tue, 22 Mar 2005 08:32:27 -0800 IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1111508715.540407"; x:"432200"; a:"rsa-sha1"; b:"nofws:6215"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"ixOeMOkTsV+Q8j+AevAhL4iAHVZYlwnychZi3y0vjJY1MtSnPPWsfrsEkpnt8sf81p0mLEXQ" "2aDubJXZxCf4h//8Zyv+hB4I10EdZTteRN49tguIXel/hj7XC5A7sD7msqNjoh9Npf2FXcRl0Nz" "OVWoUIB+BWqNS77SKaz0+uN4="; c:"Subject: Re: [Sip] high level sip-identity comments"; c:"From: Michael Thomas "; c:"Date: Tue, 22 Mar 2005 08:32:27 -0800" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 848ed35f2a4fc0638fa89629cb640f48 Cc: "sip@ietf.org" , Jon Peterson X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0534186012==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 43317e64100dd4d87214c51822b582d1 --===============0534186012== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-K64aKRko5T/hHjyUu/9G" --=-K64aKRko5T/hHjyUu/9G Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2005-03-21 at 20:39, Cullen Jennings wrote: > Thanks for the read - few inline... >=20 > On 3/21/05 12:43 PM, "Michael Thomas" wrote: >=20 > >=20 > > I did a slightly better cursory reading of sip-identity > > and have some questions. > >=20 > > 1) The draft seems to conflate authentication and > > authorization. That is, just because I have a certificate > > for something in a given domain doesn't mean that I'm > > authorized to speak on behalf of the domain. How is > > the receiver supposed to know if a given cert is authorized > > to sign, say, outgoing SIP messages? >=20 > It seems that attributes about what a certificate can be used for are wid= ely > ignored so we have just gone with the idea that if you have the private k= ey, > then the assumptions is you are authorized to sign. The expectation that > these attributes are checked when they are not seemed like more of a > security risk than the alternative. Note the domain could choose separate > domains for separate services - for example SIP could be sip.example.com > while web was www.example.com Name space separation _can_ work, but has to be completely specified: as the receiver, I have no idea whether sip.example.com is authorized to sign for a domain anymore than=20 party.on.d00d.example.com is legitimate. Since this needs to work in the case where there is no established relationship between the two parties, you'd need to partition the namespace as part of the standard itself. That said, I don't really like carving off portions of the namespace unless you really have no alternative. This is especially true for certs since there isn't an equivalent of IANA saying that the namespace prefix of _xyz is reserved (at least that I know of). The other part is that this just serves to propagate the conflation of auth and authz. In IIM, we are very explicit that the purpose of the record coming back from the KRS is an _authorization_ record, and that the authorization is bounded for particular services (eg SMTP).=20 Explicit authorization, either in the cert itself, or in a authz service (ala KRS) would be a lot safer. =20 > > 2) There is reference to fetching the cert via the > > IDENITY-INFO headers, but this seems to be really > > underspecified. What is the format of the request > > URI? Can it take GET/POST requests? Can GET/POST > > send parameters? What is the format of the return > > value from the query? Since this draft is intended > > for inter-domain use where there can't be an expectation > > of a prior introduction, I don't think this can be > > handwaved. >=20 > agreed - got the message loud and clear from a few people. we will fix th= e > text to clear up the confusion about how this can be done. The other thing that confused me was whether it was assumed that I'd need to fetch the cert in _all_ cases (modulo caching). That is, if I'm a signer do I need to put this cert-fetch service up so that others can get my certs? It's possible I missed it, but I didn't see a way to ship the cert in the method=20 itself. If it is the case that you'd be expected to get it from this server, you ought to consider whether the payload the server returns also has authz information. Also: at the point that you're fetching something from a home cert server, I'm not sure what the PKI aspects of are buying you other than the general hassle of having to get those certs, etc, etc. In IIM, we could have said that the identities were X.509 ones but it seemed like vast overkill, not to=20 mention that it's very confusing. Which is why we decided to support identities that can be auto-generated by using the uniqueness properties of the public key itself. >=20 > >=20 > > 3) I must have missed it, but I didn't see any discussion > > of header and body canonicalization. How is the hash > > that goes into the RSA signature constructed? Which headers? > > What is the order they are fed? Does whitespace count? > > What about volatile headers like Via... how does the > > receiver know which headers to feed into the hash? > > Likewise, are their extant weirdisms like in email that > > proxies, etc, munge headers and/or bodies? If so, then > > what? > > > =20 > I think we tried to be very clear in what we hashed such that for the mos= t > part no canonicalization is necessary - that is why we specified specific > sub fields from the BNF. Some things like the date we did have to provide > some additional canonicalization text for. In the body, everything is bit > for bit copied including. When I say canonicalization, it doesn't have to mean that the bits need to be altered or massaged or anything like that, only how and what is marshalled through the one-way hash. Experience here shows that it is impossible to be too explicit: it's where interoperability usually goes to hell in a handbasket. For example, when you say add a header, does that include or not include syntactic=20 whitespace? What about things that might reformat headers? What about continuation headers? What about header reordering? (in mail, this is just a fact of life, with SIP it may be present in some proxies/UA's and you don't realize it).=20 Also: it seems to me that just having the signature in=20 the sig line isn't sufficient. In IIM, we have a version, a time to live, and several other fields as well. I'm=20 also uncomfortable with having an explicit enumeration of which headers are signed in the spec without a=20 mechanism for adding new protected headers... and if the mechanism is issuing a new RFC, that's losage. And what about multiple signatures? If a message passes through multiple domains, what does that mean? What does a receiver do if it finds multiple signatures? Is there the possibility that supposedly transparent proxies will modify any of the headers and/or body parts (in mail, the obvious example are mailing lists).=20 >=20 > > 4) As Jonathan also pointed out, there's no way to express > > whether a domain has a policy of "we sign everything". > > Unless that's available, you have a trivial bid down > > attack by simply not adding an Identity header to your > > SIP method of choice. > >=20 >=20 > Yep - agree. I thought we discussed this is the draft but perhaps I just > wish we did :-) I don't see any solution to this other than for enough > people to implement this that at some point in time it is practical to > switch to requiring it. I know ideas involved using DNS to find out have > been bounced around and perhaps future work could deal with that. They > proposal I have heard so far mostly seem to rely on DNSSec. It could rely on either DNSsec or PKI ala TLS server certs; there are tradeoffs for either approach. It could be both for that matter -- or neither depending on risks.=20 The same thing goes for your cert server for that matter:=20 when I'm fetching the cert, how do I know that I'm not being redirected to a bogus server? This needs to be addressed at=20 the very least in your security considerations. Mike --=-K64aKRko5T/hHjyUu/9G Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iQCVAwUAQkBImrMsDAj/Eq++AQJykwP+Nsknoj98IYaIynoziYQgCNEyOLd2HZV4 VTagXnTNkS9BCunsVR+2Wm+HoviAD07ZyfWSZrRKHRMiQmS+K54tkO43/nSXW13q paamCqOWyaALxwqrBfWBSgmp52pRyPWOubtV8zCS5qm42Ndzji9OSz+ibvyGkAWA 1rWTURFJj2g= =ahdm -----END PGP SIGNATURE----- --=-K64aKRko5T/hHjyUu/9G-- --===============0534186012== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0534186012==-- From sip-bounces@ietf.org Tue Mar 22 12:07:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05643 for ; Tue, 22 Mar 2005 12:07:40 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDmwJ-0003AQ-Sj for sip-web-archive@ietf.org; Tue, 22 Mar 2005 12:13:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDmnR-00069S-3i; Tue, 22 Mar 2005 12:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDmnO-00069B-R6 for sip@megatron.ietf.org; Tue, 22 Mar 2005 12:03:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05311 for ; Tue, 22 Mar 2005 12:03:56 -0500 (EST) Received: from [80.74.106.10] (helo=rvil-mail.RADVISION.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDmsh-0002vn-Dh for sip@ietf.org; Tue, 22 Mar 2005 12:09:28 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Mar 2005 19:03:49 +0200 Message-ID: Thread-Topic: About register expiration Thread-Index: AcUvAR4o6sVAZL5oRoKc9O8D+TQLKQ== From: "Rachel Danor" To: X-Spam-Score: 0.4 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Subject: [Sip] About register expiration X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0068781614==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: 8068004c042dabd7f1301bcc80e039df This is a multi-part message in MIME format. --===============0068781614== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C52F01.1E065AFB" This is a multi-part message in MIME format. ------_=_NextPart_001_01C52F01.1E065AFB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have a question the SIP standard definitions for "expires" handling in the registration. This is what I see in paragraph 10.3: The registrar returns a 200 (OK) response. The response MUST contain Contact header field values enumerating all current bindings. Each Contact value MUST feature an "expires" parameter indicating its expiration interval chosen by the registrar. =20 From this I understand that the 200OK must include expires parameter in the contact header. On the other hand when I look at message examples in paragraph 24.1, I see the following: F1 REGISTER Bob -> Registrar REGISTER sip:registrar.biloxi.com SIP/2.0 Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=3Dz9hG4bKnashds7 Max-Forwards: 70 To: Bob From: Bob ;tag=3D456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: Expires: 7200 Content-Length: 0 F2 200 OK Registrar -> Bob SIP/2.0 200 OK Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=3Dz9hG4bKnashds7 ;received=3D192.0.2.4 To: Bob ;tag=3D2493k59kd From: Bob ;tag=3D456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: Expires: 7200 Content-Length: 0 Where the registrar does not set the expires parameter in the contact header, but leaves it in the Expires header. Which is correct? Is it allowed to have both Expires header and expires parameter for Contact headers in the 200OK? Regards, Rachel Danor ------_=_NextPart_001_01C52F01.1E065AFB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable About register expiration

    Hi,

    I = have a question the SIP standard definitions for "expires" = handling in the registration.

    This is what I see in paragraph 10.3:

    The registrar returns a 200 (OK) response.  = The response MUST contain Contact header field values enumerating all = current bindings.  Each Contact value MUST feature an = "expires" parameter indicating its expiration interval chosen by the = registrar. 

    From this I understand that the 200OK must include expires parameter in the = contact header.

    On = the other hand when I look at message examples in paragraph 24.1, I see = the following:


       F1 REGISTER Bob -> Registrar

           REGISTER sip:registrar.biloxi.com SIP/2.0

           Via: = SIP/2.0/UDP = bobspc.biloxi.com:5060;branch=3Dz9hG4bKnashds7

           Max-Forwards: 70

           To: Bob = <sip:bob@biloxi.com>

           From: Bob = <sip:bob@biloxi.com>;tag=3D456248

           Call-ID: = 843817637684230@998sdasdh09

           CSeq: 1826 = REGISTER

           Contact: = <sip:bob@192.0.2.4>

           Expires: = 7200

           = Content-Length: 0




       F2 200 OK Registrar = -> Bob

            SIP/2.0 = 200 OK

            Via: = SIP/2.0/UDP = bobspc.biloxi.com:5060;branch=3Dz9hG4bKnashds7

             ;received=3D192.0.2.4

            To: Bob = <sip:bob@biloxi.com>;tag=3D2493k59kd

            From: = Bob <sip:bob@biloxi.com>;tag=3D456248

            Call-ID: = 843817637684230@998sdasdh09

            CSeq: = 1826 REGISTER

            Contact: = <sip:bob@192.0.2.4>

            = Expires: = 7200

            = Content-Length: 0

    Where = the registrar does not set the expires parameter in the contact header, = but leaves it in the Expires header.

    Which is = correct? Is it allowed to have both Expires header and expires parameter = for Contact headers in the 200OK?


Regards,

Rachel Danor


------_=_NextPart_001_01C52F01.1E065AFB-- --===============0068781614== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0068781614==-- From sip-bounces@ietf.org Tue Mar 22 12:08:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05725 for ; Tue, 22 Mar 2005 12:08:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDmwq-0003Bb-Dr for sip-web-archive@ietf.org; Tue, 22 Mar 2005 12:13:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDmaP-0004in-FR; Tue, 22 Mar 2005 11:50:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDmaO-0004ii-8e for sip@megatron.ietf.org; Tue, 22 Mar 2005 11:50:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04089 for ; Tue, 22 Mar 2005 11:50:29 -0500 (EST) Received: from airwolf.sentito.com ([65.202.222.11]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DDmfg-0002Si-TE for sip@ietf.org; Tue, 22 Mar 2005 11:56:01 -0500 Received: (qmail 51104 invoked by uid 1014); 22 Mar 2005 16:49:59 -0000 Received: from shanlu@sentito.com by airwolf.sentito.com by uid 1002 with qmail-scanner-1.22 (clamdscan: 0.83. spamassassin: 2.63. Clear:RC:1(65.202.222.2):. Processed in 0.065546 secs); 22 Mar 2005 16:49:59 -0000 Received: from unknown (HELO SAJAK) (65.202.222.2) by airwolf.sentito.com with SMTP; 22 Mar 2005 16:49:59 -0000 From: "Shan Lu" To: "'K. Hal Purdy'" , Subject: RE: [Sip] UAS behavior dealing with "merged" request after dialogestablishment Date: Tue, 22 Mar 2005 11:51:37 -0500 Message-ID: <0c6201c52eff$69d48240$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <423B4344.6010907@research.att.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: 7bit Hi, Your question touched two issues in RFC3261. The first is late arrival of a retransmitted INVITE at UAS. Note although you are interested in forking, your situation is no different than a retransmitted INVITE arriving after the INVITE server transaction has terminated. See http://www1.ietf.org/mail-archive/web/sip/current/msg10326.html. The proposed solution is to keep the original INVITE transaction a bit longer (till ACK). Then you will run into second issue. See http://www1.ietf.org/mail-archive/web/sip/current/msg10432.html. Depending on your system, Section 8.2.2.2/RFC3261 does not always make sense. The prescribed behavior for merged requests is incomplete and often times broken. Regards, Shan Lu >-----Original Message----- >From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >Behalf Of K. Hal Purdy >Sent: Friday, March 18, 2005 4:08 PM >To: sip@ietf.org >Subject: [Sip] UAS behavior dealing with "merged" request >after dialogestablishment > > >I have a question about UAS behavior related to detecting "merged" >requests *after* the initial request has already resulted in an >established dialog. If a UAC sends a request that goes through a >parallel forking proxy, multiple forked requests may ultimately reach >the same UAS. This is a known scenario and is covered in >section 8.2.2.2 >of 3261: > > If the request has no tag in the To header field, the UAS core MUST > check the request against ongoing transactions. If the From tag, > Call-ID, and CSeq exactly match those associated with an ongoing > transaction, but the request does not match that transaction (based > on the matching rules in Section 17.2.3), the UAS core SHOULD > generate a 482 (Loop Detected) response and pass it to the server > transaction. > > However, if the UAS has already sent a 2xx response to the first >request received, there is no longer any "ongoing transaction." From >Section 17.2.1: > > If, while in the "Proceeding" state, the TU passes a 2xx response to > the server transaction, the server transaction MUST pass this > response to the transport layer for transmission. ... The server >transaction MUST then > transition to the "Terminated" state....Once the transaction is in >the "Terminated" state, it MUST be > destroyed immediately. > >Barring any additional work on the part of the UAS to detect this >condition, it seems that a subsequent merged request might be >treated as >an initial INVITE transaction. This doesn't seem like a good >idea. What >should the UAS do, and where is this behavior covered in a RFC? > >More generally, what normative statements can be made about the >responsibilities of UASs as regards enforcing the uniqueness of >Call-IDs, branch parameters, etc? > >Regards, >Hal Purdy > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 22 12:33:17 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08477 for ; Tue, 22 Mar 2005 12:33:17 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDnL6-0004Da-N8 for sip-web-archive@ietf.org; Tue, 22 Mar 2005 12:38:49 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDnDn-0003nV-RW; Tue, 22 Mar 2005 12:31:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDnDl-0003nN-F9 for sip@megatron.ietf.org; Tue, 22 Mar 2005 12:31:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08327 for ; Tue, 22 Mar 2005 12:31:10 -0500 (EST) From: Udit_Goyal@3com.com Received: from plmler6.mail.eds.com ([199.228.142.66]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDnIz-0004AY-Sb for sip@ietf.org; Tue, 22 Mar 2005 12:36:42 -0500 Received: from plmlir3.mail.eds.com (plmlir3-2.mail.eds.com [199.228.142.133]) by plmler6.mail.eds.com (8.13.2/8.12.10) with ESMTP id j2MHV2qR017081; Tue, 22 Mar 2005 11:31:06 -0600 Received: from plmlir3.mail.eds.com (localhost [127.0.0.1]) by plmlir3.mail.eds.com (8.13.2/8.12.10) with ESMTP id j2MHUXMn004140; Tue, 22 Mar 2005 11:30:33 -0600 Received: from usut001.3com.com ([205.142.126.149]) by plmlir3.mail.eds.com (8.13.2/8.12.10) with ESMTP id j2MHUXYw004135; Tue, 22 Mar 2005 11:30:33 -0600 In-Reply-To: MIME-Version: 1.0 To: "Rachel Danor" Subject: Re: [Sip] About register expiration X-Mailer: Lotus Notes Release 6.5.2 June 01, 2004 Message-ID: Date: Tue, 22 Mar 2005 12:35:51 -0500 X-MIMETrack: Serialize by Router on USUT001/US/3Com(Release 6.0.3|September 26, 2003) at 03/22/2005 09:30:42 AM, Serialize complete at 03/22/2005 09:30:42 AM X-Spam-Score: 1.1 (+) X-Scan-Signature: 7698d1420ecbbce1995432e99bb6d1a1 Cc: sip@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0635689352==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.1 (+) X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd This is a multipart message in MIME format. --===============0635689352== Content-Type: multipart/alternative; boundary="=_alternative 0060271385256FCC_=" This is a multipart message in MIME format. --=_alternative 0060271385256FCC_= Content-Type: text/plain; charset="US-ASCII" Hi Rachel, Expiration information can be present in Expires header or expires paramter. However, Contact header "expires" paramter has preference over Expires header, if expires parameter is present, it will be used otherwise expiration value present in Expires header will be used. -Udit Sent by: sip-bounces@ietf.org To: cc: Subject: [Sip] About register expiration Hi, I have a question the SIP standard definitions for "expires" handling in the registration. This is what I see in paragraph 10.3: The registrar returns a 200 (OK) response. The response MUST contain Contact header field values enumerating all current bindings. Each Contact value MUST feature an "expires" parameter indicating its expiration interval chosen by the registrar. >From this I understand that the 200OK must include expires parameter in the contact header. On the other hand when I look at message examples in paragraph 24.1, I see the following: F1 REGISTER Bob -> Registrar REGISTER sip:registrar.biloxi.com SIP/2.0 Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 Max-Forwards: 70 To: Bob From: Bob ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: Expires: 7200 Content-Length: 0 F2 200 OK Registrar -> Bob SIP/2.0 200 OK Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 ;received=192.0.2.4 To: Bob ;tag=2493k59kd From: Bob ;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: Expires: 7200 Content-Length: 0 Where the registrar does not set the expires parameter in the contact header, but leaves it in the Expires header. Which is correct? Is it allowed to have both Expires header and expires parameter for Contact headers in the 200OK? Regards, Rachel Danor _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --=_alternative 0060271385256FCC_= Content-Type: text/html; charset="US-ASCII"
Hi Rachel,

Expiration information can be present in Expires header or expires paramter.
However, Contact header "expires" paramter has preference over Expires header,
if expires parameter is present, it will be used
otherwise expiration value present in Expires header will be used.

-Udit



Sent by:        sip-bounces@ietf.org  

To:        <sip@ietf.org>
cc:        
Subject:        [Sip] About register expiration




Hi,

I have a question the SIP standard definitions for "expires" handling in the registration.

This is what I see in paragraph 10.3:

The registrar returns a 200 (OK) response.  The response MUST contain Contact header field values enumerating all current bindings.  Each Contact value MUST feature an "expires" parameter indicating its expiration interval chosen by the registrar. 

From this I understand that the 200OK must include expires parameter in the contact header.

On the other hand when I look at message examples in paragraph 24.1, I see the following:

   F1 REGISTER Bob -> Registrar

      REGISTER sip:registrar.biloxi.com SIP/2.0

       Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7

      Max-Forwards: 70

       To: Bob <sip:bob@biloxi.com>

       From: Bob <sip:bob@biloxi.com>;tag=456248

       Call-ID: 843817637684230@998sdasdh09

       CSeq: 1826 REGISTER

       Contact: <sip:bob@192.0.2.4>

       Expires: 7200

       Content-Length: 0



  F2 200 OK Registrar -> Bob

        SIP/2.0 200 OK

        Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7

        ;received=192.0.2.4

        To: Bob <sip:bob@biloxi.com>;tag=2493k59kd

        From: Bob <sip:bob@biloxi.com>;tag=456248

        Call-ID: 843817637684230@998sdasdh09

        CSeq: 1826 REGISTER

        Contact: <sip:bob@192.0.2.4>

        Expires: 7200

        Content-Length: 0

Where the registrar does not set the expires parameter in the contact header, but leaves it in the Expires header.

Which is correct? Is it allowed to have both Expires header and expires parameter for Contact headers in the 200OK?

Regards,

Rachel Danor


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip


 
--=_alternative 0060271385256FCC_=-- --===============0635689352== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0635689352==-- From sip-bounces@ietf.org Tue Mar 22 13:21:03 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14367 for ; Tue, 22 Mar 2005 13:21:03 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDo5K-0006L4-GP for sip-web-archive@ietf.org; Tue, 22 Mar 2005 13:26:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDnyQ-0004qK-S7; Tue, 22 Mar 2005 13:19:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDnyM-0004q7-Uv for sip@megatron.ietf.org; Tue, 22 Mar 2005 13:19:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14222 for ; Tue, 22 Mar 2005 13:19:19 -0500 (EST) Received: from mailout.excelswitching.com ([208.236.123.107]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDo3f-0006ID-3T for sip@ietf.org; Tue, 22 Mar 2005 13:24:52 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] UAS behavior dealing with "merged" request afterdialogestablishment Date: Tue, 22 Mar 2005 13:19:06 -0500 Message-ID: <656BE56E7D48F6419054CC1C811149270239FB47@exch01.corp.xl.com> Thread-Topic: [Sip] UAS behavior dealing with "merged" request afterdialogestablishment Thread-Index: AcUu/9u8Ze7x4eRXRemoB39ptvX+uQACr3Ew From: "Jain, Rajnish" To: "Shan Lu" , "K. Hal Purdy" , X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Content-Transfer-Encoding: quoted-printable X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Content-Transfer-Encoding: quoted-printable Instead of tweaking the transaction state machine behavior, why couldn't this be handled at TU Core. When the retransmitted INVITE arrives at TU Core, you can match it w/ ongoing dialogs while taking into account only the UAC-half of the dialog id. =20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Shan Lu Sent: Tuesday, March 22, 2005 11:52 AM To: 'K. Hal Purdy'; sip@ietf.org Subject: RE: [Sip] UAS behavior dealing with "merged" request afterdialogestablishment Hi, Your question touched two issues in RFC3261. The first is late arrival of a retransmitted INVITE at UAS. Note although you are interested in forking, your situation is no different than a retransmitted INVITE arriving after the INVITE server transaction has terminated. See http://www1.ietf.org/mail-archive/web/sip/current/msg10326.html. The proposed solution is to keep the original INVITE transaction a bit longer (till ACK). Then you will run into second issue. See http://www1.ietf.org/mail-archive/web/sip/current/msg10432.html. Depending on your system, Section 8.2.2.2/RFC3261 does not always make sense. The prescribed behavior for merged requests is incomplete and often times broken. Regards, Shan Lu >-----Original Message----- >From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of=20 >K. Hal Purdy >Sent: Friday, March 18, 2005 4:08 PM >To: sip@ietf.org >Subject: [Sip] UAS behavior dealing with "merged" request after=20 >dialogestablishment > > >I have a question about UAS behavior related to detecting "merged"=20 >requests *after* the initial request has already resulted in an=20 >established dialog. If a UAC sends a request that goes through a=20 >parallel forking proxy, multiple forked requests may ultimately reach=20 >the same UAS. This is a known scenario and is covered in section=20 >8.2.2.2 of 3261: > > If the request has no tag in the To header field, the UAS core MUST > check the request against ongoing transactions. If the From tag, > Call-ID, and CSeq exactly match those associated with an ongoing > transaction, but the request does not match that transaction (based > on the matching rules in Section 17.2.3), the UAS core SHOULD > generate a 482 (Loop Detected) response and pass it to the server > transaction. > > However, if the UAS has already sent a 2xx response to the first=20 >request received, there is no longer any "ongoing transaction." From=20 >Section 17.2.1: > > If, while in the "Proceeding" state, the TU passes a 2xx response to > the server transaction, the server transaction MUST pass this > response to the transport layer for transmission. ... The server=20 >transaction MUST then > transition to the "Terminated" state....Once the transaction is in=20 >the "Terminated" state, it MUST be > destroyed immediately. > >Barring any additional work on the part of the UAS to detect this=20 >condition, it seems that a subsequent merged request might be treated=20 >as an initial INVITE transaction. This doesn't seem like a good idea.=20 >What should the UAS do, and where is this behavior covered in a RFC? > >More generally, what normative statements can be made about the=20 >responsibilities of UASs as regards enforcing the uniqueness of=20 >Call-IDs, branch parameters, etc? > >Regards, >Hal Purdy > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use=20 >sip-implementors@cs.columbia.edu for questions on current sip Use=20 >sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 22 13:28:07 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15235 for ; Tue, 22 Mar 2005 13:28:07 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDoCC-0006cC-6p for sip-web-archive@ietf.org; Tue, 22 Mar 2005 13:33:40 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDo5u-0006PJ-Vc; Tue, 22 Mar 2005 13:27:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDo5s-0006MT-Gq for sip@megatron.ietf.org; Tue, 22 Mar 2005 13:27:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15169 for ; Tue, 22 Mar 2005 13:27:05 -0500 (EST) Received: from broadsoft.com ([204.200.197.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDoBB-0006at-UP for sip@ietf.org; Tue, 22 Mar 2005 13:32:38 -0500 Received: from brett1 (66.239.146.130.ptr.us.xo.net [66.239.146.130]) (authenticated bits=0) by broadsoft.com (8.13.1/8.12.11) with ESMTP id j2MIR1jO036269 for ; Tue, 22 Mar 2005 13:27:04 -0500 (EST) From: "Brett Tate" To: Subject: RE: [Sip] About register expiration Date: Tue, 22 Mar 2005 13:27:22 -0500 Message-ID: <001b01c52f0c$ca01b630$a601a8c0@brett1> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: Importance: Normal X-Spam-Score: 0.9 (/) X-Scan-Signature: 96d3a783a4707f1ab458eb15058bb2d7 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2137206854==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 16a2b98d831858659c646b3dec9ed22b This is a multi-part message in MIME format. --===============2137206854== Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01C52EE2.E12BAE30" This is a multi-part message in MIME format. ------=_NextPart_000_001C_01C52EE2.E12BAE30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Udit's response about how the response should be processed. However if I understand Jonathan's posting correctly, the registrar = still must send the expires parameter. This is likely a situation to be = strict sending and leninent receiving. =20 http://www.sipwg.org/show_bug.cgi?id=3D682 =20 -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Udit_Goyal@3com.com Sent: Tuesday, March 22, 2005 12:36 PM To: Rachel Danor Cc: sip@ietf.org Subject: Re: [Sip] About register expiration Hi Rachel,=20 Expiration information can be present in Expires header or expires = paramter. However, Contact header "expires" paramter has preference over Expires header,=20 if expires parameter is present, it will be used=20 otherwise expiration value present in Expires header will be used.=20 -Udit=20 Sent by: sip-bounces@ietf.org =20 To: =20 cc: =20 Subject: [Sip] About register expiration=20 Hi,=20 I have a question the SIP standard definitions for "expires" handling in = the registration.=20 This is what I see in paragraph 10.3:=20 The registrar returns a 200 (OK) response. The response MUST contain Contact header field values enumerating all current bindings. Each = Contact value MUST feature an "expires" parameter indicating its expiration = interval chosen by the registrar. =20 >From this I understand that the 200OK must include expires parameter in = the contact header.=20 On the other hand when I look at message examples in paragraph 24.1, I = see the following:=20 F1 REGISTER Bob -> Registrar=20 REGISTER sip:registrar.biloxi.com SIP/2.0=20 Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=3Dz9hG4bKnashds7=20 Max-Forwards: 70=20 To: Bob =20 From: Bob ;tag=3D456248=20 Call-ID: 843817637684230@998sdasdh09=20 CSeq: 1826 REGISTER=20 Contact: =20 Expires: 7200=20 Content-Length: 0=20 F2 200 OK Registrar -> Bob=20 SIP/2.0 200 OK=20 Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=3Dz9hG4bKnashds7=20 ;received=3D192.0.2.4=20 To: Bob ;tag=3D2493k59kd=20 From: Bob ;tag=3D456248=20 Call-ID: 843817637684230@998sdasdh09=20 CSeq: 1826 REGISTER=20 Contact: =20 Expires: 7200=20 Content-Length: 0=20 Where the registrar does not set the expires parameter in the contact header, but leaves it in the Expires header.=20 Which is correct? Is it allowed to have both Expires header and expires parameter for Contact headers in the 200OK?=20 Regards,=20 Rachel Danor=20 ------=_NextPart_000_001C_01C52EE2.E12BAE30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
I=20 agree with Udit's response about how the response should be = processed. =20 However if I understand Jonathan's posting correctly, the registrar = still must=20 send the expires parameter.  This is likely a situation to be = strict=20 sending and leninent receiving.
 
http://www.sipwg.org/= show_bug.cgi?id=3D682
 
-----Original Message-----
From:=20 sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of=20 Udit_Goyal@3com.com
Sent: Tuesday, March 22, 2005 12:36=20 PM
To: Rachel Danor
Cc: = sip@ietf.org
Subject:=20 Re: [Sip] About register expiration


Hi Rachel,

Expiration information can be present in Expires header or = expires=20 paramter.
However, Contact = header=20 "expires" paramter has preference over Expires header, =
if expires parameter is present, it will be = used=20
otherwise expiration value = present in Expires=20 header will be used.

-Udit=20



Sent by:   =    =20  sip-bounces@ietf.org  =20

To:     =  =20  <sip@ietf.org>=20
cc:     =    =20
Subject: =    =20    [Sip] About = register=20 expiration




Hi, =

I have a question the SIP standard definitions for "expires" = handling=20 in the registration.

This is what I see = in=20 paragraph 10.3:

The registrar returns a = 200 (OK)=20 response.  The response MUST contain Contact header field values=20 enumerating all current bindings.  = Each Contact value MUST feature an "expires" = parameter indicating its expiration interval = chosen by the=20 registrar. 

From this I=20 understand that the 200OK must include expires parameter in the = contact=20 header.

On the other hand when I look at = message=20 examples in paragraph 24.1, I see the following:

   F1 REGISTER Bob -> Registrar =

      REGISTER = sip:registrar.biloxi.com=20 SIP/2.0

       Via:=20 SIP/2.0/UDP bobspc.biloxi.com:5060;branch=3Dz9hG4bKnashds7 =

      Max-Forwards: 70=20

       To: Bob=20 <sip:bob@biloxi.com>

       From: Bob=20 <sip:bob@biloxi.com>;tag=3D456248

       Call-ID:=20 843817637684230@998sdasdh09

       CSeq: 1826 = REGISTER=20

       Contact:=20 <sip:bob@192.0.2.4>

       = Expires: 7200

       Content-Length: 0 =



  F2 200 OK Registrar -> = Bob=20

        = SIP/2.0 200=20 OK

        Via:=20 SIP/2.0/UDP bobspc.biloxi.com:5060;branch=3Dz9hG4bKnashds7 =

        ;received=3D192.= 0.2.4=20

        To: = Bob=20 <sip:bob@biloxi.com>;tag=3D2493k59kd

        From: Bob=20 <sip:bob@biloxi.com>;tag=3D456248

        Call-ID:=20 843817637684230@998sdasdh09

        CSeq: 1826 = REGISTER=20

        = Contact:=20 <sip:bob@192.0.2.4>

       =20 Expires: 7200

        Content-Length: = 0=20

Where the registrar does not set the expires = parameter in=20 the contact header, but leaves it in the Expires header. =

Which is correct? Is it allowed to have both Expires header = and expires=20 parameter for Contact headers in the 200OK?

Regards,

Rachel = Danor=20

------=_NextPart_000_001C_01C52EE2.E12BAE30-- --===============2137206854== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============2137206854==-- From sip-bounces@ietf.org Tue Mar 22 13:36:46 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16066 for ; Tue, 22 Mar 2005 13:36:46 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDoKY-0006yh-0w for sip-web-archive@ietf.org; Tue, 22 Mar 2005 13:42:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDoEH-00087I-2U; Tue, 22 Mar 2005 13:35:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDoEF-00087C-2N for sip@megatron.ietf.org; Tue, 22 Mar 2005 13:35:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15985 for ; Tue, 22 Mar 2005 13:35:44 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.201]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDoJX-0006wg-Sj for sip@ietf.org; Tue, 22 Mar 2005 13:41:17 -0500 Received: by wproxy.gmail.com with SMTP id 36so88101wri for ; Tue, 22 Mar 2005 10:35:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=q8AUlOEh6Uo6L/Ru76OXYgQ6Bo17Thv9TENAG9hmxKvBOqcuOORl2uZKHWlVoLBGUCv587Ofzy+SPhLicesJxMxDH5PXellUPoPpiaYKlGa7v+nfh5oaoe1re77kbuKPTpllimO7g8XSg6aCetyvbGzpVwksAzpwsUbxl8bAnr0= Received: by 10.54.20.30 with SMTP id 30mr418562wrt; Tue, 22 Mar 2005 10:35:36 -0800 (PST) Received: by 10.54.17.6 with HTTP; Tue, 22 Mar 2005 10:35:36 -0800 (PST) Message-ID: Date: Tue, 22 Mar 2005 13:35:36 -0500 From: Arjun Roychowdhury To: Cullen Jennings Subject: Re: [Sip] P-Alerting-Mode to standards track? In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Arjun Roychowdhury List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Content-Transfer-Encoding: 7bit Just a quick question - if P-Alerting-Mode were to be used to indicate "Auto" for a diagnostic call (loopback or otherwise), is it expected that we use a "Reason" header to provide more infomation on why I want this mode ? This is no doubt something that will be reused for other apps beyond PoC, diag being one - and I wanted a clear way to define a reason. Ideally, a token would be nice - not sure if a free form reason header can really be as effective as a well defined token.... regds arjun On Mon, 21 Mar 2005 20:46:12 -0800, Cullen Jennings wrote: > > On the requirement, I would like to have this functionality. > > On the mechanism, I would expect this to lead to a few discussions. > > > On 3/15/05 12:08 PM, "Dean Willis" wrote: > > > > > One of the consensus points that seemed to emerge during the recent > > meeting was around the proposed P-Alerting-Mode header. We appear to > > have decided that we really do need a standard (NOT a P-header) way to > > ask a UAS to "auto answer", whether for a diagnostic loopback or > > push-to-talk application. There also seems to be a consensus that this > > should be done with a header, rather than a request parameter or other > > mechanism. > > > > So, it has been proposed that this header be withdrawn from the > > P-header "informational" draft, and re-documented on standards track. > > > > If we pursue this path, it should be noted that we would need to do it > > very quickly, as OMA has real needs for this functionality ASAP. I'll > > volunteer to help Andrew get it whipped into shape, unless somebody > > else wants to throw themselves on it. It seems like a relative > > no-brainer, just an exercise in documentation. > > > > So, poll for consensus: Does anybody strongly object to the development > > of a standard header for requesting auto-answer of a request? > > > > Second poll: Do we see any reasons why this couldn't be done fairly > > quickly, such as obvious dependencies on ongoing work that I've just > > missed? > > > > > > Thanks, > > > > -- > > Dean Willis > > SIP WG chair > > > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > -- Arjun Roychowdhury _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 22 14:02:55 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18554 for ; Tue, 22 Mar 2005 14:02:55 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDojq-00081T-NL for sip-web-archive@ietf.org; Tue, 22 Mar 2005 14:08:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDod2-0003tv-Pn; Tue, 22 Mar 2005 14:01:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDod0-0003tq-UL for sip@megatron.ietf.org; Tue, 22 Mar 2005 14:01:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18497 for ; Tue, 22 Mar 2005 14:01:21 -0500 (EST) Received: from harjus.tutpro.com ([192.98.100.3] ident=Debian-exim) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDoiJ-000802-In for sip@ietf.org; Tue, 22 Mar 2005 14:06:52 -0500 Received: from jh by harjus.tutpro.com with local (Exim 4.44) id 1DDocs-0000w8-AC; Tue, 22 Mar 2005 21:01:14 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16960.27514.261378.953086@harjus.tutpro.com> Date: Tue, 22 Mar 2005 21:01:14 +0200 To: "Brett Tate" In-Reply-To: <001b01c52f0c$ca01b630$a601a8c0@brett1> References: <001b01c52f0c$ca01b630$a601a8c0@brett1> X-Mailer: VM 7.19 under Emacs 21.3.1 From: Juha Heinanen X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: sip@ietf.org Subject: [Sip] another bug in rfc3261 register example X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit rachel's message reminds me about what i considered another bug in request uri of rfc3261 register example: REGISTER sip:registrar.biloxi.com SIP/2.0 elsewhere in rfc3261: 10.2 Constructing the REGISTER Request Request-URI: The Request-URI names the domain of the location service for which the registration is meant (for example, sip:chicago.com). and 10.3 Processing REGISTER Requests 1. The registrar inspects the Request-URI to determine whether it has access to bindings for the domain identified in the Request-URI. my interpretation of the above quotes is that request uri in the above register request should be: REGISTER sip:biloxi.com SIP/2.0 perhaps this could also be mentioned in the bug register of both rfc3261 and the call flow rfc. -- juha _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 22 17:52:40 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16499 for ; Tue, 22 Mar 2005 17:52:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDsKE-0001Wv-9p for sip-web-archive@ietf.org; Tue, 22 Mar 2005 17:58:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDsBV-0001XV-2m; Tue, 22 Mar 2005 17:49:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDsBT-0001XN-Fe for sip@megatron.ietf.org; Tue, 22 Mar 2005 17:49:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16269 for ; Tue, 22 Mar 2005 17:49:09 -0500 (EST) Received: from airwolf.sentito.com ([65.202.222.11]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DDsGp-0001NS-Ee for sip@ietf.org; Tue, 22 Mar 2005 17:54:43 -0500 Received: (qmail 15097 invoked by uid 1014); 22 Mar 2005 22:49:02 -0000 Received: from shanlu@sentito.com by airwolf.sentito.com by uid 1002 with qmail-scanner-1.22 (clamdscan: 0.83. spamassassin: 2.63. Clear:RC:1(65.202.222.2):. Processed in 0.037981 secs); 22 Mar 2005 22:49:02 -0000 Received: from unknown (HELO SAJAK) (65.202.222.2) by airwolf.sentito.com with SMTP; 22 Mar 2005 22:49:02 -0000 From: "Shan Lu" To: "'Jain, Rajnish'" , Subject: RE: [Sip] UAS behavior dealing with "merged" requestafterdialogestablishment Date: Tue, 22 Mar 2005 17:50:39 -0500 Message-ID: <0cba01c52f31$920596f0$eb00000a@SAJAK> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 In-Reply-To: <656BE56E7D48F6419054CC1C811149270239FB47@exch01.corp.xl.com> Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d Content-Transfer-Encoding: 7bit How does TU decide whether to: A. No-op B. 482 C. start anew? Any of the above can be the right thing to do. Regards, Shan Lu >-----Original Message----- >From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On >Behalf Of Jain, Rajnish >Sent: Tuesday, March 22, 2005 1:19 PM >To: Shan Lu; K. Hal Purdy; sip@ietf.org >Subject: RE: [Sip] UAS behavior dealing with "merged" >requestafterdialogestablishment > > >Instead of tweaking the transaction state machine behavior, >why couldn't >this be handled at TU Core. When the retransmitted INVITE arrives at TU >Core, you can match it w/ ongoing dialogs while taking into >account only >the UAC-half of the dialog id. > > > >-----Original Message----- >From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >Shan Lu >Sent: Tuesday, March 22, 2005 11:52 AM >To: 'K. Hal Purdy'; sip@ietf.org >Subject: RE: [Sip] UAS behavior dealing with "merged" request >afterdialogestablishment > >Hi, > >Your question touched two issues in RFC3261. > >The first is late arrival of a retransmitted INVITE at UAS. Note >although you are interested in forking, your situation is no different >than a retransmitted INVITE arriving after the INVITE server >transaction >has terminated. See >http://www1.ietf.org/mail-archive/web/sip/current/msg10326.html. The >proposed solution is to keep the original INVITE transaction a bit >longer (till ACK). > >Then you will run into second issue. See >http://www1.ietf.org/mail-archive/web/sip/current/msg10432.html. >Depending on your system, Section 8.2.2.2/RFC3261 does not always make >sense. The prescribed behavior for merged requests is incomplete and >often times broken. > >Regards, > >Shan Lu > >>-----Original Message----- >>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of >>K. Hal Purdy >>Sent: Friday, March 18, 2005 4:08 PM >>To: sip@ietf.org >>Subject: [Sip] UAS behavior dealing with "merged" request after >>dialogestablishment >> >> >>I have a question about UAS behavior related to detecting "merged" >>requests *after* the initial request has already resulted in an >>established dialog. If a UAC sends a request that goes through a >>parallel forking proxy, multiple forked requests may ultimately reach >>the same UAS. This is a known scenario and is covered in section >>8.2.2.2 of 3261: >> >> If the request has no tag in the To header field, the UAS core MUST >> check the request against ongoing transactions. If the From tag, >> Call-ID, and CSeq exactly match those associated with an ongoing >> transaction, but the request does not match that transaction (based >> on the matching rules in Section 17.2.3), the UAS core SHOULD >> generate a 482 (Loop Detected) response and pass it to the server >> transaction. >> >> However, if the UAS has already sent a 2xx response to the first >>request received, there is no longer any "ongoing transaction." From >>Section 17.2.1: >> >> If, while in the "Proceeding" state, the TU passes a 2xx >response to >> the server transaction, the server transaction MUST pass this >> response to the transport layer for transmission. ... The server >>transaction MUST then >> transition to the "Terminated" state....Once the transaction is in >>the "Terminated" state, it MUST be >> destroyed immediately. >> >>Barring any additional work on the part of the UAS to detect this >>condition, it seems that a subsequent merged request might be treated >>as an initial INVITE transaction. This doesn't seem like a good idea. >>What should the UAS do, and where is this behavior covered in a RFC? >> >>More generally, what normative statements can be made about the >>responsibilities of UASs as regards enforcing the uniqueness of >>Call-IDs, branch parameters, etc? >> >>Regards, >>Hal Purdy >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol Use >>sip-implementors@cs.columbia.edu for questions on current sip Use >>sipping@ietf.org for new developments on the application of sip >> > > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol Use >sip-implementors@cs.columbia.edu for questions on current sip Use >sipping@ietf.org for new developments on the application of sip > >_______________________________________________ >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >This list is for NEW development of the core SIP Protocol >Use sip-implementors@cs.columbia.edu for questions on current sip >Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 23 00:24:28 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25779 for ; Wed, 23 Mar 2005 00:24:28 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDyRS-0007Sg-CA for sip-web-archive@ietf.org; Wed, 23 Mar 2005 00:30:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDyFP-000894-5M; Wed, 23 Mar 2005 00:17:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDyFM-00088w-BO for sip@megatron.ietf.org; Wed, 23 Mar 2005 00:17:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25032 for ; Wed, 23 Mar 2005 00:17:33 -0500 (EST) Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDyKl-00078N-FU for sip@ietf.org; Wed, 23 Mar 2005 00:23:11 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id j2N5LWOM024099 for ; Tue, 22 Mar 2005 22:21:32 -0700 (MST) Received: from zin24exm01.ap.mot.com (zin24exm01.ap.mot.com [10.232.25.1]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id j2N5Ir0F017424 for ; Tue, 22 Mar 2005 23:18:55 -0600 (CST) Received: by zin24exm01.ap.mot.com with Internet Mail Service (5.5.2657.72) id <1M6YH6KQ>; Wed, 23 Mar 2005 10:47:25 +0530 Message-ID: <772BCEF88A1DD91191F80011856715F302067FE6@zin24exm01.ap.mot.com> From: Chadha Retesh-A19894 To: sip@ietf.org Date: Wed, 23 Mar 2005 10:47:21 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 2.0 (++) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Subject: [Sip] Few questions regarding PRACK (RFC3262) X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1847108677==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 2.0 (++) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1847108677== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C52F67.978289FE" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C52F67.978289FE Content-Type: text/plain Here they go -- 1. Is there any use of PRACK, if we are sure that the underlying transport between all the SIP entities is reliable? 2. If one provisional response is reliable, is it a MUST that all the subsequent provisional responses be reliable(not with Rseq header)? What should be the behavior of the UAC? This is when UAC sent an INVITE with Supported: 100rel. 3. In what scenario, will the UAC, send a new offer in PRACK? 4. In the following scenario, what is the response to the second PRACK request - INVITE --> <-- 180 Rseq: 1 PRACK (Rack: 1)--> Crossover happened here<-- 180 RSeq:1 (this is a restransmission, since PRACK is not received and T1 timer fires) UAC got both the 1xx, but may be late PRACK (Rack: 1)--> <-- 200 ok(1st PRACK ) <-- 481(PRACK) <--- Let me know, if i am right here?? Thanks in advance. Rgds Retesh ------_=_NextPart_001_01C52F67.978289FE Content-Type: text/html Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05U RU5UPSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9VVMtQVNDSUkiPg0KPFRJVExFPk1lc3NhZ2U8L1RJVExF Pg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4yODAwLjE0NzkiIG5hbWU9R0VORVJBVE9S PjwvSEVBRD4NCjxCT0RZPg0KPERJVj48U1BBTiBjbGFzcz00MTExNDAwMDUtMjMwMzIwMDU+PEZP TlQgZmFjZT1BcmlhbCBzaXplPTI+SGVyZSB0aGV5IGdvIA0KLS08L0ZPTlQ+PC9TUEFOPjwvRElW Pg0KPERJVj48U1BBTiBjbGFzcz00MTExNDAwMDUtMjMwMzIwMDU+PEZPTlQgZmFjZT1BcmlhbCAN CnNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz00MTEx NDAwMDUtMjMwMzIwMDU+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+MS4gSXMgdGhlcmUgYW55IHVz ZSANCm9mIFBSQUNLLCBpZiB3ZSBhcmUgc3VyZSB0aGF0IHRoZSB1bmRlcmx5aW5nIHRyYW5zcG9y dCBiZXR3ZWVuIGFsbCB0aGUgU0lQIA0KZW50aXRpZXMgaXMgcmVsaWFibGU/PC9GT05UPjwvU1BB Tj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9NDExMTQwMDA1LTIzMDMyMDA1PjxGT05UIGZhY2U9 QXJpYWwgDQpzaXplPTI+PC9GT05UPjwvU1BBTj4mbmJzcDs8L0RJVj4NCjxESVY+PFNQQU4gY2xh c3M9NDExMTQwMDA1LTIzMDMyMDA1PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPjIuIElmIG9uZSAN CnByb3Zpc2lvbmFsIHJlc3BvbnNlIGlzIHJlbGlhYmxlLCBpcyBpdCBhIE1VU1QgdGhhdCBhbGwg dGhlIHN1YnNlcXVlbnQgDQpwcm92aXNpb25hbCByZXNwb25zZXMgYmUgcmVsaWFibGUobm90IHdp dGggUnNlcSBoZWFkZXIpPyBXaGF0IHNob3VsZCBiZSB0aGUgDQpiZWhhdmlvciBvZiB0aGUgVUFD PyBUaGlzIGlzIHdoZW4gVUFDIHNlbnQgYW4gSU5WSVRFIHdpdGggU3VwcG9ydGVkOiANCjEwMHJl bC48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz00MTExNDAwMDUtMjMwMzIw MDU+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz00MTExNDAwMDUtMjMwMzIw MDU+My4gSW4gd2hhdCBzY2VuYXJpbywgd2lsbCB0aGUgVUFDLCBzZW5kIGEgDQpuZXcgb2ZmZXIg aW4gUFJBQ0s/PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz00MTExNDAwMDUtMjMwMzIw MDU+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz00MTExNDAwMDUtMjMwMzIw MDU+NC4gSW4gdGhlIGZvbGxvd2luZyBzY2VuYXJpbywgd2hhdCBpcyB0aGUgDQpyZXNwb25zZSB0 byB0aGUgc2Vjb25kIFBSQUNLIHJlcXVlc3QgLTwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xh c3M9NDExMTQwMDA1LTIzMDMyMDA1PiZuYnNwOyZuYnNwOyZuYnNwOyA8Rk9OVCBmYWNlPUFyaWFs IA0Kc2l6ZT0yPklOVklURSANCi0tJmd0OzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbHQ7LS0mbmJzcDsgDQoxODAgUnNlcTogMTwvRk9OVD48L1NQQU4+PFNQQU4gY2xhc3M9 NDExMTQwMDA1LTIzMDMyMDA1PjwvRElWPg0KPERJVj4NCjxESVY+PFNQQU4gY2xhc3M9NDExMTQw MDA1LTIzMDMyMDA1PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPiZuYnNwOyZuYnNwOyZuYnNwOyAN ClBSQUNLIChSYWNrOiAxKS0tJmd0OzwvRk9OVD48L1NQQU4+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9QXJpYWwgc2l6ZT0yPjxTUEFOIGNsYXNzPTQxMTE0MDAwNS0yMzAzMjAwNT5Dcm9zc292ZXIg aGFwcGVuZWQgDQpoZXJlPC9TUEFOPiZsdDstLSZuYnNwOyAxODAgUlNlcToxICh0aGlzIGlzIGEg cmVzdHJhbnNtaXNzaW9uLCBzaW5jZSBQUkFDSyBpcyANCm5vdCByZWNlaXZlZCBhbmQgVDEgdGlt ZXIgZmlyZXMpPC9GT05UPjwvU1BBTj48L0RJVj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9NDEx MTQwMDA1LTIzMDMyMDA1PjxGT05UIGZhY2U9QXJpYWwgc2l6ZT0yPlVBQyZuYnNwO2dvdCBib3Ro IA0KdGhlIDF4eCwgYnV0IG1heSBiZSBsYXRlPC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQ QU4gY2xhc3M9NDExMTQwMDA1LTIzMDMyMDA1Pg0KPERJVj48U1BBTiBjbGFzcz00MTExNDAwMDUt MjMwMzIwMDU+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KUFJB Q0sgKFJhY2s6IDEpLS0mZ3Q7PC9GT05UPjwvU1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9 NDExMTQwMDA1LTIzMDMyMDA1Pg0KPERJVj48U1BBTiBjbGFzcz00MTExNDAwMDUtMjMwMzIwMDU+ PEZPTlQgZmFjZT1BcmlhbCANCnNpemU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbHQ7LS0mbmJzcDsgDQoyMDAgb2soMXN0IFBSQUNLICk8L0ZPTlQ+PC9TUEFOPjwvRElWPjwv U1BBTj48L0RJVj4NCjxESVY+PFNQQU4gY2xhc3M9NDExMTQwMDA1LTIzMDMyMDA1PjxGT05UIGZh Y2U9QXJpYWwgDQpzaXplPTI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0Oy0t Jm5ic3A7IA0KNDgxKFBSQUNLKTwvRk9OVD48L1NQQU4+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PFNQQU4gDQpjbGFzcz00MTExNDAwMDUtMjMwMzIwMDU+Jmx0OzwvU1BB Tj48U1BBTiBjbGFzcz00MTExNDAwMDUtMjMwMzIwMDU+LS0tIExldCBtZSANCmtub3csIGlmIGkg YW0gcmlnaHQgaGVyZT8/PC9TUEFOPjwvRElWPg0KPERJVj48U1BBTiBjbGFzcz00MTExNDAwMDUt MjMwMzIwMDU+PEZPTlQgZmFjZT1BcmlhbCANCnNpemU9Mj48L0ZPTlQ+PC9TUEFOPiZuYnNwOzwv RElWPg0KPERJVj48U1BBTiBjbGFzcz00MTExNDAwMDUtMjMwMzIwMDU+PEZPTlQgZmFjZT1Bcmlh bCBzaXplPTI+VGhhbmtzIGluIA0KYWR2YW5jZS48L0ZPTlQ+PC9TUEFOPjwvRElWPg0KPERJVj48 U1BBTiBjbGFzcz00MTExNDAwMDUtMjMwMzIwMDU+PEZPTlQgZmFjZT1BcmlhbCANCnNpemU9Mj48 L0ZPTlQ+PC9TUEFOPiZuYnNwOzwvRElWPg0KPERJVj48U1BBTiBjbGFzcz00MTExNDAwMDUtMjMw MzIwMDU+PEZPTlQgZmFjZT1BcmlhbCANCnNpemU9Mj5SZ2RzPC9GT05UPjwvU1BBTj48L0RJVj4N CjxESVY+PFNQQU4gY2xhc3M9NDExMTQwMDA1LTIzMDMyMDA1PjxGT05UIGZhY2U9QXJpYWwgDQpz aXplPTI+UmV0ZXNoPC9GT05UPjwvU1BBTj48L1NQQU4+PC9ESVY+PC9ESVY+DQo8RElWPjxTUEFO IGNsYXNzPTQxMTE0MDAwNS0yMzAzMjAwNT48Rk9OVCBmYWNlPUFyaWFsIA0Kc2l6ZT0yPjwvRk9O VD48L1NQQU4+Jm5ic3A7PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------_=_NextPart_001_01C52F67.978289FE-- --===============1847108677== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1847108677==-- From sip-bounces@ietf.org Wed Mar 23 03:57:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18252 for ; Wed, 23 Mar 2005 03:57:01 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE1lA-0006LT-Pk for sip-web-archive@ietf.org; Wed, 23 Mar 2005 04:02:41 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE1eu-0005uA-TU; Wed, 23 Mar 2005 03:56:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE1eo-0005tH-Ge for sip@megatron.ietf.org; Wed, 23 Mar 2005 03:56:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18209 for ; Wed, 23 Mar 2005 03:56:04 -0500 (EST) Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE1kC-0006Fd-GC for sip@ietf.org; Wed, 23 Mar 2005 04:01:43 -0500 Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0IDS00301RDIF0@siemenscomms.co.uk> for sip@ietf.org; Wed, 23 Mar 2005 08:53:42 +0000 (GMT) Received: from ntht206e.siemenscomms.co.uk ([137.223.247.52]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0IDS00267RDH5L@siemenscomms.co.uk>; Wed, 23 Mar 2005 08:53:41 +0000 (GMT) Received: by ntht206e.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id ; Wed, 23 Mar 2005 08:55:47 +0000 Content-return: allowed Date: Wed, 23 Mar 2005 08:55:40 +0000 From: "Elwell, John" Subject: RE: [Sip] target dialog draft To: Jonathan Rosenberg , IETF SIP List Message-id: <50B1CBA96870A34799A506B2313F266705153FBC@ntht201e.siemenscomms.co.uk> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-type: text/plain Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7BIT X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Content-Transfer-Encoding: 7BIT Jonathan, Section 3: "Typically this is the case when the dialog-initiating request would have otherwise been sent over an existing dialog, but was not since this specification allows the request to be sent on a new dialog instead." This is a bit convoluted. The reason for not using the existing dialog is that it would introduce problems with dialog reuse etc., as stated earlier in the document. The mere existence of this target dialog spec is not in itself sufficient reason for using a new dialog. In the next paragraph: Change "sent out a dialog" to "sent outside a dialog". Join and Replaces headers have "to-tag" and "from-tag" with corresponding text saying how these relate to the local tag and remote tag respectively at the recipient. Would it not be a good idea to stick to the same parameter names as Join and Replaces? Likewise the style of BNF is slightly different from that used in Join and Replaces. Would alignment be sensible? I don't have a strong opinion on these - just a suggestion. What use do you envisage for this new header in an UPDATE request (for which it is marked optional in figure 4)? The title of figure 4 seems wrong. John > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > Behalf Of Jonathan Rosenberg > Sent: 08 March 2005 01:43 > To: IETF SIP List > Subject: [Sip] target dialog draft > > Here is a URL for the target dialog draft that I wrote in response to > Rohan's email on the app interaction draft. It defines a way > for a REFER > to define a target dialog with which it is associated: > > http://www.jdrosen.net/papers/draft-rosenberg-sip-target-dialog-00.txt > > Thanks, > Jonathan R. > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Director, Service Provider VoIP Architecture Parsippany, NJ > 07054-2711 > Cisco Systems > jdrosen@cisco.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.cisco.com > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 23 15:24:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00720 for ; Wed, 23 Mar 2005 15:24:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DECUx-0001Ua-K7 for sip-web-archive@ietf.org; Wed, 23 Mar 2005 15:30:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DECLP-0003lr-0s; Wed, 23 Mar 2005 15:20:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DECLN-0003lm-Qu for sip@megatron.ietf.org; Wed, 23 Mar 2005 15:20:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00311 for ; Wed, 23 Mar 2005 15:20:44 -0500 (EST) Received: from mail-red.research.att.com ([192.20.225.110] helo=mail-white.research.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DECQu-0001Mu-6W for sip@ietf.org; Wed, 23 Mar 2005 15:26:29 -0500 Received: from [135.207.17.145] (lt-khp.research.att.com [135.207.17.145]) by bigmail.research.att.com (8.11.6+Sun/8.11.6) with ESMTP id j2NKKZ307081; Wed, 23 Mar 2005 15:20:35 -0500 (EST) Message-ID: <4241CF93.8080809@research.att.com> Date: Wed, 23 Mar 2005 15:20:35 -0500 From: "K. Hal Purdy" User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Shan Lu , SIP Mailng List Subject: Re: [Sip] UAS behavior dealing with "merged" request after dialog establishment References: <0c6201c52eff$69d48240$eb00000a@SAJAK> In-Reply-To: <0c6201c52eff$69d48240$eb00000a@SAJAK> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Content-Transfer-Encoding: 7bit X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Shan, Thanks for your reply. Further comments inline. Shan Lu wrote: >Hi, > >Your question touched two issues in RFC3261. > >The first is late arrival of a retransmitted INVITE at UAS. Note although >you are interested in forking, your situation is no different than a >retransmitted INVITE arriving after the INVITE server transaction has >terminated. See >http://www1.ietf.org/mail-archive/web/sip/current/msg10326.html. The >proposed solution is to keep the original INVITE transaction a bit longer >(till ACK). > > I agree this is a somewhat related case though it doesn't get to the heart of the issue I'm asking about. In this case, *if* the UAS maintains transaction state, it can determine that the branch tag is the same and therefore, this INVITE is a retransmission. Admittedly 3261 doesn't cover this case, but at least it's now clear to us that a UAS implementation should maintain some additional transaction state even after the transaction is destroyed. It's also clear that the correct behavior is for the UAS to simply ignore the retransmitted INVITE(s). Finally, I think it's clear that waiting for the ACK is not sufficient to completely handle this case in scenarios where message order is not preserved. A retransmitted INVITE could be sent before but arrive after the ACK sent in response to the 2xx. The case I raise is different because it's not clear (to me) what the proper UAS behavior should be. Should it ignore the "merged" request, reject it with 482 or some other code, or treat it as a new request? Treating as a new request doesn't seem right. If it rejects with 4xx code, could this cause the UAC trouble? It certainly could lead to some confusion if the 2xx were lost. Even if the 2xx is not lost, it seems that some problems might arise. I think you succinctly summarized this question in a subsequent post. >Then you will run into second issue. See >http://www1.ietf.org/mail-archive/web/sip/current/msg10432.html. Depending >on your system, Section 8.2.2.2/RFC3261 does not always make sense. The >prescribed behavior for merged requests is incomplete and often times >broken. > As I understand it, this thread raises the issue of whether sending a 482 is proper when the Request-URI in the merged request is different from the one in the original INVITE that created the UAS transaction. Again, this seems unrelated to my question since in the case I raise, once the UAS has responded with 2xx to the original INVITE, the transaction is destroyed. In the case The Request-URI could be the same or different, and its value doesn't seem to help in resolving what the correct behavior of the UAS should be. >Regards, > >Shan Lu > > Regards, Hal Purdy _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 24 00:00:56 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06544 for ; Thu, 24 Mar 2005 00:00:56 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEKYR-0004eN-5I for sip-web-archive@ietf.org; Thu, 24 Mar 2005 00:06:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEKOc-0001q8-MN; Wed, 23 Mar 2005 23:56:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEKOY-0001q3-BZ for sip@megatron.ietf.org; Wed, 23 Mar 2005 23:56:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06233 for ; Wed, 23 Mar 2005 23:56:31 -0500 (EST) Received: from rproxy.gmail.com ([64.233.170.198]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEKUA-0004VS-8M for sip@ietf.org; Thu, 24 Mar 2005 00:02:22 -0500 Received: by rproxy.gmail.com with SMTP id j1so356584rnf for ; Wed, 23 Mar 2005 20:56:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=a2fSXEnZnPZSbWuWfKqq46u7Ft75P5Nm1q6dB9K/b8wBYBscWHbdOx50jJrpEXL/XUfFHvnaUtvhak4tb9fmvmQetXaWCHH+F+0SiiB5UFreq/BlWoubtXV9ucoXgXKU+FdxQpl0TqosJJKoEuWQlz95Kjwyzal5uppQi0oDTgQ= Received: by 10.38.75.67 with SMTP id x67mr883915rna; Wed, 23 Mar 2005 20:56:33 -0800 (PST) Received: by 10.38.11.14 with HTTP; Wed, 23 Mar 2005 20:56:33 -0800 (PST) Message-ID: <3fe6b8640503232056e14f4ae@mail.gmail.com> Date: Thu, 24 Mar 2005 10:26:33 +0530 From: Malleswara Rao Ankem To: Shan Lu Subject: Re: [Sip] UAS behavior dealing with "merged" requestafterdialogestablishment In-Reply-To: <0cba01c52f31$920596f0$eb00000a@SAJAK> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <656BE56E7D48F6419054CC1C811149270239FB47@exch01.corp.xl.com> <0cba01c52f31$920596f0$eb00000a@SAJAK> X-Spam-Score: 0.0 (/) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a Content-Transfer-Encoding: 7bit Cc: sip@ietf.org, "Jain, Rajnish" X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Malleswara Rao Ankem List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Content-Transfer-Encoding: 7bit I think it should respond with a 482 (as per 3261). As for the previous 200Ok if it doesnot result in an ACK the dialog itself will cease to exist. But treating it as a no-op or as a new INVITE will create more confusion. regards Mallesh On Tue, 22 Mar 2005 17:50:39 -0500, Shan Lu wrote: > How does TU decide whether to: > > A. No-op > B. 482 > C. start anew? > > Any of the above can be the right thing to do. > > Regards, > > Shan Lu > > >-----Original Message----- > >From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On > >Behalf Of Jain, Rajnish > >Sent: Tuesday, March 22, 2005 1:19 PM > >To: Shan Lu; K. Hal Purdy; sip@ietf.org > >Subject: RE: [Sip] UAS behavior dealing with "merged" > >requestafterdialogestablishment > > > > > >Instead of tweaking the transaction state machine behavior, > >why couldn't > >this be handled at TU Core. When the retransmitted INVITE arrives at TU > >Core, you can match it w/ ongoing dialogs while taking into > >account only > >the UAC-half of the dialog id. > > > > > > > >-----Original Message----- > >From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > >Shan Lu > >Sent: Tuesday, March 22, 2005 11:52 AM > >To: 'K. Hal Purdy'; sip@ietf.org > >Subject: RE: [Sip] UAS behavior dealing with "merged" request > >afterdialogestablishment > > > >Hi, > > > >Your question touched two issues in RFC3261. > > > >The first is late arrival of a retransmitted INVITE at UAS. Note > >although you are interested in forking, your situation is no different > >than a retransmitted INVITE arriving after the INVITE server > >transaction > >has terminated. See > >http://www1.ietf.org/mail-archive/web/sip/current/msg10326.html. The > >proposed solution is to keep the original INVITE transaction a bit > >longer (till ACK). > > > >Then you will run into second issue. See > >http://www1.ietf.org/mail-archive/web/sip/current/msg10432.html. > >Depending on your system, Section 8.2.2.2/RFC3261 does not always make > >sense. The prescribed behavior for merged requests is incomplete and > >often times broken. > > > >Regards, > > > >Shan Lu > > > >>-----Original Message----- > >>From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of > >>K. Hal Purdy > >>Sent: Friday, March 18, 2005 4:08 PM > >>To: sip@ietf.org > >>Subject: [Sip] UAS behavior dealing with "merged" request after > >>dialogestablishment > >> > >> > >>I have a question about UAS behavior related to detecting "merged" > >>requests *after* the initial request has already resulted in an > >>established dialog. If a UAC sends a request that goes through a > >>parallel forking proxy, multiple forked requests may ultimately reach > >>the same UAS. This is a known scenario and is covered in section > >>8.2.2.2 of 3261: > >> > >> If the request has no tag in the To header field, the UAS core MUST > >> check the request against ongoing transactions. If the From tag, > >> Call-ID, and CSeq exactly match those associated with an ongoing > >> transaction, but the request does not match that transaction (based > >> on the matching rules in Section 17.2.3), the UAS core SHOULD > >> generate a 482 (Loop Detected) response and pass it to the server > >> transaction. > >> > >> However, if the UAS has already sent a 2xx response to the first > >>request received, there is no longer any "ongoing transaction." From > >>Section 17.2.1: > >> > >> If, while in the "Proceeding" state, the TU passes a 2xx > >response to > >> the server transaction, the server transaction MUST pass this > >> response to the transport layer for transmission. ... The server > >>transaction MUST then > >> transition to the "Terminated" state....Once the transaction is in > >>the "Terminated" state, it MUST be > >> destroyed immediately. > >> > >>Barring any additional work on the part of the UAS to detect this > >>condition, it seems that a subsequent merged request might be treated > >>as an initial INVITE transaction. This doesn't seem like a good idea. > >>What should the UAS do, and where is this behavior covered in a RFC? > >> > >>More generally, what normative statements can be made about the > >>responsibilities of UASs as regards enforcing the uniqueness of > >>Call-IDs, branch parameters, etc? > >> > >>Regards, > >>Hal Purdy > >> > >>_______________________________________________ > >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>This list is for NEW development of the core SIP Protocol Use > >>sip-implementors@cs.columbia.edu for questions on current sip Use > >>sipping@ietf.org for new developments on the application of sip > >> > > > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol Use > >sip-implementors@cs.columbia.edu for questions on current sip Use > >sipping@ietf.org for new developments on the application of sip > > > >_______________________________________________ > >Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >This list is for NEW development of the core SIP Protocol > >Use sip-implementors@cs.columbia.edu for questions on current sip > >Use sipping@ietf.org for new developments on the application of sip > > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 24 09:52:48 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18177 for ; Thu, 24 Mar 2005 09:52:48 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DETnH-0005l8-6R for sip-web-archive@ietf.org; Thu, 24 Mar 2005 09:58:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DETe1-0000dH-O4; Thu, 24 Mar 2005 09:49:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DETdz-0000dC-UD for sip@megatron.ietf.org; Thu, 24 Mar 2005 09:49:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17857 for ; Thu, 24 Mar 2005 09:49:06 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DETjf-0005cY-R2 for sip@ietf.org; Thu, 24 Mar 2005 09:55:01 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 24 Mar 2005 06:48:57 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j2OEmsZV026038; Thu, 24 Mar 2005 06:48:54 -0800 (PST) Received: from cisco.com ([161.44.79.169]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AQB58641; Thu, 24 Mar 2005 09:48:53 -0500 (EST) Message-ID: <4242D354.9030302@cisco.com> Date: Thu, 24 Mar 2005 09:48:52 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [Sip] high level sip-identity comments References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , Michael Thomas , Jon Peterson X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cullen Jennings wrote: >>4) As Jonathan also pointed out, there's no way to express >> whether a domain has a policy of "we sign everything". >> Unless that's available, you have a trivial bid down >> attack by simply not adding an Identity header to your >> SIP method of choice. > > Yep - agree. I thought we discussed this is the draft but perhaps I just > wish we did :-) I don't see any solution to this other than for enough > people to implement this that at some point in time it is practical to > switch to requiring it. I know ideas involved using DNS to find out have > been bounced around and perhaps future work could deal with that. They > proposal I have heard so far mostly seem to rely on DNSSec. The identity is something the caller (or his agent) provides in hopes that it will result in his getting better treatment by the recipient. The bid-down should just mean that the caller doesn't get that better treatment. If I do it to myself, then I get what I deserve. If I want the identity but some interloper removes it, then I should eventually realize something is happening and move to get the problem solved. On the recipient side, once identity starts to be deployed, I will perhaps encourage my friends to use a provider who supplies it. And at least I will rapidly learn which ones have it. For friends that don't, I will have to always be a bit suspicious if I am talking to them or a fake. I suppose the big issue is with the presence or absence of identity in calls from strangers. I think the best we can hope for in transition is that the UI provides good indication of the reliability of caller identity. Some mark (like the little lock in browsers for TLS) would help. Or your UA could have a feature to reject calls without identity. So I don't see this as a big or unexpected problem. Paul _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 24 10:02:41 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19358 for ; Thu, 24 Mar 2005 10:02:41 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DETwp-000683-N3 for sip-web-archive@ietf.org; Thu, 24 Mar 2005 10:08:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DETp6-00029M-OD; Thu, 24 Mar 2005 10:00:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DETp4-00029H-0Y for sip@megatron.ietf.org; Thu, 24 Mar 2005 10:00:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19113 for ; Thu, 24 Mar 2005 10:00:32 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DETul-00063H-2J for sip@ietf.org; Thu, 24 Mar 2005 10:06:27 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 24 Mar 2005 06:58:59 -0800 X-IronPort-AV: i="3.91,118,1110182400"; d="scan'208"; a="622666225:sNHT1913169270" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j2OEwqZV008461; Thu, 24 Mar 2005 06:58:52 -0800 (PST) Received: from [10.32.245.157] (stealth-10-32-245-157.cisco.com [10.32.245.157]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j2OEpQ9w001405; Thu, 24 Mar 2005 06:51:28 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <012a2d0968b24b67ac5cf5e28d85f719@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [Sip] P-Alerting-Mode to standards track? Date: Thu, 24 Mar 2005 09:58:44 -0500 To: Arjun Roychowdhury X-Mailer: Apple Mail (2.619.2) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1111675892.510323"; x:"432200"; a:"rsa-sha1"; b:"nofws:3347"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"RrbRxCkH32cGyZGPrtaUXFEgZr8bZrETWvGkUoFuIO0gKMujSPcqrbaEpugpbp+an3rQpriI" "JTBQd6+sHWWC/MBRMYkK0IILDPEmNSp5yjwlPeJeGV9NA7FA9MIubT/MpVgJgRMprj05j4zMdbY" "I2evLzIMRsgDV/N2CrSGhzP0="; c:"From: David R Oran "; c:"Subject: Re: [Sip] P-Alerting-Mode to standards track?"; c:"Date: Thu, 24 Mar 2005 09:58:44 -0500" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , Cullen Jennings , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 Content-Transfer-Encoding: 7bit On Mar 22, 2005, at 1:35 PM, Arjun Roychowdhury wrote: > Just a quick question - if P-Alerting-Mode were to be used to indicate > "Auto" for a diagnostic call (loopback or otherwise), is it expected > that we use a "Reason" header to provide more infomation on why I want > this mode ? No. We need tighter semantics than that in order to be able to do authorization feasibly. The direction I'd prefer is to define a diagnostic header that actually specifies the diagnostic mode (e.g. rtp-loopback, decode/encode loopback, analog loopback, synthetic stream, etc.) so you know if, for example, the transducers are going to be enabled or not and can authorize appropriately. > This is no doubt something that will be reused for other > apps beyond PoC, diag being one - and I wanted a clear way to define a > reason. Ideally, a token would be nice - not sure if a free form > reason header can really be as effective as a well defined token.... > Open ended reasons make authorization harder. I much prefer specifying exactly what you want to do rather than why. It works better with automatons and is also more in keeping with the general SIP philosophy of specifying mechanisms rather than services/applications. Cheers,. Dave. > > regds > arjun > > > > On Mon, 21 Mar 2005 20:46:12 -0800, Cullen Jennings > wrote: >> >> On the requirement, I would like to have this functionality. >> >> On the mechanism, I would expect this to lead to a few discussions. >> >> >> On 3/15/05 12:08 PM, "Dean Willis" wrote: >> >>> >>> One of the consensus points that seemed to emerge during the recent >>> meeting was around the proposed P-Alerting-Mode header. We appear to >>> have decided that we really do need a standard (NOT a P-header) way >>> to >>> ask a UAS to "auto answer", whether for a diagnostic loopback or >>> push-to-talk application. There also seems to be a consensus that >>> this >>> should be done with a header, rather than a request parameter or >>> other >>> mechanism. >>> >>> So, it has been proposed that this header be withdrawn from the >>> P-header "informational" draft, and re-documented on standards track. >>> >>> If we pursue this path, it should be noted that we would need to do >>> it >>> very quickly, as OMA has real needs for this functionality ASAP. I'll >>> volunteer to help Andrew get it whipped into shape, unless somebody >>> else wants to throw themselves on it. It seems like a relative >>> no-brainer, just an exercise in documentation. >>> >>> So, poll for consensus: Does anybody strongly object to the >>> development >>> of a standard header for requesting auto-answer of a request? >>> >>> Second poll: Do we see any reasons why this couldn't be done fairly >>> quickly, such as obvious dependencies on ongoing work that I've just >>> missed? >>> >>> >>> Thanks, >>> >>> -- >>> Dean Willis >>> SIP WG chair >>> >>> >>> _______________________________________________ >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>> This list is for NEW development of the core SIP Protocol >>> Use sip-implementors@cs.columbia.edu for questions on current sip >>> Use sipping@ietf.org for new developments on the application of sip >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use sip-implementors@cs.columbia.edu for questions on current sip >> Use sipping@ietf.org for new developments on the application of sip >> > > > -- > Arjun Roychowdhury > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 24 10:15:14 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21417 for ; Thu, 24 Mar 2005 10:15:14 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEU8z-0006d8-FP for sip-web-archive@ietf.org; Thu, 24 Mar 2005 10:21:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DETxC-0003s1-5o; Thu, 24 Mar 2005 10:08:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DETxA-0003rs-B9 for sip@megatron.ietf.org; Thu, 24 Mar 2005 10:08:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20320 for ; Thu, 24 Mar 2005 10:08:54 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEU2q-0006Ne-7m for sip@ietf.org; Thu, 24 Mar 2005 10:14:49 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 24 Mar 2005 07:08:46 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j2OF8dgU004833; Thu, 24 Mar 2005 07:08:42 -0800 (PST) Received: from cisco.com ([161.44.79.169]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AQB60996; Thu, 24 Mar 2005 10:08:39 -0500 (EST) Message-ID: <4242D7F6.2010505@cisco.com> Date: Thu, 24 Mar 2005 10:08:38 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Arjun Roychowdhury Subject: Re: [Sip] P-Alerting-Mode to standards track? References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Cc: Cullen Jennings , "sip@ietf.org" , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Content-Transfer-Encoding: 7bit Arjun Roychowdhury wrote: > Just a quick question - if P-Alerting-Mode were to be used to indicate > "Auto" for a diagnostic call (loopback or otherwise), is it expected > that we use a "Reason" header to provide more infomation on why I want > this mode ? This is no doubt something that will be reused for other > apps beyond PoC, diag being one - and I wanted a clear way to define a > reason. Ideally, a token would be nice - not sure if a free form > reason header can really be as effective as a well defined token.... I'm not convinced a single item like a token is useful in this regard. If I am requesting an invite session with auto answer, there may be many things in the request that identify what I want to accomplish: - an offer - callerprefs - other special headers - special body parts - ... Any or all of those could be used by the recipient to decide whether to accept the call without alerting. With or without such indications, the recipient could establish restrictions on what is it is willing to do in the absence of some kind of user confirmation that normally follows alerting. For instance, a device that supports PTT and regular voice calls might only permit PTT with auto answer because it is "safe" in the sense that it still won't transmit without explicit user input. (Auto answering a regular voice call with auto answer is a good way to assist people in listening in to your room unannounced.) Paul > regds > arjun > > > > On Mon, 21 Mar 2005 20:46:12 -0800, Cullen Jennings wrote: > >>On the requirement, I would like to have this functionality. >> >>On the mechanism, I would expect this to lead to a few discussions. >> >> >>On 3/15/05 12:08 PM, "Dean Willis" wrote: >> >> >>>One of the consensus points that seemed to emerge during the recent >>>meeting was around the proposed P-Alerting-Mode header. We appear to >>>have decided that we really do need a standard (NOT a P-header) way to >>>ask a UAS to "auto answer", whether for a diagnostic loopback or >>>push-to-talk application. There also seems to be a consensus that this >>>should be done with a header, rather than a request parameter or other >>>mechanism. >>> >>>So, it has been proposed that this header be withdrawn from the >>>P-header "informational" draft, and re-documented on standards track. >>> >>>If we pursue this path, it should be noted that we would need to do it >>>very quickly, as OMA has real needs for this functionality ASAP. I'll >>>volunteer to help Andrew get it whipped into shape, unless somebody >>>else wants to throw themselves on it. It seems like a relative >>>no-brainer, just an exercise in documentation. >>> >>>So, poll for consensus: Does anybody strongly object to the development >>>of a standard header for requesting auto-answer of a request? >>> >>>Second poll: Do we see any reasons why this couldn't be done fairly >>>quickly, such as obvious dependencies on ongoing work that I've just >>>missed? >>> >>> >>>Thanks, >>> >>>-- >>>Dean Willis >>>SIP WG chair >>> >>> >>>_______________________________________________ >>>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>>This list is for NEW development of the core SIP Protocol >>>Use sip-implementors@cs.columbia.edu for questions on current sip >>>Use sipping@ietf.org for new developments on the application of sip >> >>_______________________________________________ >>Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >>This list is for NEW development of the core SIP Protocol >>Use sip-implementors@cs.columbia.edu for questions on current sip >>Use sipping@ietf.org for new developments on the application of sip >> > > > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 24 10:49:01 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25608 for ; Thu, 24 Mar 2005 10:49:00 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEUfg-0007jk-Hw for sip-web-archive@ietf.org; Thu, 24 Mar 2005 10:54:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEUXH-0000ES-5v; Thu, 24 Mar 2005 10:46:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEUXF-0000EI-DS for sip@megatron.ietf.org; Thu, 24 Mar 2005 10:46:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25248 for ; Thu, 24 Mar 2005 10:46:11 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.202]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEUcw-0007bq-Tj for sip@ietf.org; Thu, 24 Mar 2005 10:52:07 -0500 Received: by wproxy.gmail.com with SMTP id 49so255327wri for ; Thu, 24 Mar 2005 07:46:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=HHfb51r4QSHhh6LJNOLjw+ivVtv0gZgGkQF3fQ04/nht/dpR/g6m8aToM7RGKrfPL4tMmfTa5BwrunsGH8vLRgA1Oy0dpvN6V1n+uFSMJxG85fxHlVzAItojeOBlncwT7xwrengPGmmavmr4+shXVJuyU5D0uGPZL58upV8qjNI= Received: by 10.54.20.74 with SMTP id 74mr388475wrt; Thu, 24 Mar 2005 07:46:02 -0800 (PST) Received: by 10.54.17.6 with HTTP; Thu, 24 Mar 2005 07:46:01 -0800 (PST) Message-ID: Date: Thu, 24 Mar 2005 10:46:01 -0500 From: Arjun Roychowdhury To: David R Oran Subject: Re: [Sip] P-Alerting-Mode to standards track? In-Reply-To: <012a2d0968b24b67ac5cf5e28d85f719@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <012a2d0968b24b67ac5cf5e28d85f719@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , Cullen Jennings , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Arjun Roychowdhury List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: 7bit Okay, good. I agree with this reasoning. In that case, a question on how P-headers evolve - since this was a call for standards track, my assupmtion was that P-headers evolve to standards if they are applicable to a variety of networks - not just one (in this case PoC). If that is true (not sure, please clarify if this is wrong), then should this draft not also include a mechanism to identify why P-Alerting is requested - since it really is a big deal asking my phone not to ring and accept a call, even if you are known to me. regds arjun On Thu, 24 Mar 2005 09:58:44 -0500, David R Oran wrote: > > On Mar 22, 2005, at 1:35 PM, Arjun Roychowdhury wrote: > > > Just a quick question - if P-Alerting-Mode were to be used to indicate > > "Auto" for a diagnostic call (loopback or otherwise), is it expected > > that we use a "Reason" header to provide more infomation on why I want > > this mode ? > No. We need tighter semantics than that in order to be able to do > authorization feasibly. The direction I'd prefer is to define a > diagnostic header that actually specifies the diagnostic mode (e.g. > rtp-loopback, decode/encode loopback, analog loopback, synthetic > stream, etc.) so you know if, for example, the transducers are going to > be enabled or not and can authorize appropriately. > > > This is no doubt something that will be reused for other > > apps beyond PoC, diag being one - and I wanted a clear way to define a > > reason. Ideally, a token would be nice - not sure if a free form > > reason header can really be as effective as a well defined token.... > > > Open ended reasons make authorization harder. I much prefer specifying > exactly what you want to do rather than why. It works better with > automatons and is also more in keeping with the general SIP philosophy > of specifying mechanisms rather than services/applications. > > Cheers,. Dave. > > > > > regds > > arjun > > > > > > > > On Mon, 21 Mar 2005 20:46:12 -0800, Cullen Jennings > > wrote: > >> > >> On the requirement, I would like to have this functionality. > >> > >> On the mechanism, I would expect this to lead to a few discussions. > >> > >> > >> On 3/15/05 12:08 PM, "Dean Willis" wrote: > >> > >>> > >>> One of the consensus points that seemed to emerge during the recent > >>> meeting was around the proposed P-Alerting-Mode header. We appear to > >>> have decided that we really do need a standard (NOT a P-header) way > >>> to > >>> ask a UAS to "auto answer", whether for a diagnostic loopback or > >>> push-to-talk application. There also seems to be a consensus that > >>> this > >>> should be done with a header, rather than a request parameter or > >>> other > >>> mechanism. > >>> > >>> So, it has been proposed that this header be withdrawn from the > >>> P-header "informational" draft, and re-documented on standards track. > >>> > >>> If we pursue this path, it should be noted that we would need to do > >>> it > >>> very quickly, as OMA has real needs for this functionality ASAP. I'll > >>> volunteer to help Andrew get it whipped into shape, unless somebody > >>> else wants to throw themselves on it. It seems like a relative > >>> no-brainer, just an exercise in documentation. > >>> > >>> So, poll for consensus: Does anybody strongly object to the > >>> development > >>> of a standard header for requesting auto-answer of a request? > >>> > >>> Second poll: Do we see any reasons why this couldn't be done fairly > >>> quickly, such as obvious dependencies on ongoing work that I've just > >>> missed? > >>> > >>> > >>> Thanks, > >>> > >>> -- > >>> Dean Willis > >>> SIP WG chair > >>> > >>> > >>> _______________________________________________ > >>> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >>> This list is for NEW development of the core SIP Protocol > >>> Use sip-implementors@cs.columbia.edu for questions on current sip > >>> Use sipping@ietf.org for new developments on the application of sip > >> > >> _______________________________________________ > >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > >> This list is for NEW development of the core SIP Protocol > >> Use sip-implementors@cs.columbia.edu for questions on current sip > >> Use sipping@ietf.org for new developments on the application of sip > >> > > > > > > -- > > Arjun Roychowdhury > > > > _______________________________________________ > > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > > This list is for NEW development of the core SIP Protocol > > Use sip-implementors@cs.columbia.edu for questions on current sip > > Use sipping@ietf.org for new developments on the application of sip > > > David R. Oran > Cisco Fellow > Cisco Systems > 7 Ladyslipper Lane > Acton, MA 01720 USA > Tel: +1 978 264 2048 > Email: oran@cisco.com > -- Arjun Roychowdhury _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 24 11:13:34 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28103 for ; Thu, 24 Mar 2005 11:13:34 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEV3R-00007i-83 for sip-web-archive@ietf.org; Thu, 24 Mar 2005 11:19:30 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEUvB-0003fm-Jb; Thu, 24 Mar 2005 11:10:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEUv9-0003fd-OS for sip@megatron.ietf.org; Thu, 24 Mar 2005 11:10:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27590 for ; Thu, 24 Mar 2005 11:10:53 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.194]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEV0q-0008Pc-Nh for sip@ietf.org; Thu, 24 Mar 2005 11:16:49 -0500 Received: by wproxy.gmail.com with SMTP id 36so349267wri for ; Thu, 24 Mar 2005 08:10:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=WKaFkRAXR8ZfcWVxhmWqfH+dl4ZWRzkedSm7HdFXvcz8IKRunH2E9fgDOI3lqkc4ao5nHErV74SlVcE3ni9qhhZUGFBoOy+fsGcxlTIchOnad6khiljYnwMiaSmiX4K3O8rz5lPlrdgMW/GqP8aszto/pF9+1z9ggkbDHeLUkwk= Received: by 10.54.20.74 with SMTP id 74mr406097wrt; Thu, 24 Mar 2005 08:10:45 -0800 (PST) Received: by 10.54.17.6 with HTTP; Thu, 24 Mar 2005 08:10:45 -0800 (PST) Message-ID: Date: Thu, 24 Mar 2005 11:10:45 -0500 From: Arjun Roychowdhury To: David R Oran Subject: Re: [Sip] P-Alerting-Mode to standards track? In-Reply-To: <012a2d0968b24b67ac5cf5e28d85f719@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit References: <012a2d0968b24b67ac5cf5e28d85f719@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , Cullen Jennings , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Arjun Roychowdhury List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Dave, missed this part in your mail. So are you saying its not a good idea to specify somewhere in the SIP message that is is for a "poc" application (or say this is for a "diag" application) and this should really be inferred by analyzing the other parts of the message ? So to answer my own question of indicating why P-Alerting mode is needed, I guess you are saying that if another application needs to use P-Alerting then its the responsibility of that draft specfying the usage to also specify a mechanism to identify the application through the headers/SDP attributes it may choose to introduce. Is this correct ? regds arjun On Thu, 24 Mar 2005 09:58:44 -0500, David R Oran wrote: > automatons and is also more in keeping with the general SIP philosophy > of specifying mechanisms rather than services/applications. > > Cheers,. Dave. -- Arjun Roychowdhury _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 24 11:31:59 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00413 for ; Thu, 24 Mar 2005 11:31:59 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEVLH-0000ph-Td for sip-web-archive@ietf.org; Thu, 24 Mar 2005 11:37:56 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEVCl-0006tJ-Gp; Thu, 24 Mar 2005 11:29:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEVCj-0006tB-Bf for sip@megatron.ietf.org; Thu, 24 Mar 2005 11:29:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29845 for ; Thu, 24 Mar 2005 11:29:03 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEVIR-0000gY-Fg for sip@ietf.org; Thu, 24 Mar 2005 11:34:59 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 24 Mar 2005 08:28:56 -0800 X-IronPort-AV: i="3.91,119,1110182400"; d="scan'208"; a="622719875:sNHT29076760" Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j2OGSrZV025276; Thu, 24 Mar 2005 08:28:53 -0800 (PST) Received: from [10.32.245.157] (stealth-10-32-245-157.cisco.com [10.32.245.157]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j2OGLV4c002193; Thu, 24 Mar 2005 08:21:32 -0800 In-Reply-To: References: <012a2d0968b24b67ac5cf5e28d85f719@cisco.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <93ce9111a60438dd84878757974fdc2f@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [Sip] P-Alerting-Mode to standards track? Date: Thu, 24 Mar 2005 11:28:48 -0500 To: Arjun Roychowdhury X-Mailer: Apple Mail (2.619.2) IIM-SIG: v:"1.1"; h:"imail.cisco.com"; d:"cisco.com"; z:"home"; m:"krs"; t:"1111681293.789446"; x:"432200"; a:"rsa-sha1"; b:"nofws:1532"; e:"Iw=="; n:"sQYarK2E51MdcTiUqeif3F7cWdxIfoCiXhdfb9vD5ee/j0jXL15gbFxF2p" "XIweAblu0N6XAgK7k+wrbr7bQDJaCDqOmzqpRUBjIRQAXQ7NzadpmR3pUL6wxaRUtW+c43sl9jC" "50Qg1sXHpPjt8Y+Y16ioyQAQAdSunM4YhevURc="; s:"gW8y803UuUsy2Crhxx849lnbPK2tAuLk66A65OUQ9XFIpAeou4u7akakVtAr3WScW8ueh1+W" "QNt4EYSSch7HiGucfmy3uCP8iDQDvP/0ULNNxN94fzK6tzsKdaB06uVso1yeg9KvvTbWadZ50+T" "15OVYQC2ZHQ1DlbCN0m6BgrU="; c:"From: David R Oran "; c:"Subject: Re: [Sip] P-Alerting-Mode to standards track?"; c:"Date: Thu, 24 Mar 2005 11:28:48 -0500" IIM-VERIFY: s:"y"; v:"y"; r:"60"; h:"imail.cisco.com"; c:"message from imail.cisco.com verified; " X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: "sip@ietf.org" , Cullen Jennings , Dean Willis X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit On Mar 24, 2005, at 11:10 AM, Arjun Roychowdhury wrote: > Dave, missed this part in your mail. So are you saying its not a good > idea to specify somewhere in the SIP message that is is for a "poc" > application (or say this is for a "diag" application) and this should > really be inferred by analyzing the other parts of the message ? > Correct. I'm saying headers should say what to do, not what application it is for. In the case of diagnostics, the header would say you want various diagnostic features on the call. (The detail of exactly what to loop or synthesize, and how, would be in the SDP rather than the SIP signaling, of course). There's no reason to define something rigid like a "diagnostic" application. Ditto for Push-to-talk. If there's some actual mechanism to invoke, that goes in the SIP signaling, otherwise it gets inferrred from other things. For example, I might honor auto-answer simply based on whether the caller is on a particular buddy list. > So to answer my own question of indicating why P-Alerting mode is > needed, I guess you are saying that if another application needs to > use P-Alerting then its the responsibility of that draft specfying the > usage to also specify a mechanism to identify the application through > the headers/SDP attributes it may choose to introduce. Is this correct > ? > Something has to tell the callee if the caller wants auto-answer rather than normal alerting and waiting for user action. > regds > arjun > > On Thu, 24 Mar 2005 09:58:44 -0500, David R Oran > wrote: >> automatons and is also more in keeping with the general SIP philosophy >> of specifying mechanisms rather than services/applications. >> >> Cheers,. Dave. > > -- > Arjun Roychowdhury > David R. Oran Cisco Fellow Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 USA Tel: +1 978 264 2048 Email: oran@cisco.com _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Tue Mar 29 07:37:13 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21112 for ; Tue, 29 Mar 2005 07:37:13 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGG4n-0002fL-9S for sip-web-archive@ietf.org; Tue, 29 Mar 2005 07:44:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGFqj-0005xp-JE; Tue, 29 Mar 2005 07:29:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGFqi-0005xh-AD for sip@megatron.ietf.org; Tue, 29 Mar 2005 07:29:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20248 for ; Tue, 29 Mar 2005 07:29:35 -0500 (EST) Received: from web42104.mail.yahoo.com ([66.218.93.197]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DGFxO-0002Lz-Os for sip@ietf.org; Tue, 29 Mar 2005 07:36:32 -0500 Received: (qmail 32143 invoked by uid 60001); 29 Mar 2005 12:28:57 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=oz+k8bDRBS9fRsB209/u8APiUSYZt1vmauoIxO5ZImsPWQSWC79mpNMqeBpfUYHAD3Xn9SyJnTk133o8a/rYTtnUOwgGHVi2kcu+ZL9uK9n4E2L+KfESrGDgTvXVM1egRUBgUom169B6v9QHV+Z6L8odkePn7R0gjMebtB0jaSI= ; Message-ID: <20050329122857.32141.qmail@web42104.mail.yahoo.com> Received: from [66.80.10.146] by web42104.mail.yahoo.com via HTTP; Tue, 29 Mar 2005 04:28:57 PST Date: Tue, 29 Mar 2005 04:28:57 -0800 (PST) From: sipit 2005 To: sip@ietf.org MIME-Version: 1.0 X-Spam-Score: 1.3 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Sip] Doubt on loose routing X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1887888887==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.9 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a --===============1887888887== Content-Type: multipart/alternative; boundary="0-718128901-1112099337=:30223" --0-718128901-1112099337=:30223 Content-Type: text/plain; charset=us-ascii Hi, I have record-route set from 200 OK for INVITE as Record-Route: Record-Route: Record-Route: Contact: As the last record-route header doesn't have lr param(P1 might be expecting strict routing), in this combination can I send the ACK/BYE requests to sip:u at UA.com:5060 directly? Is it possible to follow strict routing even though I get lr param? While I was interoperating with sipgate.de (SIP express router) I got ftag param and lr param in 200 OK, I was trying to send ACK/BYE requests to record-route URI instead of final destination. Iam not getting any response for BYE. Please help me. regards, SIPIT --------------------------------- Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. --0-718128901-1112099337=:30223 Content-Type: text/html; charset=us-ascii

Hi,


I have record-route set from 200 OK for INVITE as

Record-Route: <sip:pu3 at P3.com:5060;lr>
Record-Route: <sip:pu2 at P2.com:5060;lr>
Record-Route: <sip:pu1 at P1.com:5060>
Contact:<sip:u at UA.com:5060>


As the last record-route header doesn't have lr param(P1 might be expecting strict routing), in this combination can I send the ACK/BYE requests to sip:u at UA.com:5060 directly?


Is it possible to follow strict routing even though I get lr param?

While I was interoperating with sipgate.de (SIP express router)
I got ftag param and lr param in 200 OK, I was trying to sen! d ACK/BYE requests to
record-route URI instead of final destination. Iam not getting any response for BYE.

Please help me.

regards,
SIPIT

Do you Yahoo!?
Yahoo! Mail - Easier than ever with enhanced search. Learn more. --0-718128901-1112099337=:30223-- --===============1887888887== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1887888887==-- From sip-bounces@ietf.org Tue Mar 29 13:06:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07719 for ; Tue, 29 Mar 2005 13:06:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGLDd-0001lt-Qf for sip-web-archive@ietf.org; Tue, 29 Mar 2005 13:13:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGL2W-0001Ym-1E; Tue, 29 Mar 2005 13:02:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGL2T-0001Yh-IV for sip@megatron.ietf.org; Tue, 29 Mar 2005 13:02:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07373 for ; Tue, 29 Mar 2005 13:02:02 -0500 (EST) From: tammi.nguyen@conexant.com Received: from cnxtsmtp9.conexant.com ([198.62.9.205] helo=mime-nb.bbnet.ad) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGL9D-0001cR-0q for sip@ietf.org; Tue, 29 Mar 2005 13:09:04 -0500 Received: Conexant Mail To: sip@ietf.org Message-ID: Date: Tue, 29 Mar 2005 10:01:57 -0800 X-MIMETrack: Serialize by Router on NBLNBkup1/Server/Conexant (Release 6.5.3|September 14, 2004) at 03/29/2005 10:02:42 AM MIME-Version: 1.0 X-Spam-Score: 1.1 (+) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Subject: [Sip] Tammi K Nguyen/USA/Conexant is out of the office. X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1341077495==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.8 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a --===============1341077495== Content-type: multipart/alternative; Boundary="0__=07BBE540DFF088C38f9e8a93df938690918c07BBE540DFF088C3" Content-Disposition: inline --0__=07BBE540DFF088C38f9e8a93df938690918c07BBE540DFF088C3 Content-type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I will be out of the office starting 03/28/2005 and will not return until 04/04/2005. Please see Mounir Ayoub for all VoIP DVT-Related Concerns. Regards, -tammi ********************** Legal Disclaimer **************************** "This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you." ********************************************************************** --0__=07BBE540DFF088C38f9e8a93df938690918c07BBE540DFF088C3 Content-type: text/html; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: 7bit

I will be out of the office starting 03/28/2005 and will not return until 04/04/2005.

Please see Mounir Ayoub for all VoIP DVT-Related Concerns.

Regards,
-tammi

********************** Legal Disclaimer ****************************

"This email may contain confidential and privileged material for the sole use of the intended recipient. Any unauthorized review, use or distribution by others is strictly prohibited. If you have received the message in error, please advise the sender by reply email and delete the message. Thank you."

**********************************************************************

--0__=07BBE540DFF088C38f9e8a93df938690918c07BBE540DFF088C3-- --===============1341077495== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1341077495==-- From sip-bounces@ietf.org Wed Mar 30 09:56:15 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04694 for ; Wed, 30 Mar 2005 09:56:15 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGej7-0002KH-NL for sip-web-archive@ietf.org; Wed, 30 Mar 2005 10:03:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGeVz-0001vN-3r; Wed, 30 Mar 2005 09:49:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGeVx-0001vF-Aj for sip@megatron.ietf.org; Wed, 30 Mar 2005 09:49:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04044 for ; Wed, 30 Mar 2005 09:49:47 -0500 (EST) Received: from smtp8.clb.oleane.net ([213.56.31.28]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGecs-00028k-S8 for sip@ietf.org; Wed, 30 Mar 2005 09:56:59 -0500 Received: from Pavillonquatre (upperside.rain.fr [194.206.151.59] (may be forged)) (authenticated) by smtp8.clb.oleane.net with ESMTP id j2UEncxo031418 for ; Wed, 30 Mar 2005 16:49:38 +0200 Message-Id: <200503301449.j2UEncxo031418@smtp8.clb.oleane.net> From: "Chantal Ladouce" To: Date: Wed, 30 Mar 2005 16:49:33 +0200 MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcU1N69UNo6aLsSBQ5iPO6Ug+g5MrA== X-Spam-Score: 0.1 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Subject: [Sip] International SIP conference 2006 - Paris - France X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0229577406==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.2 (/) X-Scan-Signature: 202a3ece0492a8c7e7c8672d5214398f This is a multi-part message in MIME format. --===============0229577406== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0E49_01C53548.737F30C0" This is a multi-part message in MIME format. ------=_NextPart_000_0E49_01C53548.737F30C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The 8th edition of the International SIP conference will take place in Paris on February 21 to 24, 2006. The event will be jointly organized with the wVOiP Showcase. A call for proposals is online effective until May 30. Get all details at: http://www.upperside.fr/sip2006/sip2006intro.htm ------=_NextPart_000_0E49_01C53548.737F30C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The 8th edition of the = International = SIP conference will take place in Paris on February 21 to 24, 2006.

The event will be jointly organized with = the wVOiP = Showcase.

 

A call for proposals is online effective until = May 30.

 

Get all details at:

http://www.upperside.fr/sip2006/sip2006intro.htm<= /span>

 

------=_NextPart_000_0E49_01C53548.737F30C0-- --===============0229577406== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============0229577406==-- From sip-bounces@ietf.org Wed Mar 30 16:32:47 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26520 for ; Wed, 30 Mar 2005 16:32:47 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGkuu-0007co-Td for sip-web-archive@ietf.org; Wed, 30 Mar 2005 16:40:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGjqB-000717-D7; Wed, 30 Mar 2005 15:31:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGjq8-00070u-N0 for sip@megatron.ietf.org; Wed, 30 Mar 2005 15:31:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06941 for ; Wed, 30 Mar 2005 15:30:59 -0500 (EST) Received: from albatross.ericsson.se ([193.180.251.49]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGjx7-0001Hn-9R for sip@ietf.org; Wed, 30 Mar 2005 15:38:13 -0500 Received: from esealmw128.eemea.ericsson.se ([153.88.254.121]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id j2UKUwfo005720; Wed, 30 Mar 2005 22:30:58 +0200 (MEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Mar 2005 22:30:57 +0200 Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.211); Wed, 30 Mar 2005 22:30:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Few questions regarding PRACK (RFC3262) Date: Wed, 30 Mar 2005 22:30:56 +0200 Message-ID: Thread-Topic: [Sip] Few questions regarding PRACK (RFC3262) Thread-Index: AcUvaJYScEKYeCAlQoGiLG24HXJxeQF/dr2g From: "Christer Holmberg \(JO/LMF\)" To: "Chadha Retesh-A19894" , X-OriginalArrivalTime: 30 Mar 2005 20:30:57.0273 (UTC) FILETIME=[60D9FE90:01C53567] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: quoted-printable Hi, Comments inline ([CHH]) >1. Is there any use of PRACK, if we are sure that the underlying = transport between all the SIP entities is reliable? [CHH] With PRACK you can send a "real" offer/answer in a provisional = response, and in the PRACK (the first PRACK) itself. >2. If one provisional response is reliable, is it a MUST that all the = subsequent provisional responses be reliable(not with=20 >Rseq header)? What should be the behavior of the UAC? This is when UAC = sent an INVITE with Supported: 100rel. [CHH] If the UAC indicated SUPPORTED I believe that the UAS can choose = which provisional response(s) should be sent reliably and which should = not. >3. In what scenario, will the UAC, send a new offer in PRACK? [CHH] The UAC MAY send a new offer in the PRACK (the first PRACK) if it = received an answer in the 18x. >4. In the following scenario, what is the response to the second PRACK = request - > INVITE --> > <-- 180 Rseq: 1 > PRACK (Rack: 1)--> >Crossover happened here<-- 180 RSeq:1 (this is a restransmission, = since PRACK is not received and T1 timer fires) >UAC got both the 1xx, but may be late > PRACK (Rack: 1)--> > <-- 200 ok(1st PRACK ) > <-- 481(PRACK) <--- Let me know, if i am = right here?? [CHH] The UAC shall not generate a new PRACK for a re-transmission of = the 180. Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 30 16:54:37 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00581 for ; Wed, 30 Mar 2005 16:54:37 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGlG5-0000NT-0T for sip-web-archive@ietf.org; Wed, 30 Mar 2005 17:01:53 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGl4E-0004c9-22; Wed, 30 Mar 2005 16:49:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGl49-0004ZX-8F for sip@megatron.ietf.org; Wed, 30 Mar 2005 16:49:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00181 for ; Wed, 30 Mar 2005 16:49:31 -0500 (EST) From: Mpierce1@aol.com Received: from imo-m26.mx.aol.com ([64.12.137.7]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGlB6-0000FQ-G8 for sip@ietf.org; Wed, 30 Mar 2005 16:56:46 -0500 Received: from Mpierce1@aol.com by imo-m26.mx.aol.com (mail_out_v37_r5.33.) id l.1e0.390b7436 (15864); Wed, 30 Mar 2005 16:49:15 -0500 (EST) Received: from aol.com (mow-m04.webmail.aol.com [64.12.184.132]) by air-id06.mx.aol.com (v104.18) with ESMTP id MAILINID63-3df8424b1eda3aa; Wed, 30 Mar 2005 16:49:15 -0500 Date: Wed, 30 Mar 2005 16:49:14 -0500 To: sip@ietf.org, hgs@cs.columbia.edu, jmpolk@cisco.com MIME-Version: 1.0 Message-ID: <3033B0D7.5CDEDF75.007CBA4A@aol.com> X-Mailer: Atlas Mailer 2.0 X-AOL-IP: 47.230.0.45 X-AOL-Language: english Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 8bit Subject: [Sip] Comments on Resource-Priority -07 X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 1.6 (+) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Content-Transfer-Encoding: 8bit I have the following comments on the -07 version of Resource-Priority header which was posted for review on March 16 to begin the normal 2 week Last Call. 1. Nits Section 1, 7th paragraph (beginning "This document defines...") needs to be rewritten to refer to the two headers which this document defines. Section 4.6.5 wording of 2nd sentence is incomplete. Section 10.4 word "layer" should be "level" and the word "and" should be added after "priority". 2. Major problems Section 4.2, rule 1 indicates that, if there is no resource shortage at the moment, the following steps are omitted. However, the following steps are the authorization/authentication steps which must always be done first. Since one of the results of requesting a priority level, even when there is no resource shortage known to the originating end, is to include the precedence level for use in the remainder of the call. For example, the level requested may prevent a later preemption after a shortage of resources occurs. Rule 1 should simply be the final sentence. Section 4.7.3 refers to the use of "forking" with the resource-priority header. This is a major problem, since forking of a high precedence marked INVITE in a domain that performs preemption could result in preemption of multiple existing sessions when only one is needed to complete the call. Somehow, forking must be prevented. Section 10.2 states in the last sentence that the DSN (incorrectly written as "DRSN") uses preemption. This is misleading, since it may use other preferential treatment procedures as well. It is unnecessary for this document to state the algorithms/procedures used in each domain. Section 10.3 defines the operation of DRSN which uses six levels. The operation described, in which a Flash-Override-Override preempts another of the same level is not the desired operation. It appears that this may be based on the current operation of some circuit-switches because of implementation difficulties when the 6th level was added a few years ago. However, this bad operation should not be perpetuated. In any event, there is no need for this Resource-Priority header document to go into this type of detail about the inner operation of some network. This paragraph should be deleted. Section 12.1 2nd paragraph forbids adding a new priority value to a namespace (MUST NOT). Previous versions of this draft allowed it (should not). There should be no reason why another value cannot be added to DSN later. If added, it is the responsibility of the operator of the DSN domain to figure out how to do it to avoid interoperability problems. 3. Other problems Section 1, paragraph beginning "Since calls may traverse..." states that "it is important that all such domains and elements apply the same algorithms for the same namespace as otherwise the end-to-end experience of privileged users may be compromised." While this may be true for some combinations of preemption followed by queuing, it is not necessarily true for all combinations and for any algorithm that might be added later. Suggest that this sentence be reworded to say: "It is important that careful consideration be made before different algorithms are used at different places within a single call." Section 4.7.1 2nd paragraph. A UAC should never attempt another request using a different resource value upon receipt of a 417. A human user may choose to do whatever they are authorized to do when trying a new call. No device can be allowed to do this automatically, since it would be violating the policies for the use of priority levels. Although section 7 only gives "examples", the use of "DSN" causes confusion since it shows an operation which would not be used in the DSN domain. Specifically, the inclusion of the R-P header in the 180 and 200 in 7.1 and the list of accepted values in the 417 in 7.2 would not be used in the DSN. The example should use a domain that might use these techniques. Since there is none that is known to work this way, the examples should use "Foo" and "Bar" as in Section 8.2. Section 8.1 causes confusion since it implies the existence of a relative order between different namespaces. It should instead say that there is no defined relationship between the values of different namespaces and that RP actors may apply whatever algorithms or procedures they wish when dealing with multiple namespaces, as long as the relative levels within each namespace are maintained. Section 8.3 With a statement as given above, it is unnecessary to include this section on "examples of invalid orderings". Section 11.3 The association of the requirement for confidentiality and integrity of the user's data with the Resource-Priority header leads to confusion. They are unrelated requirements. Standard policy dictates whether there is a need for confidentiality and integrity of the user's data independently from the need for precedence levels. The first paragraph should be deleted so that this section only addresses the security of the R-P header itself. Section 11.4 No system that allows the use of the R-P header should allow anonymity. In any case, the use of anonymity is independent from the use of R-P header and should not be mentioned in this document. Section 12.1 The purpose of IANA registration is to prevent conflicts in assignment of names and numbers, such as the namespace. There is no need to include the "operation" (preemption or preferential queuing) in the IANA registration. In fact, the DSN may use other techniques besides preemption, such as exemption from network management controls, as described in draft-pierce-tsvwg-pref-treat-example. 4. Unsubstantiated capabilities The draft contains capabilities for which there has been no demonstrated requirement. While it is always desirable to include extra flexibility, it leads to some confusion. The requirements of the known applications only require the addition of the Resource-Priority header to the INVITE message. The receiver acts on this information if it can, and does not if it can not, in setting up the call. There is no identified requirement for the following: - The Accept-Resource-Priority Header (3.2) - Resource-Priority header in Ack, Prack, BYE (3.3) - The resource-priority option tag (3.4) - Use of Require Header (4.3) Mike Pierce _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Wed Mar 30 18:39:22 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10829 for ; Wed, 30 Mar 2005 18:39:22 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGmtT-0002hp-9B for sip-web-archive@ietf.org; Wed, 30 Mar 2005 18:46:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGmjm-0005oD-DU; Wed, 30 Mar 2005 18:36:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGmjj-0005o8-5Q for sip@megatron.ietf.org; Wed, 30 Mar 2005 18:36:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10634 for ; Wed, 30 Mar 2005 18:36:32 -0500 (EST) Received: from secure03.dhserver.net ([207.142.135.151]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGmqj-0002dN-Kf for sip@ietf.org; Wed, 30 Mar 2005 18:43:50 -0500 X-ClientAddr: 24.85.236.155 Received: from sonata (S010600095b9792b5.vc.shawcable.net [24.85.236.155]) by secure03.dhserver.net (8.11.6/8.11.6) with ESMTP id j2UNTwr11192; Wed, 30 Mar 2005 16:29:58 -0700 Message-Id: <200503302329.j2UNTwr11192@secure03.dhserver.net> From: "Shida Schubert" To: "'Kumiko Ono'" , Subject: RE: [Sip] e2m security: error code and SIP identity Date: Wed, 30 Mar 2005 15:30:04 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <31C52C0DA09A65ono.kumiko@lab.ntt.co.jp> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUsDkIYH8aTS7l+RRCQNMNaAqVCDwJcaBZg X-yoursite-MailScanner-Information: Please contact the ISP for more information X-yoursite-MailScanner: Found to be clean X-MailScanner-From: shida@ntt-at.com X-Spam-Score: 0.1 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit Cc: kumiko@cs.columbia.edu, tachimoto.shinya@lab.ntt.co.jp X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.1 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit Hi Kumiko; As I recall, it was mentioned several times at Minneapolis to make an effort to enforce the use of SIP Identity, to provide an integrity protection. According to my, not always accurate recollection, people were even alluding to mandate the use of SIP Identity in the future. Now, if you can use and depend on SIP Identity as a way to provide integrity protection, which in current spec allows proxy to verify its validity, you only have to be concerned about a scenario where SIP Identity is not attached to an encrypted message(Another beauty of SIP Identity is that the signature is in the header therefore, you don't even have to decrypt to find the signature as you do with the current e2m). In the scenario mentioned above, I think it would be okay to have extra messages exchanged as it will be a rare case for this to take place, when and if The SIP Identity is mandated, which I do hope happens in near future. So considering what I stated above, I prefer option 3. Thanks & Regards Shida Schubert > -----Original Message----- > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Kumiko > Ono > Sent: Friday, March 18, 2005 2:56 PM > To: sip@ietf.org > Cc: shida@ntt-at.com; kumiko@cs.columbia.edu; > tachimoto.shinya@lab.ntt.co.jp > Subject: [Sip] e2m security: error code > > At the SIP meeting last Tuesday, we discussed two issues of e2m security. > I would like to resolve the issue that had no consensus. > > Issue: > An error response for proxy to a UAC for combined condition, requiring > decryption (disclosure of message) and signature simultaneously. > > Followings are the options I presented at Minneapolis: > Option1: A new error response > Option2: An existing error response(493) with Warning header > Option3: Existing error responses, one task at time > > At the meeting, we had a consensus that when UA signs the body it should > place the signature inside of the encrypted body, which means the proxy > has no way to know the existence of signature until it is able to > decrypt the message. > > By using option 3, the proxy can ask for diclosure first, find out if > the message has a signature attached, and respond with another error > requesting signature when the message lacks it. This can be done and it > is general procedure of proxy, but the number of messages exchanged will > increases as it needs to respond twice when signature is not present. > > Option 1 and 2 will resolve the downside mentioned with usage of option > 3. If the local security policy of the proxy requires both signature and > disclosure, it can send error with combined reason, regardless of the > possible existence of signature in the encrypted message. > > With option 1, we need to define a new error code, such as 496 > "Undecipherable and signature required". The error condition assumes > that the signature is lackin. Additionaly, once introducing a new code > for combined reasons, we might need more new codes for other > combinations. Therefore, I don't advocate option 1. > > With option 2, we need to define a three-digit warning-code. As section > 20.43 in RFC3261 says, > >The Warning header field isused to carry additional information about the > status of a response. The currently-defined "warn-code"s are induced by > the SDP. > This leads me to think that we can set a new warn-code that is induced > by non-SDP. However, section 27.2 restricts the possible failures > resulting from a SDP problem. > > If the reasoning restriction is not too stringent, we can define the > following new warn-code, such as 340. However, it is strange to > introduce a new warn-code that has the same meaning as that of the > existing error code. Therefore, I am okay to go with option 3, not > option 2. > > Your feedback will be very much appreciated. > > Thanks, > -- > Kumiko Ono > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 31 10:41:54 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04687 for ; Thu, 31 Mar 2005 10:41:54 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH1v4-0003K8-2p for sip-web-archive@ietf.org; Thu, 31 Mar 2005 10:49:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH1iA-0002p0-Sy; Thu, 31 Mar 2005 10:35:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH1i8-0002ov-6N for sip@megatron.ietf.org; Thu, 31 Mar 2005 10:35:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04101 for ; Thu, 31 Mar 2005 10:35:54 -0500 (EST) Received: from zcars04e.nortelnetworks.com ([47.129.242.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH1pG-00036F-4J for sip@ietf.org; Thu, 31 Mar 2005 10:43:19 -0500 Received: from zrtpd0jn.us.nortel.com (zrtpd0jn.us.nortel.com [47.140.202.35]) by zcars04e.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j2VFZcq12802 for ; Thu, 31 Mar 2005 10:35:39 -0500 (EST) Received: by zrtpd0jn.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 31 Mar 2005 10:35:36 -0500 Message-ID: From: "Judy Yi" To: sip@ietf.org Date: Thu, 31 Mar 2005 10:35:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: 0.5 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Subject: [Sip] Are duplicate entries allowed in the Route and Record-Route? X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1672656640==" Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.5 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1672656640== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C53607.46AAC5B8" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C53607.46AAC5B8 Content-Type: text/plain Are duplicate entries allowed in the Route and Record-Route? E.g. is the following Route header valid? Route: , , , Thanks, Judy ------_=_NextPart_001_01C53607.46AAC5B8 Content-Type: text/html Are duplicate entries allowed in the Route and Record-Route?

Are duplicate entries allowed in the Route and Record-Route?

E.g. is the following Route header valid?
Route: <A@domain.com>, <B@domain.com>, <B@domain.com>, <A@domain.com>

Thanks,
Judy


------_=_NextPart_001_01C53607.46AAC5B8-- --===============1672656640== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --===============1672656640==-- From sip-bounces@ietf.org Thu Mar 31 13:01:33 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17384 for ; Thu, 31 Mar 2005 13:01:33 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH46G-0000IG-EO for sip-web-archive@ietf.org; Thu, 31 Mar 2005 13:09:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH3wO-0000Mo-BW; Thu, 31 Mar 2005 12:58:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH3wM-0000Mg-6c for sip@megatron.ietf.org; Thu, 31 Mar 2005 12:58:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17098 for ; Thu, 31 Mar 2005 12:58:43 -0500 (EST) Received: from broadsoft.com ([204.200.197.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH43V-0000E7-Gr for sip@ietf.org; Thu, 31 Mar 2005 13:06:10 -0500 Received: from brett1 (66.239.146.130.ptr.us.xo.net [66.239.146.130]) (authenticated bits=0) by broadsoft.com (8.13.1/8.12.11) with ESMTP id j2VHwXu8018622 for ; Thu, 31 Mar 2005 12:58:37 -0500 (EST) From: "Brett Tate" To: Subject: RE: [Sip] Are duplicate entries allowed in the Route and Record-Route? Date: Thu, 31 Mar 2005 12:58:56 -0500 Message-ID: <000e01c5361b$4f857390$a601a8c0@brett1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable > Are duplicate entries allowed in the=20 > Route and Record-Route?=20 Yes. If duplicate record-route entries are added by a proxy, it is responsible for ensuring subsequent requests traverse the resulting = route correctly. If duplicate pre-loaded Route entries are added by a UA, there is no guarantee that the request will traverse the duplicates as the UA might = have desired. Per rfc3261 section 16.3 number 4, it might trigger a 482 = response if the device is unwilling to honor the spiral. _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 31 15:09:36 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00090 for ; Thu, 31 Mar 2005 15:09:36 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH66B-0005Pb-6B for sip-web-archive@ietf.org; Thu, 31 Mar 2005 15:17:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH5yJ-0001ez-Gn; Thu, 31 Mar 2005 15:08:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH5yH-0001ef-Ny for sip@megatron.ietf.org; Thu, 31 Mar 2005 15:08:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00012 for ; Thu, 31 Mar 2005 15:08:52 -0500 (EST) Received: from ckmso1.att.com ([12.20.58.69] helo=ckmso1.proxy.att.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH65R-0005P0-Ql for sip@ietf.org; Thu, 31 Mar 2005 15:16:19 -0500 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-5.5) with ESMTP id j2VK8PJ7012899 for ; Thu, 31 Mar 2005 15:08:42 -0500 Received: from OCCLUST04EVS1.ugd.att.com (135.38.164.12) by attrh5i.attrh.att.com (7.2.052) id 423DAD7E00216830; Thu, 31 Mar 2005 15:08:40 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Comments on Resource-Priority -07 Date: Thu, 31 Mar 2005 14:08:39 -0600 Message-ID: <28F05913385EAC43AF019413F674A0170A412D0C@OCCLUST04EVS1.ugd.att.com> Thread-Topic: [Sip] Comments on Resource-Priority -07 Thread-Index: AcU1cvkc2R7fea1PSrWsu+APSPUuSgAuiHog From: "Dolly, Martin C, ALABS" To: , , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Content-Transfer-Encoding: quoted-printable X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 6ba8aaf827dcb437101951262f69b3de Content-Transfer-Encoding: quoted-printable Mike, This draft defines the SIP behavior, and not the procedures for a given = call/session type. I believe your "problems" can be addressed in the DSN = procedures document. Cheers, Martin -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org]On Behalf Of Mpierce1@aol.com Sent: Wednesday, March 30, 2005 4:49 PM To: sip@ietf.org; hgs@cs.columbia.edu; jmpolk@cisco.com Subject: [Sip] Comments on Resource-Priority -07 I have the following comments on the -07 version of Resource-Priority = header which was posted for review on March 16 to begin the normal 2 = week Last Call. 1. Nits Section 1, 7th paragraph (beginning "This document defines...") needs to = be rewritten to refer to the two headers which this document defines. Section 4.6.5 wording of 2nd sentence is incomplete. Section 10.4 word "layer" should be "level" and the word "and" should be = added after "priority". 2. Major problems Section 4.2, rule 1 indicates that, if there is no resource shortage at = the moment, the following steps are omitted. However, the following = steps are the authorization/authentication steps which must always be = done first. Since one of the results of requesting a priority level, = even when there is no resource shortage known to the originating end, is = to include the precedence level for use in the remainder of the call. = For example, the level requested may prevent a later preemption after a = shortage of resources occurs. Rule 1 should simply be the final = sentence. Section 4.7.3 refers to the use of "forking" with the resource-priority = header. This is a major problem, since forking of a high precedence = marked INVITE in a domain that performs preemption could result in = preemption of multiple existing sessions when only one is needed to = complete the call. Somehow, forking must be prevented. Section 10.2 states in the last sentence that the DSN (incorrectly = written as "DRSN") uses preemption. This is misleading, since it may use = other preferential treatment procedures as well. It is unnecessary for = this document to state the algorithms/procedures used in each domain. Section 10.3 defines the operation of DRSN which uses six levels. The = operation described, in which a Flash-Override-Override preempts another = of the same level is not the desired operation. It appears that this may = be based on the current operation of some circuit-switches because of = implementation difficulties when the 6th level was added a few years = ago. However, this bad operation should not be perpetuated. In any = event, there is no need for this Resource-Priority header document to go = into this type of detail about the inner operation of some network. This = paragraph should be deleted. Section 12.1 2nd paragraph forbids adding a new priority value to a = namespace (MUST NOT). Previous versions of this draft allowed it (should = not). There should be no reason why another value cannot be added to DSN = later. If added, it is the responsibility of the operator of the DSN = domain to figure out how to do it to avoid interoperability problems. 3. Other problems Section 1, paragraph beginning "Since calls may traverse..." states that = "it is important that all such domains and elements apply the same = algorithms for the same namespace as otherwise the end-to-end experience = of privileged users may be compromised." While this may be true for some = combinations of preemption followed by queuing, it is not necessarily = true for all combinations and for any algorithm that might be added = later. Suggest that this sentence be reworded to say: "It is important = that careful consideration be made before different algorithms are used = at different places within a single call." Section 4.7.1 2nd paragraph. A UAC should never attempt another request = using a different resource value upon receipt of a 417. A human user may = choose to do whatever they are authorized to do when trying a new call. = No device can be allowed to do this automatically, since it would be = violating the policies for the use of priority levels. Although section 7 only gives "examples", the use of "DSN" causes = confusion since it shows an operation which would not be used in the DSN = domain. Specifically, the inclusion of the R-P header in the 180 and 200 = in 7.1 and the list of accepted values in the 417 in 7.2 would not be = used in the DSN. The example should use a domain that might use these = techniques. Since there is none that is known to work this way, the = examples should use "Foo" and "Bar" as in Section 8.2. Section 8.1 causes confusion since it implies the existence of a = relative order between different namespaces. It should instead say that = there is no defined relationship between the values of different = namespaces and that RP actors may apply whatever algorithms or = procedures they wish when dealing with multiple namespaces, as long as = the relative levels within each namespace are maintained. Section 8.3 With a statement as given above, it is unnecessary to include this = section on "examples of invalid orderings". Section 11.3 The association of the requirement for confidentiality and integrity of = the user's data with the Resource-Priority header leads to confusion. = They are unrelated requirements. Standard policy dictates whether there = is a need for confidentiality and integrity of the user's data = independently from the need for precedence levels. The first paragraph = should be deleted so that this section only addresses the security of = the R-P header itself. Section 11.4 No system that allows the use of the R-P header should allow anonymity. = In any case, the use of anonymity is independent from the use of R-P = header and should not be mentioned in this document. Section 12.1 The purpose of IANA registration is to prevent conflicts in = assignment of names and numbers, such as the namespace. There is no need = to include the "operation" (preemption or preferential queuing) in the = IANA registration. In fact, the DSN may use other techniques besides = preemption, such as exemption from network management controls, as = described in draft-pierce-tsvwg-pref-treat-example. 4. Unsubstantiated capabilities The draft contains capabilities for which there has been no demonstrated = requirement. While it is always desirable to include extra flexibility, = it leads to some confusion. The requirements of the known applications = only require the addition of the Resource-Priority header to the INVITE = message. The receiver acts on this information if it can, and does not = if it can not, in setting up the call. There is no identified = requirement for the following: - The Accept-Resource-Priority Header (3.2) - Resource-Priority header in Ack, Prack, BYE (3.3) - The resource-priority option tag (3.4) - Use of Require Header (4.3) Mike Pierce _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From sip-bounces@ietf.org Thu Mar 31 16:11:30 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09695 for ; Thu, 31 Mar 2005 16:11:30 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH746-0000a5-AQ for sip-web-archive@ietf.org; Thu, 31 Mar 2005 16:18:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH6c4-0000XS-FI; Thu, 31 Mar 2005 15:50:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH6c0-0000Ws-7A; Thu, 31 Mar 2005 15:49:56 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04355; Thu, 31 Mar 2005 15:49:54 -0500 (EST) Message-Id: <200503312049.PAA04355@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Thu, 31 Mar 2005 15:49:54 -0500 Cc: sip@ietf.org Subject: [Sip] I-D ACTION:draft-ietf-sip-resource-priority-08.txt X-BeenThere: sip@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Session Initiation Protocol List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: sip-bounces@ietf.org Errors-To: sip-bounces@ietf.org X-Spam-Score: 0.4 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 --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 Working Group of the IETF. Title : Communications Resource Priority for the Session Initiation Protocol (SIP) Author(s) : H. Schulzrinne, J. Polk Filename : draft-ietf-sip-resource-priority-08.txt Pages : 36 Date : 2005-3-31 This document defines two new SIP header fields for communicating resource priority, namely "Resource-Priority" and "Accept-Resource- Priority". The "Resource-Priority" header field can influence the behavior of SIP user agents, such as telephone gateways and IP telephones, and Session Initiation Protocol (SIP) proxies. It does not directly influence the forwarding behavior of IP routers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-resource-priority-08.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-resource-priority-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-resource-priority-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. 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: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-3-31162156.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-resource-priority-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-resource-priority-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-31162156.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip --NextPart--