From exim@www1.ietf.org Sun Nov 2 08:54:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15901 for ; Sun, 2 Nov 2003 08:54:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGIgd-0005Ku-8m for sip-archive@odin.ietf.org; Sun, 02 Nov 2003 08:54:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA2DsZEZ020455 for sip-archive@odin.ietf.org; Sun, 2 Nov 2003 08:54:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGIg6-0005Iq-3B; Sun, 02 Nov 2003 08:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGIfb-0005Hg-Gz for sip@optimus.ietf.org; Sun, 02 Nov 2003 08:53:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15872 for ; Sun, 2 Nov 2003 08:53:20 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGIfZ-0006cH-00 for sip@ietf.org; Sun, 02 Nov 2003 08:53:29 -0500 Received: from bay10-f83.bay10.hotmail.com ([64.4.37.83] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AGIfZ-0006cE-00 for sip@ietf.org; Sun, 02 Nov 2003 08:53:29 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 2 Nov 2003 05:52:57 -0800 Received: from 80.74.106.2 by by10fd.bay10.hotmail.msn.com with HTTP; Sun, 02 Nov 2003 13:52:56 GMT X-Originating-IP: [80.74.106.2] X-Originating-Email: [johnyjsmith1970@hotmail.com] From: "John Smith" To: sip@ietf.org Date: Sun, 02 Nov 2003 13:52:56 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Nov 2003 13:52:57.0164 (UTC) FILETIME=[9EDF08C0:01C3A148] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA15873 Subject: [Sip] SigComp States Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I'm studying now SigComp and wondering about some issues: (1) Quoting from draft-ietf-roch-sigcomp-sip-00.txt (section 3): =93Usual= ly,=20 any states created during the lifetime of a compartment will be "logicall= y"=20 deleted when the compartment is closed. A logical deletion becomes a=20 physical one when all the compartments that created the (same) state are=20 closed.=94 When do compartments share the same state? When do different=20 compartments become related to the same state? (2) Quoting from RFC 3320 (section 6.2): =93Each instance of the UDVM can= pass=20 up to four state creation requests to the state handler=85=94 Why does a = UDVM=20 need more than a single allocated state item? (3) Continuing the quote from the previous question: =93When the state ha= ndler=20 receives a state creation request from the UDVM it takes the following=20 steps: =85 3. If the state creation request contains a state_identifier = that=20 already exists=85=94 Is there any clear example to this kind of situation= ? I would appreciate any piece of information. Thanks, John. _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE*=20 http://join.msn.com/?page=3Dfeatures/virus _______________________________________________ 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 exim@www1.ietf.org Mon Nov 3 04:27:55 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24802 for ; Mon, 3 Nov 2003 04:27:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGazn-0000Pa-BT for sip-archive@odin.ietf.org; Mon, 03 Nov 2003 04:27:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA39RZGu001578 for sip-archive@odin.ietf.org; Mon, 3 Nov 2003 04:27:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGazG-0000OA-AM; Mon, 03 Nov 2003 04:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGayh-0000NM-IQ for sip@optimus.ietf.org; Mon, 03 Nov 2003 04:26:27 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24778 for ; Mon, 3 Nov 2003 04:26:16 -0500 (EST) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGaye-0002Ve-00 for sip@ietf.org; Mon, 03 Nov 2003 04:26:24 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AGaye-0002Vb-00 for sip@ietf.org; Mon, 03 Nov 2003 04:26:24 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA39QOY26228 for ; Mon, 3 Nov 2003 11:26:24 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Mon, 3 Nov 2003 11:26:24 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Mon, 3 Nov 2003 11:26:23 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 3 Nov 2003 11:26:22 +0200 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D592A1@esebe013.ntc.nokia.com> Thread-Topic: Comments on publish-01 Thread-Index: AcOc2zC9VPY2Xj/VSwySohHHkVHr6QFC8MlA To: Cc: X-OriginalArrivalTime: 03 Nov 2003 09:26:23.0415 (UTC) FILETIME=[8C445C70:01C3A1EC] Content-Transfer-Encoding: quoted-printable Subject: [Sip] RE: Comments on publish-01 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Ben, > -----Original Message----- > From: ext Ben Campbell [mailto:bcampbell@dynamicsoft.com] > Sent: 28 October, 2003 00:38 > To: Niemi Aki (NMP/Helsinki) > Cc: sip@ietf.org > Subject: Comments on publish-01 >=20 >=20 > Hi, >=20 > I have some comments on publish-01. These are not=20 > necessarily specific=20 > to 01 changes--I apologize if I bring up old concerns again,=20 > or mention=20 > something now that I should have mentioned previously. >=20 >=20 > Thanks! >=20 > Ben. >=20 > -------------------------------------------------------------- >=20 > 4.3: Why do we require all publish packages to support partial=20 > publication? This seems more a presence requirement than a generic=20 > publish requirement. This is true.=20 =20 > 4.4: Why do we need to specify default expiration times? Why=20 > is this not=20 > just local policy of the ESC? This is also quite a good question. I think it would be enough to just = specify a default expiration time for the PUBLISH method, and leave = everything else up to the ESC. =20 > 5 (last paragraph): I _think_ the intent is to say you=20 > should not send a=20 > new request to a particular ESC when a previous one is=20 > pending for the=20 > _same_ ESC, correct? This seems to be the spirit of the=20 > text, but there=20 > is room for someone to interpret this to say that I cannot=20 > send a new=20 > publish to any ESC if I have not gotten a response from a=20 > particular ESC. I'll try to clarify the language. =20 > 5.2 Paragraph 1: Still says To header indicates the AoR. I am pretty=20 > sure we had consensus in SIMPLE that this should be the=20 > r-URI. (Although=20 > I recognize we have had a new controversy on the SIP list=20 > about this.) Yes, this was simply overlooked while editing. > Paragraph 2: Can it _ever_ be carried anywhere else? If not,=20 > we should=20 > drop the word "typically" I think it might, for example using content indirection, or perhaps the = event state could be in the Request-URI. In any case, there doesn't seem = to be that much harm if we leave the options open with "typically".=20 =20 > 5.3: This seems to conflict with the meaning of 4.4. Nothing is=20 > mentioned in 5.3 about a default expiration. Will clarify this. It should mention the default expiration. =20 > 5.4 para 5, 1st sentence: >=20 > "The If-Match header field containing an entity-tag=20 > preconditions the=20 > PUBLISH request to refresh a specific instance of event state in the=20 > ESC." Sentence is confusing to me. Are we using the word=20 > "preconditions"=20 > as a verb? I will reword. =20 > Same paragraph: Nit: I suspect that "i.e." (which translates=20 > as "that=20 > is", really should mean "for example", as there are other situations=20 > other than expired state that could cause this result. (For=20 > example, the=20 > state never existed at all.) Correct, will change this to "e.g.". =20 > Last paragraph: I think this should be MUST NOT. Doesn't the=20 > presence of=20 > a body explicily make this into a modify request, instead of=20 > a refresh? Yes, will use MUST NOT.=20 =20 > 5.7 First paragraph: Should use r-uri, not To header. Correct. > 6 step 8 last para: Do we want to limit this to explictly=20 > 500? In the=20 > example you give, it may be that 504 makes more sense. Hoe about something like: The processing of the PUBLISH request MUST be atomic. If internal errors (such as the inability to access a back-end database) occur before processing is complete, the publication MUST NOT succeed, and the ESC MUST fail with an appropriate error = response, such as 504 (Server Time-out). =20 > Table 1: Accept explicitly disallowed in requests? What if a future=20 > publish package uses bodies in responses? Would it not make sense to=20 > allow Accept in the request for such a package? That makes sense for Accept and maybe even all Accept-*. I will add an = "o" to all of them. > Security Considerations: Do we need to comment on the interaction=20 > between PUBLISH and the possibility of e2e signatures on presence=20 > documents? I don't know if that belongs here or not. There is already some text in Section 9.4 - do we need more than that? Cheers, Aki =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 From exim@www1.ietf.org Mon Nov 3 10:29:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06940 for ; Mon, 3 Nov 2003 10:29:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGgdp-0003w8-HS for sip-archive@odin.ietf.org; Mon, 03 Nov 2003 10:29:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3FTH4I015075 for sip-archive@odin.ietf.org; Mon, 3 Nov 2003 10:29:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGgda-0003uM-3m; Mon, 03 Nov 2003 10:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGgdQ-0003qx-38 for sip@optimus.ietf.org; Mon, 03 Nov 2003 10:28:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06919 for ; Mon, 3 Nov 2003 10:28:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGgdN-0007G6-00 for sip@ietf.org; Mon, 03 Nov 2003 10:28:49 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AGgdN-0007G3-00 for sip@ietf.org; Mon, 03 Nov 2003 10:28:49 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hA3FSeIc037086; Mon, 3 Nov 2003 09:28:41 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FA67426.1040204@dynamicsoft.com> Date: Mon, 03 Nov 2003 09:28:38 -0600 From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: aki.niemi@nokia.com CC: sip@ietf.org Subject: Re: [Sip] RE: Comments on publish-01 References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D592A1@esebe013.ntc.nokia.com> In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D592A1@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit aki.niemi@nokia.com wrote: [...] > > 6 step 8 last para: Do we want to limit this to explictly > > 500? In the > > example you give, it may be that 504 makes more sense. > > Hoe about something like: > > The processing of the PUBLISH request MUST be atomic. If internal > errors (such as the inability to access a back-end database) > occur before processing is complete, the publication MUST NOT > succeed, and the ESC MUST fail with an appropriate error response, > such as 504 (Server Time-out). I think that works. [...] > > Security Considerations: Do we need to comment on the interaction > > between PUBLISH and the possibility of e2e signatures on presence > > documents? I don't know if that belongs here or not. > > There is already some text in Section 9.4 - do we need more than that? I think that is fine--I just missed it the first time. Thanks! Ben. _______________________________________________ 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 exim@www1.ietf.org Mon Nov 3 18:30:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03380 for ; Mon, 3 Nov 2003 18:30:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGo9K-00019x-HO for sip-archive@odin.ietf.org; Mon, 03 Nov 2003 18:30:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA3NUIhN004399 for sip-archive@odin.ietf.org; Mon, 3 Nov 2003 18:30:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGo95-00012y-IZ; Mon, 03 Nov 2003 18:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGo90-00012N-Di for sip@optimus.ietf.org; Mon, 03 Nov 2003 18:29:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03332 for ; Mon, 3 Nov 2003 18:29:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGo8x-0000V2-00 for sip@ietf.org; Mon, 03 Nov 2003 18:29:55 -0500 Received: from argus.unit.liu.se ([130.236.1.141] helo=mail.liu.se) by ietf-mx with esmtp (Exim 4.12) id 1AGo8w-0000Uo-00 for sip@ietf.org; Mon, 03 Nov 2003 18:29:54 -0500 Received: by mail.liu.se (Postfix, from userid 506) id 68FCC1FF7D; Tue, 4 Nov 2003 00:29:49 +0100 (CET) Received: from lemuria.unit.liu.se (lemuria.unit.liu.se [130.236.230.146]) by mail.liu.se (Postfix) with ESMTP id E4F891FEC9 for ; Tue, 4 Nov 2003 00:29:48 +0100 (CET) Received: by lemuria.unit.liu.se (Postfix, from userid 104) id D7FCCF3DA; Tue, 4 Nov 2003 00:29:48 +0100 (MET) Received: from liu.se (camelot.unit.liu.se [130.236.230.139]) by lemuria.unit.liu.se (Postfix) with ESMTP id C8A16F385 for ; Tue, 4 Nov 2003 00:29:47 +0100 (MET) Received: from [130.236.213.189] by mu.unit.liu.se (mshttpd); Tue, 04 Nov 2003 00:29:47 +0100 From: Marcin Dzieweczynski To: sip@ietf.org Message-ID: <251e5525000c.25000c251e55@liu.se> Date: Tue, 04 Nov 2003 00:29:47 +0100 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.17 (built Jun 23 2003) MIME-Version: 1.0 Content-Language: en X-Accept-Language: en Priority: normal Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.60-liu_1.5 (1.212-2003-09-23-exp) on argus.unit.liu.se X-Spam-Status: No, hits=0.0 required=5.0 tests=FROM_ENDS_IN_NUMS, LIU_FROM_MATCHES_LIUSTUDENT autolearn=no version=2.60-liu_1.5 Content-Transfer-Encoding: 7bit Subject: [Sip] redirect token in caller preferences extension? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello I try to implement caller preferences extension in already existing software (which is "ser" and Kphone). I'm not quite sure how UAC should apply "redirect" token. As I see it, when UAC is satisfied with redirection it should remove this token from the following INVITES otherwise it would be redirected forever. Is my thinking correct? regards Marcin Dzieweczynski _______________________________________________ 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 exim@www1.ietf.org Mon Nov 3 19:06:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04746 for ; Mon, 3 Nov 2003 19:06:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGoi0-0003HL-V8 for sip-archive@odin.ietf.org; Mon, 03 Nov 2003 19:06:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4068Gn012573 for sip-archive@odin.ietf.org; Mon, 3 Nov 2003 19:06:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGohu-0003Fd-H0; Mon, 03 Nov 2003 19:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGohi-0003FA-Rm for sip@optimus.ietf.org; Mon, 03 Nov 2003 19:05:51 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04716 for ; Mon, 3 Nov 2003 19:05:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGohf-00017H-00 for sip@ietf.org; Mon, 03 Nov 2003 19:05:47 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1AGohe-00016U-00 for sip@ietf.org; Mon, 03 Nov 2003 19:05:47 -0500 Received: from txdwillis (bdsl.66.12.12.254.gte.net [66.12.12.254]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id hA404cv3030254 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 3 Nov 2003 18:04:39 -0600 From: "Dean Willis" To: Cc: , "'Gonzalo Camarillo'" Date: Mon, 3 Nov 2003 18:04:21 -0600 Message-ID: <02f501c3a267$330e6b20$e1036e3f@txdwillis> 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.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Subject: [Sip] Draft agenda, SIP, IETF 58 version 1 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The following is the proposed agenda for the upcoming SIP meeting. Please comment if we've missed something or you wish to make a suggestion. Note that the time slot might move, depedning on overall IETF agenda requirements. Hyperlinked version at: http://www.softarmor.com/sipwg/meets/ietf58/agenda.html Text follows: Wednesday, November 12, 1300-1500 1300 Call to Order and Agenda Bash Chairs 1305 Status Chairs 1315 Congestion Safety Dean Willis draft-ietf-sip-congest-safe-02 1325 RFC 3312 Gonzalo Camarillo draft-camarillo-sip-rfc3312-update-00.txt 1330 Publish Aki Niemi draft-ietf-sip-publish-01 1345 Request History Mary Barnes draft-ietf-sip-history-info-01 1400 Non-Invite Transactions Robert Sparks draft-sparks-sip-noninvite-01.txt 1415 GRUU Jonathan Rosenberg draft-rosenberg-sip-gruu-00.txt draft-rosenberg-sipping-gruu-reqs-01.txt 1435 Join Rohan Mahy draft-ietf-sip-join-02.txt 1445 REFER Semantics Rohan Mahy draft-olson-sipping-refer-extensions draft-mahy-sip-remote-cc _______________________________________________ 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 exim@www1.ietf.org Tue Nov 4 00:30:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15842 for ; Tue, 4 Nov 2003 00:30:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGtlg-0000pI-Ij for sip-archive@odin.ietf.org; Tue, 04 Nov 2003 00:30:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA45UGBd003117 for sip-archive@odin.ietf.org; Tue, 4 Nov 2003 00:30:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGtlT-0000nH-RA; Tue, 04 Nov 2003 00:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AGtlG-0000mp-AH for sip@optimus.ietf.org; Tue, 04 Nov 2003 00:29:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15827 for ; Tue, 4 Nov 2003 00:29:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AGtlD-0005yY-00 for sip@ietf.org; Tue, 04 Nov 2003 00:29:47 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AGtlD-0005yF-00 for sip@ietf.org; Tue, 04 Nov 2003 00:29:47 -0500 Received: from dynamicsoft.com ([63.113.46.18]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA45THca010959; Tue, 4 Nov 2003 00:29:18 -0500 (EST) Message-ID: <3FA7392B.7060607@dynamicsoft.com> Date: Tue, 04 Nov 2003 00:29:15 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marcin Dzieweczynski CC: sip@ietf.org Subject: Re: [Sip] redirect token in caller preferences extension? References: <251e5525000c.25000c251e55@liu.se> In-Reply-To: <251e5525000c.25000c251e55@liu.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Marcin Dzieweczynski wrote: > Hello > > I try to implement caller preferences extension in already existing > software (which is "ser" and Kphone). I'm not quite sure how UAC > should apply "redirect" token. As I see it, when UAC is satisfied > with redirection it should remove this token from the following > INVITES otherwise it would be redirected forever. Is my thinking > correct? Actually, I think the spec is merely ambiguous on this point. What is supposed to happen is that you get continually redirected to new URIs until you reach the UAS. The UAS itself would answer or reject the call (it could also redirect of course). Thus, the call should still work even if the UAC never removes the redirect token. However, the spec says that UAS behavior should be as if it were a proxy. This makes sense for the feature preferences, but not for the request handling preferences. The spec needs to be clarified that it applies to feature preferences and the queue request handling directive only. I'll make sure it gets clarified. Of course, its also reasonable for a UAC to purposefully use the redirect preference once, and then remove it later. It depends on the specific feature that is being implemented. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 exim@www1.ietf.org Tue Nov 4 10:06:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17001 for ; Tue, 4 Nov 2003 10:06:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH2lD-00029R-5z for sip-archive@odin.ietf.org; Tue, 04 Nov 2003 10:06:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4F6NLf008263 for sip-archive@odin.ietf.org; Tue, 4 Nov 2003 10:06:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH2kr-00025g-Lb; Tue, 04 Nov 2003 10:06:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH2kB-00023c-Qf for sip@optimus.ietf.org; Tue, 04 Nov 2003 10:05:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16797 for ; Tue, 4 Nov 2003 10:05:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH2k8-0006fS-00 for sip@ietf.org; Tue, 04 Nov 2003 10:05:16 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AH2k7-0006f1-00 for sip@ietf.org; Tue, 04 Nov 2003 10:05:15 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 04 Nov 2003 07:05:02 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hA4F4fAt024166; Tue, 4 Nov 2003 07:04:41 -0800 (PST) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADR97193; Tue, 4 Nov 2003 10:04:40 -0500 (EST) Message-ID: <3FA7C008.5070108@cisco.com> Date: Tue, 04 Nov 2003 10:04:40 -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 CC: Marcin Dzieweczynski , sip@ietf.org Subject: Re: [Sip] redirect token in caller preferences extension? References: <251e5525000c.25000c251e55@liu.se> <3FA7392B.7060607@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Marcin, In retrospect I will agree with Jonathan that it might be useful to clarify this further. I guess this is justified by the fact that you asked the question. But it always seemed obvious to me that it should work as Jonathan describes. Fundamentally, inserting the "redirect" request-disposition is a way for the UAC to say "I want to make all the decisions about which alternatives get tried." If that was confusing, what about other cases? Is it clear that a proxy should ignore this option when it is acting on a Route header? Paul Jonathan Rosenberg wrote: > > > Marcin Dzieweczynski wrote: > >> Hello >> >> I try to implement caller preferences extension in already existing >> software (which is "ser" and Kphone). I'm not quite sure how UAC >> should apply "redirect" token. As I see it, when UAC is satisfied >> with redirection it should remove this token from the following >> INVITES otherwise it would be redirected forever. Is my thinking >> correct? > > > Actually, I think the spec is merely ambiguous on this point. > > What is supposed to happen is that you get continually redirected to new > URIs until you reach the UAS. The UAS itself would answer or reject the > call (it could also redirect of course). Thus, the call should still > work even if the UAC never removes the redirect token. However, the spec > says that UAS behavior should be as if it were a proxy. This makes sense > for the feature preferences, but not for the request handling > preferences. The spec needs to be clarified that it applies to feature > preferences and the queue request handling directive only. I'll make > sure it gets clarified. > > Of course, its also reasonable for a UAC to purposefully use the > redirect preference once, and then remove it later. It depends on the > specific feature that is being implemented. > > -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 exim@www1.ietf.org Tue Nov 4 14:19:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29103 for ; Tue, 4 Nov 2003 14:19:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6hq-0005h8-JJ for sip-archive@odin.ietf.org; Tue, 04 Nov 2003 14:19:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA4JJA7D021886 for sip-archive@odin.ietf.org; Tue, 4 Nov 2003 14:19:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6hh-0005fc-QB; Tue, 04 Nov 2003 14:19:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AH6gj-0005UT-Em for sip@optimus.ietf.org; Tue, 04 Nov 2003 14:18:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28963 for ; Tue, 4 Nov 2003 14:17:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AH6gg-0003E8-00 for sip@ietf.org; Tue, 04 Nov 2003 14:17:58 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AH6gg-0003D0-00 for sip@ietf.org; Tue, 04 Nov 2003 14:17:58 -0500 Received: from cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 04 Nov 2003 11:18:48 -0800 Received: from amer.unity.cisco.com (ipcbu-exchange.cisco.com [64.101.140.91]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with SMTP id hA4JHOxg022347; Tue, 4 Nov 2003 14:17:25 -0500 (EST) content-class: urn:content-classes:message Subject: RE: [Sip] Draft agenda, SIP, IETF 58 version 1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 4 Nov 2003 13:17:24 -0600 Message-ID: Thread-Topic: [Sip] Draft agenda, SIP, IETF 58 version 1 Thread-Index: AcOiZ7AWUwEMcYc2TVmmrokRHX8xnQAoG3JA From: "Henry Chen" To: "Dean Willis" , Cc: , "Gonzalo Camarillo" Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I think Rohan Mahy's draft-mahy-sip-remote-cc is a good candidate. Thanks, Henry Chen -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Monday, November 03, 2003 6:04 PM To: sip@ietf.org Cc: rogan@cisco.com; 'Gonzalo Camarillo' Subject: [Sip] Draft agenda, SIP, IETF 58 version 1 The following is the proposed agenda for the upcoming SIP meeting. Please comment if we've missed something or you wish to make a suggestion. Note that the time slot might move, depedning on overall IETF agenda requirements. Hyperlinked version at: http://www.softarmor.com/sipwg/meets/ietf58/agenda.html Text follows: Wednesday, November 12, 1300-1500 1300 Call to Order and Agenda Bash Chairs 1305 Status Chairs 1315 Congestion Safety Dean Willis draft-ietf-sip-congest-safe-02 1325 RFC 3312 Gonzalo Camarillo draft-camarillo-sip-rfc3312-update-00.txt 1330 Publish Aki Niemi draft-ietf-sip-publish-01 1345 Request History Mary Barnes draft-ietf-sip-history-info-01 1400 Non-Invite Transactions Robert Sparks draft-sparks-sip-noninvite-01.txt 1415 GRUU Jonathan Rosenberg draft-rosenberg-sip-gruu-00.txt draft-rosenberg-sipping-gruu-reqs-01.txt 1435 Join Rohan Mahy draft-ietf-sip-join-02.txt 1445 REFER Semantics Rohan Mahy =20 draft-olson-sipping-refer-extensions draft-mahy-sip-remote-cc _______________________________________________ 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 exim@www1.ietf.org Tue Nov 4 21:56:56 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18813 for ; Tue, 4 Nov 2003 21:56:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHDqY-0004U3-PU for sip-archive@odin.ietf.org; Tue, 04 Nov 2003 21:56:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA52ucrX017175 for sip-archive@odin.ietf.org; Tue, 4 Nov 2003 21:56:38 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHDpz-0004Qm-4t; Tue, 04 Nov 2003 21:56:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHDpi-0004Q9-18 for sip@optimus.ietf.org; Tue, 04 Nov 2003 21:55:46 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18516 for ; Tue, 4 Nov 2003 21:55:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHDpe-0002XA-00 for sip@ietf.org; Tue, 04 Nov 2003 21:55:42 -0500 Received: from law11-f42.law11.hotmail.com ([64.4.17.42] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AHDpe-0002Ry-00 for sip@ietf.org; Tue, 04 Nov 2003 21:55:42 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 4 Nov 2003 18:53:35 -0800 Received: from 209.87.234.147 by lw11fd.law11.hotmail.msn.com with HTTP; Wed, 05 Nov 2003 02:53:35 GMT X-Originating-IP: [209.87.234.147] X-Originating-Email: [pqiu2@hotmail.com] From: "Peter Qiu" To: sip@ietf.org Cc: pqiu2@hotmail.com Date: Tue, 04 Nov 2003 21:53:35 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 05 Nov 2003 02:53:35.0580 (UTC) FILETIME=[0191A1C0:01C3A348] Subject: [Sip] HELP - problem with accessing provisioning GUI Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Dear all, If I try to access Provisioning GUI (VOCAL 1.5) by executing "/usr/local/vocal/bin/provgui localhost 6005", I always get a error message shown below: ---------------------------------------------------------------------------------------------------------------------------- Could not open connection to pserver because: vocal.comm.VPPLowLevelException: The program could not open a socket to the server localhost on port 6005. Reason: connection refused. ------------------------------------------------------------------------------------------------------------------------------ My VOCAL runs on Linux Redhat 7.3, and J2se 1.4.1 is installed. Anyone knows what's wrong? Thanks a lot in advance! _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/photos&pgmarket=en-ca&RU=http%3a%2f%2fjoin.msn.com%2f%3fpage%3dmisc%2fspecialoffers%26pgmarket%3den-ca _______________________________________________ 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 exim@www1.ietf.org Wed Nov 5 12:06:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13112 for ; Wed, 5 Nov 2003 12:06:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHR6i-0005fJ-67 for sip-archive@odin.ietf.org; Wed, 05 Nov 2003 12:06:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5H6CKD021773 for sip-archive@odin.ietf.org; Wed, 5 Nov 2003 12:06:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHR6Y-0005ef-2i; Wed, 05 Nov 2003 12:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHR69-0005e2-24 for sip@optimus.ietf.org; Wed, 05 Nov 2003 12:05:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13105 for ; Wed, 5 Nov 2003 12:05:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHR67-000703-00 for sip@ietf.org; Wed, 05 Nov 2003 12:05:35 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AHR67-0006zg-00 for sip@ietf.org; Wed, 05 Nov 2003 12:05:35 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id hA5H4ld02957; Wed, 5 Nov 2003 11:04:47 -0600 Subject: Re: [Sip] GRUU Mechanism I-D From: Robert Sparks To: Jonathan Rosenberg Cc: Paul Kyzivat , sip@ietf.org, rohan@cisco.com In-Reply-To: <3F973D54.3070506@dynamicsoft.com> References: <3F94E9A9.5020707@dynamicsoft.com> <3F953BD9.7040505@cisco.com> <3F95F1A2.2060107@dynamicsoft.com> <3F968FCA.1060907@cisco.com> <3F973D54.3070506@dynamicsoft.com> Content-Type: text/plain Message-Id: <1068051884.1584.47.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Wed, 05 Nov 2003 11:04:45 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I do think it would be very good medicine for the protocol to deprecate all dialog reuse. My personal preference for modifying REFER is to deprecate the implicit subscription behavior altogether (by strengthening the mechanisms proposed in Sean's and Rohan's drafts perhaps). I am uncomfortable with the idea of an implicit subscription created with an entirely new dialog id - this would require putting a new dialog correlation algorithm into all implementations. I'm sure we could invent something that worked, but is the complexity worth the gain when just removing the implicit subscription solves the problem and comes with with so much better behavior properties given the GRUU. RjS > >> > >> This is a good point. Of course, the REAL problem here is that the > >> REFER request ought to go on the dialog, followed by a separate > >> SUBSCRIBE to the GRUU, in order to track progress of the refer. That > >> is, its the implicit subscriptions which makes this complicated. > >> > >> That said, we may need to except REFER from this rule. Bleh. > > > > > > If we need to exempt REFER, then we have admitted that we can't phase > > out shared dialogs. Then, if we have to continue to support shared > > dialogs, why do we want to tell people not to use them? > > If there is no way to fix this for REFER, I would have to agree with > you. However, if there is a possibility to update REFER to take > advantage of gruu, and thus avoid dialog reuse, then it makes sense. > AFAICT, the fix to REFER is not hard at all. The recipient of the > REFER, who creates the NOTIFY, would simply send it to the gruu of the > referor, and use a different dialog ID. There is still an implicit > subscription, but the NOTIFY creates a new, separate dialog. _______________________________________________ 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 exim@www1.ietf.org Wed Nov 5 13:01:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15037 for ; Wed, 5 Nov 2003 13:01:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHRxv-0000hz-3G for sip-archive@odin.ietf.org; Wed, 05 Nov 2003 13:01:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5I1BIf002717 for sip-archive@odin.ietf.org; Wed, 5 Nov 2003 13:01:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHRxm-0000gd-Tc; Wed, 05 Nov 2003 13:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHRxa-0000fd-Ug for sip@optimus.ietf.org; Wed, 05 Nov 2003 13:00:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14988 for ; Wed, 5 Nov 2003 13:00:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHRxZ-0007ld-00 for sip@ietf.org; Wed, 05 Nov 2003 13:00:49 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AHRxY-0007lI-00 for sip@ietf.org; Wed, 05 Nov 2003 13:00:48 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 05 Nov 2003 10:04:48 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hA5I0EDd015401; Wed, 5 Nov 2003 10:00:15 -0800 (PST) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADT08861; Wed, 5 Nov 2003 13:00:14 -0500 (EST) Message-ID: <3FA93AAE.3070804@cisco.com> Date: Wed, 05 Nov 2003 13:00:14 -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: Robert Sparks CC: Jonathan Rosenberg , sip@ietf.org, rohan@cisco.com Subject: Re: [Sip] GRUU Mechanism I-D References: <3F94E9A9.5020707@dynamicsoft.com> <3F953BD9.7040505@cisco.com> <3F95F1A2.2060107@dynamicsoft.com> <3F968FCA.1060907@cisco.com> <3F973D54.3070506@dynamicsoft.com> <1068051884.1584.47.camel@RjS.localdomain> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I would be happy if dialog reuse had never been there. But at this point I think it is impossible to avoid supporting it. And once the effort has been made to support it, deprecating it in favor of a new approach is just that much more work, with more backwards compatibiilty alternatives to consider, etc. At this point I would prefer to live with the mistake. Paul Robert Sparks wrote: > I do think it would be very good medicine for the protocol to > deprecate all dialog reuse. > > My personal preference for modifying REFER is to deprecate the > implicit subscription behavior altogether (by strengthening the > mechanisms proposed in Sean's and Rohan's drafts perhaps). > > I am uncomfortable with the idea of an implicit subscription > created with an entirely new dialog id - this would require > putting a new dialog correlation algorithm into all implementations. > I'm sure we could invent something that worked, but is the complexity > worth the gain when just removing the implicit subscription solves > the problem and comes with with so much better behavior properties > given the GRUU. > > RjS > > > >>>>This is a good point. Of course, the REAL problem here is that the >>>>REFER request ought to go on the dialog, followed by a separate >>>>SUBSCRIBE to the GRUU, in order to track progress of the refer. That >>>>is, its the implicit subscriptions which makes this complicated. >>>> >>>>That said, we may need to except REFER from this rule. Bleh. >>> >>> >>>If we need to exempt REFER, then we have admitted that we can't phase >>>out shared dialogs. Then, if we have to continue to support shared >>>dialogs, why do we want to tell people not to use them? >> >>If there is no way to fix this for REFER, I would have to agree with >>you. However, if there is a possibility to update REFER to take >>advantage of gruu, and thus avoid dialog reuse, then it makes sense. >>AFAICT, the fix to REFER is not hard at all. The recipient of the >>REFER, who creates the NOTIFY, would simply send it to the gruu of the >>referor, and use a different dialog ID. There is still an implicit >>subscription, but the NOTIFY creates a new, separate dialog. > > > > _______________________________________________ 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 exim@www1.ietf.org Wed Nov 5 16:52:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25940 for ; Wed, 5 Nov 2003 16:52:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVZP-0000j3-7a for sip-archive@odin.ietf.org; Wed, 05 Nov 2003 16:52:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA5Lq7pF002763 for sip-archive@odin.ietf.org; Wed, 5 Nov 2003 16:52:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVZK-0000hj-TR; Wed, 05 Nov 2003 16:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHVZJ-0000hU-F5 for sip@optimus.ietf.org; Wed, 05 Nov 2003 16:52:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25903 for ; Wed, 5 Nov 2003 16:51:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHVZH-00047k-00 for sip@ietf.org; Wed, 05 Nov 2003 16:51:59 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AHVZG-00047S-00 for sip@ietf.org; Wed, 05 Nov 2003 16:51:59 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 05 Nov 2003 13:56:02 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hA5LpODd006135; Wed, 5 Nov 2003 13:51:25 -0800 (PST) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADT36099; Wed, 5 Nov 2003 16:51:23 -0500 (EST) Message-ID: <3FA970DB.1030006@cisco.com> Date: Wed, 05 Nov 2003 16:51: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: brett@broadsoft.com CC: sip@ietf.org Subject: Re: [Sip] GRUU Mechanism I-D References: <001701c3a3e0$5fe8cd00$2b01a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Brett Tate wrote: > > Most of the current dialog reuse issues could be > resolved by a new header which indicates a > real call-id and a parameter which indicates > that this is a request to establish a new > call/subscription/... on this dialog. I'm not clear what that helps. > A new response is also needed to indicate that > I am aware of this dialog however I am not aware > of the call/subscription/... associated with > the request (a 481 which doesn't release the > dialog). When would this be used? Perhaps if a NOTIFY was received for which no corresponding subscription is known? I agree that is a potential problem, and a suitable error code would be helpful. AFAIK that is the only case where such a problem can arise. > To avoid some complexities, potentially we could > also restrict the number of calls sharing a > dialog to be 1 at any given time. Or potentially > we could add a statement that a call cannot be > originated on an already established dialog. As things stand there can only be one call on a dialog at a time. The only action that could establish a new one (an INVITE) will be interpretted as a reINVITE for the existing call. In theory you could establish a dialog with an invite, share it with a SUBSCRIBE, terminate the first call with a BYE, and then create a new call (with another INVITE) sharing the dialog with the subscription. A rational use of this capability escapes me at the moment, but once the mechanisms are there to support sharing at all this kind of capability more or less comes for free, so why worry about it? The use of GRUUs certainly provides an alternative to sharing of dialogs for certain applications. I think it makes sense to just permit them to coexist and see how things evolve. 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 exim@www1.ietf.org Wed Nov 5 19:23:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02768 for ; Wed, 5 Nov 2003 19:23:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHXvd-0001ps-Kw for sip-archive@odin.ietf.org; Wed, 05 Nov 2003 19:23:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA60ND9r007050 for sip-archive@odin.ietf.org; Wed, 5 Nov 2003 19:23:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHXvR-0001ou-M9; Wed, 05 Nov 2003 19:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHXuj-0001n4-Ii for sip@optimus.ietf.org; Wed, 05 Nov 2003 19:22:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02741 for ; Wed, 5 Nov 2003 19:22:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHXuh-0006RU-00 for sip@ietf.org; Wed, 05 Nov 2003 19:22:15 -0500 Received: from broadsoft.com ([198.104.184.110]) by ietf-mx with esmtp (Exim 4.12) id 1AHXuh-0006RR-00 for sip@ietf.org; Wed, 05 Nov 2003 19:22:15 -0500 Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.12.10/8.12.9) with SMTP id hA60MDca065338; Wed, 5 Nov 2003 19:22:13 -0500 (EST) Reply-To: From: "Brett Tate" To: "'Paul Kyzivat'" Cc: Subject: RE: [Sip] GRUU Mechanism I-D Date: Wed, 5 Nov 2003 19:23:09 -0500 Message-ID: <001f01c3a3fc$28911a30$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3FA970DB.1030006@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > Most of the current dialog reuse issues could be > > resolved by a new header which indicates a > > real call-id and a parameter which indicates > > that this is a request to establish a new > > call/subscription/... on this dialog. > > I'm not clear what that helps. A and B both know about a subscription dialog. A thinks that a call is currently active on the dialog; B does not. A sends a re-invite for the call; B rings the phone since it does not know if it was an invite or re-invite. > > A new response is also needed to indicate that > > I am aware of this dialog however I am not aware > > of the call/subscription/... associated with > > the request (a 481 which doesn't release the > > dialog). > > When would this be used? > Perhaps if a NOTIFY was received for which no > corresponding subscription is known? I agree > that is a potential problem, and a suitable > error code would be helpful. AFAIK that is the > only case where such a problem can arise. A and B both know about a subscription dialog. A thinks that a call is currently active on the dialog; B does not. A sends a re-invite/update for the call; B uses the response code to inform that the call is not active. A can now choose to send an INVITE to request the re-establishment of the call still on the subscription dialog. > > To avoid some complexities, potentially we could > > also restrict the number of calls sharing a > > dialog to be 1 at any given time. Or potentially > > we could add a statement that a call cannot be > > originated on an already established dialog. > > As things stand there can only be one call on > a dialog at a time. The only action that could > establish a new one (an INVITE) will be > interpretted as a reINVITE for the existing call. > > In theory you could establish a dialog with > an invite, share it with a SUBSCRIBE, terminate the > first call with a BYE, and then create a new > call (with another INVITE) sharing the dialog > with the subscription. > > A rational use of this capability escapes me I am sure that someone will define an event package that allows calls to be established/re-established sharing the subscription's dialog. > at the moment, but once the mechanisms are there > to support sharing at all this kind of capability > more or less comes for free, so why worry about it? Mainly so A can distinguish a received re-invite from invite when A recently sent a BYE or lost awareness of the call but not the dialog. However I guess that it would not be that common if UPDATE is used to refresh the Session-Expires stuff. And I guess a retry-after response could be used for an invite received in proximity of sending bye. > The use of GRUUs certainly provides an alternative > to sharing of dialogs for certain applications. > I think it makes sense to just permit them to > coexist and see how things evolve. I agree. _______________________________________________ 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 exim@www1.ietf.org Thu Nov 6 05:13:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02628 for ; Thu, 6 Nov 2003 05:13:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHh8X-0004qL-Mr for sip-archive@odin.ietf.org; Thu, 06 Nov 2003 05:13:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6AD9iI018618 for sip-archive@odin.ietf.org; Thu, 6 Nov 2003 05:13:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHh8P-0004pQ-Hn; Thu, 06 Nov 2003 05:13:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHh89-0004p9-JZ for sip@optimus.ietf.org; Thu, 06 Nov 2003 05:12:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02622 for ; Thu, 6 Nov 2003 05:12:32 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHh86-0006Nq-00 for sip@ietf.org; Thu, 06 Nov 2003 05:12:42 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AHh85-0006Nn-00 for sip@ietf.org; Thu, 06 Nov 2003 05:12:41 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA6ACgY11533 for ; Thu, 6 Nov 2003 12:12:42 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 6 Nov 2003 12:12:40 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 6 Nov 2003 12:12:42 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] GRUU Mechanism I-D Date: Thu, 6 Nov 2003 12:12:41 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797392@esebe019.ntc.nokia.com> Thread-Topic: [Sip] GRUU Mechanism I-D Thread-Index: AcOjxtU8Nd0rTlgRR26dfQJ1b8RGdgAhsoOw To: , Cc: , , X-OriginalArrivalTime: 06 Nov 2003 10:12:42.0095 (UTC) FILETIME=[83BA87F0:01C3A44E] Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I share Paul's view. There are currently too many implementations = supporting dialog reuse. The only suggestion I have is that for any new SIP extension in the = future that requires either dialog reuse or GRUU, we use the GRUU = approach. /Hisham > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext > Paul Kyzivat > Sent: Wednesday, November 05, 2003 8:00 PM > To: Robert Sparks > Cc: Jonathan Rosenberg; sip@ietf.org; rohan@cisco.com > Subject: Re: [Sip] GRUU Mechanism I-D >=20 >=20 > I would be happy if dialog reuse had never been there. But at=20 > this point=20 > I think it is impossible to avoid supporting it. And once the=20 > effort has=20 > been made to support it, deprecating it in favor of a new approach is=20 > just that much more work, with more backwards compatibiilty=20 > alternatives=20 > to consider, etc. At this point I would prefer to live with=20 > the mistake. >=20 > Paul >=20 > Robert Sparks wrote: > > I do think it would be very good medicine for the protocol to > > deprecate all dialog reuse. > >=20 > > My personal preference for modifying REFER is to deprecate the > > implicit subscription behavior altogether (by strengthening the > > mechanisms proposed in Sean's and Rohan's drafts perhaps). > >=20 > > I am uncomfortable with the idea of an implicit subscription > > created with an entirely new dialog id - this would require > > putting a new dialog correlation algorithm into all implementations. > > I'm sure we could invent something that worked, but is the=20 > complexity > > worth the gain when just removing the implicit subscription solves > > the problem and comes with with so much better behavior properties > > given the GRUU. > >=20 > > RjS > >=20 > >=20 > >=20 > >>>>This is a good point. Of course, the REAL problem here is=20 > that the=20 > >>>>REFER request ought to go on the dialog, followed by a separate=20 > >>>>SUBSCRIBE to the GRUU, in order to track progress of the=20 > refer. That=20 > >>>>is, its the implicit subscriptions which makes this complicated. > >>>> > >>>>That said, we may need to except REFER from this rule. Bleh. > >>> > >>> > >>>If we need to exempt REFER, then we have admitted that we=20 > can't phase=20 > >>>out shared dialogs. Then, if we have to continue to support shared=20 > >>>dialogs, why do we want to tell people not to use them? > >> > >>If there is no way to fix this for REFER, I would have to=20 > agree with=20 > >>you. However, if there is a possibility to update REFER to take=20 > >>advantage of gruu, and thus avoid dialog reuse, then it=20 > makes sense.=20 > >>AFAICT, the fix to REFER is not hard at all. The recipient of the=20 > >>REFER, who creates the NOTIFY, would simply send it to the=20 > gruu of the=20 > >>referor, and use a different dialog ID. There is still an implicit=20 > >>subscription, but the NOTIFY creates a new, separate dialog. > >=20 > >=20 > >=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 >=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 exim@www1.ietf.org Thu Nov 6 08:55:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08910 for ; Thu, 6 Nov 2003 08:55:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHkbV-0007wr-MY for sip-archive@odin.ietf.org; Thu, 06 Nov 2003 08:55:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6DtH5W030547 for sip-archive@odin.ietf.org; Thu, 6 Nov 2003 08:55:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHkbG-0007vZ-Q8; Thu, 06 Nov 2003 08:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHkaJ-0007uL-Bd for sip@optimus.ietf.org; Thu, 06 Nov 2003 08:54:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08882 for ; Thu, 6 Nov 2003 08:53:51 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHkaH-0001KJ-00 for sip@ietf.org; Thu, 06 Nov 2003 08:54:01 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AHkaG-0001KG-00 for sip@ietf.org; Thu, 06 Nov 2003 08:54:01 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA6DrxF07381 for ; Thu, 6 Nov 2003 15:53:59 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 6 Nov 2003 15:53:59 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 6 Nov 2003 15:53:58 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 6 Nov 2003 15:53:58 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797397@esebe019.ntc.nokia.com> Thread-Topic: Comments on sip-publish-01 Thread-Index: AcOkbWx2iuQPQlvTRwGEbNvVsPgcvA== To: , X-OriginalArrivalTime: 06 Nov 2003 13:53:58.0222 (UTC) FILETIME=[6CEABEE0:01C3A46D] Content-Transfer-Encoding: quoted-printable Subject: [Sip] Comments on sip-publish-01 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Apologies if some of these comments below have already been made on the = list. There are no major comments. - General: - I think a section should be dedicated to etags. This section would = explain how they work. At the moment, it is all over the place. - Abstract: - The 1st sentence in the second paragraph repeats what is said in = the first paragraph. - Section 1:=20 - The 1st sentence in the 3rd paragraph repeats what is said in the = first paragraph. - Section 3: - Second paragraph repeats definitions section. Maybe this paragraph = can go away and references added to definitions section. - Section 4.3: - Why is it a MUST for the content-type to provide partial = publication? I think MAY is enough - Section 5: - The note: Why would a PUBLISH fork? If would only fork if the user = has explicitly registered 2 different addresses or the proxy is = configured with 2 ESCs. In any case, I don't get why the PUBLISH may not = be appropriately presented. I think this note can go away. - PUBLISH does not create a dialog. Can we have some text here why = this is so. I just to remind us in 2 years time when we start asking the = question again. - Why is it explicitly forbidden for a PUBLISH to contain a contact. = It could be as simple as saying that the ESC ignores the contact header. - Section 5.2: - Request-URI should be used instead of To-header - It should be clarified that an etag associates an EPA with the ESC = for that boot cycle or until the EPA removes a publication (or something = like that) and does not change for that duration. (I was momentarily = confused and thought that the etag changes with every PUBLISH from the = same EPA). - I think I understand the etag mechanism, but is there a chance that = a state already exists for a EPA before that initial PUBLISH (a crash = and reboot or something). How does the ESC behave in this case? Does the = ESC know it is the same ESC publishing and therefore should remove the = state that was created before this new PUBLISH? - Section 5.4 and 5.5: - "the 200 (OK) response to a PUBLISH request from the ESC contains = ..." appears a few times. This confused me into thinking that you are = talking about the 200 of the refresh/modification PUBLISH. I think you = mean the "previous" PUBLISH. - Section 5.5: - The note should be normative text. - Section 5.6 - "EPAs which support the PUBLISH method SHOULD support this = mechanism for explicitly removing event state." Should the SHOULD be a = MUST? Regards, Hisham _______________________________________________ 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 exim@www1.ietf.org Thu Nov 6 09:35:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10637 for ; Thu, 6 Nov 2003 09:35:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHlEU-0001q0-7C for sip-archive@odin.ietf.org; Thu, 06 Nov 2003 09:35:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6EZYUV007064 for sip-archive@odin.ietf.org; Thu, 6 Nov 2003 09:35:34 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHlDz-0001p4-BC; Thu, 06 Nov 2003 09:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHlDK-0001oW-4J for sip@optimus.ietf.org; Thu, 06 Nov 2003 09:34:22 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10571 for ; Thu, 6 Nov 2003 09:34:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHlDI-0001sk-00 for sip@ietf.org; Thu, 06 Nov 2003 09:34:20 -0500 Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx with esmtp (Exim 4.12) id 1AHlDH-0001sg-00 for sip@ietf.org; Thu, 06 Nov 2003 09:34:19 -0500 Received: from kathmandu.pingtel.com (kathmandu.pingtel.com [10.1.1.252]) by mail.pingtel.com (8.11.6/8.11.6) with ESMTP id hA6EYE330859 for ; Thu, 6 Nov 2003 09:34:14 -0500 To: sip@ietf.org References: <200310141935.PAA26183@ietf.org> Organization: Pingtel Corp. http://www.pingtel.com/ From: Scott Lawrence Date: Thu, 06 Nov 2003 09:34:14 -0500 In-Reply-To: <200310141935.PAA26183@ietf.org> (Internet-Drafts@ietf.org's message of "Tue, 14 Oct 2003 15:35:02 -0400") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Sip] Re: draft-ietf-sip-congestsafe-02.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This draft presents an excellent explanation of how and why the use of UDP in SIP can (and therefor by Murphys Law, will :-) cause network operation problems. In doing so, it makes a good case for SIP having been designed differently, possibly not using UDP at all, but acknowleges that it is too late for that. It goes on to propose mechanisms by which this oversight can now be corrected by defining a congestion-safe mode of operation and adding a protocol feature to require operation in that mode. Unfortunately, I don't think that creating such a mechanism is useful, because there is little or no incentive for any significant number of systems to use it. The cat is not only out of the bag in that SIP was designed to support UDP, but later standards (SIP use of NAPTR and DNSSRV in RFC 3263) have provided for explicit administrative control mechanisms by which users (administrators) can (perhaps unwisely) prefer the use of UDP. The proposed 'congestion-managed' option would allow a system to send messages that conflict with policy as set by network administration at some later point in the message path; to illustrate: UAC Proxy Proxy Proxy UAC A -----> B --------> C ------> D ------> E UAC A sends an INVITE to E with 'Proxy-Require: congestion-managed', initially handing it off to Proxy B. Using normal SIP routing mechanisms, that message finds itself in due course at Proxy D (the local proxy on E's network). The administrator of that network has (for whatever reason) chosen to configure SIP on that network to prefer (or even be limited to) UDP. This potential conflict raises two questions: - Why should a user elsewhere in the network (A) be empowered to exercise any control of routing policy within the local network (E's network)? - Why would A want to send a request using this mechanism, given that doing so introduces a new potential failure mode, but does not improve that chances that this individual request will succeed? Granted - A acted (as any IETFer would naturally be inclined to do) with the best of intentions, with the health of the Internet itself in mind. If everyone did as A did, and all systems supported it, the network would be healthier and happier, and SIP (along with everything else) would work better. BUT. If one takes the view of a product manufacturer, or a local network administrator - why would you construct or configure your system such that lack of support for that new and improved world in just one system outside your control would cause your calls to fail? Remember that your only way to make them work when that (inevitably) happens is to resend them without 'congestion-managed', so you're going to end up potentially contributing to congestion problems anyway - but your first attempt failed even if no congestion problem actually existed. I do think that there is a problem to be solved - I think that the draft makes that case well, and has some good rules for system developers and administrators on how best to configure systems. Rather than a protocol extension, I would prefer to see this work redirected to producing a BCP document on how to configure SIP requests to prevent congestion problems - the incentives of network and SIP administrators are all in alignment there. -- Scott Lawrence Pingtel Corp. _______________________________________________ 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 exim@www1.ietf.org Thu Nov 6 10:16:46 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12858 for ; Thu, 6 Nov 2003 10:16:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHls4-00045C-G9 for sip-archive@odin.ietf.org; Thu, 06 Nov 2003 10:16:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6FGSrj015688 for sip-archive@odin.ietf.org; Thu, 6 Nov 2003 10:16:28 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHlqh-0003s7-Kr; Thu, 06 Nov 2003 10:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHlpl-0003rK-JP for sip@optimus.ietf.org; Thu, 06 Nov 2003 10:14:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12505 for ; Thu, 6 Nov 2003 10:13:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHlpj-0002Hb-00 for Sip@ietf.org; Thu, 06 Nov 2003 10:14:03 -0500 Received: from bay10-f66.bay10.hotmail.com ([64.4.37.66] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AHlpi-0002HI-00 for Sip@ietf.org; Thu, 06 Nov 2003 10:14:03 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 6 Nov 2003 07:13:32 -0800 Received: from 80.74.106.2 by by10fd.bay10.hotmail.msn.com with HTTP; Thu, 06 Nov 2003 15:13:31 GMT X-Originating-IP: [80.74.106.2] X-Originating-Email: [johnyjsmith1970@hotmail.com] From: "John Smith" To: Sip@ietf.org Date: Thu, 06 Nov 2003 15:13:31 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 06 Nov 2003 15:13:32.0036 (UTC) FILETIME=[8A54F440:01C3A478] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id KAA12506 Subject: [Sip] Questions about SigComp over SIP Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, I would like to develop SigComp over SIP, and find some issues unclear: 1. Quoting from RFC3486 (Compressing the Session Initiation Protocol): =93= The=20 presence of this parameter (comp=3Dsigcomp) in a URI indicates that the=20 request has to be compressed using SigComp, as defined in [2]=94 (section= no.=20 2). Then, below in section no.7 it continues with: =93If a SIP client sends a= =20 compressed request and the client transaction times out without having=20 received any response, the client SHOULD retry the same request without=20 using compression.=94 This quotation instructs us to send the same messa= ge=20 without specifying the following details: =B7 Is the parameter =91comp=3Dsigcomp=92 has to be removed from the orig= inal=20 request URI before re-sending the uncompressed SIP request message? =B7 In case that a SIP message has to be re-sent uncompressed, should it=20 contain different Via branch value (as it is done after transmission=20 failure, when using DNS) or different CSeq? 2. Is there any example of SigComp state that is created dynamically and = is=20 used by more than a single compartment? I=92m looking for an example of s= tate=20 that is not =91global=92 or created during initialization process (such a= s state=20 that keeps the dictionary or state that keeps compression/decompression=20 algorithm). 3. Do the compression/decompression algorithms instruct us which states a= nd=20 how many of them have to be created in order to support the SigComp featu= re?=20 or Does the states creation depend on the way that SigComp is implemented= ? I would appreciate answers to any of my questions. Thank You, John. _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8.=20 http://join.msn.com/?page=3Dfeatures/junkmail _______________________________________________ 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 exim@www1.ietf.org Thu Nov 6 10:51:43 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14281 for ; Thu, 6 Nov 2003 10:51:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHmPu-0006Gf-Jx for sip-archive@odin.ietf.org; Thu, 06 Nov 2003 10:51:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6FpQRl024035 for sip-archive@odin.ietf.org; Thu, 6 Nov 2003 10:51:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHmOY-0005yu-GX; Thu, 06 Nov 2003 10:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHmNd-0005xc-12 for sip@optimus.ietf.org; Thu, 06 Nov 2003 10:49:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14111 for ; Thu, 6 Nov 2003 10:48:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHmNa-0002jr-00 for sip@ietf.org; Thu, 06 Nov 2003 10:49:02 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AHmNZ-0002jR-00 for sip@ietf.org; Thu, 06 Nov 2003 10:49:02 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 06 Nov 2003 07:53:19 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hA6FmQw5008193; Thu, 6 Nov 2003 07:48:26 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANH46461; Thu, 6 Nov 2003 07:48:25 -0800 (PST) Date: Thu, 6 Nov 2003 07:28:19 -0800 Subject: Re: [Sip] GRUU Mechanism I-D Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Robert Sparks , Jonathan Rosenberg , Paul Kyzivat , sip@ietf.org To: Adam Roach From: Rohan Mahy In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E865C0@dyn-tx-exch-001.dynamicsoft.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Frankly, I think this medicine will kill the patient. While not pretty, what we have *is* implemented and implementable. While not what we would have chosen another go-around, I think we should stick with the behavior we have. thanks, -rohan On Wednesday, November 5, 2003, at 12:56 PM, Adam Roach wrote: >> I do think it would be very good medicine for the protocol to >> deprecate all dialog reuse. > > Hear, hear! > >> My personal preference for modifying REFER is to deprecate the >> implicit subscription behavior altogether (by strengthening the >> mechanisms proposed in Sean's and Rohan's drafts perhaps). > > I agree with this course of action, for the reasons you cite, > and others. > > /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 exim@www1.ietf.org Thu Nov 6 11:02:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15121 for ; Thu, 6 Nov 2003 11:02:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHmaH-0007cX-7T for sip-archive@odin.ietf.org; Thu, 06 Nov 2003 11:02:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6G29EP029233 for sip-archive@odin.ietf.org; Thu, 6 Nov 2003 11:02:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHmZG-00074C-5d; Thu, 06 Nov 2003 11:01:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHmYO-0006yi-JN for sip@optimus.ietf.org; Thu, 06 Nov 2003 11:00:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14704 for ; Thu, 6 Nov 2003 10:59:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHmYL-0002w2-00 for sip@ietf.org; Thu, 06 Nov 2003 11:00:09 -0500 Received: from c213-100-38-57.swipnet.se ([213.100.38.57] helo=coruscant.bilien.org) by ietf-mx with esmtp (Exim 4.12) id 1AHmYL-0002uz-00 for sip@ietf.org; Thu, 06 Nov 2003 11:00:09 -0500 Received: by coruscant.bilien.org (Postfix, from userid 1000) id 7166492C79; Thu, 6 Nov 2003 17:01:01 +0100 (CET) Date: Thu, 6 Nov 2003 17:01:01 +0100 From: Johan Bilien To: sip@ietf.org Message-ID: <20031106160101.GA19907@via.ecp.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i Subject: [Sip] Certificates handling in SIP/TLS Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, I have a few questions regarding the certificates handling when using SIP over TLS: . When the mutual authentication isn't used, should the TLS connection between the proxy and the UA be kept alive after the first registration ? Otherwise, how can the proxy contact the client, for example to forward an incoming INVITE: if the initial connection was closed, the UA will need a TLS listening connection, thus act as a TLS server and need a certificate. . When using mutual authentication, to which identity should the UA certificate's CN refer ? To the FQDN of the UA, or to the SIP URI ? In the last case, it would allow to use the same certificate as in MIKEY for instance. Thanks, -- Johan Bilien _______________________________________________ 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 exim@www1.ietf.org Thu Nov 6 14:39:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25134 for ; Thu, 6 Nov 2003 14:39:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHpyI-0005H3-E5 for sip-archive@odin.ietf.org; Thu, 06 Nov 2003 14:39:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6JdArg020214 for sip-archive@odin.ietf.org; Thu, 6 Nov 2003 14:39:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHpy9-0005F9-US; Thu, 06 Nov 2003 14:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHpxi-0005Cx-UL for sip@optimus.ietf.org; Thu, 06 Nov 2003 14:38:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25083 for ; Thu, 6 Nov 2003 14:38:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHpxf-0006ag-00 for sip@ietf.org; Thu, 06 Nov 2003 14:38:31 -0500 Received: from ftpbox.mot.com ([129.188.136.101]) by ietf-mx with esmtp (Exim 4.12) id 1AHpxf-0006aZ-00 for sip@ietf.org; Thu, 06 Nov 2003 14:38:31 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by ftpbox.mot.com (Motorola/Ftpbox) with ESMTP id hA6JcUSr019585 for ; Thu, 6 Nov 2003 12:38:30 -0700 (MST) Received: from il27exm01.cig.mot.com (il27exm01.cig.mot.com [10.17.193.2]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id hA6Jb4Lv029993 for ; Thu, 6 Nov 2003 13:37:05 -0600 Received: by il27exm01.cig.mot.com with Internet Mail Service (5.5.2657.2) id ; Thu, 6 Nov 2003 13:38:29 -0600 Message-ID: From: Baniel Uri-CUB001 To: "'sip@ietf.org'" Date: Thu, 6 Nov 2003 13:38:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.2) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Sip] test Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , _______________________________________________ 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 exim@www1.ietf.org Thu Nov 6 15:15:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27666 for ; Thu, 6 Nov 2003 15:15:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHqX9-00083c-II for sip-archive@odin.ietf.org; Thu, 06 Nov 2003 15:15:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6KFB4f030913 for sip-archive@odin.ietf.org; Thu, 6 Nov 2003 15:15:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHqX4-00081V-J6; Thu, 06 Nov 2003 15:15:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHqWj-0007tn-Sv for sip@optimus.ietf.org; Thu, 06 Nov 2003 15:14:45 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27524 for ; Thu, 6 Nov 2003 15:14:34 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AHqT2-0005T1-H1; Thu, 06 Nov 2003 15:10:56 -0500 X-test-idtracker: no To: IETF-Announce :; Cc: sip@ietf.org From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Thu, 06 Nov 2003 15:10:56 -0500 Subject: [Sip] Last Call: 'Caller Preferences for the Session Initiation Protocol (SIP)' to Proposed Standard Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Session Initiation Protocol WG to consider the following document: - 'Caller Preferences for the Session Initiation Protocol (SIP) ' 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 2003-11-28. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-callerprefs-10.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 exim@www1.ietf.org Thu Nov 6 15:31:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28821 for ; Thu, 6 Nov 2003 15:31:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHqme-0000cm-KF for sip-archive@odin.ietf.org; Thu, 06 Nov 2003 15:31:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6KVCGl002342 for sip-archive@odin.ietf.org; Thu, 6 Nov 2003 15:31:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHqmW-0000Xb-9X; Thu, 06 Nov 2003 15:31:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHqmO-0000Vl-DD for sip@optimus.ietf.org; Thu, 06 Nov 2003 15:30:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28747 for ; Thu, 6 Nov 2003 15:30:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHqmM-0007UN-00 for sip@ietf.org; Thu, 06 Nov 2003 15:30:55 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AHqmM-0007U1-00 for sip@ietf.org; Thu, 06 Nov 2003 15:30:54 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hA6KUMw5017240; Thu, 6 Nov 2003 12:30:22 -0800 (PST) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADU22661; Thu, 6 Nov 2003 15:30:21 -0500 (EST) Message-ID: <3FAAAF5D.1030502@cisco.com> Date: Thu, 06 Nov 2003 15:30:21 -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: brett@broadsoft.com CC: sip@ietf.org Subject: Re: [Sip] GRUU Mechanism I-D References: <001f01c3a3fc$28911a30$2b01a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Brett Tate wrote: >>>Most of the current dialog reuse issues could be >>>resolved by a new header which indicates a >>>real call-id and a parameter which indicates >>>that this is a request to establish a new >>>call/subscription/... on this dialog. >> >>I'm not clear what that helps. > > > A and B both know about a subscription dialog. > A thinks that a call is currently active on the > dialog; B does not. A sends a re-invite for > the call; B rings the phone since it does not > know if it was an invite or re-invite. > > >>>A new response is also needed to indicate that >>>I am aware of this dialog however I am not aware >>>of the call/subscription/... associated with >>>the request (a 481 which doesn't release the >>>dialog). >> >>When would this be used? >>Perhaps if a NOTIFY was received for which no >>corresponding subscription is known? I agree >>that is a potential problem, and a suitable >>error code would be helpful. AFAIK that is the >>only case where such a problem can arise. > > > A and B both know about a subscription dialog. > A thinks that a call is currently active on the > dialog; B does not. A sends a re-invite/update > for the call; B uses the response code to inform > that the call is not active. A can now choose > to send an INVITE to request the re-establishment > of the call still on the subscription dialog. OK, I see. Taking both of your comments above - your goal is to distinguish "call refresh" from "new call" and "subscription refresh" from "new subscription". It isn't really needed for subscriptions (or for REFER) because there are already unique event ids that distinguish them. But for the call there is indeed ambiguity - you can only have one call at a time, but in race conditions there could be confusion about whether an INVITE is or is not a reINVITE. I'm sure we can find some relatively simple way to resolve that. >>>To avoid some complexities, potentially we could >>>also restrict the number of calls sharing a >>>dialog to be 1 at any given time. Or potentially >>>we could add a statement that a call cannot be >>>originated on an already established dialog. >> >>As things stand there can only be one call on >>a dialog at a time. The only action that could >>establish a new one (an INVITE) will be >>interpretted as a reINVITE for the existing call. >> >>In theory you could establish a dialog with >>an invite, share it with a SUBSCRIBE, terminate the >>first call with a BYE, and then create a new >>call (with another INVITE) sharing the dialog >>with the subscription. >> >>A rational use of this capability escapes me > > > I am sure that someone will define an event > package that allows calls to be > established/re-established > sharing the subscription's dialog. Why does anything need to be defined in an event package for this? AFAIK it is quite ok today to establish a dialog via a SUBSCRIBE, and then send an INVITE within that dialog to establish a new call. The question is whether this is a *useful* capability. I guess one good example of a use would be when subscribing to the dialog package. If you saw a call that you wanted to affect - perhaps join - then it makes perfect sense to send the INVITE thru the same dialog. Of course this is also the exact use case that GRUUs render unnecessary. 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 exim@www1.ietf.org Thu Nov 6 15:41:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29572 for ; Thu, 6 Nov 2003 15:41:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHqwG-00020S-I2 for sip-archive@odin.ietf.org; Thu, 06 Nov 2003 15:41:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6Kf8nw007651 for sip-archive@odin.ietf.org; Thu, 6 Nov 2003 15:41:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHqwB-0001xt-UG; Thu, 06 Nov 2003 15:41:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHqvv-0001wE-11 for sip@optimus.ietf.org; Thu, 06 Nov 2003 15:40:47 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29465 for ; Thu, 6 Nov 2003 15:40:35 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AHqj8-0007fM-Jk; Thu, 06 Nov 2003 15:27:34 -0500 X-test-idtracker: no To: IETF-Announce :; Cc: sip@ietf.org From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Thu, 06 Nov 2003 15:27:34 -0500 Subject: [Sip] Last Call: 'The SIP Referred-By Mechanism' to Proposed Standard Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Session Initiation Protocol WG to consider the following document: - 'The SIP Referred-By Mechanism ' 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 2003-11-28. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-referredby-03.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 exim@www1.ietf.org Thu Nov 6 15:41:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29573 for ; Thu, 6 Nov 2003 15:41:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHqwG-00020j-Iz for sip-archive@odin.ietf.org; Thu, 06 Nov 2003 15:41:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6Kf89m007662 for sip-archive@odin.ietf.org; Thu, 6 Nov 2003 15:41:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHqwA-0001xf-PJ; Thu, 06 Nov 2003 15:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHqvr-0001vS-8t for sip@optimus.ietf.org; Thu, 06 Nov 2003 15:40:43 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29457 for ; Thu, 6 Nov 2003 15:40:31 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AHqa6-0007Dk-Cl; Thu, 06 Nov 2003 15:18:14 -0500 X-test-idtracker: no To: IETF-Announce :; Cc: sip@ietf.org From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Thu, 06 Nov 2003 15:18:14 -0500 Subject: [Sip] Last Call: 'SIP Authenticated Identity Body (AIB) Format' to Proposed Standard Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Session Initiation Protocol WG to consider the following document: - 'SIP Authenticated Identity Body (AIB) Format ' 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 2003-11-28. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-authid-body-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 exim@www1.ietf.org Thu Nov 6 16:01:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00784 for ; Thu, 6 Nov 2003 16:01:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrFf-0003SX-Bd for sip-archive@odin.ietf.org; Thu, 06 Nov 2003 16:01:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6L1BlG013237 for sip-archive@odin.ietf.org; Thu, 6 Nov 2003 16:01:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrFW-0003Q0-Jo; Thu, 06 Nov 2003 16:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrEv-0003N1-9s for sip@optimus.ietf.org; Thu, 06 Nov 2003 16:00:25 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00706 for ; Thu, 6 Nov 2003 16:00:13 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AHqwt-0000PY-1X; Thu, 06 Nov 2003 15:41:47 -0500 X-test-idtracker: no To: IETF-Announce :; Cc: sip@ietf.org From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Thu, 06 Nov 2003 15:41:47 -0500 Subject: [Sip] Last Call: 'Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)' to Proposed Standard Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Session Initiation Protocol WG to consider the following document: - 'Indicating User Agent Capabilities in the Session Initiation Protocol (SIP) ' 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 2003-11-28. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-callee-caps-01.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 exim@www1.ietf.org Thu Nov 6 16:11:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01128 for ; Thu, 6 Nov 2003 16:11:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrPL-0004J3-5G for sip-archive@odin.ietf.org; Thu, 06 Nov 2003 16:11:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6LBBAk016493 for sip-archive@odin.ietf.org; Thu, 6 Nov 2003 16:11:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrPD-0004E8-Cl; Thu, 06 Nov 2003 16:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrP5-0004CJ-RH for sip@optimus.ietf.org; Thu, 06 Nov 2003 16:10:56 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01025 for ; Thu, 6 Nov 2003 16:10:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHrP4-0000XX-00 for sip@ietf.org; Thu, 06 Nov 2003 16:10:54 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1AHrP3-0000XP-00 for sip@ietf.org; Thu, 06 Nov 2003 16:10:53 -0500 Received: from bdsl.greycouncil.com (www.softarmor.com [127.0.0.1]) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id hA6LBNv4009814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 6 Nov 2003 15:11:23 -0600 Received: (from dwillis@localhost) by bdsl.greycouncil.com (8.12.8/8.12.8/Submit) id hA6LBNTe009812; Thu, 6 Nov 2003 15:11:23 -0600 X-Authentication-Warning: bdsl.greycouncil.com: dwillis set sender to dean.willis@softarmor.com using -f Subject: Consensus on direction needed (was Re: [Sip] Re: draft-ietf-sip-congestsafe-02.txt)] From: Dean Willis To: sip@ietf.org, slawrence@pingtel.com Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1068153082.8295.59.camel@bdsl.greycouncil.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Thu, 06 Nov 2003 15:11:22 -0600 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thu, 2003-11-06 at 08:34, Scott Lawrence wrote: > This draft presents an excellent explanation of how and why the > use of UDP in SIP can (and therefor by Murphys Law, will :-) cause > network operation problems. In doing so, it makes a good case for > SIP having been designed differently, possibly not using UDP at > all, but acknowleges that it is too late for that. It goes on to > propose mechanisms by which this oversight can now be corrected by > defining a congestion-safe mode of operation and adding a protocol > feature to require operation in that mode. > Unfortunately, I don't think that creating such a mechanism is > useful, because there is little or no incentive for any > significant number of systems to use it. The cat is not only out > of the bag in that SIP was designed to support UDP, but later > standards (SIP use of NAPTR and DNSSRV in RFC 3263) have provided > for explicit administrative control mechanisms by which users > (administrators) can (perhaps unwisely) prefer the use of UDP. . . . Excellent summary and commentary. Here's the deal. Before long, EVERY e2e-secured SIP request or response is going to be bigger than one packet. The security people aren't going to give up on e2e. This gives us two viable alternatives, as I see them: 1) Deprecate UDP usage in SIP. 2) Deprecate SIP. Since #2 would leave me unemployed :-(, the question I'm interested is how to do #1. Three possibilities suggest themselves, and I'd like to get a sense of consensus from the group on the direction (or other suggestions, if there are any). 1) Leave the UDP stuff in place, but convince people not to use it by doing a "UDP Considered Harmful for SIP" BCP, (which Scott seems to be suggesting). 2) Leave the UDP stuff in place, but give people tools to keep it from being used (which this draft suggests). 3) Rev the spec to 3.0 and rip UDP out by the toenails. Any other ideas? What is the right thing to do here? -- 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 exim@www1.ietf.org Thu Nov 6 16:45:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02683 for ; Thu, 6 Nov 2003 16:45:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrwM-00063w-S2 for sip-archive@odin.ietf.org; Thu, 06 Nov 2003 16:45:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6LjIud023298 for sip-archive@odin.ietf.org; Thu, 6 Nov 2003 16:45:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrw7-00062Q-My; Thu, 06 Nov 2003 16:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHrvB-0005xr-Jo for sip@optimus.ietf.org; Thu, 06 Nov 2003 16:44:05 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02656 for ; Thu, 6 Nov 2003 16:43:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHrv9-00014e-00 for sip@ietf.org; Thu, 06 Nov 2003 16:44:03 -0500 Received: from broadsoft.com ([198.104.184.110]) by ietf-mx with esmtp (Exim 4.12) id 1AHrv8-00014b-00 for sip@ietf.org; Thu, 06 Nov 2003 16:44:02 -0500 Received: from tate (host4.brodsoft.com [66.160.10.4] (may be forged)) by broadsoft.com (8.12.10/8.12.9) with SMTP id hA6Lhw9V084398; Thu, 6 Nov 2003 16:43:58 -0500 (EST) Reply-To: From: "Brett Tate" To: "'Paul Kyzivat'" Cc: Subject: RE: [Sip] GRUU Mechanism I-D Date: Thu, 6 Nov 2003 16:44:54 -0500 Message-ID: <001001c3a4af$37f8f340$2b01a8c0@broadsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <3FAAAF5D.1030502@cisco.com> Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > > A and B both know about a subscription dialog. > > A thinks that a call is currently active on the > > dialog; B does not. A sends a re-invite/update > > for the call; B uses the response code to inform > > that the call is not active. A can now choose > > to send an INVITE to request the re-establishment > > of the call still on the subscription dialog. > > OK, I see. Taking both of your comments above - > your goal is to distinguish "call refresh" from > "new call" Yes. > and "subscription refresh" from "new subscription". Actually it is being able to reject a notify with a cause code that reflects that I am aware of the dialog but not the subscription. No response code indicates known dialog but unknown subscription/call. > But for the call there is indeed ambiguity - > you can only have one call at a time, but in race > conditions there could be confusion about whether > an INVITE is or is not a reINVITE. I'm sure we > can find some relatively simple way to resolve that. I agree. > >>As things stand there can only be one call on > >>a dialog at a time. The only action that could > >>establish a new one (an INVITE) will be > >>interpretted as a reINVITE for the existing call. > >> > >>In theory you could establish a dialog with > >>an invite, share it with a SUBSCRIBE, terminate the > >>first call with a BYE, and then create a new > >>call (with another INVITE) sharing the dialog > >>with the subscription. > >> > >>A rational use of this capability escapes me > > > > > > I am sure that someone will define an event > > package that allows calls to be > > established/re-established > > sharing the subscription's dialog. > > Why does anything need to be defined in an > event package for this? I was mainly indicating that nobody has yet submitted a draft/rfc indicating such functionality. However I am sure that somebody will start defining call-me-back-over-this-dialog type subscription events. > AFAIK it is quite ok today to establish a dialog > via a SUBSCRIBE, and then send an INVITE within > that dialog to establish a new call. Yes. However many products would reject the invite unless it has meaning associated with the subscription. > The question is whether this is a *useful* capability. > > I guess one good example of a use would be when > subscribing to the dialog package. If you saw a > call that you wanted to affect - perhaps > join - then it makes perfect sense to send the > INVITE thru the same dialog. > > Of course this is also the exact use case that > GRUUs render unnecessary. Agreed. That was why I was trying to either: 1) Resolve the issues of originating/re-originating a call over a subscription's dialog. 2) Or mention that such functionality is not approved by the working group because GRUU must be used instead. I prefer option 1 since it will take time to get the GRUU solution approved for RFC and widely deployed. _______________________________________________ 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 exim@www1.ietf.org Thu Nov 6 16:57:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03390 for ; Thu, 6 Nov 2003 16:57:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHs7p-0006tO-AS for sip-archive@odin.ietf.org; Thu, 06 Nov 2003 16:57:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6Lv9bj026462 for sip-archive@odin.ietf.org; Thu, 6 Nov 2003 16:57:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHs7h-0006rW-Vx; Thu, 06 Nov 2003 16:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHs7K-0006pu-Ow for sip@optimus.ietf.org; Thu, 06 Nov 2003 16:56:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03329 for ; Thu, 6 Nov 2003 16:56:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHs7I-0001Kf-00 for sip@ietf.org; Thu, 06 Nov 2003 16:56:36 -0500 Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx with esmtp (Exim 4.12) id 1AHs7I-0001KP-00 for sip@ietf.org; Thu, 06 Nov 2003 16:56:36 -0500 Received: from kathmandu.pingtel.com (kathmandu.pingtel.com [10.1.1.252]) by mail.pingtel.com (8.11.6/8.11.6) with ESMTP id hA6LuU310342; Thu, 6 Nov 2003 16:56:30 -0500 To: Dean Willis Cc: sip@ietf.org, slawrence@pingtel.com References: <1068153082.8295.59.camel@bdsl.greycouncil.com> Organization: Pingtel Corp. http://www.pingtel.com/ From: Scott Lawrence Date: Thu, 06 Nov 2003 16:56:30 -0500 In-Reply-To: <1068153082.8295.59.camel@bdsl.greycouncil.com> (Dean Willis's message of "Thu, 06 Nov 2003 15:11:22 -0600") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Sip] Re: Consensus on direction needed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Dean Willis writes: > The security people aren't going to give up on e2e. Which is not the same thing as saying that users will use it... but that's a different discussion. > Three possibilities suggest themselves, and I'd like to get a sense of > consensus from the group on the direction (or other suggestions, if > there are any). > > 1) Leave the UDP stuff in place, but convince people not to use it by > doing a "UDP Considered Harmful for SIP" BCP, (which Scott seems to be > suggesting). > > 2) Leave the UDP stuff in place, but give people tools to keep it from > being used (which this draft suggests). > > 3) Rev the spec to 3.0 and rip UDP out by the toenails. > > Any other ideas? What is the right thing to do here? #1 is a good start, but in the absense of an alternative that is perceived as being equally good, it won't matter. accordingly, I'd modify #2 slightly to: Leave the UDP stuff in place, _and_ provide good alternatives that are better. The BCP will be a valuable part of getting the word out that something else is better by educating administrators & users about the problem with SIP/UDP. I do think that we need to refine some other things further to provide the alternative. One suggestion I'd make toward that end is that everyone look closely at draft-mahy-sip-connect-reuse-00 - I think that it goes a long way to solving some of the barriers to wider adoption of SIP over TCP. I've a comment or two on that that I'll send separately... -- Scott Lawrence Pingtel Corp. _______________________________________________ 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 exim@www1.ietf.org Thu Nov 6 17:00:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03652 for ; Thu, 6 Nov 2003 17:00:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsAh-0007DL-9p for sip-archive@odin.ietf.org; Thu, 06 Nov 2003 17:00:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6M05xE027634 for sip-archive@odin.ietf.org; Thu, 6 Nov 2003 17:00:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsAd-0007B8-6u; Thu, 06 Nov 2003 17:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHs9m-00079Z-Di for sip@optimus.ietf.org; Thu, 06 Nov 2003 16:59:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03476 for ; Thu, 6 Nov 2003 16:58:57 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHs9k-0001Nu-00 for sip@ietf.org; Thu, 06 Nov 2003 16:59:08 -0500 Received: from [204.57.52.4] (helo=commserver.iperia.com) by ietf-mx with esmtp (Exim 4.12) id 1AHs9j-0001Mx-00 for sip@ietf.org; Thu, 06 Nov 2003 16:59:07 -0500 Received: by COMMSERVER with Internet Mail Service (5.5.2653.19) id ; Thu, 6 Nov 2003 16:58:34 -0500 Message-ID: <1A69639B9B6AD511812B00B0D0DE19F60130AE06@COMMSERVER> From: Gordon Ledgard To: "'Dean Willis'" , sip@ietf.org, slawrence@pingtel.com Subject: RE: Consensus on direction needed (was Re: [Sip] Re: draft-ietf-s ip-congestsafe-02.txt)] Date: Thu, 6 Nov 2003 16:58:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , >> On Thu, 2003-11-06 at 08:34, Scott Lawrence wrote: >> This draft presents an excellent explanation of how and why the >> use of UDP in SIP can (and therefor by Murphys Law, will :-) cause >> network operation problems. In doing so, it makes a good case for >> SIP having been designed differently, possibly not using UDP at >> all, but acknowleges that it is too late for that. It goes on to >> propose mechanisms by which this oversight can now be corrected by >> defining a congestion-safe mode of operation and adding a protocol >> feature to require operation in that mode. >> >> Unfortunately, I don't think that creating such a mechanism is >> useful, because there is little or no incentive for any >> significant number of systems to use it. The cat is not only out >> of the bag in that SIP was designed to support UDP, but later >> standards (SIP use of NAPTR and DNSSRV in RFC 3263) have provided >> for explicit administrative control mechanisms by which users >> (administrators) can (perhaps unwisely) prefer the use of UDP. On Thu, 2003-11-06 at 16:12, Dean Willis wrote: > Excellent summary and commentary. > > Here's the deal. Before long, EVERY e2e-secured SIP request or response > is going to be bigger than one packet. The security people aren't going > to give up on e2e. > > This gives us two viable alternatives, as I see them: > > 1) Deprecate UDP usage in SIP. > > 2) Deprecate SIP. > > Since #2 would leave me unemployed :-(, the question I'm interested is > how to do #1. > > Three possibilities suggest themselves, and I'd like to get a sense of > consensus from the group on the direction (or other suggestions, if > there are any). > > 1) Leave the UDP stuff in place, but convince people not to use it by > doing a "UDP Considered Harmful for SIP" BCP, (which Scott seems to be > suggesting). > > 2) Leave the UDP stuff in place, but give people tools to keep it from > being used (which this draft suggests). > > 3) Rev the spec to 3.0 and rip UDP out by the toenails. > > Any other ideas? What is the right thing to do here? > > -- > Dean You could always leave the current definition of SIP alone, and define a new version of it (call it SIPNEW or something?) that uses non-UDP transports to support e2e. Why deprecate the old one if people find it useful for certain problems? You could just mandate that old SIP cannot be used in e2e environments, and that if e2e is ever required for your application, you need to use the newer SIP. I've long been of the opinion that there needs to be two flavors of SIP, one for secured proprietary networks, and one for the internet at large. (Don't flame me! I understand the current mandate of SIP. I'm just saying it might be useful.) The motivation for the simpler SIP would be to improve speed and cut down on message bloat. Gordon _______________________________________________ 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 exim@www1.ietf.org Thu Nov 6 17:13:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04190 for ; Thu, 6 Nov 2003 17:13:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsNN-0008Lb-Nx for sip-archive@odin.ietf.org; Thu, 06 Nov 2003 17:13:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6MDD3v032028 for sip-archive@odin.ietf.org; Thu, 6 Nov 2003 17:13:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsNC-0008JD-2n; Thu, 06 Nov 2003 17:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsMV-0008I8-Aj for sip@optimus.ietf.org; Thu, 06 Nov 2003 17:12:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04166 for ; Thu, 6 Nov 2003 17:12:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsMT-0001eO-00 for sip@ietf.org; Thu, 06 Nov 2003 17:12:17 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AHsMR-0001eC-00 for sip@ietf.org; Thu, 06 Nov 2003 17:12:16 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 06 Nov 2003 14:16:39 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hA6MBgw5023398; Thu, 6 Nov 2003 14:11:42 -0800 (PST) Received: from cisco.com ([161.44.79.51]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADU33212; Thu, 6 Nov 2003 17:11:41 -0500 (EST) Message-ID: <3FAAC71D.8030604@cisco.com> Date: Thu, 06 Nov 2003 17:11:41 -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: brett@broadsoft.com CC: sip@ietf.org Subject: Re: [Sip] GRUU Mechanism I-D References: <001001c3a4af$37f8f340$2b01a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Brett Tate wrote: > >>AFAIK it is quite ok today to establish a dialog >>via a SUBSCRIBE, and then send an INVITE within >>that dialog to establish a new call. > > Yes. However many products would reject the invite > unless it has meaning associated with the subscription. Well, you are probably right about that, though there is no particular reason why that ought to be the case. While it is probably outside the scope of the IETF, it seems plausible to me that a request arriving within an existing dialog ought to accepted if the exact same request would have been accepted in a new dialog. In addition, there MAY be cases where a request in a dialog might be accepted with less restrictions if in an existing dialog than if received in a new one. Clearly, if interop problems arise due to differences in authorization policies, then the mechanism isn't useful. In that sense using separate dialogs and GRUUs may be easier. But that approach will probably also have problems of some sort - perhaps around who can use a GRUU or what for, GRUU lifetime, etc. 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 exim@www1.ietf.org Thu Nov 6 17:36:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05522 for ; Thu, 6 Nov 2003 17:36:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsjc-0001v0-7c for sip-archive@odin.ietf.org; Thu, 06 Nov 2003 17:36:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6MaC3W007368 for sip-archive@odin.ietf.org; Thu, 6 Nov 2003 17:36:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsjS-0001sn-Dh; Thu, 06 Nov 2003 17:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHsie-0001rz-Cq for sip@optimus.ietf.org; Thu, 06 Nov 2003 17:35:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05470 for ; Thu, 6 Nov 2003 17:34:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHsib-00029l-00 for sip@ietf.org; Thu, 06 Nov 2003 17:35:09 -0500 Received: from dirty.research.bell-labs.com ([204.178.16.6]) by ietf-mx with esmtp (Exim 4.12) id 1AHsib-00029i-00 for sip@ietf.org; Thu, 06 Nov 2003 17:35:09 -0500 Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.10/8.12.10) with ESMTP id hA6MZ3fO007252; Thu, 6 Nov 2003 17:35:03 -0500 (EST) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.12.9/8.12.9) with ESMTP id hA6MYv0C018084; Thu, 6 Nov 2003 17:34:57 -0500 (EST) Received: from bell-labs.com (volker-hopc [135.180.240.186]) by bronx.dnrc.bell-labs.com (8.12.9/8.12.9) with ESMTP id hA6MYtFU027421; Thu, 6 Nov 2003 17:34:56 -0500 (EST) Message-ID: <3FAACC6E.1040001@bell-labs.com> Date: Thu, 06 Nov 2003 17:34:22 -0500 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: de-de, de, en-us, en MIME-Version: 1.0 To: Rohan Mahy , Adam Roach , Robert Sparks , Jonathan Rosenberg , Paul Kyzivat CC: sip@ietf.org Subject: Re: [Sip] GRUU Mechanism I-D References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The main issue with deprecating the implicit subscription seems to be that it must be done in a backwards compatible way, since a lot of implementations already exist. To my understanding, a backwards compatible solution would need to: - enable the UAC to detect, whether the UAS is an "old" UA that uses the deprecated implicit subscriptions or a "new" UA that supports explicit subscriptions. - enable the UAS to detect, whether the UAC expects implicit or explicit subscriptions. Would a new option tag help (along the lines of Sean's draft) that is mandatory for new implementations? Btw. since explicit subscriptions require the UAS to use a gruu, the first case could be covered just by looking for the gruu option tag. However, I'm not sure if it is safe to assume that a "new" UAC also includes a gruu in its REFER request (in this case, we could even use the "gruu" option tag as an indicator). -- Volker -- Volker Hilt Bell Labs / Lucent Technologies phone: +1 732 332 6432 101 Crawfords Corner Rd email: volkerh@bell-labs.com Holmdel, NJ 07733 _______________________________________________ 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 exim@www1.ietf.org Thu Nov 6 18:33:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08492 for ; Thu, 6 Nov 2003 18:33:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHtch-0005Yi-Ud for sip-archive@odin.ietf.org; Thu, 06 Nov 2003 18:33:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA6NX7q6021343 for sip-archive@odin.ietf.org; Thu, 6 Nov 2003 18:33:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHtcb-0005Wy-Df; Thu, 06 Nov 2003 18:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHtbe-0005Rw-1I for sip@optimus.ietf.org; Thu, 06 Nov 2003 18:32:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08401 for ; Thu, 6 Nov 2003 18:31:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHtba-0002oe-00 for sip@ietf.org; Thu, 06 Nov 2003 18:31:59 -0500 Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx with esmtp (Exim 4.12) id 1AHtba-0002oY-00 for sip@ietf.org; Thu, 06 Nov 2003 18:31:58 -0500 Received: from kathmandu.pingtel.com (kathmandu.pingtel.com [10.1.1.252]) by mail.pingtel.com (8.11.6/8.11.6) with ESMTP id hA6NVl312321; Thu, 6 Nov 2003 18:31:48 -0500 To: Gordon Ledgard Cc: "'Dean Willis'" , sip@ietf.org, slawrence@pingtel.com References: <1A69639B9B6AD511812B00B0D0DE19F60130AE06@COMMSERVER> Organization: Pingtel Corp. http://www.pingtel.com/ From: Scott Lawrence Date: Thu, 06 Nov 2003 18:31:13 -0500 In-Reply-To: <1A69639B9B6AD511812B00B0D0DE19F60130AE06@COMMSERVER> (Gordon Ledgard's message of "Thu, 6 Nov 2003 16:58:26 -0500") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Sip] Re: Consensus on direction needed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > On Thu, 2003-11-06 at 16:12, Dean Willis wrote: >> Here's the deal. Before long, EVERY e2e-secured SIP request or response >> is going to be bigger than one packet. The security people aren't going >> to give up on e2e. Gordon Ledgard writes: > You could always leave the current definition of SIP alone, and > define a new version of it (call it SIPNEW or something?) that > uses non-UDP transports to support e2e. Why deprecate the old > one if people find it useful for certain problems? You could just > mandate that old SIP cannot be used in e2e environments, and that > if e2e is ever required for your application, you need to use > the newer SIP. e2e is not required to cause the congestion-related bad behaviour of SIP; large messages are not even required. All that's required is _something_ that causes packet loss on links that are already running at a load close enough to capacity, somewhere in the path - after that, the retransmissions push the network into collapse. -- Scott Lawrence Pingtel Corp. _______________________________________________ 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 exim@www1.ietf.org Thu Nov 6 19:06:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09440 for ; Thu, 6 Nov 2003 19:06:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHu8h-0007GZ-Qa for sip-archive@odin.ietf.org; Thu, 06 Nov 2003 19:06:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA706BmA027872 for sip-archive@odin.ietf.org; Thu, 6 Nov 2003 19:06:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHu8Y-0007Ec-A9; Thu, 06 Nov 2003 19:06:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AHu8T-0007E2-V2 for sip@optimus.ietf.org; Thu, 06 Nov 2003 19:05:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09419 for ; Thu, 6 Nov 2003 19:05:43 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AHu8Q-0003Cy-00 for sip@ietf.org; Thu, 06 Nov 2003 19:05:54 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AHu8P-0003C8-00 for sip@ietf.org; Thu, 06 Nov 2003 19:05:53 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hA705HhL023686; Thu, 6 Nov 2003 19:05:17 -0500 (EST) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hA705Fg30456; Thu, 6 Nov 2003 19:05:15 -0500 Message-ID: <3FAAE1BB.3060508@cs.columbia.edu> Date: Thu, 06 Nov 2003 19:05:15 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: sip@ietf.org, slawrence@pingtel.com Subject: Re: Consensus on direction needed (was Re: [Sip] Re: draft-ietf-sip-congestsafe-02.txt)] References: <1068153082.8295.59.camel@bdsl.greycouncil.com> In-Reply-To: <1068153082.8295.59.camel@bdsl.greycouncil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > 3) Rev the spec to 3.0 and rip UDP out by the toenails. For the historical record, that was roughly SIP 1.0 :-) _______________________________________________ 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 exim@www1.ietf.org Fri Nov 7 02:21:07 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02756 for ; Fri, 7 Nov 2003 02:21:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI0vH-0002PU-Od for sip-archive@odin.ietf.org; Fri, 07 Nov 2003 02:20:48 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA77KlNP009263 for sip-archive@odin.ietf.org; Fri, 7 Nov 2003 02:20:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI0uZ-0002Ml-5l; Fri, 07 Nov 2003 02:20:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI0to-0002Ku-Sd for sip@optimus.ietf.org; Fri, 07 Nov 2003 02:19:17 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02558 for ; Fri, 7 Nov 2003 02:19:05 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI0tl-00009S-00 for sip@ietf.org; Fri, 07 Nov 2003 02:19:13 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AI0tk-00009P-00 for sip@ietf.org; Fri, 07 Nov 2003 02:19:12 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA77JDY25234 for ; Fri, 7 Nov 2003 09:19:13 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Nov 2003 09:19:10 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 7 Nov 2003 09:19:12 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Consensus on direction needed (was Re: [Sip] Re:draft-ietf-sip-congestsafe-02.txt)] Date: Fri, 7 Nov 2003 09:19:11 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB70179739C@esebe019.ntc.nokia.com> Thread-Topic: Consensus on direction needed (was Re: [Sip] Re:draft-ietf-sip-congestsafe-02.txt)] Thread-Index: AcOkqp8/SofoOu89QU2ThCXethXlZAAVD3LQ To: , , X-OriginalArrivalTime: 07 Nov 2003 07:19:12.0526 (UTC) FILETIME=[718E1AE0:01C3A4FF] Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext > Dean Willis > Sent: Thursday, November 06, 2003 11:11 PM > To: sip@ietf.org; slawrence@pingtel.com > Subject: Consensus on direction needed (was Re: [Sip] > Re:draft-ietf-sip-congestsafe-02.txt)] >=20 >=20 > Here's the deal. Before long, EVERY e2e-secured SIP request=20 > or response > is going to be bigger than one packet. The security people=20 > aren't going > to give up on e2e. >=20 > This gives us two viable alternatives, as I see them: >=20 > 1) Deprecate UDP usage in SIP. >=20 > 2) Deprecate SIP. >=20 > Since #2 would leave me unemployed :-(, the question I'm interested is > how to do #1. >=20 > Three possibilities suggest themselves, and I'd like to get a sense of > consensus from the group on the direction (or other suggestions, if > there are any). >=20 > 1) Leave the UDP stuff in place, but convince people not to use it by > doing a "UDP Considered Harmful for SIP" BCP, (which Scott=20 > seems to be > suggesting).=20 >=20 > 2) Leave the UDP stuff in place, but give people tools to keep it from > being used (which this draft suggests). >=20 > 3) Rev the spec to 3.0 and rip UDP out by the toenails. >=20 > Any other ideas? What is the right thing to do here? I prefer 1. I would not deprecate UDP completely, it has its uses. We = can also extend option 1 so that the default transport protocol is TCP = if the transport parameter is not present. Regards, Hisham >=20 > -- > Dean >=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 From exim@www1.ietf.org Fri Nov 7 03:01:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04173 for ; Fri, 7 Nov 2003 03:01:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1YV-0004xe-EB for sip-archive@odin.ietf.org; Fri, 07 Nov 2003 03:01:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA781JMT019010 for sip-archive@odin.ietf.org; Fri, 7 Nov 2003 03:01:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1YF-0004sF-S7; Fri, 07 Nov 2003 03:01:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1Xo-0004rL-VZ for sip@optimus.ietf.org; Fri, 07 Nov 2003 03:00:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04134 for ; Fri, 7 Nov 2003 03:00:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI1Xk-0000i8-00 for sip@ietf.org; Fri, 07 Nov 2003 03:00:32 -0500 Received: from pine.neustar.com ([209.173.57.70]) by ietf-mx with esmtp (Exim 4.12) id 1AI1Xk-0000ge-00 for sip@ietf.org; Fri, 07 Nov 2003 03:00:32 -0500 Received: from chiimc01.npac.com (chiimc01.neustar.com [10.32.90.4]) by pine.neustar.com (8.12.8/8.11.0) with ESMTP id hA7802b9027045; Fri, 7 Nov 2003 08:00:02 GMT Received: by CHIIMC01 with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Nov 2003 02:01:25 -0600 Message-ID: From: "Peterson, Jon" To: "'Dean Willis'" , sip@ietf.org, slawrence@pingtel.com Subject: RE: Consensus on direction needed (was Re: [Sip] Re: draft-ietf-s ip-congestsafe-02.txt)] Date: Fri, 7 Nov 2003 02:01:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > Here's the deal. Before long, EVERY e2e-secured SIP request or response > is going to be bigger than one packet. The security people aren't going > to give up on e2e. It would be nice if the security people could find an e2e solution better suited to SIP's needs, then, I gather. > This gives us two viable alternatives, as I see them: > > 1) Deprecate UDP usage in SIP. > > 2) Deprecate SIP. > > Since #2 would leave me unemployed :-(, the question I'm interested is > how to do #1. > > Three possibilities suggest themselves, and I'd like to get a sense of > consensus from the group on the direction (or other suggestions, if > there are any). > > 1) Leave the UDP stuff in place, but convince people not to use it by > doing a "UDP Considered Harmful for SIP" BCP, (which Scott seems to be > suggesting). > > 2) Leave the UDP stuff in place, but give people tools to keep it from > being used (which this draft suggests). > > 3) Rev the spec to 3.0 and rip UDP out by the toenails. > I'm afraid I remain closest to option 3, though this particular motivation is far from my main reason reason for feeling so. Jon Peterson NeuStar, Inc. > Any other ideas? What is the right thing to do here? > > -- > 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 exim@www1.ietf.org Fri Nov 7 03:06:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04453 for ; Fri, 7 Nov 2003 03:06:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1dA-0005HN-7p for sip-archive@odin.ietf.org; Fri, 07 Nov 2003 03:06:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7868tL020258 for sip-archive@odin.ietf.org; Fri, 7 Nov 2003 03:06:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1d5-0005FS-L1; Fri, 07 Nov 2003 03:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI1ch-0005CI-Kf for sip@optimus.ietf.org; Fri, 07 Nov 2003 03:05:39 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04352 for ; Fri, 7 Nov 2003 03:05:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI1cd-0000ly-00 for sip@ietf.org; Fri, 07 Nov 2003 03:05:35 -0500 Received: from mail.stalker.com ([206.253.23.169]) by ietf-mx with esmtp (Exim 4.12) id 1AI1cc-0000lv-00 for sip@ietf.org; Fri, 07 Nov 2003 03:05:34 -0500 Received: from [206.253.23.171] (account butenko@mail.stalker.com) by mail.stalker.com (CommuniGate Pro WebUser 4.1.6) with HTTP id 27538730 for sip@ietf.org; Fri, 07 Nov 2003 00:03:28 -0800 From: "Vladimir A. Butenko" To: sip@ietf.org X-Mailer: CommuniGate Pro WebUser Interface v.4.1.6 Date: Fri, 07 Nov 2003 00:03:28 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [Sip] REGISTER requests via NAT Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Excuse me if this topic has been already discussed, I have not found an answer in the list archive. The situation: an organization with 2 offices, each running its own NAT'ed network, with a SIP server installed on each NAT gateway. The SIP servers insert the Record-Route headers for all requests coming to and from their LANs, and they also do media stream proxing: the Record-Route mechanism allows user@network1.com to exchange SIP messages and to establish calls with any user@network2.com. Now, the organization decides to register users of these 2 (or more) networks within one domain, so employees moving back and force between offices can be addressed by their name, user@company.com. The company.com SIP registrar is installed, let's say, "outside" both LANs. The SIP servers in each office properly redirect the REGISTER requests to that company.com server. But the Contact: header fields, obviously, contain the internal LAN addresses of those users. As the RFC3261 explicitly specifies that any Record-Route information in REGISTER requests should be ignored, is there any other, "legal" way to "attach" the routing information to those requests, so it is stored by the registrar and all SIP requests made to user@company.com from a different LAN (coming to the registrar proxy) will be routed correctly? Sincerely, Vladimir _______________________________________________ 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 exim@www1.ietf.org Fri Nov 7 04:16:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06579 for ; Fri, 7 Nov 2003 04:16:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI2j0-0001dM-J8 for sip-archive@odin.ietf.org; Fri, 07 Nov 2003 04:16:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA79GEqe006220 for sip-archive@odin.ietf.org; Fri, 7 Nov 2003 04:16:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI2ip-0001bU-5T; Fri, 07 Nov 2003 04:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI2iB-0001ZD-4g for sip@optimus.ietf.org; Fri, 07 Nov 2003 04:15:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06575 for ; Fri, 7 Nov 2003 04:15:11 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI2i8-0001dw-00 for sip@ietf.org; Fri, 07 Nov 2003 04:15:20 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AI2i7-0001dt-00 for sip@ietf.org; Fri, 07 Nov 2003 04:15:19 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA79FJY00743 for ; Fri, 7 Nov 2003 11:15:19 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Nov 2003 11:15:16 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 7 Nov 2003 11:15:17 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] Re: draft-ietf-sip-congestsafe-02.txt Date: Fri, 7 Nov 2003 11:15:17 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017973A0@esebe019.ntc.nokia.com> Thread-Topic: [Sip] Re: draft-ietf-sip-congestsafe-02.txt Thread-Index: AcOkc3Xu9L6VGBwrTlWM+SaGE05GHwAmyeqg To: , X-OriginalArrivalTime: 07 Nov 2003 09:15:17.0623 (UTC) FILETIME=[A9139070:01C3A50F] Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext > Scott Lawrence > Sent: Thursday, November 06, 2003 4:34 PM > To: sip@ietf.org > Subject: [Sip] Re: draft-ietf-sip-congestsafe-02.txt >=20 > UAC Proxy Proxy Proxy UAC > A -----> B --------> C ------> D ------> E >=20 > UAC A sends an INVITE to E with 'Proxy-Require: congestion-managed', > initially handing it off to Proxy B. Using normal SIP routing > mechanisms, that message finds itself in due course at Proxy D > (the local proxy on E's network). The administrator of that > network has (for whatever reason) chosen to configure SIP on that > network to prefer (or even be limited to) UDP. This potential > conflict raises two questions: >=20 > - Why should a user elsewhere in the network (A) be empowered to > exercise any control of routing policy within the local network > (E's network)? >=20 > - Why would A want to send a request using this mechanism, given > that doing so introduces a new potential failure mode, but does > not improve that chances that this individual request will > succeed? Actually, Proxy D uses the transport protocol that E has indicated in = its contact-header of REGISTER. REGISTER ... Contact: This forces D to forward the message to E using TCP. Proxies B, C, and D can have NAPTR entries without a udp option. Eg of B network NSPTR records (no UDP option): ; order pref flags service regexp replacement IN NAPTR 50 50 "s" "SIPS+D2T" "" = _sips._tcp.domain1.com. IN NAPTR 90 50 "s" "SIP+D2T" "" = _sip._tcp.domain1.com It is true that is a collected effort in that all domains have to = configure their networks as above. This is the BCP I would propose. Regards, Hisham _______________________________________________ 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 exim@www1.ietf.org Fri Nov 7 08:43:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14023 for ; Fri, 7 Nov 2003 08:43:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI6tL-0006NJ-3l for sip-archive@odin.ietf.org; Fri, 07 Nov 2003 08:43:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7DhBlt024506 for sip-archive@odin.ietf.org; Fri, 7 Nov 2003 08:43:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI6tB-0006MH-Bw; Fri, 07 Nov 2003 08:43:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI6st-0006M1-84 for sip@optimus.ietf.org; Fri, 07 Nov 2003 08:42:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13998 for ; Fri, 7 Nov 2003 08:42:32 -0500 (EST) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI6sr-00055L-00 for sip@ietf.org; Fri, 07 Nov 2003 08:42:41 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AI6sq-00055I-00 for sip@ietf.org; Fri, 07 Nov 2003 08:42:41 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hA7Dgde29447 for ; Fri, 7 Nov 2003 15:42:39 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 7 Nov 2003 15:42:39 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Nov 2003 15:42:38 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6139); Fri, 7 Nov 2003 15:42:38 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Consensus on direction needed (was Re: [Sip] Re:draft-ietf-sip-congestsafe-02.txt)] Date: Fri, 7 Nov 2003 15:42:37 +0200 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D592A8@esebe013.ntc.nokia.com> Thread-Topic: Consensus on direction needed (was Re: [Sip] Re:draft-ietf-sip-congestsafe-02.txt)] Thread-Index: AcOkqp8MZgblXq2YRZW45eg76iQ/4gAhGQMA To: , , X-OriginalArrivalTime: 07 Nov 2003 13:42:38.0693 (UTC) FILETIME=[024C9950:01C3A535] Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Dean, Inline. > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext > Dean Willis > Sent: 06 November, 2003 23:11 > To: sip@ietf.org; slawrence@pingtel.com > Subject: Consensus on direction needed (was Re: [Sip] > Re:draft-ietf-sip-congestsafe-02.txt)] >=20 >=20 >=20 > On Thu, 2003-11-06 at 08:34, Scott Lawrence wrote: > > This draft presents an excellent explanation of how and why the > > use of UDP in SIP can (and therefor by Murphys Law, will=20 > :-) cause > > network operation problems. In doing so, it makes a=20 > good case for > > SIP having been designed differently, possibly not using UDP at > > all, but acknowleges that it is too late for that. It goes on to > > propose mechanisms by which this oversight can now be=20 > corrected by > > defining a congestion-safe mode of operation and adding=20 > a protocol > > feature to require operation in that mode. >=20 > > Unfortunately, I don't think that creating such a mechanism is > > useful, because there is little or no incentive for any > > significant number of systems to use it. The cat is not only out > > of the bag in that SIP was designed to support UDP, but later > > standards (SIP use of NAPTR and DNSSRV in RFC 3263) have provided > > for explicit administrative control mechanisms by which users > > (administrators) can (perhaps unwisely) prefer the use of UDP. >=20 > . . .=20 >=20 > Excellent summary and commentary. >=20 > Here's the deal. Before long, EVERY e2e-secured SIP request=20 > or response > is going to be bigger than one packet. The security people=20 > aren't going > to give up on e2e. >=20 > This gives us two viable alternatives, as I see them: >=20 > 1) Deprecate UDP usage in SIP. >=20 > 2) Deprecate SIP. >=20 > Since #2 would leave me unemployed :-(, the question I'm=20 > interested is > how to do #1. >=20 > Three possibilities suggest themselves, and I'd like to get=20 > a sense of > consensus from the group on the direction (or other suggestions, if > there are any). >=20 > 1) Leave the UDP stuff in place, but convince people not to use it by > doing a "UDP Considered Harmful for SIP" BCP, (which Scott=20 > seems to be > suggesting).=20 Which UDP stuff? My recollection of this problem and how this work on congest-safe came = about in the first place is mainly that in RFC 3428, there are strict = size limits for sending a message. These limits can be circumvented only = by knowledge that the entire path that the message takes uses TCP (or = other congestion controlled transport). Currently, there is no other way = to know this, except by administration, and that only works in closed = environments.=20 The problem that lead to this restriction as I remember it is that per = RFC 3261 Ch 18.1.1., in the SIP transport layer, if the size of a = message exceeds path MTU (or 1300 bytes when the path MTU for the next = hop is unknown) the request MUST always be sent using TCP or similar = congestion controlled protocol. But, there is an unfortunate exception = to this rule in taking into consideration backwards compatibility with = RFC 2543 implementations - if the TCP connection fails or is not there, = the request may be retried using UDP. I think what we really want to do is deprecate *this* behavior. =20 > 2) Leave the UDP stuff in place, but give people tools to=20 > keep it from > being used (which this draft suggests). Assuming the above is the "UDP stuff" then I agree. However, I agree = that documenting the congestion problems in SIP in general is a good = idea, and a BCP therefore makes sense as suggested in 1). =20 =20 > 3) Rev the spec to 3.0 and rip UDP out by the toenails. Well... ;) > Any other ideas? What is the right thing to do here? I think we should separate these two things here. First, we have the = general congestion-safetyness of SIP to worry about, and as people have = already pointed out, a BCP discussing the options in mitigating those = concerns is a good idea.=20 Secondly, we have the harmful "if-TCP-fails-then-fall-back-to-UDP" = behavior, which we want to deprecate and in the mean time hack a fix = around it. Cheers, Aki > -- > Dean >=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 From exim@www1.ietf.org Fri Nov 7 09:51:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16203 for ; Fri, 7 Nov 2003 09:51:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI7xC-00013n-T0 for sip-archive@odin.ietf.org; Fri, 07 Nov 2003 09:51:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7EpEgb004015 for sip-archive@odin.ietf.org; Fri, 7 Nov 2003 09:51:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI7x0-00011z-9m; Fri, 07 Nov 2003 09:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AI7wg-00010n-Ud for sip@optimus.ietf.org; Fri, 07 Nov 2003 09:50:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16158 for ; Fri, 7 Nov 2003 09:50:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AI7we-0005xF-00 for sip@ietf.org; Fri, 07 Nov 2003 09:50:40 -0500 Received: from [65.220.123.3] (helo=mail.pingtel.com) by ietf-mx with esmtp (Exim 4.12) id 1AI7we-0005xC-00 for sip@ietf.org; Fri, 07 Nov 2003 09:50:40 -0500 Received: from kathmandu.pingtel.com (kathmandu.pingtel.com [10.1.1.252]) by mail.pingtel.com (8.11.6/8.11.6) with ESMTP id hA7Eod324400; Fri, 7 Nov 2003 09:50:39 -0500 To: Cc: , , References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D592A8@esebe013.ntc.nokia.com> Organization: Pingtel Corp. http://www.pingtel.com/ From: Scott Lawrence Date: Fri, 07 Nov 2003 09:50:39 -0500 In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D592A8@esebe013.ntc.nokia.com> (aki niemi's message of "Fri, 7 Nov 2003 15:42:37 +0200") Message-ID: User-Agent: Gnus/5.1001 (Gnus v5.10.1) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Sip] Re: Consensus on direction needed Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , writes: > Secondly, we have the harmful "if-TCP-fails-then-fall-back-to-UDP" > behavior, which we want to deprecate and in the mean time hack a fix > around it. but it isn't just that - we have placed the control of which transport is used _explicitly_ in the hands of the user. Having done that, our only recourse now as vendors is to make the TCP alternative more attractive to them than UDP. -- Scott Lawrence Pingtel Corp. _______________________________________________ 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 exim@www1.ietf.org Fri Nov 7 13:52:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29149 for ; Fri, 7 Nov 2003 13:52:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBiM-0007hE-GS for sip-archive@odin.ietf.org; Fri, 07 Nov 2003 13:52:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7IqAaC029577 for sip-archive@odin.ietf.org; Fri, 7 Nov 2003 13:52:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBiE-0007g9-D6; Fri, 07 Nov 2003 13:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIBhp-0007eY-HD for sip@optimus.ietf.org; Fri, 07 Nov 2003 13:51:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29110 for ; Fri, 7 Nov 2003 13:51:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIBhn-0001EM-00 for sip@ietf.org; Fri, 07 Nov 2003 13:51:35 -0500 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AIBhm-0001Dz-00 for sip@ietf.org; Fri, 07 Nov 2003 13:51:34 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hA7IoxR29823; Fri, 7 Nov 2003 12:51:00 -0600 (CST) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id hA7Iow200880; Fri, 7 Nov 2003 12:50:59 -0600 (CST) Message-ID: <3FABE98C.90508@lucent.com> Date: Fri, 07 Nov 2003 12:50:52 -0600 From: "Vijay K. Gurbani" Organization: Wireless Networks Research and Development User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: sip@ietf.org Subject: Re: Consensus on direction needed (was Re: [Sip] Re: draft-ietf-sip-congestsafe-02.txt)] References: <1068153082.8295.59.camel@bdsl.greycouncil.com> In-Reply-To: <1068153082.8295.59.camel@bdsl.greycouncil.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dean Willis wrote: > This gives us two viable alternatives, as I see them: > > 1) Deprecate UDP usage in SIP. > > 2) Deprecate SIP. Deprecate SIP!! What'choo talkin' about, Willis? (Sorry, always wanted to say that :-) ) > Three possibilities suggest themselves > > 1) Leave the UDP stuff in place, but convince people not to use it by > doing a "UDP Considered Harmful for SIP" BCP, (which Scott seems to be > suggesting). > > 2) Leave the UDP stuff in place, but give people tools to keep it from > being used (which this draft suggests). > > 3) Rev the spec to 3.0 and rip UDP out by the toenails. If we rev the spec to 3.0, can we guarantee that the only change in SIP/3.0 will be UDP removal? What if someone wants to take this opportunity to put other behavior in the spec? Do we run the risk of ending up with a protocol that does not quite resemble SIP/2.0. I do not know what the criteria of IESG is to rev up a protocol version. The only instance of this happening that I am actively aware of is the rev from HTTP/1.0 to HTTP/1.1. But in that particular instance, backward compatibility was preserved, I believe. I think it may be too late to deprecating UDP completely; so much deployed gear uses it. I have also witnessed many >>new<< SIP implementations start out with only supporting UDP with the (mistaken) belief that it will be easier to code. > Any other ideas? What is the right thing to do here? I like Aki's idea of selectively deprecating UDP-related backwards compatibility issues in rfc3261 which haunt us at this point, but still maintain UDP as a transport (albeit not endorse it as the preferred transport, which it was in rfc2543). Cheers, - 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 exim@www1.ietf.org Fri Nov 7 14:30:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03104 for ; Fri, 7 Nov 2003 14:30:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICJ5-0001lh-SZ for sip-archive@odin.ietf.org; Fri, 07 Nov 2003 14:30:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7JU7Lk006791 for sip-archive@odin.ietf.org; Fri, 7 Nov 2003 14:30:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICJ1-0001kV-Qz; Fri, 07 Nov 2003 14:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICIN-0001Xd-2G for sip@optimus.ietf.org; Fri, 07 Nov 2003 14:29:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02989 for ; Fri, 7 Nov 2003 14:29:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AICIK-0001kQ-00 for sip@ietf.org; Fri, 07 Nov 2003 14:29:20 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AICIJ-0001k3-00 for sip@ietf.org; Fri, 07 Nov 2003 14:29:20 -0500 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hA7JShmU028247; Fri, 7 Nov 2003 11:28:43 -0800 (PST) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJT45073; Fri, 7 Nov 2003 11:28:38 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Fri, 07 Nov 2003 11:28:34 -0800 From: Cullen Jennings To: , Jonathan Rosenberg CC: Paul Kyzivat Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] GRUU, Contacts, and privacy Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit When making anonymous calls, the contact should change on every call. For example of if you don't do this ... Bill makes an anonymous call from Monika's phone to Hillary. Hillary, takes the call, is suppositious about the location and makes note of the contact. Now Hillary calls Monika and notes the contact. If the two contacts are the same, the privacy of the original call is lost and Hillary knows the original call was from Monika's phone. Unfortunately, it looks like the grid approach still reveals this information - the grid on the two calls might be different but the core GRUU is still the same. I have a hard time imagining a simple solution that allowed the UA to generate the GRUUs and still have fast lookup for the proxy. It seems like a way is needed for the UA to get many GRUU that it can use and that these need to be anonymous and uncorelatable by third parties. One possible solution for this is to send another Register after each call to get a new GRUU that can be used. This would drive the text to change so that re-registrations must result in a new GRUU - the current encryption mechanism with salt would meet this. Presumable, the old GRUU's would continue to work and be good as long as the contact that generated it was still valid. 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 exim@www1.ietf.org Fri Nov 7 14:39:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03476 for ; Fri, 7 Nov 2003 14:39:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICRp-0002uQ-RQ for sip-archive@odin.ietf.org; Fri, 07 Nov 2003 14:39:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7Jd9U1011122 for sip-archive@odin.ietf.org; Fri, 7 Nov 2003 14:39:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICRh-0002sY-Sr; Fri, 07 Nov 2003 14:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AICR7-0002rg-D4 for sip@optimus.ietf.org; Fri, 07 Nov 2003 14:38:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03440 for ; Fri, 7 Nov 2003 14:38:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AICR4-0001to-00 for sip@ietf.org; Fri, 07 Nov 2003 14:38:22 -0500 Received: from h-135-207-24-32.research.att.com ([135.207.24.32] helo=mailman.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 1AICR4-0001tX-00 for sip@ietf.org; Fri, 07 Nov 2003 14:38:22 -0500 Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71]) by mailman.research.att.com (8.12.8/8.12.8) with ESMTP id hA7KUvuF015207 for ; Fri, 7 Nov 2003 15:30:57 -0500 Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by unixmail.research.att.com (8.12.8+Sun/8.8.7) with ESMTP id hA7JZHZn016523; Fri, 7 Nov 2003 14:35:17 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id OAA47229; Fri, 7 Nov 2003 14:37:47 -0500 (EST) Date: Fri, 7 Nov 2003 14:37:47 -0500 (EST) Message-Id: <200311071937.OAA47229@fish.research.att.com> To: sip@ietf.org Subject: RE: Consensus on direction needed (was Re: [Sip] Re: draft-ietf-sip-congestsafe-02.txt)] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Dean wrote: > > Three possibilities suggest themselves, and I'd like to get a sense of > consensus from the group on the direction (or other suggestions, if > there are any). > > 1) Leave the UDP stuff in place, but convince people not to use it by > doing a "UDP Considered Harmful for SIP" BCP, (which Scott seems to be > suggesting). > > 2) Leave the UDP stuff in place, but give people tools to keep it from > being used (which this draft suggests). > > 3) Rev the spec to 3.0 and rip UDP out by the toenails. > > Any other ideas? What is the right thing to do here? I think there are really two cases here: case #1 between the UA and its first proxy (where there is very little signaling traffic), and case #2 between proxies (where there is lots more traffic). In case #1: one major problem is the impact TCP has on post-dial delay. While it certainly can be fixed by a custom TCP stack in the UA, this doesn't generally seem to be happening. Lacking this, UDP is left as the preferred solution here. Can such modified parameters for TCP be suggested in a BCP? In case #2: one problem is the impact TCP has due to head-of-line blocking. This can be fixed with SCTP. A BCP recommending this would be good. So it seems the best solution is a variation of #1, "UDP Considered Harmful between SIP Proxies". Another idea, not that I expect much traction. If a protocol is to "ripped out by its toenails", how about TCP? It seems to be stuck in the middle, not perfect for either case. Bill Marshall wtm@research.att.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 exim@www1.ietf.org Fri Nov 7 16:28:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08562 for ; Fri, 7 Nov 2003 16:28:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE9P-0002Gu-0O for sip-archive@odin.ietf.org; Fri, 07 Nov 2003 16:28:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7LSESa008672 for sip-archive@odin.ietf.org; Fri, 7 Nov 2003 16:28:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE9C-0002F4-6M; Fri, 07 Nov 2003 16:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIE94-0002ES-3f for sip@optimus.ietf.org; Fri, 07 Nov 2003 16:27:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08523 for ; Fri, 7 Nov 2003 16:27:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIE92-0003Dz-00 for sip@ietf.org; Fri, 07 Nov 2003 16:27:52 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1AIE91-0003Dw-00 for sip@ietf.org; Fri, 07 Nov 2003 16:27:51 -0500 Received: from txdwillis (bdsl.66.12.12.254.gte.net [66.12.12.254]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id hA7LSQv3014601 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 7 Nov 2003 15:28:27 -0600 From: "Dean Willis" To: "'William Marshall'" , Subject: RE: Consensus on direction needed (was Re: [Sip] Re: draft-ietf-sip-congestsafe-02.txt)] Date: Fri, 7 Nov 2003 15:27:34 -0600 Message-ID: <00ae01c3a575$f5da7fc0$e1036e3f@txdwillis> 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.4510 In-Reply-To: <200311071937.OAA47229@fish.research.att.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Bill said: > I think there are really two cases here: case #1 between the > UA and its first proxy (where there is very little signaling > traffic), and case #2 between proxies (where there is lots > more traffic). > > In case #1: one major problem is the impact TCP has on post-dial > delay. While it certainly can be fixed by a custom TCP stack > in the UA, this doesn't generally seem to be happening. > Lacking this, > UDP is left as the preferred solution here. Can such > modified parameters for TCP be suggested in a BCP? Isn't this pretty much resolved by connection-reuse and a persistent TCP connection between UA and proxy? This seems to be even sweeter if TLS is also used. > In case #2: one problem is the impact TCP has due to head-of-line > blocking. This can be fixed with SCTP. A BCP recommending > this would be good. Good point. Would it be adequate to put this discussion into the SIP-SCTP doc, http://www.softarmor.com/wgdb/docs/draft-ietf-sip-sctp-03.txt Bill also said: > So it seems the best solution is a variation of #1, "UDP > Considered Harmful between SIP Proxies". > > Another idea, not that I expect much traction. > If a protocol is to "ripped out by its toenails", how about TCP? > It seems to be stuck in the middle, not perfect for either case. There's also DCCP to consider. -- 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 exim@www1.ietf.org Fri Nov 7 16:56:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09642 for ; Fri, 7 Nov 2003 16:56:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEaY-00046B-5P for sip-archive@odin.ietf.org; Fri, 07 Nov 2003 16:56:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7LuIin015695 for sip-archive@odin.ietf.org; Fri, 7 Nov 2003 16:56:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEaI-000449-2N; Fri, 07 Nov 2003 16:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEZg-00043Z-Nd for sip@optimus.ietf.org; Fri, 07 Nov 2003 16:55:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09627 for ; Fri, 7 Nov 2003 16:55:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIEZe-0003bb-00 for sip@ietf.org; Fri, 07 Nov 2003 16:55:22 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AIEZd-0003bY-00 for sip@ietf.org; Fri, 07 Nov 2003 16:55:21 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hA7LtGhL018888; Fri, 7 Nov 2003 16:55:16 -0500 (EST) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hA7LtFg18278; Fri, 7 Nov 2003 16:55:16 -0500 Message-ID: <3FAC14C3.9020407@cs.columbia.edu> Date: Fri, 07 Nov 2003 16:55:15 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: "'William Marshall'" , sip@ietf.org Subject: Re: Consensus on direction needed (was Re: [Sip] Re: draft-ietf-sip-congestsafe-02.txt)] References: <00ae01c3a575$f5da7fc0$e1036e3f@txdwillis> In-Reply-To: <00ae01c3a575$f5da7fc0$e1036e3f@txdwillis> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit >>In case #2: one problem is the impact TCP has due to head-of-line >>blocking. This can be fixed with SCTP. A BCP recommending >>this would be good. > > > Good point. Would it be adequate to put this discussion into the SIP-SCTP > doc, > > http://www.softarmor.com/wgdb/docs/draft-ietf-sip-sctp-03.txt > Obligatory discussion reminder: From previous discussions, sometimes people assume that SCTP fixes head-of-line blocking if there is a slower downstream system for one session. It does not. There seem to be actually very few places in SIP-style systems where SCTP head-of-line blocking avoidance matters. _______________________________________________ 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 exim@www1.ietf.org Fri Nov 7 16:58:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09727 for ; Fri, 7 Nov 2003 16:58:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEcG-0004K5-38 for sip-archive@odin.ietf.org; Fri, 07 Nov 2003 16:58:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7Lw4tT016583 for sip-archive@odin.ietf.org; Fri, 7 Nov 2003 16:58:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEcE-0004Iw-Ad; Fri, 07 Nov 2003 16:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEbv-0004Ec-0L for sip@optimus.ietf.org; Fri, 07 Nov 2003 16:57:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09688 for ; Fri, 7 Nov 2003 16:57:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIEbs-0003dM-00 for sip@ietf.org; Fri, 07 Nov 2003 16:57:40 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AIEbr-0003cf-00 for sip@ietf.org; Fri, 07 Nov 2003 16:57:39 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hA7Lv3w10123; Fri, 7 Nov 2003 15:57:04 -0600 (CST) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id hA7Lv3216461; Fri, 7 Nov 2003 15:57:03 -0600 (CST) Message-ID: <3FAC1528.1080409@lucent.com> Date: Fri, 07 Nov 2003 15:56:56 -0600 From: "Vijay K. Gurbani" Organization: Wireless Networks Research and Development User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dean Willis CC: sip@ietf.org, "Jain, Rajnish" Subject: Re: Consensus on direction needed (was Re: [Sip] Re: draft-ietf-sip-congestsafe-02.txt)] References: <00ae01c3a575$f5da7fc0$e1036e3f@txdwillis> In-Reply-To: <00ae01c3a575$f5da7fc0$e1036e3f@txdwillis> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Dean Willis wrote: >>In case #1: one major problem is the impact TCP has on post-dial >>delay. While it certainly can be fixed by a custom TCP stack >>in the UA, this doesn't generally seem to be happening. >>Lacking this, >>UDP is left as the preferred solution here. Can such >>modified parameters for TCP be suggested in a BCP? > > Isn't this pretty much resolved by connection-reuse and a persistent TCP > connection between UA and proxy? This seems to be even sweeter if TLS is > also used. Problem is that the spec is vague on reusing TCP connections. Rohan has an I-D on connection resue and I had presented one at the Atlanta IETF that extended that paradigm to longer lived connections (i.e. beyond the dialog). Let me see -- the I-D is still in the archives: http://www.ietf.org/internet-drafts/draft-jain-sipping-persistent-conn-reqs-00.txt If TCP becomes the dominant transport, the specification should probably provide more direction on connection reuse and connection longevity (especially with TLS in the picture). Cheers, - 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 exim@www1.ietf.org Fri Nov 7 17:01:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10053 for ; Fri, 7 Nov 2003 17:01:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEfH-0004qA-7n for sip-archive@odin.ietf.org; Fri, 07 Nov 2003 17:01:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA7M1Bsu018597 for sip-archive@odin.ietf.org; Fri, 7 Nov 2003 17:01:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEfC-0004ni-5a; Fri, 07 Nov 2003 17:01:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIEeW-0004hb-3f for sip@optimus.ietf.org; Fri, 07 Nov 2003 17:00:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09942 for ; Fri, 7 Nov 2003 17:00:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIEeT-0003lV-00 for sip@ietf.org; Fri, 07 Nov 2003 17:00:21 -0500 Received: from h-135-207-24-32.research.att.com ([135.207.24.32] helo=mailman.research.att.com) by ietf-mx with esmtp (Exim 4.12) id 1AIEeT-0003fS-00 for sip@ietf.org; Fri, 07 Nov 2003 17:00:21 -0500 Received: from unixmail.research.att.com (unixmail.research.att.com [135.207.26.71]) by mailman.research.att.com (8.12.8/8.12.8) with ESMTP id hA7MqvuF020684; Fri, 7 Nov 2003 17:52:57 -0500 Received: from fish.research.att.com (fish.research.att.com [135.207.27.137]) by unixmail.research.att.com (8.12.8+Sun/8.8.7) with ESMTP id hA7LvIZn020184; Fri, 7 Nov 2003 16:57:18 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish.research.att.com (SGI-8.9.3/8.8.5) id QAA94539; Fri, 7 Nov 2003 16:57:42 -0500 (EST) Date: Fri, 7 Nov 2003 16:57:42 -0500 (EST) Message-Id: <200311072157.QAA94539@fish.research.att.com> To: dean.willis@softarmor.com, sip@ietf.org Subject: RE: Consensus on direction needed (was Re: [Sip] Re: draft-ietf-sip-congestsafe-02.txt)] Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Dean wrote: > Bill said: > > In case #1: one major problem is the impact TCP has on post-dial > > delay. While it certainly can be fixed by a custom TCP stack > > in the UA, this doesn't generally seem to be happening. > > Lacking this, > > UDP is left as the preferred solution here. Can such > > modified parameters for TCP be suggested in a BCP? > > Isn't this pretty much resolved by connection-reuse and a persistent TCP > connection between UA and proxy? This seems to be even sweeter if TLS is > also used. Persistent connections solves one of the TCP problems, the extra round- trips (SYN-SYNACK-ACK) needed before the INVITE request can be sent. But the other problem is when an INVITE request is dropped by the network due to corruption on the transmission link (far more likely on access links than on backbone connections). TCP will wait for a timeout on the sender before sending a query; that timeout standrad value is too long for telephony-type services. As an aside, the post-dial-delay issue also seems to be forcing IPsec for endpoints over TLS. Bill Marshall wtm@research.att.com -----original message----- From: "Dean Willis" To: "'William Marshall'" , Subject: RE: Consensus on direction needed (was Re: [Sip] Re: draft-ietf-sip-congestsafe-02.txt)] Date: Fri, 7 Nov 2003 15:27:34 -0600 Bill said: > I think there are really two cases here: case #1 between the > UA and its first proxy (where there is very little signaling > traffic), and case #2 between proxies (where there is lots > more traffic). > > In case #1: one major problem is the impact TCP has on post-dial > delay. While it certainly can be fixed by a custom TCP stack > in the UA, this doesn't generally seem to be happening. > Lacking this, > UDP is left as the preferred solution here. Can such > modified parameters for TCP be suggested in a BCP? Isn't this pretty much resolved by connection-reuse and a persistent TCP connection between UA and proxy? This seems to be even sweeter if TLS is also used. > In case #2: one problem is the impact TCP has due to head-of-line > blocking. This can be fixed with SCTP. A BCP recommending > this would be good. Good point. Would it be adequate to put this discussion into the SIP-SCTP doc, http://www.softarmor.com/wgdb/docs/draft-ietf-sip-sctp-03.txt Bill also said: > So it seems the best solution is a variation of #1, "UDP > Considered Harmful between SIP Proxies". > > Another idea, not that I expect much traction. > If a protocol is to "ripped out by its toenails", how about TCP? > It seems to be stuck in the middle, not perfect for either case. There's also DCCP to consider. -- 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 exim@www1.ietf.org Fri Nov 7 22:42:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21127 for ; Fri, 7 Nov 2003 22:42:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIJzM-0004dC-BG for sip-archive@odin.ietf.org; Fri, 07 Nov 2003 22:42:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA83gGYp017798 for sip-archive@odin.ietf.org; Fri, 7 Nov 2003 22:42:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIJz8-0004bw-RO; Fri, 07 Nov 2003 22:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIJz0-0004bh-7d for sip@optimus.ietf.org; Fri, 07 Nov 2003 22:41:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21124 for ; Fri, 7 Nov 2003 22:41:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIJyw-000066-00 for sip@ietf.org; Fri, 07 Nov 2003 22:41:50 -0500 Received: from smtp104.mail.sc5.yahoo.com ([66.163.169.223]) by ietf-mx with smtp (Exim 4.12) id 1AIJyv-000063-00 for sip@ietf.org; Fri, 07 Nov 2003 22:41:50 -0500 Received: from 12-235-146-159.client.attbi.com (HELO cranberry) (seancolson@12.235.146.159 with login) by smtp-v1.mail.vip.sc5.yahoo.com with SMTP; 8 Nov 2003 03:41:44 -0000 Reply-To: From: "Sean Olson" To: "'Cullen Jennings'" , , "'Jonathan Rosenberg'" Cc: "'Paul Kyzivat'" , Subject: RE: [Sip] GRUU, Contacts, and privacy Date: Fri, 7 Nov 2003 19:41:44 -0800 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: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Thread-Index: AcOlZZ69lxoVMhK3Qe+lh3GwkRMxTQAREcgg Message-Id: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I would like to offer the suggestion that while privacy is an interesting and useful property, it is not a necessity for many applications that might otherwise use GRUU. I would go even further and state that is runs counter to some applications that might want to use a globally routable and unique URI. Part of the complexity of the grid approach is this requirement for obfuscation/privacy. If you remove that requirement, it is entirely possible to come up with a simpler solution. -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Cullen Jennings Sent: Friday, November 07, 2003 11:29 AM To: sip@ietf.org; Jonathan Rosenberg Cc: Paul Kyzivat Subject: [Sip] GRUU, Contacts, and privacy When making anonymous calls, the contact should change on every call. For example of if you don't do this ... Bill makes an anonymous call from Monika's phone to Hillary. Hillary, takes the call, is suppositious about the location and makes note of the contact. Now Hillary calls Monika and notes the contact. If the two contacts are the same, the privacy of the original call is lost and Hillary knows the original call was from Monika's phone. Unfortunately, it looks like the grid approach still reveals this information - the grid on the two calls might be different but the core GRUU is still the same. I have a hard time imagining a simple solution that allowed the UA to generate the GRUUs and still have fast lookup for the proxy. It seems like a way is needed for the UA to get many GRUU that it can use and that these need to be anonymous and uncorelatable by third parties. One possible solution for this is to send another Register after each call to get a new GRUU that can be used. This would drive the text to change so that re-registrations must result in a new GRUU - the current encryption mechanism with salt would meet this. Presumable, the old GRUU's would continue to work and be good as long as the contact that generated it was still valid. 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 From exim@www1.ietf.org Sat Nov 8 01:36:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25095 for ; Sat, 8 Nov 2003 01:36:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIMhi-0003GI-1I for sip-archive@odin.ietf.org; Sat, 08 Nov 2003 01:36:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA86aD1J012478 for sip-archive@odin.ietf.org; Sat, 8 Nov 2003 01:36:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIMhW-0003ER-Kx; Sat, 08 Nov 2003 01:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIMhT-0003E0-3D for sip@optimus.ietf.org; Sat, 08 Nov 2003 01:35:59 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25068 for ; Sat, 8 Nov 2003 01:35:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIMhP-00029u-00 for sip@ietf.org; Sat, 08 Nov 2003 01:35:55 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AIMhP-00029p-00 for sip@ietf.org; Sat, 08 Nov 2003 01:35:55 -0500 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA86ZFca013907; Sat, 8 Nov 2003 01:35:16 -0500 (EST) Message-ID: <3FAC8EA2.10604@dynamicsoft.com> Date: Sat, 08 Nov 2003 01:35:14 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: pkyzivat@cisco.com, rsparks@dynamicsoft.com, sip@ietf.org, rohan@cisco.com Subject: Re: [Sip] GRUU Mechanism I-D References: <2038BCC78B1AD641891A0D1AE133DBB701797392@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797392@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > I share Paul's view. There are currently too many implementations > supporting dialog reuse. Well, the issue isn't so much as to whether its been implemented, as to whether it is being used. I would actually be surprised if there was a lot of usage of it, and in particular, interoperable usage of it, given the various problems we have identified with it since publication of rfc3261. Can people comment on any real usage of dialog reuse they are aware of? I suspect REFER on an INVITE dialog is the main (if only) one... Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 exim@www1.ietf.org Sat Nov 8 01:46:07 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25397 for ; Sat, 8 Nov 2003 01:46:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIMqx-000488-Sj for sip-archive@odin.ietf.org; Sat, 08 Nov 2003 01:45:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA86jltT015873 for sip-archive@odin.ietf.org; Sat, 8 Nov 2003 01:45:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIMqF-0003y4-9U; Sat, 08 Nov 2003 01:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIMq1-0003ww-B3 for sip@optimus.ietf.org; Sat, 08 Nov 2003 01:44:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25326 for ; Sat, 8 Nov 2003 01:44:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIMpy-0002Gl-00 for sip@ietf.org; Sat, 08 Nov 2003 01:44:46 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AIMpx-0002GW-00 for sip@ietf.org; Sat, 08 Nov 2003 01:44:45 -0500 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA86i9ca013911; Sat, 8 Nov 2003 01:44:09 -0500 (EST) Message-ID: <3FAC90B7.6000908@dynamicsoft.com> Date: Sat, 08 Nov 2003 01:44:07 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: sip@ietf.org, Paul Kyzivat References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: GRUU, Contacts, and privacy Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > > When making anonymous calls, the contact should change on every call. For > example of if you don't do this ... Bill makes an anonymous call from > Monika's phone to Hillary. Hillary, takes the call, is suppositious about > the location and makes note of the contact. Now Hillary calls Monika and > notes the contact. If the two contacts are the same, the privacy of the > original call is lost and Hillary knows the original call was from Monika's > phone. > > Unfortunately, it looks like the grid approach still reveals this > information - the grid on the two calls might be different but the core GRUU > is still the same. True. > > I have a hard time imagining a simple solution that allowed the UA to > generate the GRUUs and still have fast lookup for the proxy. It seems like a > way is needed for the UA to get many GRUU that it can use and that these > need to be anonymous and uncorelatable by third parties. In my original I-D on this subject, I had postulated the existence of a separate LEASE operation that would allow for explicit requests for a GRUU. It made sense to use this method for cases where allocation of gruus was decoupled from registrations. Here is an example of such a case. GRUUs obtained by a lease may very well require extra state in proxies, but that would be OK - the lease operation could be used under more exceptional circumstances. > > One possible solution for this is to send another Register after each call > to get a new GRUU that can be used. This would drive the text to change so > that re-registrations must result in a new GRUU - the current encryption > mechanism with salt would meet this. Presumable, the old GRUU's would > continue to work and be good as long as the contact that generated it was > still valid. Actually, if you *really* wanted privacy, this would still not be sufficient. The reason is that your domain is still there, for all to see. Indeed, so would the IP address in your media stream. You'd need a real privacy service (as described in rfc3323) which would presumably obscure everything. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 exim@www1.ietf.org Sat Nov 8 02:51:42 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09590 for ; Sat, 8 Nov 2003 02:51:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AINsR-0000bT-2E for sip-archive@odin.ietf.org; Sat, 08 Nov 2003 02:51:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA87pM7j002319 for sip-archive@odin.ietf.org; Sat, 8 Nov 2003 02:51:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AINs6-0000aL-Hg; Sat, 08 Nov 2003 02:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AINrw-0000Zp-DY for sip@optimus.ietf.org; Sat, 08 Nov 2003 02:50:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09567 for ; Sat, 8 Nov 2003 02:50:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AINrs-0003Eg-00 for sip@ietf.org; Sat, 08 Nov 2003 02:50:48 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AINrr-0003EP-00 for sip@ietf.org; Sat, 08 Nov 2003 02:50:48 -0500 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA87oKca013927; Sat, 8 Nov 2003 02:50:20 -0500 (EST) Message-ID: <3FACA03B.2010706@dynamicsoft.com> Date: Sat, 08 Nov 2003 02:50:19 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Lawrence CC: aki.niemi@nokia.com, dean.willis@softarmor.com, sip@ietf.org Subject: Re: [Sip] Re: Consensus on direction needed References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D592A8@esebe013.ntc.nokia.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Scott Lawrence wrote: > writes: > > >>Secondly, we have the harmful "if-TCP-fails-then-fall-back-to-UDP" >>behavior, which we want to deprecate and in the mean time hack a fix >>around it. > > > but it isn't just that - we have placed the control of which transport > is used _explicitly_ in the hands of the user. Having done that, our > only recourse now as vendors is to make the TCP alternative more > attractive to them than UDP. The spec is pretty clear on the behavior for large packets: If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the request MUST be sent using an RFC 2914 [43] congestion controlled transport protocol, such as TCP. this is not leaving it the hands of the user at all. The problem, as Aki has pointed out, is the exception clause in the paragraph that follows. Indeed, I would go so far is to say that this isnt the problem either. Practically speaking, most implementations are rfc3261 compliant by now - or so they say. The issue is that many implementations are rfc3261 compliant, but have chosen not to implement or support tcp. No doubt this is in part due to the perceived complexities of tcp (some of which are real - large scale connection management is hard). There is also the lack of specification on properly doing connection reuse, which we are also addressing. As such, there are really two separate problems here. One is getting people to use tcp, because we think its better. The second is being able to verify, in any particular request, that it really is being sent over congestion controlled transports. Mostly this would be for rfc3428 implementations that want to send a big message. Solving the first problem, is done by a combination of the bcp, along with connection-reuse getting wrapped, as Scott has suggested. Dean's draft addresses the second. I would anticipate that this mechanism would be used infrequently, if ever. Since messaging sessions is getting close to done, that would be our preferred mechanism for large messages anyway. There isn't going to be a SIP/3.0 - certainly not one that isnt backwards compatible. We don't get that kind of luxury in protocol design, not for ones that achieve any amount of success at least. So, since it needs to be backwards compatible anyway, we are right back to where we started from, and thus there is no point in a rev of the spec number. Thanks, Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 exim@www1.ietf.org Sat Nov 8 03:04:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09870 for ; Sat, 8 Nov 2003 03:04:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIO4p-0001Ie-85 for sip-archive@odin.ietf.org; Sat, 08 Nov 2003 03:04:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA884BWE004995 for sip-archive@odin.ietf.org; Sat, 8 Nov 2003 03:04:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIO4h-0001Hd-GZ; Sat, 08 Nov 2003 03:04:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIO4O-0001Fb-1S for sip@optimus.ietf.org; Sat, 08 Nov 2003 03:03:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09831 for ; Sat, 8 Nov 2003 03:03:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIO4J-0003PD-00 for sip@ietf.org; Sat, 08 Nov 2003 03:03:39 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AIO4J-0003Oh-00 for sip@ietf.org; Sat, 08 Nov 2003 03:03:39 -0500 Received: from dynamicsoft.com ([63.113.46.71]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hA883Bca013934; Sat, 8 Nov 2003 03:03:12 -0500 (EST) Message-ID: <3FACA33E.9050709@dynamicsoft.com> Date: Sat, 08 Nov 2003 03:03:10 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vladimir A. Butenko" CC: sip@ietf.org Subject: Re: [Sip] REGISTER requests via NAT References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit See the Path header extension: http://www.ietf.org/rfc/rfc3327.txt -Jonathan R. Vladimir A. Butenko wrote: > Excuse me if this topic has been already discussed, I have not found an > answer in the list archive. > > The situation: an organization with 2 offices, each running its own > NAT'ed network, with a SIP server installed on each NAT gateway. The SIP > servers insert the Record-Route headers for all requests coming to and > from their LANs, and they also do media stream proxing: the Record-Route > mechanism allows user@network1.com to exchange SIP messages and to > establish calls with any user@network2.com. > > Now, the organization decides to register users of these 2 (or more) > networks within one domain, so employees moving back and force between > offices can be addressed by their name, user@company.com. The > company.com SIP registrar is installed, let's say, "outside" both LANs. > > The SIP servers in each office properly redirect the REGISTER requests > to that company.com server. But the Contact: header fields, obviously, > contain the internal LAN addresses of those users. > > As the RFC3261 explicitly specifies that any Record-Route information in > REGISTER requests should be ignored, is there any other, "legal" way to > "attach" the routing information to those requests, so it is stored by > the registrar and all SIP requests made to user@company.com from a > different LAN (coming to the registrar proxy) will be routed correctly? > > Sincerely, > Vladimir > > _______________________________________________ > 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 Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 exim@www1.ietf.org Sat Nov 8 17:36:43 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28729 for ; Sat, 8 Nov 2003 17:36:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIbgu-0001SD-Pp for sip-archive@odin.ietf.org; Sat, 08 Nov 2003 17:36:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hA8MaOxt005531 for sip-archive@odin.ietf.org; Sat, 8 Nov 2003 17:36:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIbgY-0001QF-2z; Sat, 08 Nov 2003 17:36:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AIbgW-0001Po-3f for sip@optimus.ietf.org; Sat, 08 Nov 2003 17:36:00 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28713 for ; Sat, 8 Nov 2003 17:35:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AIbgT-0005sk-00 for sip@ietf.org; Sat, 08 Nov 2003 17:35:57 -0500 Received: from mail.stalker.com ([206.253.23.169]) by ietf-mx with esmtp (Exim 4.12) id 1AIbgT-0005sh-00 for sip@ietf.org; Sat, 08 Nov 2003 17:35:57 -0500 Received: from [64.161.28.83] (account butenko@mail.stalker.com) by mail.stalker.com (CommuniGate Pro WebUser 4.1.6) with HTTP id 27547147; Sat, 08 Nov 2003 14:33:49 -0800 From: "Vladimir A. Butenko" Subject: Re: [Sip] REGISTER requests via NAT To: Jonathan Rosenberg Cc: sip@ietf.org X-Mailer: CommuniGate Pro WebUser Interface v.4.1.6 Date: Sat, 08 Nov 2003 14:33:49 -0800 Message-ID: In-Reply-To: <3FACA33E.9050709@dynamicsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="KOI8-R"; format="flowed" Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit On Sat, 08 Nov 2003 03:03:10 -0500 Jonathan Rosenberg wrote: > See the Path header extension: > http://www.ietf.org/rfc/rfc3327.txt > > -Jonathan R. Thank you very much, that's exactly whay I was looking for. Please forgive my ignorance :-(. Sincerely, Vladimir _______________________________________________ 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 exim@www1.ietf.org Mon Nov 10 08:54:48 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19553 for ; Mon, 10 Nov 2003 08:54:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJCUt-0004r5-OL for sip-archive@odin.ietf.org; Mon, 10 Nov 2003 08:54:31 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAADsMMN018042 for sip-archive@odin.ietf.org; Mon, 10 Nov 2003 08:54:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJCUV-0004P4-Bh; Mon, 10 Nov 2003 08:54:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJCTh-0004NR-Oe for sip@optimus.ietf.org; Mon, 10 Nov 2003 08:53:14 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19359 for ; Mon, 10 Nov 2003 08:53:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJCTg-0004hO-00 for sip@ietf.org; Mon, 10 Nov 2003 08:53:12 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AJCTf-0004gs-01 for sip@ietf.org; Mon, 10 Nov 2003 08:53:12 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 10 Nov 2003 05:58:57 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAADqgAv007599; Mon, 10 Nov 2003 05:52:44 -0800 (PST) Received: from [130.129.142.157] (sjc-vpn1-121.cisco.com [10.21.96.121]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJU61070; Mon, 10 Nov 2003 05:52:41 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sun, 09 Nov 2003 22:46:15 -0800 Subject: Re: Consensus on direction needed (was Re: [Sip] Re: draft-ietf-sip-congestsafe-02.txt)] From: Cullen Jennings To: William Marshall , Dean Willis , Message-ID: In-Reply-To: <200311072157.QAA94539@fish.research.att.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 11/7/03 1:57 PM, "William Marshall" wrote: > As an aside, the post-dial-delay issue also seems to be forcing > IPsec for endpoints over TLS. > I'm curious about this - can you provide some more information and the type of deployments where this is an issue? _______________________________________________ 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 exim@www1.ietf.org Mon Nov 10 08:55:00 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19568 for ; Mon, 10 Nov 2003 08:54:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJCUt-0004r6-OQ for sip-archive@odin.ietf.org; Mon, 10 Nov 2003 08:54:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAADsMwi018405 for sip-archive@odin.ietf.org; Mon, 10 Nov 2003 08:54:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJCUc-0004Uv-55; Mon, 10 Nov 2003 08:54:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJCTm-0004Nk-H7 for sip@optimus.ietf.org; Mon, 10 Nov 2003 08:53:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19368 for ; Mon, 10 Nov 2003 08:53:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJCTl-0004he-00 for sip@ietf.org; Mon, 10 Nov 2003 08:53:17 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AJCTj-0004gt-01 for sip@ietf.org; Mon, 10 Nov 2003 08:53:16 -0500 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAADqfmU028213; Mon, 10 Nov 2003 05:52:41 -0800 (PST) Received: from [130.129.142.157] (sjc-vpn1-121.cisco.com [10.21.96.121]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJU61065; Mon, 10 Nov 2003 05:52:40 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sun, 09 Nov 2003 22:32:18 -0800 Subject: Re: [Sip] Certificates handling in SIP/TLS From: Cullen Jennings To: Johan Bilien , Message-ID: In-Reply-To: <20031106160101.GA19907@via.ecp.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 11/6/03 8:01 AM, "Johan Bilien" wrote: > Hi, > > I have a few questions regarding the certificates handling when using > SIP over TLS: > > . When the mutual authentication isn't used, should the TLS connection > between the proxy and the UA be kept alive after the first > registration ? Yes - and it it goes down, the UA should re-register. If you are behind many types of firewalls or gasp worse yet a NAT, you will have to do this even if you are not using TLS. > Otherwise, how can the proxy contact the client, for > example to forward an incoming INVITE: if the initial connection was > closed, the UA will need a TLS listening connection, thus act as a TLS > server and need a certificate. > > . When using mutual authentication, to which identity should the UA > certificate's CN refer ? To the FQDN of the UA, or to the SIP URI ? It's really the SubjectAltname not the CN that should be used in SIP. This should refer to the same FQDN as the proxy would be trying to connect to - this basically means it needs to assert the hostname portion of of whatever it put in it's contact. This is not really possible if you got your hostname/IP via DHCP like nearly every device that registers does. I view mutual TLS as very useful between proxies and to things like gateways or voice mail servers but not really very practical to most devices where user register. 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 exim@www1.ietf.org Mon Nov 10 11:20:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27768 for ; Mon, 10 Nov 2003 11:20:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEm4-00065F-M6 for sip-archive@odin.ietf.org; Mon, 10 Nov 2003 11:20:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAGKKAG023381 for sip-archive@odin.ietf.org; Mon, 10 Nov 2003 11:20:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJElo-00063q-9Q; Mon, 10 Nov 2003 11:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJEku-00062e-W7 for sip@optimus.ietf.org; Mon, 10 Nov 2003 11:19:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27729 for ; Mon, 10 Nov 2003 11:18:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJEku-0007Bs-00 for sip@ietf.org; Mon, 10 Nov 2003 11:19:08 -0500 Received: from c213-100-38-57.swipnet.se ([213.100.38.57] helo=coruscant.bilien.org) by ietf-mx with esmtp (Exim 4.12) id 1AJEks-0007BT-00 for sip@ietf.org; Mon, 10 Nov 2003 11:19:07 -0500 Received: by coruscant.bilien.org (Postfix, from userid 1000) id 3A45392C79; Mon, 10 Nov 2003 17:20:32 +0100 (CET) Date: Mon, 10 Nov 2003 17:20:32 +0100 From: Johan Bilien To: sip@ietf.org Subject: Re: [Sip] Certificates handling in SIP/TLS Message-ID: <20031110162032.GA29896@via.ecp.fr> References: <20031106160101.GA19907@via.ecp.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , On Sun, Nov 09, 2003, Cullen Jennings wrote: > > . When the mutual authentication isn't used, should the TLS connection > > between the proxy and the UA be kept alive after the first > > registration ? > > Yes - and it it goes down, the UA should re-register. If you are behind many > types of firewalls or gasp worse yet a NAT, you will have to do this even if > you are not using TLS. So the client should check continuously that the connection is up ? And if the connection goes down, and the client does not see it for some reason, the server will not be able to forward the next INVITE messages. In some cases, it is not very convenient to have to maintain a connection alive, for example in case of mobile IP. On the other hand, having the UA being able to handle TLS-server connections would allow to re-establish a closed connection in any case. Using TLS session resumption, re-establishing the connection is very fast. The need for a UA certificate has other motivations (see below). > > . When using mutual authentication, to which identity should the UA > > certificate's CN refer ? To the FQDN of the UA, or to the SIP URI ? > > It's really the SubjectAltname not the CN that should be used in SIP. This > should refer to the same FQDN as the proxy would be trying to connect to - > this basically means it needs to assert the hostname portion of of whatever > it put in it's contact. This is not really possible if you got your > hostname/IP via DHCP like nearly every device that registers does. I view > mutual TLS as very useful between proxies and to things like gateways or > voice mail servers but not really very practical to most devices where user > register. In the case of a UA, having the certificate point to the FQDM doesn't make much sense to me. On the other hand, having a certificate pointing to the SIP URI of the user would allow several interesting things: . Replace the HTTP Digest client-to-proxy authentication with a TLS mutual authentication. . Allow a user to switch from one device to another without having to use different certificates. . Use the same certificate for the signature of a Diffie-Hellman key exchange, in a scheme such a MIKEY [1], and maybe for instant messaging encryption and signature ... In this case, the association user-hostname would still be provided in a secured way through the contact header, in the TLS-encrypted REGISTER. [1] http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-07.txt Best regards, -- Johan Bilien _______________________________________________ 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 exim@www1.ietf.org Mon Nov 10 11:39:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28923 for ; Mon, 10 Nov 2003 11:39:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJF4M-0007tQ-Ci for sip-archive@odin.ietf.org; Mon, 10 Nov 2003 11:39:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAGdEab030334 for sip-archive@odin.ietf.org; Mon, 10 Nov 2003 11:39:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJF4A-0007r7-PG; Mon, 10 Nov 2003 11:39:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJF3Z-0007k3-Ks for sip@optimus.ietf.org; Mon, 10 Nov 2003 11:38:25 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28878 for ; Mon, 10 Nov 2003 11:38:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJF3Y-0007aQ-00 for sip@ietf.org; Mon, 10 Nov 2003 11:38:24 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AJF3X-0007aN-00 for sip@ietf.org; Mon, 10 Nov 2003 11:38:23 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAAGcLc28265 for ; Mon, 10 Nov 2003 18:38:21 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Mon, 10 Nov 2003 18:38:21 +0200 Received: from nokia.com ([10.162.13.26]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Mon, 10 Nov 2003 18:38:19 +0200 Message-ID: <3FAFBEF8.90105@nokia.com> Date: Mon, 10 Nov 2003 18:38:16 +0200 From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "ext hisham.khartabil@nokia.com" CC: sip@ietf.org Subject: Re: [Sip] Comments on sip-publish-01 References: <2038BCC78B1AD641891A0D1AE133DBB701797397@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB701797397@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Nov 2003 16:38:20.0451 (UTC) FILETIME=[0CEA7730:01C3A7A9] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Hisham, Sorry for the delay in answering. Inline- ext hisham.khartabil@nokia.com wrote: > Apologies if some of these comments below have already been made on > the list. There are no major comments. > > - General: - I think a section should be dedicated to etags. This > section would explain how they work. At the moment, it is all over > the place. This is probably a good idea. I will try to address this in the next rev. > - Abstract: - The 1st sentence in the second paragraph repeats what > is said in the first paragraph. Hmm... I don't quite see how, but perhaps you can suggest a better wording? > - Section 1: - The 1st sentence in the 3rd paragraph repeats what is > said in the first paragraph. I think it is sort of elaborating on the text in the 1st paragraph, but I will change it if you can suggest some better wording. > - Section 3: - Second paragraph repeats definitions section. Maybe > this paragraph can go away and references added to definitions > section. True. How about this: I remove references to presence from the definitions and that way chapter 3 adds value in describing how these components relate to presence. > - Section 4.3: - Why is it a MUST for the content-type to provide > partial publication? I think MAY is enough Ben commented this before, and this is mainly a presence related thing anyway. Some event packages may have no use for such a thing. I'll try to reword this so that what is meant here is more in terms of allowing more than one EPA at a time. Then, if that is the case, the content-type may also need to support this explicitly. > - Section 5: - The note: Why would a PUBLISH fork? If would only fork > if the user has explicitly registered 2 different addresses or the > proxy is configured with 2 ESCs. In any case, I don't get why the > PUBLISH may not be appropriately presented. I think this note can go > away. - PUBLISH does not create a dialog. Can we have some text here > why this is so. I just to remind us in 2 years time when we start > asking the question again. - Why is it explicitly forbidden for a > PUBLISH to contain a contact. It could be as simple as saying that > the ESC ignores the contact header. This note is about an OPTIONS forking, in which case the 200 OK may not be from an ESC, and thus lack support for the PUBLISH method. > - Section 5.2: - Request-URI should be used instead of To-header Correct, I missed this while editing. > - It > should be clarified that an etag associates an EPA with the ESC for > that boot cycle or until the EPA removes a publication (or something > like that) and does not change for that duration. (I was momentarily > confused and thought that the etag changes with every PUBLISH from > the same EPA). - I think I understand the etag mechanism, but is > there a chance that a state already exists for a EPA before that > initial PUBLISH (a crash and reboot or something). How does the ESC > behave in this case? Does the ESC know it is the same ESC publishing > and therefore should remove the state that was created before this > new PUBLISH? The ESC would not know, and would instead assign a new etag and treat this as an initial publication. The original publication would simply expire and be garbage-collected. The etags are just receipts for the EPA on a given publication. Modifying, refreshing or removing that state is only possible upon presenting this receipt to the ESC. I gather this sort of text needs to be in that chapter explaining the etags usage a bit closer. > - Section 5.4 and 5.5: - "the 200 (OK) response to a PUBLISH request > from the ESC contains ..." appears a few times. This confused me into > thinking that you are talking about the 200 of the > refresh/modification PUBLISH. I think you mean the "previous" > PUBLISH. Right. I need to clarify those passages a bit. > - Section 5.5: - The note should be normative text. It ought to be - in Chapter 6 which describes the ESC behavior. > - Section 5.6 - "EPAs which support the PUBLISH method SHOULD support > this mechanism for explicitly removing event state." Should the > SHOULD be a MUST? You're right. This is a MUST. Thanks for the comments! Cheers, Aki > Regards, Hisham > _______________________________________________ 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 exim@www1.ietf.org Mon Nov 10 12:11:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00814 for ; Mon, 10 Nov 2003 12:11:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFZH-0002i8-9J for sip-archive@odin.ietf.org; Mon, 10 Nov 2003 12:11:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAHBB1T010359 for sip-archive@odin.ietf.org; Mon, 10 Nov 2003 12:11:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFZ8-0002fp-Vt; Mon, 10 Nov 2003 12:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFYv-0002f1-1u for sip@optimus.ietf.org; Mon, 10 Nov 2003 12:10:49 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00738 for ; Mon, 10 Nov 2003 12:10:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJFYt-0000RV-00 for sip@ietf.org; Mon, 10 Nov 2003 12:10:47 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1AJFYt-0000RS-00 for sip@ietf.org; Mon, 10 Nov 2003 12:10:47 -0500 Received: from txdwillis (dyn077-227.ietf58.ietf.org [130.129.77.227]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id hAAHBZv3001759 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 10 Nov 2003 11:11:36 -0600 From: "Dean Willis" To: Date: Mon, 10 Nov 2003 11:10:20 -0600 Message-ID: <001c01c3a7ad$85e31b20$e34d8182@txdwillis> 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.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [Sip] Slides for SIP meeting at IETF 58 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'll be posting the slides for our meeting at http://www.softarmor.com/sipwg/meets/ietf58/slides/ If you're using slides in the meeting, please send them to me -- preferably IN ADVANCE so that remote participants can download the materials. In any case, get them to me by the end of the week if you want them in the proceedings. -- 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 exim@www1.ietf.org Mon Nov 10 12:33:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02245 for ; Mon, 10 Nov 2003 12:33:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFuZ-0003os-VM for sip-archive@odin.ietf.org; Mon, 10 Nov 2003 12:33:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAHXBa6014681 for sip-archive@odin.ietf.org; Mon, 10 Nov 2003 12:33:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFuP-0003nz-I2; Mon, 10 Nov 2003 12:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJFtc-0003mp-NK for sip@optimus.ietf.org; Mon, 10 Nov 2003 12:32:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02200 for ; Mon, 10 Nov 2003 12:31:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJFtb-0000xT-00 for sip@ietf.org; Mon, 10 Nov 2003 12:32:11 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AJFta-0000w1-00 for sip@ietf.org; Mon, 10 Nov 2003 12:32:10 -0500 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAAHVcmU007692; Mon, 10 Nov 2003 09:31:38 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANK40197; Mon, 10 Nov 2003 09:31:37 -0800 (PST) Date: Mon, 10 Nov 2003 09:31:39 -0800 Subject: Re: [Sip] Comments on history-info Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "SIP List (E-mail)" To: "Eric Burger" From: Rohan Mahy In-Reply-To: <4A3384433CE2AB46A63468CB207E209D4F691D@zoe.office.snowshore.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thursday, November 6, 2003, at 01:44 AM, Eric Burger wrote: > Big question: > Why don't we use multiple History-Info headers, instead of a > (potentially VERY long) single header? Hey Eric, These are semantically equivalent and implementations are supposed to support receiving BOTH syntaxes. Just like: Supported: 100rel, timer, replaces is equivalent to Supported: 100rel Supported: timer Supported: replaces AND Via: SIP/2.0/TCP sip1.example.com, SIP/2.0/TCP sip2.example.com, SIP/2.0/TCP sip3.example.com is equivalent to Via: SIP/2.0/TCP sip1.example.com Via: SIP/2.0/TCP sip2.example.com Via: SIP/2.0/TCP sip3.example.com (branches omitted for clarity) Bottom Line: The draft is using the correct BNF. thanks, -rohan > I would argue for multiple headers on two grounds. > > First, the idea of a proxy modifying history information doesn't sound > smart. If it screws up, it is hard to figure out who screwed up. > > Second, the index parameter frees us from worrying about header order, > which is a VERY good thing. > > > > Overview: > While the motivation for History-Info is for the initiator of a > request to know what happened to a request, it is also of great use to > the recipient (End of Section 2 overview paragraph). > > Section 1.2: > How is History-Info any different than Via w.r.t. security? > > > > Nits: > Section 2.5, first paragraph, last sentence: > this would like be a local > this would likely be a local > ^^ > > Appendix B, message F8, extra space before last angle-bracket in the > History-Info line. > > > _______________________________________________ > 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 exim@www1.ietf.org Mon Nov 10 14:33:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07658 for ; Mon, 10 Nov 2003 14:33:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJHmm-0002wg-V1 for sip-archive@odin.ietf.org; Mon, 10 Nov 2003 14:33:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAAJXGVk011262 for sip-archive@odin.ietf.org; Mon, 10 Nov 2003 14:33:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJHmX-0002uO-Sk; Mon, 10 Nov 2003 14:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJHm8-0002tO-64 for sip@optimus.ietf.org; Mon, 10 Nov 2003 14:32:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07529 for ; Mon, 10 Nov 2003 14:32:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJHm5-0002vg-00 for sip@ietf.org; Mon, 10 Nov 2003 14:32:33 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1AJHm4-0002vd-00 for sip@ietf.org; Mon, 10 Nov 2003 14:32:32 -0500 Received: from txdwillis (dyn141-154.ietf58.ietf.org [130.129.141.154]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id hAAJXGv3002191 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 10 Nov 2003 13:33:23 -0600 From: "Dean Willis" To: Date: Mon, 10 Nov 2003 13:32:01 -0600 Message-ID: <000001c3a7c1$54842920$9a8d8182@txdwillis> 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.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [Sip] Reading List Addition for IETF 58 meeting, supplementary docs for Request History Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I've been asked to add two relevant documents to the reading list for the Request History discussion. The amended agenda item is below. 1345 Request History Mary Barnes draft-ietf-sip-history-info-01 draft-jennings-sip-voicemail-uri-00.txt RFC 3087 -- 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 exim@www1.ietf.org Mon Nov 10 18:29:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22311 for ; Mon, 10 Nov 2003 18:29:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJLT6-0006AD-Bn for sip-archive@odin.ietf.org; Mon, 10 Nov 2003 18:29:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAANTC9N023689 for sip-archive@odin.ietf.org; Mon, 10 Nov 2003 18:29:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJLSx-00067p-ND; Mon, 10 Nov 2003 18:29:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJLSU-00064e-7e for sip@optimus.ietf.org; Mon, 10 Nov 2003 18:28:34 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22261 for ; Mon, 10 Nov 2003 18:28:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJLSQ-0007LO-00 for sip@ietf.org; Mon, 10 Nov 2003 18:28:30 -0500 Received: from goalie.snowshore.com ([216.57.133.4] helo=webshield.office.snowshore.com) by ietf-mx with smtp (Exim 4.12) id 1AJLSQ-0007KN-00 for sip@ietf.org; Mon, 10 Nov 2003 18:28:30 -0500 Received: from zoe.office.snowshore.com(192.168.1.172) by webshield.office.snowshore.com via csmap id 21642; Mon, 10 Nov 2003 18:34:55 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.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 history-info Date: Mon, 10 Nov 2003 18:27:59 -0500 Message-ID: <4A3384433CE2AB46A63468CB207E209D4F6981@zoe.office.snowshore.com> Thread-Topic: [Sip] Comments on history-info Thread-Index: AcOnsIEVSdJ5kcVgRCqNZzYScVDncwALJ6qQ From: "Eric Burger" To: "Rohan Mahy" Cc: "SIP List (E-mail)" Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Whoops! I should have looked closer at the ABNF. Maybe we should include an example that has multiple lines. Otherwise, = we KNOW people will look at the examples, think everything has to go on = a single line, and then barf when a fully conformant UA sends a response = with multiple lines. > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Mon, November 10, 2003 12:32 PM > To: Eric Burger > Cc: SIP List (E-mail) > Subject: Re: [Sip] Comments on history-info >=20 >=20 > On Thursday, November 6, 2003, at 01:44 AM, Eric Burger wrote: > > Big question: > > Why don't we use multiple History-Info headers, instead of a=20 > > (potentially VERY long) single header? >=20 > Hey Eric, >=20 > These are semantically equivalent and implementations are supposed to=20 > support receiving BOTH syntaxes. >=20 > Just like: >=20 > Supported: 100rel, timer, replaces >=20 > is equivalent to >=20 > Supported: 100rel > Supported: timer > Supported: replaces >=20 > AND >=20 > Via: SIP/2.0/TCP sip1.example.com, SIP/2.0/TCP sip2.example.com,=20 > SIP/2.0/TCP sip3.example.com >=20 > is equivalent to >=20 > Via: SIP/2.0/TCP sip1.example.com > Via: SIP/2.0/TCP sip2.example.com > Via: SIP/2.0/TCP sip3.example.com >=20 > (branches omitted for clarity) >=20 > Bottom Line: The draft is using the correct BNF. >=20 > thanks, > -rohan >=20 > > I would argue for multiple headers on two grounds. > > > > First, the idea of a proxy modifying history information=20 > doesn't sound=20 > > smart. If it screws up, it is hard to figure out who screwed up. > > > > Second, the index parameter frees us from worrying about=20 > header order,=20 > > which is a VERY good thing. > > > > > > > > Overview: > > While the motivation for History-Info is for the initiator of a=20 > > request to know what happened to a request, it is also of=20 > great use to=20 > > the recipient (End of Section 2 overview paragraph). > > > > Section 1.2: > > How is History-Info any different than Via w.r.t. security? > > > > > > > > Nits: > > Section 2.5, first paragraph, last sentence: > > this would like be a local > > this would likely be a local > > ^^ > > > > Appendix B, message F8, extra space before last=20 > angle-bracket in the=20 > > History-Info line. > > > > > > _______________________________________________ > > 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 >=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 exim@www1.ietf.org Mon Nov 10 22:55:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03457 for ; Mon, 10 Nov 2003 22:55:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPcX-0005EF-KP for sip-archive@odin.ietf.org; Mon, 10 Nov 2003 22:55:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAB3tDrR020093 for sip-archive@odin.ietf.org; Mon, 10 Nov 2003 22:55:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPcM-0005DE-Pe; Mon, 10 Nov 2003 22:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJPbY-00059r-Dk for sip@optimus.ietf.org; Mon, 10 Nov 2003 22:54:12 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03399 for ; Mon, 10 Nov 2003 22:53:57 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJPbU-00040R-00 for sip@ietf.org; Mon, 10 Nov 2003 22:54:08 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AJPbT-00040O-00 for sip@ietf.org; Mon, 10 Nov 2003 22:54:08 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAB3s7J11237 for ; Tue, 11 Nov 2003 05:54:07 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 11 Nov 2003 05:54:07 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 11 Nov 2003 05:54:05 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] GRUU, Contacts, and privacy Date: Tue, 11 Nov 2003 05:54:04 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017973AF@esebe019.ntc.nokia.com> Thread-Topic: [Sip] GRUU, Contacts, and privacy Thread-Index: AcOlZbZiztwxCjDXRrihtIlyWg0sZgCoZ4Ig To: , , Cc: X-OriginalArrivalTime: 11 Nov 2003 03:54:05.0856 (UTC) FILETIME=[73DC4A00:01C3A807] Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable How about reg event package? You get NOTIFY with new GRUU. /Hisham > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext > Cullen Jennings > Sent: Friday, November 07, 2003 9:29 PM > To: sip@ietf.org; Jonathan Rosenberg > Cc: Paul Kyzivat > Subject: [Sip] GRUU, Contacts, and privacy >=20 >=20 > =20 > When making anonymous calls, the contact should change on=20 > every call. For > example of if you don't do this ... Bill makes an anonymous call from > Monika's phone to Hillary. Hillary, takes the call, is=20 > suppositious about > the location and makes note of the contact. Now Hillary calls=20 > Monika and > notes the contact. If the two contacts are the same, the=20 > privacy of the > original call is lost and Hillary knows the original call was=20 > from Monika's > phone.=20 >=20 > Unfortunately, it looks like the grid approach still reveals this > information - the grid on the two calls might be different=20 > but the core GRUU > is still the same.=20 >=20 > I have a hard time imagining a simple solution that allowed the UA to > generate the GRUUs and still have fast lookup for the proxy.=20 > It seems like a > way is needed for the UA to get many GRUU that it can use and=20 > that these > need to be anonymous and uncorelatable by third parties. >=20 > One possible solution for this is to send another Register=20 > after each call > to get a new GRUU that can be used. This would drive the text=20 > to change so > that re-registrations must result in a new GRUU - the current=20 > encryption > mechanism with salt would meet this. Presumable, the old GRUU's would > continue to work and be good as long as the contact that=20 > generated it was > still valid.=20 >=20 > Cullen >=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 >=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 exim@www1.ietf.org Tue Nov 11 10:01:57 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03315 for ; Tue, 11 Nov 2003 10:01:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJa1P-0005qP-NB for sip-archive@odin.ietf.org; Tue, 11 Nov 2003 10:01:39 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hABF1ZGX022464 for sip-archive@odin.ietf.org; Tue, 11 Nov 2003 10:01:35 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJa0s-0005oP-By; Tue, 11 Nov 2003 10:01:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJa01-0005hP-8l for sip@optimus.ietf.org; Tue, 11 Nov 2003 10:00:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03181 for ; Tue, 11 Nov 2003 09:59:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJZzz-00047x-00 for sip@ietf.org; Tue, 11 Nov 2003 10:00:07 -0500 Received: from dgesmtp02.wcom.com ([199.249.16.17]) by ietf-mx with esmtp (Exim 4.12) id 1AJZzy-00047J-00 for sip@ietf.org; Tue, 11 Nov 2003 10:00:06 -0500 Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.wcom.com (Iplanet MTA 5.2) with ESMTP id <0HO700LCQ02MVS@firewall.wcom.com> for sip@ietf.org; Tue, 11 Nov 2003 14:54:22 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with SMTP id <0HO700L0102HYX@pmismtp02.wcomnet.com>; Tue, 11 Nov 2003 14:54:22 +0000 (GMT) Received: from xs578v3521.mci.com ([166.50.124.21]) by pmismtp02.wcomnet.com (iPlanet Messaging Server 5.1 HotFix 0.7 (built May 7 2002)) with ESMTP id <0HO700L6G00GP3@pmismtp02.wcomnet.com>; Tue, 11 Nov 2003 14:53:07 +0000 (GMT) Date: Mon, 10 Nov 2003 20:19:47 -0600 From: Alan Johnston Subject: RE: [Sip] GRUU, Contacts, and privacy In-reply-to: X-Sender: Alan.Johnston@pop.mcit.com To: seancolson@yahoo.com, "'Cullen Jennings'" , sip@ietf.org, "'Jonathan Rosenberg'" Cc: "'Paul Kyzivat'" , oritl@microsoft.com Message-id: <5.2.1.1.0.20031110201758.028c9868@pop.mcit.com> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Version 5.2.1 Content-type: text/plain; charset=us-ascii; format=flowed References: Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , At 07:41 PM 11/7/2003 -0800, Sean Olson wrote: >I would like to offer the suggestion that while privacy is an interesting >and useful property, it is not a necessity for many applications that might >otherwise use GRUU. I would go even further and state that is runs counter >to some applications that might want to use a globally routable and unique >URI. Part of the complexity of the grid approach is this requirement for >obfuscation/privacy. If you remove that requirement, it is entirely possible >to come up with a simpler solution. I agree 100%. A private Contact URI is just one small piece of the privacy puzzle. I think this privacy requirement should be removed. Thanks, Alan Johnston MCI sip:alan@sipstation.com >-----Original Message----- >From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Cullen >Jennings >Sent: Friday, November 07, 2003 11:29 AM >To: sip@ietf.org; Jonathan Rosenberg >Cc: Paul Kyzivat >Subject: [Sip] GRUU, Contacts, and privacy > > >When making anonymous calls, the contact should change on every call. For >example of if you don't do this ... Bill makes an anonymous call from >Monika's phone to Hillary. Hillary, takes the call, is suppositious about >the location and makes note of the contact. Now Hillary calls Monika and >notes the contact. If the two contacts are the same, the privacy of the >original call is lost and Hillary knows the original call was from Monika's >phone. > >Unfortunately, it looks like the grid approach still reveals this >information - the grid on the two calls might be different but the core GRUU >is still the same. > >I have a hard time imagining a simple solution that allowed the UA to >generate the GRUUs and still have fast lookup for the proxy. It seems like a >way is needed for the UA to get many GRUU that it can use and that these >need to be anonymous and uncorelatable by third parties. > >One possible solution for this is to send another Register after each call >to get a new GRUU that can be used. This would drive the text to change so >that re-registrations must result in a new GRUU - the current encryption >mechanism with salt would meet this. Presumable, the old GRUU's would >continue to work and be good as long as the contact that generated it was >still valid. > >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 _______________________________________________ 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 exim@www1.ietf.org Wed Nov 12 15:02:16 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04585 for ; Wed, 12 Nov 2003 15:02:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1Be-0003nz-OP for sip-archive@odin.ietf.org; Wed, 12 Nov 2003 15:01:58 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACK1w1p014569 for sip-archive@odin.ietf.org; Wed, 12 Nov 2003 15:01:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1As-0003dH-V9; Wed, 12 Nov 2003 15:01:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1AW-0003Sb-Te for sip@optimus.ietf.org; Wed, 12 Nov 2003 15:00:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04408 for ; Wed, 12 Nov 2003 15:00:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1AT-0004me-00 for sip@ietf.org; Wed, 12 Nov 2003 15:00:45 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AK1AS-0004jt-00 for sip@ietf.org; Wed, 12 Nov 2003 15:00:45 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hACK0AGd021723 for ; Wed, 12 Nov 2003 14:00:10 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Wed, 12 Nov 2003 14:00:10 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E865FD@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'sip@ietf.org'" Date: Wed, 12 Nov 2003 14:00:10 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [Sip] PUBLISH message rates Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , To get the conversation started on the list, I'll summarize what I heard as salient points being made at the microphone. - Event packages define SHOULD or MUST strength requirements that NOTIFYs cannot be sent faster than a hard limit. Aki's proposal can be summarized as: PUBLISH will inherit these hard limits as maximum rates of publication. - It was pointed out that recipients of PUBLISH requests can push back against excessive traffic with 5xx class responses that have "Retry-After" headers. - A point was made that NOTIFY will often be subject to filtering, in which case there is no one-to-one correlation between the amount of information sent to an event server in PUBLISH and the amount of information sent by an event server in NOTIFYs. To be honest, after giving the topic a bit more thought, I'm somewhat on the fence. /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 exim@www1.ietf.org Wed Nov 12 15:26:45 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07312 for ; Wed, 12 Nov 2003 15:26:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1ZK-0008Km-DF for sip-archive@odin.ietf.org; Wed, 12 Nov 2003 15:26:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACKQQte031971 for sip-archive@odin.ietf.org; Wed, 12 Nov 2003 15:26:26 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1Yx-0008Eu-KL; Wed, 12 Nov 2003 15:26:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK1YY-0008CC-R5 for sip@optimus.ietf.org; Wed, 12 Nov 2003 15:25:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07287 for ; Wed, 12 Nov 2003 15:25:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK1YX-0005NM-00 for sip@ietf.org; Wed, 12 Nov 2003 15:25:37 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AK1YW-0005NJ-00 for sip@ietf.org; Wed, 12 Nov 2003 15:25:36 -0500 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hACKPQ9D027821; Wed, 12 Nov 2003 15:25:26 -0500 (EST) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hACKPKf06376; Wed, 12 Nov 2003 15:25:21 -0500 Message-ID: <3FB2972C.7010608@cs.columbia.edu> Date: Wed, 12 Nov 2003 15:25:16 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'sip@ietf.org'" Subject: Re: [Sip] PUBLISH message rates References: <9BF66EBF6BEFD942915B4D4D45C051F3E865FD@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E865FD@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit To amplify the third point: Since multiple entities may publish for the same presentity, for example, the NOTIFY rate may be as high as the sum of the PUBLISH rates. Thus, restricting PUBLISH cannot be relied upon to limit the NOTIFY rate, since the different PUBLISH sources presumably have no idea what others have been up to. Thus, requiring some max. PUBLISH rate is not likely to be effective, but may be harmful in some (future) scenarios. Adam Roach wrote: > To get the conversation started on the list, I'll summarize > what I heard as salient points being made at the microphone. > > - Event packages define SHOULD or MUST strength requirements > that NOTIFYs cannot be sent faster than a hard limit. > Aki's proposal can be summarized as: PUBLISH will inherit > these hard limits as maximum rates of publication. > > - It was pointed out that recipients of PUBLISH requests can > push back against excessive traffic with 5xx class responses > that have "Retry-After" headers. > > - A point was made that NOTIFY will often be subject to filtering, > in which case there is no one-to-one correlation between the > amount of information sent to an event server in PUBLISH and > the amount of information sent by an event server in NOTIFYs. > > To be honest, after giving the topic a bit more thought, I'm > somewhat on the fence. > > /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 _______________________________________________ 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 exim@www1.ietf.org Wed Nov 12 16:14:48 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10014 for ; Wed, 12 Nov 2003 16:14:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2Jp-0007EI-Os for sip-archive@odin.ietf.org; Wed, 12 Nov 2003 16:14:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACLETQi027784 for sip-archive@odin.ietf.org; Wed, 12 Nov 2003 16:14:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2JO-0007Cd-8D; Wed, 12 Nov 2003 16:14:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK2J4-0007Bi-CB for sip@optimus.ietf.org; Wed, 12 Nov 2003 16:13:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09974 for ; Wed, 12 Nov 2003 16:13:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK2J2-0006Ry-00 for sip@ietf.org; Wed, 12 Nov 2003 16:13:40 -0500 Received: from delicious.ietf58.ietf.org ([130.129.16.24]) by ietf-mx with esmtp (Exim 4.12) id 1AK2J1-0006Rv-00 for sip@ietf.org; Wed, 12 Nov 2003 16:13:40 -0500 Received: from Toshiba4 (dyn130-94.ietf58.ietf.org [130.129.130.94]) by delicious.ietf58.ietf.org (8.12.10/8.12.10) with SMTP id hACLDdKg008707; Wed, 12 Nov 2003 15:13:40 -0600 (CST) From: "Ashir Ahmed" To: "Henning Schulzrinne" , "Adam Roach" Cc: Subject: RE: [Sip] PUBLISH message rates Date: Thu, 13 Nov 2003 06:13:29 +0900 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-reply-to: <3FB2972C.7010608@cs.columbia.edu> Importance: Normal Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Is there any ways that the PUA know about the watcher's request? Why do I care? I have a mobile phone ( a PUA). I don't want to pay money for PUBLISHing unnecessary information. Besides the frequency of PUBLISH, there is another concern about the volume of PUBLISH. So, if the PUA have the information about the watcher's request (WHAT and when (the frequency) is being subscribed), the PUA can respond accordingly. ashir -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Henning Schulzrinne Sent: Thursday, November 13, 2003 5:25 AM To: Adam Roach Cc: 'sip@ietf.org' Subject: Re: [Sip] PUBLISH message rates To amplify the third point: Since multiple entities may publish for the same presentity, for example, the NOTIFY rate may be as high as the sum of the PUBLISH rates. Thus, restricting PUBLISH cannot be relied upon to limit the NOTIFY rate, since the different PUBLISH sources presumably have no idea what others have been up to. Thus, requiring some max. PUBLISH rate is not likely to be effective, but may be harmful in some (future) scenarios. Adam Roach wrote: > To get the conversation started on the list, I'll summarize > what I heard as salient points being made at the microphone. > > - Event packages define SHOULD or MUST strength requirements > that NOTIFYs cannot be sent faster than a hard limit. > Aki's proposal can be summarized as: PUBLISH will inherit > these hard limits as maximum rates of publication. > > - It was pointed out that recipients of PUBLISH requests can > push back against excessive traffic with 5xx class responses > that have "Retry-After" headers. > > - A point was made that NOTIFY will often be subject to filtering, > in which case there is no one-to-one correlation between the > amount of information sent to an event server in PUBLISH and > the amount of information sent by an event server in NOTIFYs. > > To be honest, after giving the topic a bit more thought, I'm > somewhat on the fence. > > /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 _______________________________________________ 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 exim@www1.ietf.org Wed Nov 12 17:00:10 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12118 for ; Wed, 12 Nov 2003 17:00:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK31k-0002Hc-Gg for sip-archive@odin.ietf.org; Wed, 12 Nov 2003 16:59:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACLxq1M008721 for sip-archive@odin.ietf.org; Wed, 12 Nov 2003 16:59:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK30x-000263-8A; Wed, 12 Nov 2003 16:59:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK30S-00024y-Fk for sip@optimus.ietf.org; Wed, 12 Nov 2003 16:58:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12010 for ; Wed, 12 Nov 2003 16:58:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK30Q-0007Bk-00 for sip@ietf.org; Wed, 12 Nov 2003 16:58:30 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AK30P-0007Bg-00 for sip@ietf.org; Wed, 12 Nov 2003 16:58:29 -0500 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hACLwG9D011137; Wed, 12 Nov 2003 16:58:21 -0500 (EST) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hACLwEf08296; Wed, 12 Nov 2003 16:58:15 -0500 Message-ID: <3FB2ACF4.5090201@cs.columbia.edu> Date: Wed, 12 Nov 2003 16:58:12 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ashir Ahmed CC: Adam Roach , sip@ietf.org Subject: Re: [Sip] PUBLISH message rates References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ashir Ahmed wrote: > Is there any ways that the PUA know about the watcher's request? > Why do I care? > I have a mobile phone ( a PUA). I don't want to pay money for PUBLISHing > unnecessary information. Besides the frequency of PUBLISH, there is another > concern about the volume of PUBLISH. So, if the PUA have the information > about the watcher's request (WHAT and when (the frequency) is being > subscribed), the PUA can respond accordingly. Unless you have a very special situation in mind, the number of watchers is typically large. You would have to compute the max. desired rate across all watchers and in addition take into account the filters they may have installed. Since you're paying, you should just update the presence information when you feel like it. After all, you're providing the service (typically) for free. _______________________________________________ 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 exim@www1.ietf.org Wed Nov 12 18:00:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14538 for ; Wed, 12 Nov 2003 18:00:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK3yD-000799-IJ for sip-archive@odin.ietf.org; Wed, 12 Nov 2003 18:00:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hACN0Hg5027416 for sip-archive@odin.ietf.org; Wed, 12 Nov 2003 18:00:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK3xz-00075k-Gy; Wed, 12 Nov 2003 18:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK3xQ-00074x-3H for sip@optimus.ietf.org; Wed, 12 Nov 2003 17:59:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14486 for ; Wed, 12 Nov 2003 17:59:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK3xN-0000QP-00 for sip@ietf.org; Wed, 12 Nov 2003 17:59:25 -0500 Received: from 138.muda.mnpl.sfldmibv.dsl.att.net ([12.98.223.138] helo=osrmail) by ietf-mx with esmtp (Exim 4.12) id 1AK3xM-0000QM-00 for sip@ietf.org; Wed, 12 Nov 2003 17:59:24 -0500 Received: from sip (127.0.0.1) by localhost (127.0.0.1) with [XMail 0.74 (Win32/Ix86) ESMTP Server] id for from ; Wed, 12 Nov 2003 14:53:39 -0000 From: "Christian Stredicke" To: Date: Wed, 12 Nov 2003 16:59:45 -0600 Message-ID: <050c01c3a970$aa52a4c0$be08f20a@sip> 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.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [Sip] Connection: Keep-Alive Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi There! The discussion today about moving to TCP transport layer and the consequences on NAT raises the question if we should define a header that asks the proxy explicitly to keep the TCP connection open. As far as I see this has not been defined yet. I see two possibilities: 1) Implicit: The proxy detects that client cannot be reached by the address which it is using (using the received or rport parameter in the top via). 2) Explicit: The client explicitly requests this. This could be done with the famous Connection header, maybe as a parameter in the top via. In any case the behavior of the UAC as well as the proxy needs to be (re)defined, I think the current TCP specification does not allow a permanent connection. Any thoughts on this? CS -- Christian Stredicke tel:+49.30.39833.401 (ENUM & PSTN) ----------------------------------------------------------------- Learn more about snom! Subscribe our newsletter at http://www.snom.com/newsletter.php ----------------------------------------------------------------- _______________________________________________ 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 exim@www1.ietf.org Wed Nov 12 22:30:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24866 for ; Wed, 12 Nov 2003 22:30:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK8BV-00073d-7z for sip-archive@odin.ietf.org; Wed, 12 Nov 2003 22:30:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD3UHZY027129 for sip-archive@odin.ietf.org; Wed, 12 Nov 2003 22:30:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK8BH-00072a-5t; Wed, 12 Nov 2003 22:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK8AM-00071Q-49 for sip@optimus.ietf.org; Wed, 12 Nov 2003 22:29:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24828 for ; Wed, 12 Nov 2003 22:28:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK8AI-0004NY-00 for sip@ietf.org; Wed, 12 Nov 2003 22:29:02 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AK8AH-0004NS-00 for sip@ietf.org; Wed, 12 Nov 2003 22:29:02 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAD3SxIc027909; Wed, 12 Nov 2003 21:28:59 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FB2FA77.9020307@dynamicsoft.com> Date: Wed, 12 Nov 2003 21:28:55 -0600 From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Adam Roach CC: "'sip@ietf.org'" Subject: Re: [Sip] PUBLISH message rates References: <9BF66EBF6BEFD942915B4D4D45C051F3E865FD@dyn-tx-exch-001.dynamicsoft.com> In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E865FD@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Are we assuming that any event package can automatically be used with publish? Or do we expect explicit documentation about how to use publish with a package? Maybe future event packages should document use of publish as part of the package documentation. If we do expect package specific documentation for the use of PUBLISH, then it wouuld make sense to ask for it to specify the behavior just like we expect package documentation to do it. One option would be to state that the rules are inherited from the NOTIFY documentation. But for some packages, other approaches may make sense. Adam Roach wrote: > To get the conversation started on the list, I'll summarize > what I heard as salient points being made at the microphone. > > - Event packages define SHOULD or MUST strength requirements > that NOTIFYs cannot be sent faster than a hard limit. > Aki's proposal can be summarized as: PUBLISH will inherit > these hard limits as maximum rates of publication. > > - It was pointed out that recipients of PUBLISH requests can > push back against excessive traffic with 5xx class responses > that have "Retry-After" headers. > > - A point was made that NOTIFY will often be subject to filtering, > in which case there is no one-to-one correlation between the > amount of information sent to an event server in PUBLISH and > the amount of information sent by an event server in NOTIFYs. > > To be honest, after giving the topic a bit more thought, I'm > somewhat on the fence. > > /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 _______________________________________________ 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 exim@www1.ietf.org Wed Nov 12 23:16:53 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26537 for ; Wed, 12 Nov 2003 23:16:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK8uF-0002hO-Vy for sip-archive@odin.ietf.org; Wed, 12 Nov 2003 23:16:34 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD4GVpr010369 for sip-archive@odin.ietf.org; Wed, 12 Nov 2003 23:16:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK8tq-0002P6-Ll; Wed, 12 Nov 2003 23:16:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AK8su-0002Gt-Ed for sip@optimus.ietf.org; Wed, 12 Nov 2003 23:15:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26433 for ; Wed, 12 Nov 2003 23:14:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AK8sr-00054u-00 for sip@ietf.org; Wed, 12 Nov 2003 23:15:05 -0500 Received: from hoemail1.lucent.com ([192.11.226.161] helo=hoemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AK8sq-00054L-00 for sip@ietf.org; Wed, 12 Nov 2003 23:15:04 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by hoemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hAD4ES501298; Wed, 12 Nov 2003 22:14:29 -0600 (CST) Received: from lucent.com (vkg.lra.lucent.com [192.11.61.176]) by ihmail.ih.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id hAD4ENB09621; Wed, 12 Nov 2003 22:14:23 -0600 (CST) Message-ID: <3FB3051A.6050203@lucent.com> Date: Wed, 12 Nov 2003 22:14:18 -0600 From: "Vijay K. Gurbani" Organization: Wireless Research and Development Group User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christian Stredicke CC: sip@ietf.org, rajnishjain@xl.com Subject: Re: [Sip] Connection: Keep-Alive References: <050c01c3a970$aa52a4c0$be08f20a@sip> In-Reply-To: <050c01c3a970$aa52a4c0$be08f20a@sip> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Christian Stredicke wrote: > Hi There! > > The discussion today about moving to TCP transport layer and the > consequences on NAT raises the question if we should define a header > that asks the proxy explicitly to keep the TCP connection open. As far > as I see this has not been defined yet. I've discussed this in a I-D I presented at the Atlanta IETF. See http://www.ietf.org/internet-drafts/draft-jain-sipping-persistent-conn-reqs-00.txt on some ways to do so. That I-D builds on Rohan's connection-reuse draft and fills in a couple of gaps in it. Namely the longevity aspects of the connection and the neediness of a client in requesting a persistent connection. > I see two possibilities: > > 1) Implicit: The proxy detects that client cannot be reached by the > address which it is using (using the received or rport parameter in the > top via). > > 2) Explicit: The client explicitly requests this. This could be done > with the famous Connection header, maybe as a parameter in the top via. Section 8 of that I-D describes some ways to explicitly signal the intent. > In any case the behavior of the UAC as well as the proxy needs to be > (re)defined, I think the current TCP specification does not allow a > permanent connection. > > Any thoughts on this? At the Atlanta IETF, it was decided that we will open a bug against rfc3261 to provide more information on TCP connection handling. But as I said on the floor then, I believe that we need to go beyond that; a BCP outlining TCP connection handling was suggested as an additional venue. I have not had the time to do that so far. Given the current and growing interest in this topic, maybe we can get together some more heads interested in this to hammer out a BCP. We can use the above I-D as a starting point. The need for persistent connections will become pressing as more implementations support TLS. Despite TLS session resumption, persistent TLS connections between two high-volume proxies can be extremely beneficial. Question to SIP/SIPPING chairs: Is the time ripe for a design team on this? Cheers, - 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 exim@www1.ietf.org Thu Nov 13 02:13:49 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10808 for ; Thu, 13 Nov 2003 02:13:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKBfV-00047K-Ij for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 02:13:30 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD7DTgJ015766 for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 02:13:29 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKBf4-00043g-1g; Thu, 13 Nov 2003 02:13:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKBew-00040s-KW for sip@optimus.ietf.org; Thu, 13 Nov 2003 02:12:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09831 for ; Thu, 13 Nov 2003 02:12:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKBes-0007Vd-00 for sip@ietf.org; Thu, 13 Nov 2003 02:12:50 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AKBes-0007VI-00 for sip@ietf.org; Thu, 13 Nov 2003 02:12:50 -0500 Received: from dynamicsoft.com ([63.113.46.127]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAD7CMca016509; Thu, 13 Nov 2003 02:12:23 -0500 (EST) Message-ID: <3FB32ED4.40800@dynamicsoft.com> Date: Thu, 13 Nov 2003 02:12:20 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Vijay K. Gurbani" CC: Christian Stredicke , sip@ietf.org, rajnishjain@xl.com Subject: Re: [Sip] Connection: Keep-Alive References: <050c01c3a970$aa52a4c0$be08f20a@sip> <3FB3051A.6050203@lucent.com> In-Reply-To: <3FB3051A.6050203@lucent.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Vijay K. Gurbani wrote: >> In any case the behavior of the UAC as well as the proxy needs to be >> (re)defined, I think the current TCP specification does not allow a >> permanent connection. >> >> Any thoughts on this? > > > At the Atlanta IETF, it was decided that we will open a bug > against rfc3261 to provide more information on TCP connection > handling. Well, in particular, it was concluded that signaling "please keep this connection open" was not needed at all. Rather, the server should keep the connection open as long as it could, and only close it if it ran out of resources. Since there was no benefit to closing it prematurely (extra costs of setting it up again), and since signaling the desire for persistence could not be used to force the server to keep it open if the server ran out of resources, the signaling was not needed. Indeed, the observation was that many implementations in any case were doing this; it was just unclear in the spec. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 exim@www1.ietf.org Thu Nov 13 02:20:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14176 for ; Thu, 13 Nov 2003 02:20:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKBm7-0004v0-Vm for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 02:20:20 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD7KJ9S018841 for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 02:20:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKBlq-0004rW-Nv; Thu, 13 Nov 2003 02:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKBky-0004lb-20 for sip@optimus.ietf.org; Thu, 13 Nov 2003 02:19:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14023 for ; Thu, 13 Nov 2003 02:18:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKBku-0007bB-00 for sip@ietf.org; Thu, 13 Nov 2003 02:19:04 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AKBkt-0007aw-00 for sip@ietf.org; Thu, 13 Nov 2003 02:19:03 -0500 Received: from dynamicsoft.com ([63.113.46.127]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAD7IUca016512; Thu, 13 Nov 2003 02:18:30 -0500 (EST) Message-ID: <3FB33044.1000201@dynamicsoft.com> Date: Thu, 13 Nov 2003 02:18:28 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henning Schulzrinne CC: Adam Roach , "'sip@ietf.org'" Subject: Re: [Sip] PUBLISH message rates References: <9BF66EBF6BEFD942915B4D4D45C051F3E865FD@dyn-tx-exch-001.dynamicsoft.com> <3FB2972C.7010608@cs.columbia.edu> In-Reply-To: <3FB2972C.7010608@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > To amplify the third point: Since multiple entities may publish for the > same presentity, for example, the NOTIFY rate may be as high as the sum > of the PUBLISH rates. Thus, restricting PUBLISH cannot be relied upon to > limit the NOTIFY rate, since the different PUBLISH sources presumably > have no idea what others have been up to. I didnt think the intent was to use a limit on the PUBLISH rate to enforce the limit on the NOTIFY rate. I think the point was that, if we believed there was value in limiting the NOTIFY rate (and we do, according to rfc3265), there is probably value in limiting the PUBLISH rate too. I dont feel that strongly about this, since I think its a non-issue practically speaking until we have packages that really push limits. Before we get there, its mostly an academic exercise. In that case, I am inclined to go for consistency, and have PUBLISH limited in rate as NOTIFYs are within a package. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 exim@www1.ietf.org Thu Nov 13 02:41:03 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15199 for ; Thu, 13 Nov 2003 02:41:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKC5s-0006ht-8h for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 02:40:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD7eiHh025782 for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 02:40:44 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKC5E-0006fN-F5; Thu, 13 Nov 2003 02:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKC4P-0006bJ-OE for sip@optimus.ietf.org; Thu, 13 Nov 2003 02:39:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15152 for ; Thu, 13 Nov 2003 02:39:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKC4L-00009x-00 for sip@ietf.org; Thu, 13 Nov 2003 02:39:09 -0500 Received: from smtp001.mail.ukl.yahoo.com ([217.12.11.32]) by ietf-mx with smtp (Exim 4.12) id 1AKC4K-00009g-00 for sip@ietf.org; Thu, 13 Nov 2003 02:39:08 -0500 Received: from 12-235-146-159.client.attbi.com (HELO cranberry) (seancolson@12.235.146.159 with login) by smtp1.mail.vip.ukl.yahoo.com with SMTP; 13 Nov 2003 07:38:38 -0000 Reply-To: From: "Sean Olson" To: "'Jonathan Rosenberg'" , "'Vijay K. Gurbani'" Cc: "'Christian Stredicke'" , , Subject: RE: [Sip] Connection: Keep-Alive Date: Wed, 12 Nov 2003 23:38:44 -0800 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.1165 Thread-Index: AcOptak8VQ6svje/QfeHdPCw1R932QAA3ARA In-Reply-To: <3FB32ED4.40800@dynamicsoft.com> Message-Id: Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Actually, many implementations are not doing this unfortunately. A BCP is not a bad idea. -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Jonathan Rosenberg Sent: Wednesday, November 12, 2003 11:12 PM To: Vijay K. Gurbani Cc: Christian Stredicke; sip@ietf.org; rajnishjain@xl.com Subject: Re: [Sip] Connection: Keep-Alive Vijay K. Gurbani wrote: >> In any case the behavior of the UAC as well as the proxy needs to be >> (re)defined, I think the current TCP specification does not allow a >> permanent connection. >> >> Any thoughts on this? > > > At the Atlanta IETF, it was decided that we will open a bug against > rfc3261 to provide more information on TCP connection handling. Well, in particular, it was concluded that signaling "please keep this connection open" was not needed at all. Rather, the server should keep the connection open as long as it could, and only close it if it ran out of resources. Since there was no benefit to closing it prematurely (extra costs of setting it up again), and since signaling the desire for persistence could not be used to force the server to keep it open if the server ran out of resources, the signaling was not needed. Indeed, the observation was that many implementations in any case were doing this; it was just unclear in the spec. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 exim@www1.ietf.org Thu Nov 13 02:44:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15283 for ; Thu, 13 Nov 2003 02:44:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKC9E-0007FT-3x for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 02:44:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAD7iBZQ027802 for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 02:44:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKC94-0007DT-Sb; Thu, 13 Nov 2003 02:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKC8S-0007Am-LQ for sip@optimus.ietf.org; Thu, 13 Nov 2003 02:43:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15259 for ; Thu, 13 Nov 2003 02:43:12 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKC8O-0000Cf-00 for sip@ietf.org; Thu, 13 Nov 2003 02:43:20 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AKC8O-0000CT-00 for sip@ietf.org; Thu, 13 Nov 2003 02:43:20 -0500 Received: from dynamicsoft.com ([63.113.46.127]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAD7grca016529; Thu, 13 Nov 2003 02:42:53 -0500 (EST) Message-ID: <3FB335FA.7000900@dynamicsoft.com> Date: Thu, 13 Nov 2003 02:42:50 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: seancolson@yahoo.com CC: "'Vijay K. Gurbani'" , "'Christian Stredicke'" , sip@ietf.org, rajnishjain@xl.com Subject: Re: [Sip] Connection: Keep-Alive References: <200311130738.hAD7ch0K023866@mail2.dynamicsoft.com> In-Reply-To: <200311130738.hAD7ch0K023866@mail2.dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Sorry for not being clear - I wasnt saying we DONT want a document. At the meeting today, I advocated (and I think many others agreed) for creation of a document. In particular, I think it makes sense to have a proposed standard document that describes all of the issues with getting tcp to work. This would presumably be an expansion of the existing connect-reuse draft. It needs to be PS since there is normative behavior associated with many parts of it. -Jonathan R. Sean Olson wrote: > Actually, many implementations are not doing this unfortunately. A BCP is > not a bad idea. > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Jonathan > Rosenberg > Sent: Wednesday, November 12, 2003 11:12 PM > To: Vijay K. Gurbani > Cc: Christian Stredicke; sip@ietf.org; rajnishjain@xl.com > Subject: Re: [Sip] Connection: Keep-Alive > > > > Vijay K. Gurbani wrote: > > > >>>In any case the behavior of the UAC as well as the proxy needs to be >>>(re)defined, I think the current TCP specification does not allow a >>>permanent connection. >>> >>>Any thoughts on this? >> >> >>At the Atlanta IETF, it was decided that we will open a bug against >>rfc3261 to provide more information on TCP connection handling. > > > Well, in particular, it was concluded that signaling "please keep this > connection open" was not needed at all. Rather, the server should keep the > connection open as long as it could, and only close it if it ran out of > resources. Since there was no benefit to closing it prematurely (extra costs > of setting it up again), and since signaling the desire for persistence > could not be used to force the server to keep it open if the server ran out > of resources, the signaling was not needed. > Indeed, the observation was that many implementations in any case were doing > this; it was just unclear in the spec. > > -Jonathan R. > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 exim@www1.ietf.org Thu Nov 13 07:51:42 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22676 for ; Thu, 13 Nov 2003 07:51:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKGwT-00076g-U9 for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 07:51:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADCpLHs027319 for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 07:51:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKGwA-00075M-6K; Thu, 13 Nov 2003 07:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKGvC-00072U-1q for sip@optimus.ietf.org; Thu, 13 Nov 2003 07:50:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22556 for ; Thu, 13 Nov 2003 07:49:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKGvB-0003wK-00 for sip@ietf.org; Thu, 13 Nov 2003 07:50:01 -0500 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 1AKGvA-0003wF-00 for sip@ietf.org; Thu, 13 Nov 2003 07:50:00 -0500 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Thu, 13 Nov 2003 12:52:34 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [Sip] Connection: Keep-Alive Date: Thu, 13 Nov 2003 12:49:57 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE0219B10E@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Sip] Connection: Keep-Alive Thread-Index: AcOpu0l50C0FY1qvSU2MBwdtTPsCrwAKNJwn From: "Chris Boulton" To: "Jonathan Rosenberg" , Cc: "Vijay K. Gurbani" , "Christian Stredicke" , , Content-Transfer-Encoding: base64 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 SSBhbHNvIGFncmVlIHRoYXQgYSBkb2N1bWVudCBpcyBpbXBvcnRhbnQuICBUaGUgY29uc2Vuc3Vz IGluIHRoZSByb29tIHllc3RlcmRheSB3YXMgYW0gZW1waGFzaXMgb24gVENQIHVzYWdlIGR1ZSB0 byB0aGUga25vd24gbGltaXRhdGlvbnMgb2YgVURQLiAgU29tZSBmb3JtIG9mIEJDUCBtaWdodCBn byBhIGxvbmcgd2F5IHRvIHByb21vdGluZyBpdCdzIGN1cnJlbnRseSBsaW1pdGVkIHVzYWdlLg0K IA0KQ2hyaXMuDQogDQoNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLSANCglGcm9tOiBKb25h dGhhbiBSb3NlbmJlcmcgW21haWx0bzpqZHJvc2VuQGR5bmFtaWNzb2Z0LmNvbV0gDQoJU2VudDog VGh1IDEzLzExLzIwMDMgMDc6NDIgDQoJVG86IHNlYW5jb2xzb25AeWFob28uY29tIA0KCUNjOiAn VmlqYXkgSy4gR3VyYmFuaSc7ICdDaHJpc3RpYW4gU3RyZWRpY2tlJzsgc2lwQGlldGYub3JnOyBy YWpuaXNoamFpbkB4bC5jb20gDQoJU3ViamVjdDogUmU6IFtTaXBdIENvbm5lY3Rpb246IEtlZXAt QWxpdmUNCgkNCgkNCg0KCVNvcnJ5IGZvciBub3QgYmVpbmcgY2xlYXIgLSBJIHdhc250IHNheWlu ZyB3ZSBET05UIHdhbnQgYSBkb2N1bWVudC4gQXQNCgl0aGUgbWVldGluZyB0b2RheSwgSSBhZHZv Y2F0ZWQgKGFuZCBJIHRoaW5rIG1hbnkgb3RoZXJzIGFncmVlZCkgZm9yDQoJY3JlYXRpb24gb2Yg YSBkb2N1bWVudC4gSW4gcGFydGljdWxhciwgSSB0aGluayBpdCBtYWtlcyBzZW5zZSB0byBoYXZl DQoJYSBwcm9wb3NlZCBzdGFuZGFyZCBkb2N1bWVudCB0aGF0IGRlc2NyaWJlcyBhbGwgb2YgdGhl IGlzc3VlcyB3aXRoDQoJZ2V0dGluZyB0Y3AgdG8gd29yay4gVGhpcyB3b3VsZCBwcmVzdW1hYmx5 IGJlIGFuIGV4cGFuc2lvbiBvZiB0aGUNCglleGlzdGluZyBjb25uZWN0LXJldXNlIGRyYWZ0LiBJ dCBuZWVkcyB0byBiZSBQUyBzaW5jZSB0aGVyZSBpcw0KCW5vcm1hdGl2ZSBiZWhhdmlvciBhc3Nv Y2lhdGVkIHdpdGggbWFueSBwYXJ0cyBvZiBpdC4NCgkNCgktSm9uYXRoYW4gUi4NCgkNCglTZWFu IE9sc29uIHdyb3RlOg0KCQ0KCT4gQWN0dWFsbHksIG1hbnkgaW1wbGVtZW50YXRpb25zIGFyZSBu b3QgZG9pbmcgdGhpcyB1bmZvcnR1bmF0ZWx5LiBBIEJDUCBpcw0KCT4gbm90IGEgYmFkIGlkZWEu DQoJPg0KCT4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCgk+IEZyb206IHNpcC1hZG1pbkBp ZXRmLm9yZyBbbWFpbHRvOnNpcC1hZG1pbkBpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvbmF0aGFu DQoJPiBSb3NlbmJlcmcNCgk+IFNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMTIsIDIwMDMgMTE6 MTIgUE0NCgk+IFRvOiBWaWpheSBLLiBHdXJiYW5pDQoJPiBDYzogQ2hyaXN0aWFuIFN0cmVkaWNr ZTsgc2lwQGlldGYub3JnOyByYWpuaXNoamFpbkB4bC5jb20NCgk+IFN1YmplY3Q6IFJlOiBbU2lw XSBDb25uZWN0aW9uOiBLZWVwLUFsaXZlDQoJPg0KCT4NCgk+DQoJPiBWaWpheSBLLiBHdXJiYW5p IHdyb3RlOg0KCT4NCgk+DQoJPg0KCT4+PkluIGFueSBjYXNlIHRoZSBiZWhhdmlvciBvZiB0aGUg VUFDIGFzIHdlbGwgYXMgdGhlIHByb3h5IG5lZWRzIHRvIGJlDQoJPj4+KHJlKWRlZmluZWQsIEkg dGhpbmsgdGhlIGN1cnJlbnQgVENQIHNwZWNpZmljYXRpb24gZG9lcyBub3QgYWxsb3cgYQ0KCT4+ PnBlcm1hbmVudCBjb25uZWN0aW9uLg0KCT4+Pg0KCT4+PkFueSB0aG91Z2h0cyBvbiB0aGlzPw0K CT4+DQoJPj4NCgk+PkF0IHRoZSBBdGxhbnRhIElFVEYsIGl0IHdhcyBkZWNpZGVkIHRoYXQgd2Ug d2lsbCBvcGVuIGEgYnVnIGFnYWluc3QNCgk+PnJmYzMyNjEgdG8gcHJvdmlkZSBtb3JlIGluZm9y bWF0aW9uIG9uIFRDUCBjb25uZWN0aW9uIGhhbmRsaW5nLg0KCT4NCgk+DQoJPiBXZWxsLCBpbiBw YXJ0aWN1bGFyLCBpdCB3YXMgY29uY2x1ZGVkIHRoYXQgc2lnbmFsaW5nICJwbGVhc2Uga2VlcCB0 aGlzDQoJPiBjb25uZWN0aW9uIG9wZW4iIHdhcyBub3QgbmVlZGVkIGF0IGFsbC4gUmF0aGVyLCB0 aGUgc2VydmVyIHNob3VsZCBrZWVwIHRoZQ0KCT4gY29ubmVjdGlvbiBvcGVuIGFzIGxvbmcgYXMg aXQgY291bGQsIGFuZCBvbmx5IGNsb3NlIGl0IGlmIGl0IHJhbiBvdXQgb2YNCgk+IHJlc291cmNl cy4gU2luY2UgdGhlcmUgd2FzIG5vIGJlbmVmaXQgdG8gY2xvc2luZyBpdCBwcmVtYXR1cmVseSAo ZXh0cmEgY29zdHMNCgk+IG9mIHNldHRpbmcgaXQgdXAgYWdhaW4pLCBhbmQgc2luY2Ugc2lnbmFs aW5nIHRoZSBkZXNpcmUgZm9yIHBlcnNpc3RlbmNlDQoJPiBjb3VsZCBub3QgYmUgdXNlZCB0byBm b3JjZSB0aGUgc2VydmVyIHRvIGtlZXAgaXQgb3BlbiBpZiB0aGUgc2VydmVyIHJhbiBvdXQNCgk+ IG9mIHJlc291cmNlcywgdGhlIHNpZ25hbGluZyB3YXMgbm90IG5lZWRlZC4NCgk+IEluZGVlZCwg dGhlIG9ic2VydmF0aW9uIHdhcyB0aGF0IG1hbnkgaW1wbGVtZW50YXRpb25zIGluIGFueSBjYXNl IHdlcmUgZG9pbmcNCgk+IHRoaXM7IGl0IHdhcyBqdXN0IHVuY2xlYXIgaW4gdGhlIHNwZWMuDQoJ Pg0KCT4gLUpvbmF0aGFuIFIuDQoJPg0KCQ0KCS0tDQoJSm9uYXRoYW4gRC4gUm9zZW5iZXJnLCBQ aC5ELiAgICAgICAgICAgICAgICA2MDAgTGFuaWRleCBQbGF6YQ0KCUNoaWVmIFRlY2hub2xvZ3kg T2ZmaWNlciAgICAgICAgICAgICAgICAgICAgUGFyc2lwcGFueSwgTkogMDcwNTQtMjcxMQ0KCWR5 bmFtaWNzb2Z0DQoJamRyb3NlbkBkeW5hbWljc29mdC5jb20gICAgICAgICAgICAgICAgICAgICBG QVg6ICAgKDk3MykgOTUyLTUwNTANCglodHRwOi8vd3d3Lmpkcm9zZW4ubmV0ICAgICAgICAgICAg ICAgICAgICAgIFBIT05FOiAoOTczKSA5NTItNTAwMA0KCWh0dHA6Ly93d3cuZHluYW1pY3NvZnQu Y29tDQoJDQoJDQoJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCglTaXAgbWFpbGluZyBsaXN0ICBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zaXANCglUaGlzIGxpc3QgaXMgZm9yIE5FVyBkZXZlbG9wbWVudCBvZiB0aGUgY29yZSBT SVAgUHJvdG9jb2wNCglVc2Ugc2lwLWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUgZm9yIHF1 ZXN0aW9ucyBvbiBjdXJyZW50IHNpcA0KCVVzZSBzaXBwaW5nQGlldGYub3JnIGZvciBuZXcgZGV2 ZWxvcG1lbnRzIG9uIHRoZSBhcHBsaWNhdGlvbiBvZiBzaXANCgkNCg0K _______________________________________________ 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 exim@www1.ietf.org Thu Nov 13 07:59:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22914 for ; Thu, 13 Nov 2003 07:59:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKH3z-0007ZT-GD for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 07:59:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADCx7L1029100 for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 07:59:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKH3u-0007Ya-21; Thu, 13 Nov 2003 07:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKH3c-0007Sn-Hb for sip@optimus.ietf.org; Thu, 13 Nov 2003 07:58:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22897 for ; Thu, 13 Nov 2003 07:58:33 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKH3b-00043k-00 for sip@ietf.org; Thu, 13 Nov 2003 07:58:43 -0500 Received: from news.ubiquity.net ([194.202.146.92] helo=gbnewp0186s1.eu.ubiquity.net) by ietf-mx with smtp (Exim 4.12) id 1AKH3b-00043h-00 for sip@ietf.org; Thu, 13 Nov 2003 07:58:43 -0500 Received: from mailhost.eu.ubiquity.net by gbnewp0186s1.eu.ubiquity.net via smtpd (for ietf-mx.ietf.org [132.151.6.1]) with SMTP; Thu, 13 Nov 2003 13:01:17 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Subject: RE: [Sip] PUBLISH message rates Date: Thu, 13 Nov 2003 12:58:41 -0000 Message-ID: <45730E094814E44488F789C1CDED27AE0219B10F@gbnewp0758m.eu.ubiquity.net> Thread-Topic: [Sip] PUBLISH message rates Thread-Index: AcOpmxoFULn/TgWJS82PV9Ec+inZqgASalET From: "Chris Boulton" To: "Ben Campbell" , "Adam Roach" Cc: Content-Transfer-Encoding: base64 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: base64 QmVuLA0KPDxzZWUgY29tbWVudHM+Pg0KDQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0gDQoJ RnJvbTogQmVuIENhbXBiZWxsIFttYWlsdG86YmNhbXBiZWxsQGR5bmFtaWNzb2Z0LmNvbV0gDQoJ U2VudDogVGh1IDEzLzExLzIwMDMgMDM6MjggDQoJVG86IEFkYW0gUm9hY2ggDQoJQ2M6ICdzaXBA aWV0Zi5vcmcnIA0KCVN1YmplY3Q6IFJlOiBbU2lwXSBQVUJMSVNIIG1lc3NhZ2UgcmF0ZXMNCgkN CgkNCg0KCUFyZSB3ZSBhc3N1bWluZyB0aGF0IGFueSBldmVudCBwYWNrYWdlIGNhbiBhdXRvbWF0 aWNhbGx5IGJlIHVzZWQgd2l0aA0KCXB1Ymxpc2g/IE9yIGRvIHdlIGV4cGVjdCBleHBsaWNpdCBk b2N1bWVudGF0aW9uIGFib3V0IGhvdyB0byB1c2UgcHVibGlzaA0KCXdpdGggYSBwYWNrYWdlPyBN YXliZSBmdXR1cmUgZXZlbnQgcGFja2FnZXMgc2hvdWxkIGRvY3VtZW50IHVzZSBvZg0KCXB1Ymxp c2ggYXMgcGFydCBvZiB0aGUgcGFja2FnZSBkb2N1bWVudGF0aW9uLg0KDQoJPDwgSSB0aGluayB0 aGF0IHdlIGhhdmUgdG8gYXNzdW1lIHRoYXQgZXZlcnkgZXZlbnQgcGFjYWthZ2UgQ09VTEQgdXNl IFBVQkxJU0ggaW4gc29tZQ0KDQoJc2hhcGUgb3IgZm9ybS4gIEV2ZW4gaWYgaW5pdGlhbGx5IHRo ZSB1c2UgZG9lcyBub3Qgc2VlbSBvYnZpb3VzLj4+DQoJDQoJSWYgd2UgZG8gZXhwZWN0IHBhY2th Z2Ugc3BlY2lmaWMgZG9jdW1lbnRhdGlvbiBmb3IgdGhlIHVzZSBvZiBQVUJMSVNILA0KCXRoZW4g aXQgd291dWxkIG1ha2Ugc2Vuc2UgdG8gYXNrIGZvciBpdCB0byBzcGVjaWZ5IHRoZSBiZWhhdmlv ciBqdXN0DQoJbGlrZSB3ZSBleHBlY3QgcGFja2FnZSBkb2N1bWVudGF0aW9uIHRvIGRvIGl0LiBP bmUgb3B0aW9uIHdvdWxkIGJlIHRvDQoJc3RhdGUgdGhhdCB0aGUgcnVsZXMgYXJlIGluaGVyaXRl ZCBmcm9tIHRoZSBOT1RJRlkgZG9jdW1lbnRhdGlvbi4gQnV0DQoJZm9yIHNvbWUgcGFja2FnZXMs IG90aGVyIGFwcHJvYWNoZXMgbWF5IG1ha2Ugc2Vuc2UuDQoNCgk8PCAgSSBtYXkgYmUgbWlzc2lu ZyBzb21ldGhpbmcgQlVUIEkgZG9uJ3Qgc2VlIGhvdyB0aGlzIGhlbHBzLCBlc3BlY2lhbGx5IGlu IHRoZSBjYXNlIG9mIA0KDQoJbGFyZ2UgKGFuZCBwb3RlbnRpYWxseSAgZXhwYW5kaW5nKSBudW1i ZXJzIG9mIFBBIGFsbCBQdWJsaXNoaW5nIGF0IHRoZSBzYW1lIHRpbWUuPj4gICANCgkNCglBZGFt IFJvYWNoIHdyb3RlOg0KCQ0KCT4gVG8gZ2V0IHRoZSBjb252ZXJzYXRpb24gc3RhcnRlZCBvbiB0 aGUgbGlzdCwgSSdsbCBzdW1tYXJpemUNCgk+IHdoYXQgSSBoZWFyZCBhcyBzYWxpZW50IHBvaW50 cyBiZWluZyBtYWRlIGF0IHRoZSBtaWNyb3Bob25lLg0KCT4NCgk+ICAtIEV2ZW50IHBhY2thZ2Vz IGRlZmluZSBTSE9VTEQgb3IgTVVTVCBzdHJlbmd0aCByZXF1aXJlbWVudHMNCgk+ICAgIHRoYXQg Tk9USUZZcyBjYW5ub3QgYmUgc2VudCBmYXN0ZXIgdGhhbiBhIGhhcmQgbGltaXQuDQoJPiAgICBB a2kncyBwcm9wb3NhbCBjYW4gYmUgc3VtbWFyaXplZCBhczogUFVCTElTSCB3aWxsIGluaGVyaXQN Cgk+ICAgIHRoZXNlIGhhcmQgbGltaXRzIGFzIG1heGltdW0gcmF0ZXMgb2YgcHVibGljYXRpb24u DQoJPg0KCT4gIC0gSXQgd2FzIHBvaW50ZWQgb3V0IHRoYXQgcmVjaXBpZW50cyBvZiBQVUJMSVNI IHJlcXVlc3RzIGNhbg0KCT4gICAgcHVzaCBiYWNrIGFnYWluc3QgZXhjZXNzaXZlIHRyYWZmaWMg d2l0aCA1eHggY2xhc3MgcmVzcG9uc2VzDQoJPiAgICB0aGF0IGhhdmUgIlJldHJ5LUFmdGVyIiBo ZWFkZXJzLg0KCT4NCgk+ICAtIEEgcG9pbnQgd2FzIG1hZGUgdGhhdCBOT1RJRlkgd2lsbCBvZnRl biBiZSBzdWJqZWN0IHRvIGZpbHRlcmluZywNCgk+ICAgIGluIHdoaWNoIGNhc2UgdGhlcmUgaXMg bm8gb25lLXRvLW9uZSBjb3JyZWxhdGlvbiBiZXR3ZWVuIHRoZQ0KCT4gICAgYW1vdW50IG9mIGlu Zm9ybWF0aW9uIHNlbnQgdG8gYW4gZXZlbnQgc2VydmVyIGluIFBVQkxJU0ggYW5kDQoJPiAgICB0 aGUgYW1vdW50IG9mIGluZm9ybWF0aW9uIHNlbnQgYnkgYW4gZXZlbnQgc2VydmVyIGluIE5PVElG WXMuDQoJPg0KCT4gVG8gYmUgaG9uZXN0LCBhZnRlciBnaXZpbmcgdGhlIHRvcGljIGEgYml0IG1v cmUgdGhvdWdodCwgSSdtDQoJPiBzb21ld2hhdCBvbiB0aGUgZmVuY2UuDQoJPg0KCT4gL2ENCgk+ DQoJPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KCT4g U2lwIG1haWxpbmcgbGlzdCAgaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2lwDQoJPiBUaGlzIGxpc3QgaXMgZm9yIE5FVyBkZXZlbG9wbWVudCBvZiB0aGUgY29yZSBTSVAg UHJvdG9jb2wNCgk+IFVzZSBzaXAtaW1wbGVtZW50b3JzQGNzLmNvbHVtYmlhLmVkdSBmb3IgcXVl c3Rpb25zIG9uIGN1cnJlbnQgc2lwDQoJPiBVc2Ugc2lwcGluZ0BpZXRmLm9yZyBmb3IgbmV3IGRl dmVsb3BtZW50cyBvbiB0aGUgYXBwbGljYXRpb24gb2Ygc2lwDQoJDQoJDQoJDQoJX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCglTaXAgbWFpbGluZyBsaXN0 ICBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXANCglUaGlzIGxpc3Qg aXMgZm9yIE5FVyBkZXZlbG9wbWVudCBvZiB0aGUgY29yZSBTSVAgUHJvdG9jb2wNCglVc2Ugc2lw LWltcGxlbWVudG9yc0Bjcy5jb2x1bWJpYS5lZHUgZm9yIHF1ZXN0aW9ucyBvbiBjdXJyZW50IHNp cA0KCVVzZSBzaXBwaW5nQGlldGYub3JnIGZvciBuZXcgZGV2ZWxvcG1lbnRzIG9uIHRoZSBhcHBs aWNhdGlvbiBvZiBzaXANCgkNCg0K _______________________________________________ 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 exim@www1.ietf.org Thu Nov 13 08:30:42 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25231 for ; Thu, 13 Nov 2003 08:30:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKHYE-0000rd-BA for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 08:30:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADDUMnX003321 for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 08:30:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKHXv-0000ms-GF; Thu, 13 Nov 2003 08:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AJQX7-0000V6-Jw for sip@optimus.ietf.org; Mon, 10 Nov 2003 23:53:41 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05757 for ; Mon, 10 Nov 2003 23:53:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AJQX5-0004pH-00 for sip@ietf.org; Mon, 10 Nov 2003 23:53:39 -0500 Received: from h65s138a81n47.user.nortelnetworks.com ([47.81.138.65] helo=zsc3s004.nortelnetworks.com) by ietf-mx with esmtp (Exim 4.12) id 1AJQX4-0004p6-00 for sip@ietf.org; Mon, 10 Nov 2003 23:53:38 -0500 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zsc3s004.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAB4qqg27532; Mon, 10 Nov 2003 20:52:52 -0800 (PST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 10 Nov 2003 22:52:52 -0600 Message-ID: <870397D7C140C84DB081B88396458DAF578DFB@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Eric Burger'" , Rohan Mahy Cc: "SIP List (E-mail)" Subject: RE: [Sip] Comments on history-info Date: Mon, 10 Nov 2003 22:52:43 -0600 X-Mailer: Internet Mail Service (5.5.2653.19) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Eric, Thanks for your comments and reviewing the draft. I can add an example in the next version. Mary. -----Original Message----- From: Eric Burger [mailto:eburger@snowshore.com] Sent: Monday, November 10, 2003 5:28 PM To: Rohan Mahy Cc: SIP List (E-mail) Subject: RE: [Sip] Comments on history-info Whoops! I should have looked closer at the ABNF. Maybe we should include an example that has multiple lines. Otherwise, we KNOW people will look at the examples, think everything has to go on a single line, and then barf when a fully conformant UA sends a response with multiple lines. > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Mon, November 10, 2003 12:32 PM > To: Eric Burger > Cc: SIP List (E-mail) > Subject: Re: [Sip] Comments on history-info > > > On Thursday, November 6, 2003, at 01:44 AM, Eric Burger wrote: > > Big question: > > Why don't we use multiple History-Info headers, instead of a > > (potentially VERY long) single header? > > Hey Eric, > > These are semantically equivalent and implementations are supposed to > support receiving BOTH syntaxes. > > Just like: > > Supported: 100rel, timer, replaces > > is equivalent to > > Supported: 100rel > Supported: timer > Supported: replaces > > AND > > Via: SIP/2.0/TCP sip1.example.com, SIP/2.0/TCP sip2.example.com, > SIP/2.0/TCP sip3.example.com > > is equivalent to > > Via: SIP/2.0/TCP sip1.example.com > Via: SIP/2.0/TCP sip2.example.com > Via: SIP/2.0/TCP sip3.example.com > > (branches omitted for clarity) > > Bottom Line: The draft is using the correct BNF. > > thanks, > -rohan > > > I would argue for multiple headers on two grounds. > > > > First, the idea of a proxy modifying history information > doesn't sound > > smart. If it screws up, it is hard to figure out who screwed up. > > > > Second, the index parameter frees us from worrying about > header order, > > which is a VERY good thing. > > > > > > > > Overview: > > While the motivation for History-Info is for the initiator of a > > request to know what happened to a request, it is also of > great use to > > the recipient (End of Section 2 overview paragraph). > > > > Section 1.2: > > How is History-Info any different than Via w.r.t. security? > > > > > > > > Nits: > > Section 2.5, first paragraph, last sentence: > > this would like be a local > > this would likely be a local > > ^^ > > > > Appendix B, message F8, extra space before last > angle-bracket in the > > History-Info line. > > > > > > _______________________________________________ > > 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 exim@www1.ietf.org Thu Nov 13 10:24:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02627 for ; Thu, 13 Nov 2003 10:24:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJKW-0002kA-JQ for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 10:24:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADFOK1P010545 for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 10:24:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJKF-0002fS-2Q; Thu, 13 Nov 2003 10:24:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJK7-0002eP-SP for sip@optimus.ietf.org; Thu, 13 Nov 2003 10:23:55 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02562 for ; Thu, 13 Nov 2003 10:23:42 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJK5-0006nB-00 for sip@ietf.org; Thu, 13 Nov 2003 10:23:53 -0500 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AKJK4-0006mc-00 for sip@ietf.org; Thu, 13 Nov 2003 10:23:52 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hADFN6Y08179; Thu, 13 Nov 2003 09:23:08 -0600 (CST) Received: from lucent.com (vkg.lra.lucent.com [192.11.62.150]) by ihmail.ih.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id hADFN1503523; Thu, 13 Nov 2003 09:23:01 -0600 (CST) Message-ID: <3FB3A1D6.6050607@lucent.com> Date: Thu, 13 Nov 2003 09:23:02 -0600 From: "Vijay K. Gurbani" Organization: Wireless Research and Development Group User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: seancolson@yahoo.com, "'Christian Stredicke'" , sip@ietf.org, rajnishjain@xl.com Subject: Re: [Sip] Connection: Keep-Alive References: <200311130738.hAD7ch0K023866@mail2.dynamicsoft.com> <3FB335FA.7000900@dynamicsoft.com> In-Reply-To: <3FB335FA.7000900@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Sorry for not being clear - I wasnt saying we DONT want a document. At > the meeting today, I advocated (and I think many others agreed) for > creation of a document. In particular, I think it makes sense to have a > proposed standard document that describes all of the issues with getting > tcp to work. This would presumably be an expansion of the existing > connect-reuse draft. It needs to be PS since there is normative behavior > associated with many parts of it. Jonathan: Thanks. A document will go a long way. My experience has been that many existing implementations do not keep connections open in any deterministic manner. As the I-D I presented in Atlanta indicates, I still think there is some amount of advantages to actually negotiating a persistent connection instead of simply relying on server implementations to keep the connection open and implement a LRU algorithm to do connection garbage collection. Clients behind a NAT may want to signal to the server to keep the connection alive. But in the absence of a negotiation, I am happy to at least have some work go into specifying connection management and reuse techniques. Will the co-chairs designate a design team, or should we "go and do it". The Atlanta I-D and discussion was a start to "go and do it", but it'll be good to have more folks involved with some recognition from the chairs. Cheers, - 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 exim@www1.ietf.org Thu Nov 13 11:03:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04870 for ; Thu, 13 Nov 2003 11:03:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJw9-0006nZ-Bu for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 11:03:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADG3DQe026132 for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 11:03:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJvz-0006lh-26; Thu, 13 Nov 2003 11:03:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKJvk-0006kb-38 for sip@optimus.ietf.org; Thu, 13 Nov 2003 11:02:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04700 for ; Thu, 13 Nov 2003 11:02:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKJvh-0007bF-00 for sip@ietf.org; Thu, 13 Nov 2003 11:02:45 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AKJvh-0007aT-00 for sip@ietf.org; Thu, 13 Nov 2003 11:02:45 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hADG1r9D021371; Thu, 13 Nov 2003 11:01:53 -0500 (EST) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hADG1rg23271; Thu, 13 Nov 2003 11:01:53 -0500 Message-ID: <3FB3AAF0.4070701@cs.columbia.edu> Date: Thu, 13 Nov 2003 11:01:52 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Adam Roach , "'sip@ietf.org'" Subject: Re: [Sip] PUBLISH message rates References: <9BF66EBF6BEFD942915B4D4D45C051F3E865FD@dyn-tx-exch-001.dynamicsoft.com> <3FB2972C.7010608@cs.columbia.edu> <3FB33044.1000201@dynamicsoft.com> In-Reply-To: <3FB33044.1000201@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit We should look at the motivation for the rate limitation. It can't be transport - that's a separate problem. There is some justification for limiting NOTIFYs since these are directed to devices that have a loose relationship to the PA. Also, these devices may have limited capabilities and may not be ready to receive 100 notifications/second. However, in most cases of interest, the PA and the publisher are closely related. In addition, since the end system has complete control over the rate of sending PUBLISH, the 'protect low-end end systems' arguments doesn't apply. I don't see why a spec should proscribe how often my UA and my PA can talk to each other. I'm not aware of any other Internet application protocol that makes such recommendations. We don't have a spec that says that you have to limit your SMTP rate to your outbound MTA to a certain value. I'm philosophically opposed to "pulled out of thin air" recommendations that are ineffective and have no engineering basis. Jonathan Rosenberg wrote: > > > Henning Schulzrinne wrote: > >> To amplify the third point: Since multiple entities may publish for >> the same presentity, for example, the NOTIFY rate may be as high as >> the sum of the PUBLISH rates. Thus, restricting PUBLISH cannot be >> relied upon to limit the NOTIFY rate, since the different PUBLISH >> sources presumably have no idea what others have been up to. > > > I didnt think the intent was to use a limit on the PUBLISH rate to > enforce the limit on the NOTIFY rate. But why else tie the two rates in any way? > > I think the point was that, if we believed there was value in limiting > the NOTIFY rate (and we do, according to rfc3265), there is probably > value in limiting the PUBLISH rate too. > > I dont feel that strongly about this, since I think its a non-issue > practically speaking until we have packages that really push limits. > Before we get there, its mostly an academic exercise. > > In that case, I am inclined to go for consistency, and have PUBLISH > limited in rate as NOTIFYs are within a package. > > -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 exim@www1.ietf.org Thu Nov 13 11:45:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06974 for ; Thu, 13 Nov 2003 11:45:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKar-0002Tw-B2 for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 11:45:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADGjHRT009534 for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 11:45:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKad-0002Sl-GN; Thu, 13 Nov 2003 11:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKZf-0002QD-LF for sip@optimus.ietf.org; Thu, 13 Nov 2003 11:44:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06936 for ; Thu, 13 Nov 2003 11:43:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKKZe-0000Wx-00 for sip@ietf.org; Thu, 13 Nov 2003 11:44:02 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AKKZd-0000Wu-00 for sip@ietf.org; Thu, 13 Nov 2003 11:44:02 -0500 Received: from esvir01nok.ntc.nokia.com (esvir01nokt.ntc.nokia.com [172.21.143.33]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hADGi0A12011 for ; Thu, 13 Nov 2003 18:44:00 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir01nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Nov 2003 18:43:59 +0200 Received: from nokia.com ([10.162.15.98]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 13 Nov 2003 18:43:59 +0200 Message-ID: <3FB3B4CE.3080001@nokia.com> Date: Thu, 13 Nov 2003 18:43:58 +0200 From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Henning Schulzrinne CC: Jonathan Rosenberg , Adam Roach , "'sip@ietf.org'" Subject: Re: [Sip] PUBLISH message rates References: <9BF66EBF6BEFD942915B4D4D45C051F3E865FD@dyn-tx-exch-001.dynamicsoft.com> <3FB2972C.7010608@cs.columbia.edu> <3FB33044.1000201@dynamicsoft.com> <3FB3AAF0.4070701@cs.columbia.edu> In-Reply-To: <3FB3AAF0.4070701@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Nov 2003 16:44:00.0085 (UTC) FILETIME=[5697C050:01C3AA05] Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit ext Henning Schulzrinne wrote: > We should look at the motivation for the rate limitation. It can't be > transport - that's a separate problem. There is some justification for > limiting NOTIFYs since these are directed to devices that have a loose > relationship to the PA. Also, these devices may have limited > capabilities and may not be ready to receive 100 notifications/second. Even this isn't solved using the default rate limit in notifications, because it will only apply to a single notifier. Typically, an endpoint has many active subscriptions, so the aggregate rate may still be considerable. The event-throttle work attempts to address this. > However, in most cases of interest, the PA and the publisher are closely > related. In addition, since the end system has complete control over the > rate of sending PUBLISH, the 'protect low-end end systems' arguments > doesn't apply. Right, it would mainly be about protecting the SIP routing fabric and the composer. > I don't see why a spec should proscribe how often my UA and my PA can > talk to each other. I'm not aware of any other Internet application > protocol that makes such recommendations. We don't have a spec that says > that you have to limit your SMTP rate to your outbound MTA to a certain > value. > > I'm philosophically opposed to "pulled out of thin air" recommendations > that are ineffective and have no engineering basis. I guess these recommendations would anyway be "hand-waiving" with or without a hard rate limit recommendations. It's not like the rate could ever really be enforced in a meaningful way. I think we can agree that documenting this issue is a good thing. Also, I would say explaining how a composer can use the SIP level push-back should be in the draft. Whether to have a concrete rate limit or not, I'm ok either way. I can suggest text that has a SHOULD strength recommendation that publishing EPAs pay attention to the rate at which they send updates. Cheers, Aki > Jonathan Rosenberg wrote: > >> >> >> Henning Schulzrinne wrote: >> >>> To amplify the third point: Since multiple entities may publish for >>> the same presentity, for example, the NOTIFY rate may be as high as >>> the sum of the PUBLISH rates. Thus, restricting PUBLISH cannot be >>> relied upon to limit the NOTIFY rate, since the different PUBLISH >>> sources presumably have no idea what others have been up to. >> >> >> >> I didnt think the intent was to use a limit on the PUBLISH rate to >> enforce the limit on the NOTIFY rate. > > > But why else tie the two rates in any way? > >> >> I think the point was that, if we believed there was value in limiting >> the NOTIFY rate (and we do, according to rfc3265), there is probably >> value in limiting the PUBLISH rate too. >> >> I dont feel that strongly about this, since I think its a non-issue >> practically speaking until we have packages that really push limits. >> Before we get there, its mostly an academic exercise. >> >> In that case, I am inclined to go for consistency, and have PUBLISH >> limited in rate as NOTIFYs are within a package. >> >> -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 From exim@www1.ietf.org Thu Nov 13 12:03:09 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08111 for ; Thu, 13 Nov 2003 12:03:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKrn-0004Kx-SB for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 12:02:51 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADH2lHO016670 for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 12:02:47 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKr6-0004Fo-Px; Thu, 13 Nov 2003 12:02:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKKqd-00049c-Uj for sip@optimus.ietf.org; Thu, 13 Nov 2003 12:01:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08025 for ; Thu, 13 Nov 2003 12:01:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKKqc-0000wB-00 for sip@ietf.org; Thu, 13 Nov 2003 12:01:34 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AKKqb-0000vs-00 for sip@ietf.org; Thu, 13 Nov 2003 12:01:34 -0500 Received: from magnum.cs.columbia.edu (IDENT:root@magnum.cs.columbia.edu [128.59.16.117]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hADH0r9D028628; Thu, 13 Nov 2003 12:00:53 -0500 (EST) Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) by magnum.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hADH0pg29187; Thu, 13 Nov 2003 12:00:53 -0500 Message-ID: <3FB3B8C3.7010906@cs.columbia.edu> Date: Thu, 13 Nov 2003 12:00:51 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Aki Niemi CC: Jonathan Rosenberg , Adam Roach , "'sip@ietf.org'" Subject: Re: [Sip] PUBLISH message rates References: <9BF66EBF6BEFD942915B4D4D45C051F3E865FD@dyn-tx-exch-001.dynamicsoft.com> <3FB2972C.7010608@cs.columbia.edu> <3FB33044.1000201@dynamicsoft.com> <3FB3AAF0.4070701@cs.columbia.edu> <3FB3B4CE.3080001@nokia.com> In-Reply-To: <3FB3B4CE.3080001@nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Even this isn't solved using the default rate limit in notifications, > because it will only apply to a single notifier. Typically, an endpoint > has many active subscriptions, so the aggregate rate may still be > considerable. The event-throttle work attempts to address this. True (and somewhat beyond the topic of this discussion). One could defend the rate limit in the NOTIFY case in arguing that at least the poor resource-constrained UA knows that it is subscribing to N events and thus can upperbound the event rate by summing them up. The PA can't, since it has generally no way of knowing how many entities will publish for a single event. > >> However, in most cases of interest, the PA and the publisher are >> closely related. In addition, since the end system has complete >> control over the rate of sending PUBLISH, the 'protect low-end end >> systems' arguments doesn't apply. > > > Right, it would mainly be about protecting the SIP routing fabric and > the composer. Since it doesn't in any way limit the aggregate rate, this is a very loose way to protect anything. As noted, we don't limit the individual rate of sending email in the Internet by protocol spec to protect the aggregate MTA population. (Obviously, individual ISPs do sometimes apply rate limits for email submission to keep spammers out of their network, but that's a local policy decision, not a protocol decision.) > I guess these recommendations would anyway be "hand-waiving" with or > without a hard rate limit recommendations. It's not like the rate could > ever really be enforced in a meaningful way. We have Congress to pass meaningless declarations of good intent, so no need for the IETF to get into that business :-) > > I think we can agree that documenting this issue is a good thing. Also, > I would say explaining how a composer can use the SIP level push-back > should be in the draft. Whether to have a concrete rate limit or not, > I'm ok either way. I can suggest text that has a SHOULD strength > recommendation that publishing EPAs pay attention to the rate at which > they send updates. My basic test for any protocol spec normative statement is whether I can tell if somebody is violating the spec by observing external behavior. I'm unclear how I can measure 'paying attention' - I have a hard enough time with telling whether my students are ... _______________________________________________ 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 exim@www1.ietf.org Thu Nov 13 14:09:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13269 for ; Thu, 13 Nov 2003 14:09:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKMq6-0004si-53 for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 14:09:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADJ9AEd018704 for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 14:09:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKMpx-0004nv-D6; Thu, 13 Nov 2003 14:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKMp0-0004d6-IV for sip@optimus.ietf.org; Thu, 13 Nov 2003 14:08:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13118 for ; Thu, 13 Nov 2003 14:07:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKMoy-00031F-00 for sip@ietf.org; Thu, 13 Nov 2003 14:08:00 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AKMox-00030w-00 for sip@ietf.org; Thu, 13 Nov 2003 14:07:59 -0500 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hADJ7RAt024359; Thu, 13 Nov 2003 11:07:27 -0800 (PST) Received: from [130.129.129.178] (rtp-vpn1-41.cisco.com [10.82.224.41]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJX82245; Thu, 13 Nov 2003 11:07:08 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 13 Nov 2003 08:26:31 -0800 Subject: Re: [Sip] GRUU, Contacts, and privacy From: Cullen Jennings To: Adam Roach , "'Alan Johnston'" , , , Jonathan Rosenberg CC: Paul Kyzivat , Orit Levin Message-ID: In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E865FE@dyn-tx-exch-001.dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ok, I can live with that. Cullen > Alan Johnston [mailto:alan.johnston@mci.com] writes: > >> I agree 100%. A private Contact URI is just one small piece >> of the privacy puzzle. I think this privacy requirement should >> be removed. _______________________________________________ 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 exim@www1.ietf.org Thu Nov 13 16:53:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22529 for ; Thu, 13 Nov 2003 16:53:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKPOt-0000nt-EL for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 16:53:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADLrFGk003085 for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 16:53:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKPOf-0000kH-LI; Thu, 13 Nov 2003 16:53:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKPNi-0000io-MX for sip@optimus.ietf.org; Thu, 13 Nov 2003 16:52:02 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22469 for ; Thu, 13 Nov 2003 16:51:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKPNg-00061N-00 for sip@ietf.org; Thu, 13 Nov 2003 16:52:00 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AKPNf-00061G-00 for sip@ietf.org; Thu, 13 Nov 2003 16:52:00 -0500 Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hADLpx606561 for ; Thu, 13 Nov 2003 23:51:59 +0200 (EET) Received: from esebh002.NOE.Nokia.com (unverified) by esvir04nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 13 Nov 2003 23:51:59 +0200 Received: from nokia.com ([10.162.14.154]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Thu, 13 Nov 2003 23:51:57 +0200 Message-ID: <3FB3FCFA.7040309@nokia.com> Date: Thu, 13 Nov 2003 23:51:54 +0200 From: Aki Niemi User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030901 Thunderbird/0.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ext Chris Boulton CC: Ben Campbell , Adam Roach , sip@ietf.org Subject: Re: [Sip] PUBLISH message rates References: <45730E094814E44488F789C1CDED27AE0219B10F@gbnewp0758m.eu.ubiquity.net> In-Reply-To: <45730E094814E44488F789C1CDED27AE0219B10F@gbnewp0758m.eu.ubiquity.net> Content-Type: text/plain; charset=UTF-8; format=flowed X-OriginalArrivalTime: 13 Nov 2003 21:51:57.0873 (UTC) FILETIME=[5C367210:01C3AA30] Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-x4.nokia.com id hADLpx606561 Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable ext Chris Boulton wrote: > Ben, <> >=20 > -----Original Message----- From: Ben Campbell > [mailto:bcampbell@dynamicsoft.com] Sent: Thu 13/11/2003 03:28 To: > Adam Roach Cc: 'sip@ietf.org' Subject: Re: [Sip] PUBLISH message > rates =20 >=20 > Are we assuming that any event package can automatically be used with > publish? Or do we expect explicit documentation about how to use > publish with a package? Maybe future event packages should document > use of publish as part of the package documentation. >=20 > << I think that we have to assume that every event pacakage COULD use > PUBLISH in some >=20 > shape or form. Even if initially the use does not seem obvious.>> =20 > If we do expect package specific documentation for the use of > PUBLISH, then it wouuld make sense to ask for it to specify the > behavior just like we expect package documentation to do it. One > option would be to state that the rules are inherited from the NOTIFY > documentation. But for some packages, other approaches may make > sense. >=20 > << I may be missing something BUT I don't see how this helps, > especially in the case of >=20 > large (and potentially expanding) numbers of PA all Publishing at > the same time.>> =20 It doesn't. That is a separate problem, and one way to address this=20 would be the SIP level push-back from the composer. I'm inclined to agree with Henning on this. We could inherit the event=20 package specific limits, but in PUBLISH, they are even more useless. At=20 least in NOTIFYs, given the default rate of 1/x, the subscriber can=20 calculate the absolute aggregate rate of its y subscriptions: y * 1/x. The composer doesn't have that possibility. Cheers, Aki Adam Roach wrote: > To get the conversation > started on the list, I'll summarize > what I heard as salient points > being made at the microphone. > > - Event packages define SHOULD or > MUST strength requirements > that NOTIFYs cannot be sent faster > than a hard limit. > Aki's proposal can be summarized as: PUBLISH > will inherit > these hard limits as maximum rates of publication.=20 > > > - It was pointed out that recipients of PUBLISH requests can > > push back against excessive traffic with 5xx class responses > > that have "Retry-After" headers. > > - A point was made that NOTIFY > will often be subject to filtering, > in which case there is no > one-to-one correlation between the > amount of information sent to > an event server in PUBLISH and > the amount of information sent by > an event server in NOTIFYs. > > To be honest, after giving the topic > a bit more thought, I'm > somewhat on the fence. > > /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 =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 > J*fj)b? > b??m????=0C0?'?~???f??f??X??)=DF=A3?"?8b?X??+=1F??DY=D7=AFzZ)????ay?+y"= =0F>?-??%R=C7=AC????W?z{h??,r?n???y=DB=9F???z?b?{(?=CB=AB???*T??"????'?~?= ?~??{=07^??h?g???'?=17???bq?b?z=1Fsip=3D _______________________________________________ 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 exim@www1.ietf.org Thu Nov 13 18:38:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29730 for ; Thu, 13 Nov 2003 18:38:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKR2c-0001y9-2a for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 18:38:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hADNcMSY007565 for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 18:38:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKR2L-0001lU-3Z; Thu, 13 Nov 2003 18:38:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKR1y-0001gt-Mo for sip@optimus.ietf.org; Thu, 13 Nov 2003 18:37:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29624 for ; Thu, 13 Nov 2003 18:37:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKR1v-0000HK-00 for sip@ietf.org; Thu, 13 Nov 2003 18:37:39 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AKR1u-0000Gd-00 for sip@ietf.org; Thu, 13 Nov 2003 18:37:38 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 13 Nov 2003 15:44:15 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hADNb7At028196; Thu, 13 Nov 2003 15:37:07 -0800 (PST) Received: from [130.129.129.178] (sjc-vpn3-209.cisco.com [10.21.64.209]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJY15316; Thu, 13 Nov 2003 15:37:05 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 13 Nov 2003 15:11:12 -0800 Subject: Re: [Sip] Certificates handling in SIP/TLS From: Cullen Jennings To: Johan Bilien , Message-ID: In-Reply-To: <20031110162032.GA29896@via.ecp.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 11/10/03 8:20 AM, "Johan Bilien" wrote: > On Sun, Nov 09, 2003, Cullen Jennings wrote: >>> . When the mutual authentication isn't used, should the TLS connection >>> between the proxy and the UA be kept alive after the first >>> registration ? >> >> Yes - and it it goes down, the UA should re-register. If you are behind many >> types of firewalls or gasp worse yet a NAT, you will have to do this even if >> you are not using TLS. > > So the client should check continuously that the connection is up ? And > if the connection goes down, and the client does not see it for some > reason, the server will not be able to forward the next INVITE messages. > In some cases, it is not very convenient to have to maintain a > connection alive, for example in case of mobile IP. Yes I agree. > > On the other hand, having the UA being able to handle TLS-server > connections would allow to re-establish a closed connection in any case. > Using TLS session resumption, re-establishing the connection is very > fast. The need for a UA certificate has other motivations (see below). > This is good as long as you have stable address that is used to reach the device that can be bound into the credentials of the device. This is typically true in wireless systems. However, with IP phones or soft phones often get their address via DHCP and do not have a stable IP address or DNS domain name and this is unfortunately what is used to address them. I agree that session resumption can greatly speed the set up. > >>> . When using mutual authentication, to which identity should the UA >>> certificate's CN refer ? To the FQDN of the UA, or to the SIP URI ? >> >> It's really the SubjectAltname not the CN that should be used in SIP. This >> should refer to the same FQDN as the proxy would be trying to connect to - >> this basically means it needs to assert the hostname portion of of whatever >> it put in it's contact. This is not really possible if you got your >> hostname/IP via DHCP like nearly every device that registers does. I view >> mutual TLS as very useful between proxies and to things like gateways or >> voice mail servers but not really very practical to most devices where user >> register. > > In the case of a UA, having the certificate point to the FQDM doesn't > make much sense to me. On the other hand, having a certificate pointing > to the SIP URI of the user would allow several interesting things: I assume you mean the SIP AOR like sip:alice@example.com so you can do end to end or middle to end security. I agree this is a good idea but I think this what was being address by S/MIME stuff. > > . Replace the HTTP Digest client-to-proxy authentication with a TLS > mutual authentication. Sure - see e2m stuff. > > . Allow a user to switch from one device to another without having to > use different certificates. > This does introduce the tricky problem of making sure both devices have the same private key but yes. > . Use the same certificate for the signature of a Diffie-Hellman key > exchange, in a scheme such a MIKEY [1], and maybe for instant > messaging encryption and signature ... > > In this case, the association user-hostname would still be provided in a > secured way through the contact header, in the TLS-encrypted REGISTER. > > [1] http://www.ietf.org/internet-drafts/draft-ietf-msec-mikey-07.txt > > Best regards, _______________________________________________ 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 exim@www1.ietf.org Thu Nov 13 20:05:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02532 for ; Thu, 13 Nov 2003 20:05:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKSOh-0006SA-AM for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 20:05:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE15F3w024745 for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 20:05:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKSOV-0006Ps-0v; Thu, 13 Nov 2003 20:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKSNy-0006OJ-45 for sip@optimus.ietf.org; Thu, 13 Nov 2003 20:04:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02481 for ; Thu, 13 Nov 2003 20:04:19 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKSNw-0001bA-00 for sip@ietf.org; Thu, 13 Nov 2003 20:04:28 -0500 Received: from 138.muda.mnpl.sfldmibv.dsl.att.net ([12.98.223.138] helo=osrmail) by ietf-mx with esmtp (Exim 4.12) id 1AKSNv-0001b7-00 for sip@ietf.org; Thu, 13 Nov 2003 20:04:27 -0500 Received: from sip (127.0.0.1) by localhost (127.0.0.1) with [XMail 0.74 (Win32/Ix86) ESMTP Server] id for from ; Thu, 13 Nov 2003 16:58:35 -0000 From: "Christian Stredicke" To: "Rohan Mahy" Cc: Date: Thu, 13 Nov 2003 19:04:45 -0600 Message-ID: <061901c3aa4b$4d579380$be08f20a@sip> 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.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Subject: [Sip] Dialog-State Use Cases Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Rohan, looks like we have just been bombed back into the requirements phase of the dialog (or whatever the name is) package. I see the following use-cases: 1. STATUS information We need to see if a dialog is "ringing", "talking", "on hold", or has just been "terminated". Also it would be nice to have the to- and from, maybe referred-by and the start of the "talking" (so that we can calculate the duration). This information is nice for LED and SWITCHBOARD applications. 2. Call pickup, join, and other ACTIONS The dialog state subscriber needs to know what URL to dial in order to pick up a call or on how to join a call. Other actions might also be indicated. 3. The question of HANDSET-LIFTING We need to know if handsets have been lifted up (that's a simple requirement from the switchboard people which laugh at us if we say "impossible"; it is also needed for AUTOMATIC CALL BACK). We could model this as dialog where "to" is not set yet. That's all on my wish list! No need for CSeq or other stuff end-users are not interested in! Please don't forget SIP did not replace the good old PBX yet and there is a reason for this. CS _______________________________________________ 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 exim@www1.ietf.org Thu Nov 13 20:27:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03493 for ; Thu, 13 Nov 2003 20:27:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKSjq-0000fs-1x for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 20:27:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE1R66K002566 for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 20:27:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKSjl-0000eQ-V4; Thu, 13 Nov 2003 20:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKSjL-0000dZ-9a for sip@optimus.ietf.org; Thu, 13 Nov 2003 20:26:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03479 for ; Thu, 13 Nov 2003 20:26:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKSjI-00021E-00 for sip@ietf.org; Thu, 13 Nov 2003 20:26:32 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AKSjI-00020W-00 for sip@ietf.org; Thu, 13 Nov 2003 20:26:32 -0500 Received: from cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 13 Nov 2003 17:26:07 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAE1Ptxg004938; Thu, 13 Nov 2003 20:25:56 -0500 (EST) Received: from cisco.com (che-vpn-cluster-2-116.cisco.com [10.86.242.116]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADZ16725; Thu, 13 Nov 2003 20:25:54 -0500 (EST) Message-ID: <3FB42F22.2000004@cisco.com> Date: Thu, 13 Nov 2003 20:25:54 -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: Christian Stredicke CC: Rohan Mahy , sip@ietf.org Subject: Re: [Sip] Dialog-State Use Cases References: <061901c3aa4b$4d579380$be08f20a@sip> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I think a lot of confusion could be eliminated by renaming the document and the event package it defines. While it has something to do with dialogs, it isn't fundamentally about dialogs. For instance, it has *nothing* to do with dialogs containing only subscriptions. It is largely but not entirely related to dialogs that contain an invitation. But it is concerned with some things that can't be learned from just that. I suggest something like "call-info". More inline... Paul Christian Stredicke wrote: > > 3. The question of HANDSET-LIFTING > > We need to know if handsets have been lifted up (that's a simple > requirement from the switchboard people which laugh at us if we say > "impossible"; it is also needed for AUTOMATIC CALL BACK). We could model > this as dialog where "to" is not set yet. It really need have nothing to do with lifting a handset. Lots of devices don't even have a handset - at least not one you lift. I think it is about being in a state of preparing to make a call. But it is more than that, because not all devices would want to report this when preparing to make a call. It also has something to do with being unwilling or unable to receive a call while in this state, and/or wanting to seize a shared line resource. _______________________________________________ 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 exim@www1.ietf.org Thu Nov 13 22:51:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09937 for ; Thu, 13 Nov 2003 22:51:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKUzH-0003HL-9p for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 22:51:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE3pBUP012596 for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 22:51:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKUz9-0003Ff-JB; Thu, 13 Nov 2003 22:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKUyO-0003CP-04 for sip@optimus.ietf.org; Thu, 13 Nov 2003 22:50:16 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09892 for ; Thu, 13 Nov 2003 22:50:02 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKUyK-0004h8-00 for sip@ietf.org; Thu, 13 Nov 2003 22:50:12 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AKUyJ-0004gw-00 for sip@ietf.org; Thu, 13 Nov 2003 22:50:11 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAE3oAA28036 for ; Fri, 14 Nov 2003 05:50:10 +0200 (EET) Received: from esebh001.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Fri, 14 Nov 2003 05:50:06 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Fri, 14 Nov 2003 05:50:05 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] PUBLISH message rates Date: Fri, 14 Nov 2003 05:50:04 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB7017973D0@esebe019.ntc.nokia.com> Thread-Topic: [Sip] PUBLISH message rates Thread-Index: AcOqCBrGUaxg6O9LR3qKhM1+lWblGAAWOgIQ To: , Cc: , , X-OriginalArrivalTime: 14 Nov 2003 03:50:05.0383 (UTC) FILETIME=[63C44570:01C3AA62] Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable I agree with Henning. If there is ever 1 subscriber and 1 publisher, = then this rate limiting makes sense. But in many cases, especially = presence, there are n publishers. If there are 5 publishers for a package that limits the rate to 5 per = second. There will be 20 NOTIFYs and 100 PUBLISHs sent in one minute . = How does that help? The only way to do this right is to do what RTCP does with report = interval, and that is to adjust the rate of PUBLISH using some formula = that takes into account the number of publishers at a given time. The = more publishers that join, the less the rate at which PUBLISH is sent = at. The compositors need to communicate that calculated rate to the = publishers somehow. Do we want to make it that complicated? If not, then = I suggest adding text the says if the compositor is overloaded, it can = send a 5xx response with retry-after. Regards, Hisham > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext > Henning Schulzrinne > Sent: Thursday, November 13, 2003 7:01 PM > To: Niemi Aki (NMP/Helsinki) > Cc: Jonathan Rosenberg; Adam Roach; 'sip@ietf.org' > Subject: Re: [Sip] PUBLISH message rates >=20 >=20 > > Even this isn't solved using the default rate limit in=20 > notifications,=20 > > because it will only apply to a single notifier. Typically,=20 > an endpoint=20 > > has many active subscriptions, so the aggregate rate may still be=20 > > considerable. The event-throttle work attempts to address this. >=20 > True (and somewhat beyond the topic of this discussion). One could=20 > defend the rate limit in the NOTIFY case in arguing that at least the=20 > poor resource-constrained UA knows that it is subscribing to N events=20 > and thus can upperbound the event rate by summing them up.=20 > The PA can't,=20 > since it has generally no way of knowing how many entities=20 > will publish=20 > for a single event. >=20 >=20 > >=20 > >> However, in most cases of interest, the PA and the publisher are=20 > >> closely related. In addition, since the end system has complete=20 > >> control over the rate of sending PUBLISH, the 'protect low-end end=20 > >> systems' arguments doesn't apply. > >=20 > >=20 > > Right, it would mainly be about protecting the SIP routing=20 > fabric and=20 > > the composer. >=20 > Since it doesn't in any way limit the aggregate rate, this is a very=20 > loose way to protect anything. As noted, we don't limit the=20 > individual=20 > rate of sending email in the Internet by protocol spec to protect the=20 > aggregate MTA population. (Obviously, individual ISPs do=20 > sometimes apply=20 > rate limits for email submission to keep spammers out of=20 > their network,=20 > but that's a local policy decision, not a protocol decision.) >=20 >=20 >=20 > > I guess these recommendations would anyway be=20 > "hand-waiving" with or=20 > > without a hard rate limit recommendations. It's not like=20 > the rate could=20 > > ever really be enforced in a meaningful way. >=20 > We have Congress to pass meaningless declarations of good=20 > intent, so no=20 > need for the IETF to get into that business :-) >=20 > >=20 > > I think we can agree that documenting this issue is a good=20 > thing. Also,=20 > > I would say explaining how a composer can use the SIP level=20 > push-back=20 > > should be in the draft. Whether to have a concrete rate=20 > limit or not,=20 > > I'm ok either way. I can suggest text that has a SHOULD strength=20 > > recommendation that publishing EPAs pay attention to the=20 > rate at which=20 > > they send updates. >=20 > My basic test for any protocol spec normative statement is=20 > whether I can=20 > tell if somebody is violating the spec by observing external=20 > behavior.=20 > I'm unclear how I can measure 'paying attention' - I have a=20 > hard enough=20 > time with telling whether my students are ... >=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 _______________________________________________ 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 exim@www1.ietf.org Thu Nov 13 22:53:23 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10031 for ; Thu, 13 Nov 2003 22:53:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKV17-0003gD-AM for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 22:53:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE3r5iW014146 for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 22:53:05 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKV14-0003fE-6v; Thu, 13 Nov 2003 22:53:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKV0l-0003eg-FZ for sip@optimus.ietf.org; Thu, 13 Nov 2003 22:52:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10022 for ; Thu, 13 Nov 2003 22:52:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKV0h-0004jy-00 for sip@ietf.org; Thu, 13 Nov 2003 22:52:39 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1AKV0h-0004ju-00 for sip@ietf.org; Thu, 13 Nov 2003 22:52:39 -0500 Received: from softarmor.com (dyn131-204.ietf58.ietf.org [130.129.131.204]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id hAE3rdv4017285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 13 Nov 2003 21:53:41 -0600 Message-ID: <3FB4515C.9030603@softarmor.com> Date: Thu, 13 Nov 2003 21:51:56 -0600 From: Dean Willis User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org CC: rohan@cisco.com, Allison Mankin , Jon Peterson Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by bdsl.greycouncil.com id hAE3rdv4017285 Content-Transfer-Encoding: quoted-printable Subject: [Sip] Draft SIP Minutes for IETF 58 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Please review the follwing and correct where needed. Master copy posted at: http://www.softarmor.com/sipwg/meets/ietf58/notes/minutes-sipwg-ietf58.ht= ml Text follows: ---------------------------------- Draft Minutes, SIP WG, IETF 58 Official Scribe, Ben Campbell Supplementary Scribe, Vijay Gurbani Minutes Edited by Dean Willis Topic: Call to Order and Agenda Bash --------------------------------------- No issues raised. Topic: Status, Chairs --------------------- Slides presented. New milestones proposed. No schedule objections raised, but it was=20 proposed that the app-interaction framework be published as a proposed=20 standard instead of BCP. Concerns about MIB status raised. Noted that=20 SIP should certainly plan to operate at least through the current=20 work-elevation plan from SIPPING, which extends through December 2004. Topic: Congestion Safety, Dean Willis --------------------------------------- Reading list: draft-ietf-sip-congest-safe-02 There appears to be little interest in implementing this draft. Some=20 suggestions for simplifying it were made. It was also suggested that we=20 need to change RFC 3263to prefer TCP over UDP, explain congestion issues=20 and avoidance in a BCP, and complete the connection reuse work in order=20 to encourage TCP deployment. Many endpoints now implement only UDP. We=20 also need to differentiate fragmentation and congestion. It was noted=20 that this problem does not just apply to MESSAGE, but can be frequently=20 expected with NOTIFY, and with INVITES using S/MIME protection. DCCP is=20 only a partial solution. Several people volunteered to work on this=20 proposed BCP. It was also suggested that the current draft could be simplified to=20 eliminate new response codes 515 and 516, providing a minimal "NO UDP"=20 assurance. Topic: RFC 3312 Updates, Gonzalo Camarillo Reading list: draft-camarillo-sip-rfc3312-update-00.txt Slides presented. Suggested that we adopt as WG item. No objections were raised. Conclusion: adopt draft as wg item, negotiate milestone. Topic: Publish, Aki Niemi Reading List: draft-ietf-sip-publish-01 Slides presented. Issue: Should etags be updated on every publish? Consensus: Usage should=20 be made consistent with HTTP. If it cannot be, we should call these=20 something else. Issue: Publication rate. Proposed that rate from event package be used.=20 Noted that this is probably an irrelevant and meaningless number, as=20 there may be multiple publishers with no knowledge of each other. Much=20 debate ensued, with no resolution Further discussion deferred to the=20 mailing list. Topic: Request History, Mary Barnes Reading List: draft-ietf-sip-history-info-01 draft-jennings-sip-voicemail-uri-00.txt RFC 3087 Slides presented. Issue: r-uri captured anytime request is forwarded. Proposal: Only add=20 reason for history entries added due to retargeting. Issue: Privacy. Proposal: information not included when there are=20 privacy considerations. (when uas sets session or header level privacy) . Next steps: complete flow detail. Do we want to fold reqs into doc as=20 front matter? Request more mailing list feedback. Dependency on mid-end=20 security draft. Presentation of applicability to voicemail. Issue: Optionality. Suggested that we apply stronger language to suggest=20 applications gracefully degrade in absence of history. Issue: Implementability: Concerns raised by Robert Sparks, who will=20 detail on mailing list. Issue: Security. Note that this in-general seems to depend on the=20 middle-to-end and end-to-middle security work. Conclusion: Work should continue, but more thinking about optionality is=20 needed. RJS and Mary to talk offline. 1400 Non-Invite Transactions, Robert Sparks Reading list: draft-sparks-sip-noninvite-01.txt Slides presented. Noted that this problem is not related to the transport protocol, but is=20 specific to the SIP-layer transaction reliability mechanism for all=20 transactions other than INVITE. Several alternatives were presented: A) a series of tweaks B) Eliminate Timer F, allowing non-invite transactions to pend. C) USe path-timing estimation techniques to improve UAs knowledge of timi= ng. D) Revise 3263 caching language to reduce severity of impact. E) Ignore the problem Suggested that SIP be revised to use 3-way handshake like INVITE on all=20 transactions. This might be made backward-compatible through use of an=20 option tag. Polls indicated no consensus on any action, and that the working group=20 didn't understand the nature of problem or disagreed as to its severity.=20 Despite the objections of Morton Thiokol engineers, the shuttle was=20 launched in cold-weather conditions under which it had never been=20 tested, and the O-rings in the boosters failed. Conclusion: None. Further discussion deferred to the mailing list. Topic: GRUU, Jonathan Rosenberg Reading list: draft-rosenberg-sip-gruu-00.txt draft-rosenberg-sipping-gruu-reqs-01.txt Slides presented. Issue: GRUU generation for stateless proxy behavior. Consensus that we=20 need a sample algorithm for understanding. Issues: Liftime of a GRUU. Can a gruu change during a registration?=20 Conclusion: No, gruu is good for lifetime of registrations, refreshes=20 get same gruu. Do we need a guarantee of difference between registrations? Probably no,=20 discuss on list. Issue: Dialog reuse=97no longer a need with gruu. Should gruu spec=20 deprecate dialog resuse if both peers support gruu? (Impacts refer,=20 other subscribe usage). Conclusion: Do not address in gruu spec, address in other drafts, put=20 pressure on future work to avoid dialog resuse. Issue: Does Gruu interferes with e2e signaling. UA can try to generate a=20 local gruu, could use ice-like mechaninsm to decide if it is reachable.=20 Propose to add to draft, but never try to put local address in contact=20 header without using the mechanism. Chair suggestion: Put statement=20 about not using local gruu in gruu draft, put =93iceing=94 in separate=20 draft. Author agreed. Issue: MUST NOT use locally generated gruu is too strong. Clarified=20 that definition of local gruu is one with a different domain part than=20 AoR, MUST does not apply to the examples given. Topic: Join, Rohan Mahy Reading List: draft-ietf-sip-join-02.txt Slides presented. Noted that no comments in wglc. Room shows interest, but no one has=20 implemented. We want more list discussion before sending to IESG. Topic: REFER Semantics, Rohan Mahy Reading List: draft-olson-sipping-refer-extensions draft-mahy-sip-remote-cc Slides presented. Basic premise is that the semantics of the various uses of REFER are=20 under-specified. Much discussion ensued. Issue: Is this equivalent to specifying fixed services? If we have to=20 specify all the services/features, then the refer approach has failed. Issue: How do you put refer requests in a context? Dialog reuse?=20 Separate GRUUs? Explicit refer-to header parameters? Noted that it may=20 require per-scheme semantics in addition to context. Issue: Need more than context=97how do you know what an endpoint will do=20 with a particular URI scheme? Issue: Not useful for authorization, because referee cannot decide if=20 issuing the request could be bad. Another motivation that is relevant is=20 to determine how to render the UI for the action. Sugested: this does not mean fixing refer, it means adding something new=20 to it. Discussion on proceeding: How do we proceed? Refer for other than=20 transfer unlikely to work on today=92s UAs. Rohan suggests defining=20 semantics for baskets of functionality. Use option tags to make sure=20 they are supported. Propose explicit dialog parameters for refer-to.=20 Provide guidance for remote call control vs. remote UI invocation. No conclusion, further discussion deferred to list. Interested parties=20 are to contact Rohan and work on it. Final To-Do: ------------- App Interaction Framework -- change from BCP to PS. Add milestone for RFC 3312 update as PS. Discuss publication rate on mailing list. _______________________________________________ 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 exim@www1.ietf.org Thu Nov 13 23:11:17 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10599 for ; Thu, 13 Nov 2003 23:11:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKVIR-00059A-LL for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 23:10:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE4AxRt019778 for sip-archive@odin.ietf.org; Thu, 13 Nov 2003 23:10:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKVHW-0004w3-UX; Thu, 13 Nov 2003 23:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKVHN-0004vg-4K for sip@optimus.ietf.org; Thu, 13 Nov 2003 23:09:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10560 for ; Thu, 13 Nov 2003 23:09:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKVHH-00050I-00 for sip@ietf.org; Thu, 13 Nov 2003 23:09:48 -0500 Received: from cs.columbia.edu ([128.59.16.20]) by ietf-mx with esmtp (Exim 4.12) id 1AKVHH-000506-00 for sip@ietf.org; Thu, 13 Nov 2003 23:09:47 -0500 Received: from razor.cs.columbia.edu (IDENT:root@razor.cs.columbia.edu [128.59.16.8]) by cs.columbia.edu (8.12.10/8.12.10) with ESMTP id hAE4989D017211; Thu, 13 Nov 2003 23:09:08 -0500 (EST) Received: from cs.columbia.edu (IDENT:root@localhost [127.0.0.1]) by razor.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id hAE497f19145; Thu, 13 Nov 2003 23:09:07 -0500 Message-ID: <3FB45563.7070408@cs.columbia.edu> Date: Thu, 13 Nov 2003 23:09:07 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: hisham.khartabil@nokia.com CC: aki.niemi@nokia.com, jdrosen@dynamicsoft.com, adam@dynamicsoft.com, sip@ietf.org Subject: Re: [Sip] PUBLISH message rates References: <2038BCC78B1AD641891A0D1AE133DBB7017973D0@esebe019.ntc.nokia.com> In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017973D0@esebe019.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit hisham.khartabil@nokia.com wrote: > The only way to do this right is to do what RTCP does with report > interval, and that is to adjust the rate of PUBLISH using some > formula that takes into account the number of publishers at a given > time. The more publishers that join, the less the rate at which > PUBLISH is sent at. The compositors need to communicate that > calculated rate to the publishers somehow. Do we want to make it that > complicated? If not, then I suggest adding text the says if the > compositor is overloaded, it can send a 5xx response with > retry-after. And that probably assumes some reasonably uniform generation pattern for the events. The whole point of events is that they are unpredictable, so that rate smoothing would have to be applied over longish time intervals, further complicating the whole system. Unlike for filters that are subscriber-specific, the publishers would also have to guess what notifications are droppable - which they can only do if they know what kind of things the subscribers care about most, even assuming that they have uniform tastes. I can see that for some continuous-change events, this is at least plausible. For geospatial notifications that have change thresholds, I can easily compute the minimum displacement threshold across subscribers and adjust the publication rate accordingly. This would not be a simple rate limit, as the rate would depend on my movement pattern (slow if circling the block, fast if driving at highway speeds). Thus, you'd almost want to feed back some kind of 'distilled' subscription to the publisher - I would find that far more useful than some hard 'messages/second' limit. _______________________________________________ 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 exim@www1.ietf.org Fri Nov 14 01:36:41 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14956 for ; Fri, 14 Nov 2003 01:36:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKXZA-00049b-E4 for sip-archive@odin.ietf.org; Fri, 14 Nov 2003 01:36:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAE6aOGB015910 for sip-archive@odin.ietf.org; Fri, 14 Nov 2003 01:36:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKXXr-0003us-1k; Fri, 14 Nov 2003 01:35:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKXXY-0003u8-RP for sip@optimus.ietf.org; Fri, 14 Nov 2003 01:34:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14904 for ; Fri, 14 Nov 2003 01:34:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKXXV-00078S-00 for sip@ietf.org; Fri, 14 Nov 2003 01:34:41 -0500 Received: from 138.muda.mnpl.sfldmibv.dsl.att.net ([12.98.223.138] helo=osrmail) by ietf-mx with esmtp (Exim 4.12) id 1AKXXV-00078P-00 for sip@ietf.org; Fri, 14 Nov 2003 01:34:41 -0500 Received: from sip (127.0.0.1) by localhost (127.0.0.1) with [XMail 0.74 (Win32/Ix86) ESMTP Server] id for from ; Thu, 13 Nov 2003 22:28:53 -0000 From: "Christian Stredicke" To: "'Paul Kyzivat'" Cc: "'Rohan Mahy'" , Subject: AW: [Sip] Dialog-State Use Cases Date: Fri, 14 Nov 2003 00:35:07 -0600 Message-ID: <062f01c3aa79$73233dc0$be08f20a@sip> 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.4024 Importance: Normal In-Reply-To: <3FB42F22.2000004@cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > I suggest something like "call-info". > Absolutely! > > 3. The question of HANDSET-LIFTING > > > > We need to know if handsets have been lifted up (that's a simple > > requirement from the switchboard people which laugh at us if we say > > "impossible"; it is also needed for AUTOMATIC CALL BACK). We could model > > this as dialog where "to" is not set yet. > > It really need have nothing to do with lifting a handset. Lots of > devices don't even have a handset - at least not one you lift. > > I think it is about being in a state of preparing to make a call. But it > is more than that, because not all devices would want to report this > when preparing to make a call. It also has something to do with being > unwilling or unable to receive a call while in this state, and/or > wanting to seize a shared line resource. Call it "virtual handset lifting"... I think we are in agreement that we need something to indicate inability to receive a call while in this state. Christian _______________________________________________ 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 exim@www1.ietf.org Fri Nov 14 07:08:46 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07604 for ; Fri, 14 Nov 2003 07:08:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKckZ-00029h-Fj for sip-archive@odin.ietf.org; Fri, 14 Nov 2003 07:08:32 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEC8VQm008224 for sip-archive@odin.ietf.org; Fri, 14 Nov 2003 07:08:31 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKck6-00023I-Ga; Fri, 14 Nov 2003 07:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKcjQ-0001uR-TN for sip@optimus.ietf.org; Fri, 14 Nov 2003 07:07:21 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07575 for ; Fri, 14 Nov 2003 07:07:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKcjM-0003zR-00 for sip@ietf.org; Fri, 14 Nov 2003 07:07:16 -0500 Received: from 138.muda.mnpl.sfldmibv.dsl.att.net ([12.98.223.138] helo=osrmail) by ietf-mx with esmtp (Exim 4.12) id 1AKcjL-0003zE-00 for sip@ietf.org; Fri, 14 Nov 2003 07:07:15 -0500 Received: from sip (127.0.0.1) by localhost (127.0.0.1) with [XMail 0.74 (Win32/Ix86) ESMTP Server] id for from ; Fri, 14 Nov 2003 04:01:18 -0000 From: "Christian Stredicke" To: , , Cc: , , Subject: AW: [Sip] PUBLISH message rates Date: Fri, 14 Nov 2003 06:07:35 -0600 Message-ID: <065801c3aaa7$e478d3d0$be08f20a@sip> 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.4024 Importance: Normal In-Reply-To: <2038BCC78B1AD641891A0D1AE133DBB7017973D0@esebe019.ntc.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > If there are 5 publishers for a package that limits the rate to 5 per > second. There will be 20 NOTIFYs and 100 PUBLISHs sent in one minute . How > does that help? Limiting the rate is about statistics. There is definitely a correlation between the rate limitation and the actual rate. In other words: it has an effect. Ok you can't make any guarantees on the actual performance, but it helps to reduce the network load. In the above example, we are talking about say 1000 messages without limitation and 100 with limitation. I would call that a success. Anyway I would not be too religious about this. I think practically it's not really relevant as implementers should keep an eye on rate anyway even without explicit rate negotiation. Christian _______________________________________________ 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 exim@www1.ietf.org Fri Nov 14 09:32:00 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11641 for ; Fri, 14 Nov 2003 09:32:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKez9-0001rK-Mg for sip-archive@odin.ietf.org; Fri, 14 Nov 2003 09:31:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEEVh9i007086 for sip-archive@odin.ietf.org; Fri, 14 Nov 2003 09:31:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKeyU-0001lO-5h; Fri, 14 Nov 2003 09:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKexr-0001kM-VL for sip@optimus.ietf.org; Fri, 14 Nov 2003 09:30:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11526 for ; Fri, 14 Nov 2003 09:30:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKexq-0005sT-00 for sip@ietf.org; Fri, 14 Nov 2003 09:30:22 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AKexp-0005s8-00 for sip@ietf.org; Fri, 14 Nov 2003 09:30:21 -0500 Received: from cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 14 Nov 2003 06:32:27 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAEETfAt007155; Fri, 14 Nov 2003 06:29:41 -0800 (PST) Received: from cisco.com (che-vpn-cluster-1-165.cisco.com [10.86.240.165]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ADZ39390; Fri, 14 Nov 2003 09:29:40 -0500 (EST) Message-ID: <3FB4E6D2.7080206@cisco.com> Date: Fri, 14 Nov 2003 09:29: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: Henning Schulzrinne CC: hisham.khartabil@nokia.com, aki.niemi@nokia.com, jdrosen@dynamicsoft.com, adam@dynamicsoft.com, sip@ietf.org Subject: Re: [Sip] PUBLISH message rates References: <2038BCC78B1AD641891A0D1AE133DBB7017973D0@esebe019.ntc.nokia.com> <3FB45563.7070408@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > hisham.khartabil@nokia.com wrote: > >> The only way to do this right is to do what RTCP does with report >> interval, and that is to adjust the rate of PUBLISH using some >> formula that takes into account the number of publishers at a given >> time. The more publishers that join, the less the rate at which >> PUBLISH is sent at. The compositors need to communicate that >> calculated rate to the publishers somehow. Do we want to make it that >> complicated? If not, then I suggest adding text the says if the >> compositor is overloaded, it can send a 5xx response with >> retry-after. Of course use of 5xx with retry-after wastes the effort the compositor has already expended in processing the publish up to that point. It might be interesting to make a change permitting use of the Retry-After header with a 2xx response. Then the compositor could accept a publish and at the same time ensure that the next one doesn't come too soon. This wouldn't be useful in all cases, but maybe in some. 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 exim@www1.ietf.org Fri Nov 14 11:56:56 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20234 for ; Fri, 14 Nov 2003 11:56:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKhFP-00063u-Rl for sip-archive@odin.ietf.org; Fri, 14 Nov 2003 11:56:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAEGud12023302 for sip-archive@odin.ietf.org; Fri, 14 Nov 2003 11:56:39 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKhEp-0005pr-W9; Fri, 14 Nov 2003 11:56:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AKhEk-0005oO-IW for sip@optimus.ietf.org; Fri, 14 Nov 2003 11:55:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20139 for ; Fri, 14 Nov 2003 11:55:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AKhEj-0000vp-00 for sip@ietf.org; Fri, 14 Nov 2003 11:55:57 -0500 Received: from bdsl.66.12.12.130.gte.net ([66.12.12.130] helo=bdsl.greycouncil.com) by ietf-mx with esmtp (Exim 4.12) id 1AKhEi-0000vm-00 for sip@ietf.org; Fri, 14 Nov 2003 11:55:56 -0500 Received: from txdwillis (dyn132-174.ietf58.ietf.org [130.129.132.174]) (authenticated bits=0) by bdsl.greycouncil.com (8.12.8/8.12.8) with ESMTP id hAEGupv4019556 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 14 Nov 2003 10:56:52 -0600 From: "Dean Willis" To: Cc: , "'Gonzalo Camarillo'" Date: Fri, 14 Nov 2003 10:55:04 -0600 Message-ID: <004401c3aad0$0e72a620$ae848182@txdwillis> 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.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Content-Transfer-Encoding: quoted-printable Subject: [Sip] Chair Rambling: Thoughts on Conflicting Pressures in SIP Work Planning Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Over the last week, I've had several fascinating conversations with = people about the way that SIP work gets planned and done. This has led me to a realization of an underlying conflict that needs to be carefully = managed. Observation 1: Over time, the set of actively contributing people has declined. New people find it hard to penetrate the "Inner Circle", and = take their energy, enthusiasm, and talent elsewhere -- or even worse, = nowhere. Observation 2: We have a lot of diffferent topics under consideration -- more than the set of actively contributing people can execute, or even assimilate. It was noted several times in the SIP meeting that "This is = a great idea, and very interesting, but we just don't have the bandwidth = to do it." The traditional way to deal with #1 is to open up to new ideas. The traditional way to deal with #2 is to focus narrowly on priorities (usually meaning "stuff we're already doing") and refuse to consider any = new topics. Another approach is to invest effort in getting more people = actively involved and contributing, which can be difficult "late in the game". What we've been trying to do is steer a happy medium between the two -- giving consideration to new ideas that MIGHT become priority items, encouraging new participation, and managing to priorities. SIPPING, for example, is a mechanism for helping SIP evaluate and set incoming priorities, while also entertaining newer ideas. It has certainly = helped. But there is always room for improvement. As you relax and bask in that happy post-meeting glow (which I hope = lasts no more than about 72 hours, we have WORK to do!), I invite you all to = consider this matter, and share any insights either with the list as a whole or = one or all of the chairs as you feel is most appropriate. Thanks, and I wish all of you who were at IETF 58 a safe trip home. -- 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 exim@www1.ietf.org Sat Nov 15 18:50:43 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25335 for ; Sat, 15 Nov 2003 18:50:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALABP-0000NM-MW for sip-archive@odin.ietf.org; Sat, 15 Nov 2003 18:50:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAFNoRWb001377 for sip-archive@odin.ietf.org; Sat, 15 Nov 2003 18:50:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALAB1-0000HK-Nf; Sat, 15 Nov 2003 18:50:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALAAI-0000FX-2S for sip@optimus.ietf.org; Sat, 15 Nov 2003 18:49:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25304 for ; Sat, 15 Nov 2003 18:49:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALAAE-00001I-00 for sip@ietf.org; Sat, 15 Nov 2003 18:49:14 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1ALAAE-000009-00 for sip@ietf.org; Sat, 15 Nov 2003 18:49:14 -0500 Received: from cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 15 Nov 2003 15:49:14 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id hAFNmgiN021476; Sat, 15 Nov 2003 15:48:43 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANP66917; Sat, 15 Nov 2003 15:48:41 -0800 (PST) Date: Fri, 14 Nov 2003 16:03:39 -0600 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: To: "Christian Stredicke" From: Rohan Mahy In-Reply-To: <061901c3aa4b$4d579380$be08f20a@sip> Message-Id: <673E338C-16EE-11D8-9CB0-0003938AF740@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Subject: [Sip] Re: Dialog-State Use Cases Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Christian, Thanks for your quick turn around. -rohan On Thursday, November 13, 2003, at 07:04 PM, Christian Stredicke wrote: > Hi Rohan, > > looks like we have just been bombed back into the requirements phase of > the dialog (or whatever the name is) package. > > I see the following use-cases: > > 1. STATUS information > > We need to see if a dialog is "ringing", "talking", "on hold", or has > just been "terminated". Also it would be nice to have the to- and from, > maybe referred-by and the start of the "talking" (so that we can > calculate the duration). This information is nice for LED and > SWITCHBOARD applications. > > > 2. Call pickup, join, and other ACTIONS > > The dialog state subscriber needs to know what URL to dial in order to > pick up a call or on how to join a call. Other actions might also be > indicated. > > > 3. The question of HANDSET-LIFTING > > We need to know if handsets have been lifted up (that's a simple > requirement from the switchboard people which laugh at us if we say > "impossible"; it is also needed for AUTOMATIC CALL BACK). We could > model > this as dialog where "to" is not set yet. > > > That's all on my wish list! No need for CSeq or other stuff end-users > are not interested in! > > Please don't forget SIP did not replace the good old PBX yet and there > is a reason for this. > > > CS > _______________________________________________ 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 exim@www1.ietf.org Sat Nov 15 19:29:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26505 for ; Sat, 15 Nov 2003 19:29:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALAmu-00024I-VZ for sip-archive@odin.ietf.org; Sat, 15 Nov 2003 19:29:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAG0TCSd007889 for sip-archive@odin.ietf.org; Sat, 15 Nov 2003 19:29:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALAmk-00022O-E8; Sat, 15 Nov 2003 19:29:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALAmT-00021Y-HT for sip@optimus.ietf.org; Sat, 15 Nov 2003 19:28:45 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26480 for ; Sat, 15 Nov 2003 19:28:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALAmR-0000Zu-00 for sip@ietf.org; Sat, 15 Nov 2003 19:28:43 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ALAmQ-0000ZH-00 for sip@ietf.org; Sat, 15 Nov 2003 19:28:42 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 15 Nov 2003 16:35:45 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAG0SAw5013222; Sat, 15 Nov 2003 16:28:11 -0800 (PST) Received: from [10.0.1.3] (sjc-vpn3-104.cisco.com [10.21.64.104]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AJZ46673; Sat, 15 Nov 2003 16:28:09 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sat, 15 Nov 2003 16:28:08 -0800 Subject: Re: [Sip] GRUU, Contacts, and privacy From: Cullen Jennings To: CC: Jonathan Rosenberg Message-ID: In-Reply-To: <3FB3354C.6020802@dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I'm convinced :-) I agree we should not bother to deal with the privacy stuff in GRUU. Cullen On 11/12/03 11:39 PM, "Jonathan Rosenberg" wrote: > I agree, and I believe this was the consensus at the meeting as well. > Interestingly, the current requirements document: > http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-gruu-reqs-01.txt > > doesnt actually have any privacy requirements at all. So, there is > nothing to remove :) > > -Jonathan R. > > Adam Roach wrote: > >> Alan Johnston [mailto:alan.johnston@mci.com] writes: >> >>> I agree 100%. A private Contact URI is just one small piece >>> of the privacy puzzle. I think this privacy requirement should >>> be removed. >> >> I further agree. >> >> /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 exim@www1.ietf.org Sat Nov 15 19:45:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25334 for ; Sat, 15 Nov 2003 18:50:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALABP-0000NL-MA for sip-archive@odin.ietf.org; Sat, 15 Nov 2003 18:50:28 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAFNoRl5001381 for sip-archive@odin.ietf.org; Sat, 15 Nov 2003 18:50:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALAB3-0000Hb-1t; Sat, 15 Nov 2003 18:50:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALAAJ-0000Fc-Je for sip@optimus.ietf.org; Sat, 15 Nov 2003 18:49:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25307 for ; Sat, 15 Nov 2003 18:49:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALAAF-00001N-00 for sip@ietf.org; Sat, 15 Nov 2003 18:49:16 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ALAAF-00000A-00 for sip@ietf.org; Sat, 15 Nov 2003 18:49:15 -0500 Received: from cisco.com (171.68.223.137) by sj-iport-3.cisco.com with ESMTP; 15 Nov 2003 15:56:18 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hAFNmhrX028263; Sat, 15 Nov 2003 15:48:43 -0800 (PST) Received: from cisco.com (ssh-sjc-1.cisco.com [171.68.225.134]) by mira-sjc5-b.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ANP66919; Sat, 15 Nov 2003 15:48:42 -0800 (PST) Date: Fri, 14 Nov 2003 16:07:08 -0600 Subject: Re: [Sip] Dialog-State Use Cases Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: Christian Stredicke , sip@ietf.org To: Paul Kyzivat From: Rohan Mahy In-Reply-To: <3FB42F22.2000004@cisco.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On Thursday, November 13, 2003, at 07:25 PM, Paul Kyzivat wrote: > I think a lot of confusion could be eliminated by renaming the > document and the event package it defines. While it has something to > do with dialogs, it isn't fundamentally about dialogs. For instance, > it has *nothing* to do with dialogs containing only subscriptions. > > It is largely but not entirely related to dialogs that contain an > invitation. But it is concerned with some things that can't be learned > from just that. > > I suggest something like "call-info". That was the original title, but for some reason we changed that. Event package for SIP session and session-participation information ? thanks, -rohan > More inline... > > Paul > > Christian Stredicke wrote: >> 3. The question of HANDSET-LIFTING >> We need to know if handsets have been lifted up (that's a simple >> requirement from the switchboard people which laugh at us if we say >> "impossible"; it is also needed for AUTOMATIC CALL BACK). We could >> model >> this as dialog where "to" is not set yet. > > It really need have nothing to do with lifting a handset. Lots of > devices don't even have a handset - at least not one you lift. > > I think it is about being in a state of preparing to make a call. But > it is more than that, because not all devices would want to report > this when preparing to make a call. It also has something to do with > being unwilling or unable to receive a call while in this state, > and/or wanting to seize a shared line resource. _______________________________________________ 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 exim@www1.ietf.org Sun Nov 16 22:41:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17090 for ; Sun, 16 Nov 2003 22:41:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALaGQ-0002Jn-4R for sip-archive@odin.ietf.org; Sun, 16 Nov 2003 22:41:22 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAH3fMrn008912 for sip-archive@odin.ietf.org; Sun, 16 Nov 2003 22:41:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALaG5-0002IR-7z; Sun, 16 Nov 2003 22:41:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALaF7-0002Gc-8u for sip@optimus.ietf.org; Sun, 16 Nov 2003 22:40:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17072; Sun, 16 Nov 2003 22:39:46 -0500 (EST) From: peter_blatherwick@mitel.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALaF2-00004z-00; Sun, 16 Nov 2003 22:39:56 -0500 Received: from newgate2.mitel.com ([216.191.234.101] helo=mitel.mitel.com) by ietf-mx with esmtp (Exim 4.12) id 1ALaF2-00004v-00; Sun, 16 Nov 2003 22:39:56 -0500 Received: from kanmta01.mitel.com (kanmta01 [134.199.37.58]) by mitel.mitel.com (8.12.10/8.12.10) with ESMTP id hAH3dFYj008919; Sun, 16 Nov 2003 22:39:15 -0500 (EST) To: "Dean Willis" Cc: sip@ietf.org, sip-admin@ietf.org Subject: Re: [Sip] Chair Rambling: Thoughts on Conflicting Pressures in SIP Work Planning MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: Date: Sun, 16 Nov 2003 22:39:12 -0500 X-MIMETrack: Serialize by Router on kanmta01/Mitel(Release 5.0.12 |February 13, 2003) at 11/16/2003 10:33:21 PM, Serialize complete at 11/16/2003 10:33:21 PM Content-Type: multipart/alternative; boundary="=_alternative 001423D085256DE1_=" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multipart message in MIME format. --=_alternative 001423D085256DE1_= Content-Type: text/plain; charset="us-ascii" Hi Dean, all, Nice summary of conflicting pressures. However, another serious pressure which has severely affected most all of us, especially over the past 2 - 3 years, is overlooked -- economics. These have been nasty economic times, to say the least. And IETF is basically a volunteer organization. It is certainly difficult to contribute to the greater good when the short term bottom line threatens basic personal security. Therefore another contributing factor to the difficulty to progress the movement / mayhem we call SIP has been good ol' fashioned economic reality. With these points in mind I think it is paramount to make sure any new direction is forced to show a connection to the real world. What is the value to the end user? What is the value to those that would deploy it? What is the business case that will make this sustainable? Therefore, what is in it for me, the would-be contributor of my precious personal time? Don't get me wrong!!! While I have not been able to spend the time recently, I still want to do so. And I still believe strongly in the cause. However, any sort of process that would allow proof of the value to me and my employer would be a huge help in being able to commit the time required to really do the job. While I actually think SIP/SIPPING does a pretty good job of showing value, and of driving related requirements, an explicit and visible evaluation process does seem to be lacking. Of course, I have NO IDEA how to put such a process in place. I just think it would be highly valuable, both to gaining willing / committed contributors to the process, and to focusing efforts on overall success. My $0.01, Peter Blatherwick "Dean Willis" Sent by: sip-admin@ietf.org 14.11.03 11:55 To: cc: , "'Gonzalo Camarillo'" Subject: [Sip] Chair Rambling: Thoughts on Conflicting Pressures in SIP Work Planning Over the last week, I've had several fascinating conversations with people about the way that SIP work gets planned and done. This has led me to a realization of an underlying conflict that needs to be carefully managed. Observation 1: Over time, the set of actively contributing people has declined. New people find it hard to penetrate the "Inner Circle", and take their energy, enthusiasm, and talent elsewhere -- or even worse, nowhere. Observation 2: We have a lot of diffferent topics under consideration -- more than the set of actively contributing people can execute, or even assimilate. It was noted several times in the SIP meeting that "This is a great idea, and very interesting, but we just don't have the bandwidth to do it." The traditional way to deal with #1 is to open up to new ideas. The traditional way to deal with #2 is to focus narrowly on priorities (usually meaning "stuff we're already doing") and refuse to consider any new topics. Another approach is to invest effort in getting more people actively involved and contributing, which can be difficult "late in the game". What we've been trying to do is steer a happy medium between the two -- giving consideration to new ideas that MIGHT become priority items, encouraging new participation, and managing to priorities. SIPPING, for example, is a mechanism for helping SIP evaluate and set incoming priorities, while also entertaining newer ideas. It has certainly helped. But there is always room for improvement. As you relax and bask in that happy post-meeting glow (which I hope lasts no more than about 72 hours, we have WORK to do!), I invite you all to consider this matter, and share any insights either with the list as a whole or one or all of the chairs as you feel is most appropriate. Thanks, and I wish all of you who were at IETF 58 a safe trip home. -- 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 --=_alternative 001423D085256DE1_= Content-Type: text/html; charset="us-ascii"
Hi Dean, all,

Nice summary of conflicting pressures.  

However, another serious pressure which has severely affected most all of us, especially over the past 2 - 3 years, is overlooked -- economics.  These have been nasty economic times, to say the least.   And IETF is basically a volunteer organization.   It is certainly difficult to contribute to the greater good when the short term bottom line threatens basic personal security.  Therefore another contributing factor to the difficulty to progress the movement / mayhem we call SIP has been good ol' fashioned economic reality.  

With these points in mind I think it is paramount to make sure any new direction is forced to show a connection to the real world.   What is the value to the end user?  What is the value to those that would deploy it?  What is the business case that will make this sustainable?  Therefore, what is in it for me, the would-be contributor of my precious personal time?  

Don't get me wrong!!!  While I have not been able to spend the time recently, I still want to do so.  And I still believe strongly in the cause.  However, any sort of process that would allow proof of the value to me and my employer would be a huge help in being able to commit the time required to really do the job.  While I actually think SIP/SIPPING does a pretty good job of showing value, and of driving related requirements, an explicit and visible evaluation process does seem to be lacking.  

Of course, I have NO IDEA how to put such a process in place.  I just think it would be highly valuable, both to gaining willing / committed contributors to the process, and to focusing efforts on overall success.  

My $0.01,
Peter Blatherwick





"Dean Willis" <dwillis@dynamicsoft.com>
Sent by: sip-admin@ietf.org

14.11.03 11:55

       
        To:        <sip@ietf.org>
        cc:        <rohan@cisco.com>, "'Gonzalo Camarillo'" <Gonzalo.Camarillo@lmf.ericsson.se>
        Subject:        [Sip] Chair Rambling: Thoughts on Conflicting Pressures in SIP Work Planning




Over the last week, I've had several fascinating conversations with people
about the way that SIP work gets planned and done. This has led me to a
realization of an underlying conflict that needs to be carefully managed.

Observation 1: Over time, the set of actively contributing people has
declined. New people find it hard to penetrate the "Inner Circle", and take
their energy, enthusiasm, and talent elsewhere -- or even worse, nowhere.

Observation 2: We have a lot of diffferent topics under consideration --
more than the set of actively contributing people can execute, or even
assimilate. It was noted several times in the SIP meeting that "This is a
great idea, and very interesting, but we just don't have the bandwidth to do
it."

The traditional way to deal with #1 is to open up to new ideas.

The traditional way to deal with #2 is to focus narrowly on priorities
(usually meaning "stuff we're already doing") and refuse to consider any new
topics. Another approach is to invest effort in getting more people actively
involved and contributing, which can be difficult "late in the game".

What we've been trying to do is steer a happy medium between the two --
giving consideration to new ideas that MIGHT become priority items,
encouraging new participation, and managing to priorities. SIPPING, for
example, is a mechanism for helping SIP evaluate and set incoming
priorities, while also entertaining newer ideas. It has certainly helped.
But there is always room for improvement.

As you relax and bask in that happy post-meeting glow (which I hope lasts no
more than about 72 hours, we have WORK to do!), I invite you all to consider
this matter, and share any insights either with the list as a whole or one
or all of the chairs as you feel is most appropriate.

Thanks, and I wish all of you who were at IETF 58 a safe trip home.

--
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

--=_alternative 001423D085256DE1_=-- _______________________________________________ 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 exim@www1.ietf.org Mon Nov 17 08:33:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11198 for ; Mon, 17 Nov 2003 08:33:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALjVC-0006dJ-3n for sip-archive@odin.ietf.org; Mon, 17 Nov 2003 08:33:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHDXDtU025437 for sip-archive@odin.ietf.org; Mon, 17 Nov 2003 08:33:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALjV0-0006bE-Bp; Mon, 17 Nov 2003 08:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALjU7-0006YI-33 for sip@optimus.ietf.org; Mon, 17 Nov 2003 08:32:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11136 for ; Mon, 17 Nov 2003 08:31:55 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALjU5-0006XJ-00 for sip@ietf.org; Mon, 17 Nov 2003 08:32:05 -0500 Received: from smtp2.dataconnection.com ([192.91.191.8] helo=miles.dataconnection.com) by ietf-mx with esmtp (Exim 4.12) id 1ALjU5-0006Wm-00 for sip@ietf.org; Mon, 17 Nov 2003 08:32:05 -0500 Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2656.59) id ; Mon, 17 Nov 2003 13:31:19 -0000 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F80261FC61@baker.datcon.co.uk> From: "Paul D.Smith" To: "'sip@ietf.org'" Subject: RE: [Sip] Connection: Keep-Alive Date: Mon, 17 Nov 2003 13:31:19 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA11137 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable All, Can I just flag up that in one respect, UDP can have advantages over TCP = (or any other reliable transport). Once the path from sender to receiver machines becomes congested, TCP builds up a queue of pending SIP requests. Note that this "queue" consists of messages queued both at the receiver (= if receiver is unable to handle received requests at a rate equal or in exce= ss of arrival rates) and the sender (if the network itself or the connection= to the receiver is congested). Quite where messages are queued can be immaterial. Ultimately, the time taken for a request to move from the bottom of this queue to the top can exceed the 32s (64 * T1) request timeout imposed by = RFC 3261 and policed by the sender. Once this occurs, _all_ SIP requests sen= t to the receiver machine then fail until congestion subsides and the "bott= om to top" time falls below 32s (64 x T1). By comparison, a UDP stack drops frames when congested so many SIP reques= ts will be dropped and fail but some will be get lucky and get processed by = the receiver. As a result, under severe congestion, UDP can have _better_ request success rates that TCP. As is currently being discussed, congestion can have many causes and solv= ing it is very tricky, if not impossible across the entire network. I just wanted to flag that using a reliable transport can introduce some problem= s as well as solving others. Finally, a question for the group to consider. If we are using a reliabl= e transport, does it even make sense to enforce the 32s (64 x T1) timeout? It seems that if we have a reliable transport, we should accept that the request _will_ reach the next hop and that a response _will_ come back (unless the connection fails - which we should be able to detect) and therefore the 32s timeout might be unneccessary. Paul D.Smith Network Protocols Group=20 Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com=20 Fax: +44 20 8363 1039 Web: http://www.dataconnection.com -----Original Message----- From: Chris Boulton [mailto:cboulton@ubiquity.net] Sent: 13 November 2003 12:52 To: SIP (E-mail) Subject: RE: [Sip] Connection: Keep-Alive I also agree that a document is important. The consensus in the room yesterday was am emphasis on TCP usage due to the known limitations of UD= P. Some form of BCP might go a long way to promoting it's currently limited usage. =20 Chris. =20 -----Original Message-----=20 From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com]=20 Sent: Thu 13/11/2003 07:42=20 To: seancolson@yahoo.com=20 Cc: 'Vijay K. Gurbani'; 'Christian Stredicke'; sip@ietf.org; rajnishjain@xl.com=20 Subject: Re: [Sip] Connection: Keep-Alive =09 =09 Sorry for not being clear - I wasnt saying we DONT want a document. At the meeting today, I advocated (and I think many others agreed) for creation of a document. In particular, I think it makes sense to have a proposed standard document that describes all of the issues with getting tcp to work. This would presumably be an expansion of the existing connect-reuse draft. It needs to be PS since there is normative behavior associated with many parts of it. =09 -Jonathan R. =09 Sean Olson wrote: =09 > Actually, many implementations are not doing this unfortunately. A BCP is > not a bad idea. > > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Jonathan > Rosenberg > Sent: Wednesday, November 12, 2003 11:12 PM > To: Vijay K. Gurbani > Cc: Christian Stredicke; sip@ietf.org; rajnishjain@xl.com > Subject: Re: [Sip] Connection: Keep-Alive > > > > Vijay K. Gurbani wrote: > > > >>>In any case the behavior of the UAC as well as the proxy needs to be >>>(re)defined, I think the current TCP specification does not allow a >>>permanent connection. >>> >>>Any thoughts on this? >> >> >>At the Atlanta IETF, it was decided that we will open a bug against >>rfc3261 to provide more information on TCP connection handling. > > > Well, in particular, it was concluded that signaling "please keep this > connection open" was not needed at all. Rather, the server should keep the > connection open as long as it could, and only close it if it ran out of > resources. Since there was no benefit to closing it prematurely (extra costs > of setting it up again), and since signaling the desire for persistence > could not be used to force the server to keep it open if the server ran out > of resources, the signaling was not needed. > Indeed, the observation was that many implementations in any case were doing > this; it was just unclear in the spec. > > -Jonathan R. > =09 -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com =09 =09 _______________________________________________ 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 =09 J*fj)b bm=EB=81=B6?=0C0=EC=87=9B'~ffX)=EE=96=8A"8bX=E9=AC=B6+=1FDY=D7=AFz= Z) ay=ED=AF=81+y"=0F>-%R=E0=A7=9BWz{h,r=E4=89=89ny=DB=9Fzb=E6=A4=A2{(=CB=AB *T"=E7=A6=98'~~=E6=8A=8A{=07^hgg'=EB=81=B6=17bqbz=1F _______________________________________________ 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 exim@www1.ietf.org Mon Nov 17 10:03:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13531 for ; Mon, 17 Nov 2003 10:03:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALkuL-0001lK-79 for sip-archive@odin.ietf.org; Mon, 17 Nov 2003 10:03:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHF3HC8006715 for sip-archive@odin.ietf.org; Mon, 17 Nov 2003 10:03:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALku5-0001iZ-IA; Mon, 17 Nov 2003 10:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALkt9-0001fb-Ky for sip@optimus.ietf.org; Mon, 17 Nov 2003 10:02:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13443 for ; Mon, 17 Nov 2003 10:01:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALkt7-0007RK-00 for sip@ietf.org; Mon, 17 Nov 2003 10:02:01 -0500 Received: from smtp2.dataconnection.com ([192.91.191.8] helo=miles.dataconnection.com) by ietf-mx with esmtp (Exim 4.12) id 1ALkt6-0007Qx-00 for sip@ietf.org; Mon, 17 Nov 2003 10:02:01 -0500 Received: by miles.datcon.co.uk with Internet Mail Service (5.5.2656.59) id ; Mon, 17 Nov 2003 15:01:14 -0000 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F80261FC66@baker.datcon.co.uk> From: "Paul D.Smith" To: "'sip@ietf.org'" Date: Mon, 17 Nov 2003 15:01:13 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="ISO-8859-1" Subject: [Sip] 3-way handshake bad! Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , All, For context, see IETF 58 minutes. There was a suggestion that the non-INVITE avalanche problem be solved by using a 3-way handshake. I just want to flag that this idea can have unfortunate consequences during congestion. Firstly, consider a server under load. The 3-way handshake requires the following. server processes request - #1 server sends response - #2 server processes request/handshake - #3. By adding the 3rd step, we have _doubled_ the number of requests to be handled by the server increasing the load and increasing the chances it becomes congested. As per my earlier e-mail, for TCP, the chances of the initial request completing can be either 1.0 or 0.0 depending on the congestion. Increasing the congestion at the server, increases the chance of requests failing. For UDP, there is a 1/x (x >= 1) chance of the request being received and processed by the server. Similarly, there is a 1/x chance of the 3rd request/handshake reaching the server. This means the chances of the 3-way handshake completing are 1/(x^2). So adding the third step greatly affects the chances of the 3-way handshake completing. Paul D.Smith Network Protocols Group Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com Fax: +44 20 8363 1039 Web: http://www.dataconnection.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 exim@www1.ietf.org Mon Nov 17 10:20:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15172 for ; Mon, 17 Nov 2003 10:20:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALlAn-0002vx-M1 for sip-archive@odin.ietf.org; Mon, 17 Nov 2003 10:20:17 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHFKHjw011276 for sip-archive@odin.ietf.org; Mon, 17 Nov 2003 10:20:17 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALlAc-0002ua-Eb; Mon, 17 Nov 2003 10:20:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALlA4-0002tT-Bd for sip@optimus.ietf.org; Mon, 17 Nov 2003 10:19:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15117 for ; Mon, 17 Nov 2003 10:19:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALl9z-0007el-00 for sip@ietf.org; Mon, 17 Nov 2003 10:19:27 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ALl9y-0007eM-00 for sip@ietf.org; Mon, 17 Nov 2003 10:19:26 -0500 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAHFIqw5012269; Mon, 17 Nov 2003 07:18:53 -0800 (PST) Received: from [10.32.245.146] (stealth-10-32-245-146.cisco.com [10.32.245.146]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AJZ92378; Mon, 17 Nov 2003 07:18:51 -0800 (PST) Date: Mon, 17 Nov 2003 10:18:36 -0500 From: "David R. Oran" To: "Paul D.Smith" , "'sip@ietf.org'" Subject: Re: [Sip] 3-way handshake bad! Message-ID: <87309171.1069064316@[10.32.245.146]> In-Reply-To: <53F74F5A7B94D511841C00B0D0AB16F80261FC66@baker.datcon.co.uk> References: <53F74F5A7B94D511841C00B0D0AB16F80261FC66@baker.datcon.co.uk> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========AD3F99A15433A655726C==========" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --==========AD3F99A15433A655726C========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable --On Monday, November 17, 2003 3:01 PM +0000 "Paul D.Smith"=20 wrote: > All, > > For context, see IETF 58 minutes. There was a suggestion that the > non-INVITE avalanche problem be solved by using a 3-way handshake. I = just > want to flag that this idea can have unfortunate consequences during > congestion. > I made that suggestion. I disagree that it has unfortunate congestion=20 consequences. See below. Note however, that it may be unproductive to start = an extended dialog on this subject since such a change to SIP may be too=20 radical at this stage in the protocol's evolution. We need to weigh this=20 against the efficacy-versus-radicality tradeoffs of other possible ways to=20 ameliorate the problems. > Firstly, consider a server under load. The 3-way handshake requires the > following. > > server processes request - #1 > server sends response - #2 > server processes request/handshake - #3. > > By adding the 3rd step, we have _doubled_ the number of requests to be > handled by the server increasing the load and increasing the chances it > becomes congested. > Not really. The processing of an ACK transaction is not nearly as expensive = as processing of the actual request. All it requires is transaction=20 matching and state cleanup (if any). This had better be blindingly fast in=20 any reasonable SIP server or you have a lot of worse things to worry about, = including DoS attacks from legitimate authenticated/authorized sources. (Aside: I actually have a patent disclosure filed on how to do DoS=20 prevention by SIP servers where the relative costs of transaction matching, = authentication, authorization, and state-creation are taken into account). > As per my earlier e-mail, for TCP, the chances of the initial request > completing can be either 1.0 or 0.0 depending on the congestion. For a single signaling hop this is more-or-less true, but assumes a number=20 of things, including whether the server is programmed to back-pressure the=20 TCP connection (causing HOL blocking) or is maintaining internal request=20 queues from which requests might get dropped on overflow. For multi-hop=20 signaling, TCP is of little help especially when multiplexing is happening. > Increasing the congestion at the server, increases the chance of requests > failing. For UDP, there is a 1/x (x >=3D 1) chance of the request being > received and processed by the server. Similarly, there is a 1/x chance > of the 3rd request/handshake reaching the server. This is true only if all requests have equal costs, and if ACKs have equal=20 costs to requests. This is demonstrably not the case. > This means the chances > of the 3-way handshake completing are > 1/(x^2). So adding the third step greatly affects the chances of the > 3-way handshake completing. > I believe this logic is flawed. Cheers, Dave. > Paul D.Smith > Network Protocols Group > Data Connection Ltd (DCL) > Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com > Fax: +44 20 8363 1039 Web: http://www.dataconnection.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 ------------------------ David R. Oran Cisco Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.com --==========AD3F99A15433A655726C========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: Mulberry PGP Plugin v3.0 Comment: processed by Mulberry PGP Plugin iQA/AwUBP7jm2I1mhLZU3SrmEQLQTgCeI/DiTO5SJB4V1E87RyGAF732aB8AoO/T Bl0hGqXvkNV3ugrgnNKQPX9N =uAfA -----END PGP SIGNATURE----- --==========AD3F99A15433A655726C==========-- _______________________________________________ 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 exim@www1.ietf.org Mon Nov 17 10:27:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15614 for ; Mon, 17 Nov 2003 10:27:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALlHa-0003tX-S8 for sip-archive@odin.ietf.org; Mon, 17 Nov 2003 10:27:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHFRId9014911 for sip-archive@odin.ietf.org; Mon, 17 Nov 2003 10:27:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALlHL-0003jl-8U; Mon, 17 Nov 2003 10:27:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALlH0-0003eB-Gx for sip@optimus.ietf.org; Mon, 17 Nov 2003 10:26:42 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15535 for ; Mon, 17 Nov 2003 10:26:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALlGy-0007mb-00 for sip@ietf.org; Mon, 17 Nov 2003 10:26:40 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1ALlGx-0007mD-00 for sip@ietf.org; Mon, 17 Nov 2003 10:26:39 -0500 Received: from cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 17 Nov 2003 07:27:12 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hAHFQ6rX005016; Mon, 17 Nov 2003 07:26:07 -0800 (PST) Received: from [10.32.245.146] (stealth-10-32-245-146.cisco.com [10.32.245.146]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id AJZ92678; Mon, 17 Nov 2003 07:26:05 -0800 (PST) Date: Mon, 17 Nov 2003 10:26:02 -0500 From: "David R. Oran" To: "Paul D.Smith" , "'sip@ietf.org'" Subject: RE: [Sip] Connection: Keep-Alive Message-ID: <87755187.1069064762@[10.32.245.146]> In-Reply-To: <53F74F5A7B94D511841C00B0D0AB16F80261FC61@baker.datcon.co.uk> References: <53F74F5A7B94D511841C00B0D0AB16F80261FC61@baker.datcon.co.uk> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="==========81B3EE555A863AF4107B==========" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --==========81B3EE555A863AF4107B========== Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Unlike Paul's earlier message on 3-way handshaking, with which I disagreed, = this post makes a very important point with which I whole-heartedly agree. When the signaling is single-hop, it may in fact make sense to disable the=20 request timers. Unfortunately, when the signaling is multi-hop this doesn't = work and it isn't clear what to do. One of the objections to 3-way handshakes (aside from the one Paul made in=20 his earlier post) is the additional state in proxies. If we in fact do=20 enough surgery to SIP to introduce 3-way handshakes on non-invite=20 transactions, perhaps we can also at the same time introduce a header hint=20 on non-invite transactions which indicate to proxies that it is safe to=20 operate statelessly on such transactions if the proxy so chooses. Dave. --On Monday, November 17, 2003 1:31 PM +0000 "Paul D.Smith"=20 wrote: > All, > > Can I just flag up that in one respect, UDP can have advantages over TCP > (or any other reliable transport). Once the path from sender to receiver > machines becomes congested, TCP builds up a queue of pending SIP = requests. > Note that this "queue" consists of messages queued both at the receiver > (if receiver is unable to handle received requests at a rate equal or in > excess of arrival rates) and the sender (if the network itself or the > connection to the receiver is congested). Quite where messages are > queued can be immaterial. > > Ultimately, the time taken for a request to move from the bottom of this > queue to the top can exceed the 32s (64 * T1) request timeout imposed by > RFC 3261 and policed by the sender. Once this occurs, _all_ SIP requests > sent to the receiver machine then fail until congestion subsides and the > "bottom to top" time falls below 32s (64 x T1). > > By comparison, a UDP stack drops frames when congested so many SIP > requests will be dropped and fail but some will be get lucky and get > processed by the receiver. As a result, under severe congestion, UDP can > have _better_ request success rates that TCP. > > As is currently being discussed, congestion can have many causes and > solving it is very tricky, if not impossible across the entire network. > I just wanted to flag that using a reliable transport can introduce some > problems as well as solving others. > > Finally, a question for the group to consider. If we are using a = reliable > transport, does it even make sense to enforce the 32s (64 x T1) timeout? > It seems that if we have a reliable transport, we should accept that the > request _will_ reach the next hop and that a response _will_ come back > (unless the connection fails - which we should be able to detect) and > therefore the 32s timeout might be unneccessary. > > Paul D.Smith > Network Protocols Group > Data Connection Ltd (DCL) > Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com > Fax: +44 20 8363 1039 Web: http://www.dataconnection.com > > > -----Original Message----- > From: Chris Boulton [mailto:cboulton@ubiquity.net] > Sent: 13 November 2003 12:52 > To: SIP (E-mail) > Subject: RE: [Sip] Connection: Keep-Alive > > > I also agree that a document is important. The consensus in the room > yesterday was am emphasis on TCP usage due to the known limitations of > UDP. Some form of BCP might go a long way to promoting it's currently > limited usage. > > Chris. > > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thu 13/11/2003 07:42 > To: seancolson@yahoo.com > Cc: 'Vijay K. Gurbani'; 'Christian Stredicke'; sip@ietf.org; > rajnishjain@xl.com > Subject: Re: [Sip] Connection: Keep-Alive > > > > Sorry for not being clear - I wasn't saying we DONT want a document. > At > the meeting today, I advocated (and I think many others agreed) for > creation of a document. In particular, I think it makes sense to > have > a proposed standard document that describes all of the issues with > getting tcp to work. This would presumably be an expansion of the > existing connect-reuse draft. It needs to be PS since there is > normative behavior associated with many parts of it. > > -Jonathan R. > > Sean Olson wrote: > > > Actually, many implementations are not doing this unfortunately. A > BCP is > > not a bad idea. > > > > -----Original Message----- > > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of > Jonathan > > Rosenberg > > Sent: Wednesday, November 12, 2003 11:12 PM > > To: Vijay K. Gurbani > > Cc: Christian Stredicke; sip@ietf.org; rajnishjain@xl.com > > Subject: Re: [Sip] Connection: Keep-Alive > > > > > > > > Vijay K. Gurbani wrote: > > > > > > > >>>In any case the behavior of the UAC as well as the proxy needs to > be > >>>(re)defined, I think the current TCP specification does not allow > a > >>>permanent connection. > >>> > >>>Any thoughts on this? > >> > >> > >>At the Atlanta IETF, it was decided that we will open a bug > against > >>rfc3261 to provide more information on TCP connection handling. > > > > > > Well, in particular, it was concluded that signaling "please keep > this > > connection open" was not needed at all. Rather, the server should > keep the > > connection open as long as it could, and only close it if it ran > out of > > resources. Since there was no benefit to closing it prematurely > (extra costs > > of setting it up again), and since signaling the desire for > persistence > > could not be used to force the server to keep it open if the > server ran out > > of resources, the signaling was not needed. > > Indeed, the observation was that many implementations in any case > were doing > > this; it was just unclear in the spec. > > > > -Jonathan R. > > > > -- > Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza > Chief Technology Officer Parsippany, NJ > 07054-2711 > dynamicsoft > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.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 > > > J*fj)b bm??=0C0?'~ffX)?"8bX?+=1FDY?zZ) ay?+y"=0F>-%R?Wz{h,r?ny?zb?{(? > *T"?'~~?{=07^hgg'?=17bqbz=1F > > _______________________________________________ > 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 Systems 7 Ladyslipper Lane Acton, MA 01720 Office: +1 978 264 2048 VoIP: +1 408 571 4576 Email: oran@cisco.com --==========81B3EE555A863AF4107B========== Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: Mulberry PGP Plugin v3.0 Comment: processed by Mulberry PGP Plugin iQA/AwUBP7joio1mhLZU3SrmEQJ88QCeMk+NYDsiGMm1PaciSMCMrShJseIAn2S0 tSJK/QvU5kCPOnGYjZkiT3Yg =UUyN -----END PGP SIGNATURE----- --==========81B3EE555A863AF4107B==========-- _______________________________________________ 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 exim@www1.ietf.org Mon Nov 17 16:11:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05108 for ; Mon, 17 Nov 2003 16:11:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALqeV-00065O-4o for sip-archive@odin.ietf.org; Mon, 17 Nov 2003 16:11:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHLBJHh023390 for sip-archive@odin.ietf.org; Mon, 17 Nov 2003 16:11:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALqeF-00060k-BG; Mon, 17 Nov 2003 16:11:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALqe9-00060H-IA for sip@optimus.ietf.org; Mon, 17 Nov 2003 16:10:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05033 for ; Mon, 17 Nov 2003 16:10:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALqe7-0006C9-00 for sip@ietf.org; Mon, 17 Nov 2003 16:10:55 -0500 Received: from [198.202.216.4] (helo=fullsail.illuminet.com) by ietf-mx with esmtp (Exim 4.12) id 1ALqe6-0006C6-00 for sip@ietf.org; Mon, 17 Nov 2003 16:10:54 -0500 Received: from oly1wnexc01.corp.illuminet.com (oly1wnexc01.corp.illuminet.com [10.55.13.12]) by fullsail.illuminet.com (8.12.10/8.12.10) with ESMTP id hAHLAoLm015097 for ; Mon, 17 Nov 2003 13:10:50 -0800 (PST) Received: by oly1wnexc01.corp.illuminet.com with Internet Mail Service (5.5.2653.19) id ; Mon, 17 Nov 2003 13:10:47 -0800 Message-ID: <318266A4431BC549B4C4D6FD3EA6E24D012CECE3@ove1wnexm01.corp.illuminet.com> From: "McCandless, Kevin" To: sip@ietf.org Date: Mon, 17 Nov 2003 13:10:40 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3AD4F.4184F500" Subject: [Sip] Sip support for TCAP queries Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , 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_01C3AD4F.4184F500 Content-Type: text/plain Has any progress been taken on the draft by Frank Miller on Carrying TCAP in SIP messages? Are there other drafts that address SIP access to SS7 database information through TCAP or another method? Thanks, Kevin ------_=_NextPart_001_01C3AD4F.4184F500 Content-Type: text/html Message
Has any progress been taken on the draft by Frank Miller on Carrying TCAP in SIP messages?  Are there other drafts that address SIP access to SS7 database information through TCAP or another method?
 
Thanks,
 
Kevin
------_=_NextPart_001_01C3AD4F.4184F500-- _______________________________________________ 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 exim@www1.ietf.org Mon Nov 17 18:19:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13308 for ; Mon, 17 Nov 2003 18:19:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALseF-0006lr-Jb for sip-archive@odin.ietf.org; Mon, 17 Nov 2003 18:19:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAHNJBRw026023 for sip-archive@odin.ietf.org; Mon, 17 Nov 2003 18:19:11 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALse7-0006kr-Gj; Mon, 17 Nov 2003 18:19:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALsdY-0006eS-2P for sip@optimus.ietf.org; Mon, 17 Nov 2003 18:18:28 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13242 for ; Mon, 17 Nov 2003 18:18:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALsdV-00019p-00 for sip@ietf.org; Mon, 17 Nov 2003 18:18:25 -0500 Received: from airwolf.sentito.com ([65.202.222.11]) by ietf-mx with smtp (Exim 4.12) id 1ALsdU-00019Q-00 for sip@ietf.org; Mon, 17 Nov 2003 18:18:24 -0500 Received: (qmail 24789 invoked from network); 17 Nov 2003 23:19:08 -0000 Received: from unknown (HELO frankgks0u6mmz) (relay@65.202.222.2) by airwolf.sentito.com with SMTP; 17 Nov 2003 23:19:08 -0000 From: "Frank W. Miller" To: "'McCandless, Kevin'" Cc: Subject: RE: [Sip] Sip support for TCAP queries Date: Mon, 17 Nov 2003 18:17:45 -0500 Message-ID: <003c01c3ad61$02008f90$9100000a@frankgks0u6mmz> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003D_01C3AD37.192A8790" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <318266A4431BC549B4C4D6FD3EA6E24D012CECE3@ove1wnexm01.corp.illuminet.com> Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_003D_01C3AD37.192A8790 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable =20 You mean other than us implementing it? No, I don't think so. I think = its considered Rosemary's Baby by most. =20 FM =20 =20 Frank W. Miller, Ph.D. Chief Technical Officer sentitO Networks, Inc. fmiller@sentito.com =20 -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of McCandless, Kevin Sent: Monday, November 17, 2003 4:11 PM To: sip@ietf.org Subject: [Sip] Sip support for TCAP queries =20 Has any progress been taken on the draft by Frank Miller on Carrying = TCAP in SIP messages? Are there other drafts that address SIP access to SS7 database information through TCAP or another method? =20 Thanks, =20 Kevin=20 ------=_NextPart_000_003D_01C3AD37.192A8790 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message

 

You mean other than us implementing = it?  No, I don’t think so.  I think its considered Rosemary’s = Baby by most…

 

FM

 

 

Frank W. Miller, = Ph.D.

Chief Technical = Officer

sentitO Networks, = Inc.

fmiller@sentito.com

 

-----Original = Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On = Behalf Of McCandless, Kevin
Sent: Monday, November = 17, 2003 4:11 PM
To: sip@ietf.org
Subject: [Sip] Sip = support for TCAP queries

 

Has any progress been taken = on the draft by Frank Miller on Carrying TCAP in SIP messages?  Are there = other drafts that address SIP access to SS7 database information through TCAP = or another method?

 

Thanks,

 

Kevin =

------=_NextPart_000_003D_01C3AD37.192A8790-- _______________________________________________ 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 exim@www1.ietf.org Tue Nov 18 06:34:27 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16652 for ; Tue, 18 Nov 2003 06:34:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM47M-0005oD-IV for sip-archive@odin.ietf.org; Tue, 18 Nov 2003 06:34:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIBY0vn022271 for sip-archive@odin.ietf.org; Tue, 18 Nov 2003 06:34:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM46P-0005hw-QG; Tue, 18 Nov 2003 06:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM46F-0005go-C1 for sip@optimus.ietf.org; Tue, 18 Nov 2003 06:32:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16557 for ; Tue, 18 Nov 2003 06:32:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM46B-0003CW-00 for sip@ietf.org; Tue, 18 Nov 2003 06:32:47 -0500 Received: from law12-f73.law12.hotmail.com ([64.4.19.73] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AM46A-0003C3-00 for sip@ietf.org; Tue, 18 Nov 2003 06:32:46 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 18 Nov 2003 03:32:18 -0800 Received: from 203.197.98.3 by lw12fd.law12.hotmail.msn.com with HTTP; Tue, 18 Nov 2003 11:32:17 GMT X-Originating-IP: [203.197.98.3] X-Originating-Email: [rajarshi_chakraborty@hotmail.com] From: "Rajarshi Chakraborty" To: sip@ietf.org Cc: agupta@cse.iitkgp.ernet.in Date: Tue, 18 Nov 2003 11:32:17 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 18 Nov 2003 11:32:18.0022 (UTC) FILETIME=[9F5C2860:01C3ADC7] Subject: [Sip] URGENT: Refering to obsolete drafts Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, I want to put an Internet Draft's name in the reference of my research paper. This Internet Draft happens to be obsolete(draft-schulzrinne-sip-register-01); it expired on Oct'01 and no more versions of it were released. Could someone suggest me how to address this obsolete draft in the reference section? I used the following: Schulzrinne, H., "SIP Registration", , work in progress, October 2001 Is the above correct? Is it proper to use "work in progress" for this obsolete draft? Any kind of immediate response and/or suggestion will be highly appreciated. I am new in this. regards, Rajarshi Rajarshi Chakraborty B-196, IIT Campus, Kharagpur, West Bengal, India PIN-721302 _________________________________________________________________ Garfield on your mobile. Download now. http://server1.msn.co.in/sp03/gprs/ How cool can life get? _______________________________________________ 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 exim@www1.ietf.org Tue Nov 18 11:29:11 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28575 for ; Tue, 18 Nov 2003 11:29:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM8ii-0005dD-Q2 for sip-archive@odin.ietf.org; Tue, 18 Nov 2003 11:28:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIGSquC021647 for sip-archive@odin.ietf.org; Tue, 18 Nov 2003 11:28:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM8ht-0005c2-Tq; Tue, 18 Nov 2003 11:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM8hg-0005bR-Ri for sip@optimus.ietf.org; Tue, 18 Nov 2003 11:27:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28525 for ; Tue, 18 Nov 2003 11:27:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM8hf-0000AO-00 for sip@ietf.org; Tue, 18 Nov 2003 11:27:47 -0500 Received: from kcmso1.att.com ([192.128.133.69] helo=kcmso1.proxy.att.com) by ietf-mx with esmtp (Exim 4.12) id 1AM8hf-00009r-00 for sip@ietf.org; Tue, 18 Nov 2003 11:27:47 -0500 Received: from attrh5i.attrh.att.com ([135.38.62.12]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-5.0) with ESMTP id hAIEpn7W032686 for ; Tue, 18 Nov 2003 10:27:16 -0600 Received: from KCCLUST06EVS1.ugd.att.com (135.38.164.89) by attrh5i.attrh.att.com (6.5.032) id 3F307C6C01EAD7C3; Tue, 18 Nov 2003 11:26:55 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3ADF0.D33915A5" Subject: RE: [Sip] Sip support for TCAP queries Date: Tue, 18 Nov 2003 10:27:14 -0600 Message-ID: <73656AE8EE4C9C4D9FFF9DBFEAE9A00F0B1C3C@KCCLUST06EVS1.ugd.att.com> Thread-Topic: [Sip] Sip support for TCAP queries Thread-Index: AcOtYXkLHJlfBjGrSiGFCFE0fdXjAAAhUBqg From: "Chong, Koan S, ALABS" To: "Frank W. Miller" , "McCandless, Kevin" Cc: Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C3ADF0.D33915A5 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable =20 A couple specific questions: =20 What is the recommendation on how a SIP network element can access the callers' name databases (CNAM in US) in PSTN after the SIP element has determined that the called parties have subscribed to Caller ID? =20 How about interworking with CLASS Auto-Recall/Callback (CCBS in ITU?) procedures? =20 Assume TCAP over SIGTRAN is a bit long long term.... =20 Koan Koan S.Chong AT&T 1-732-420-4557 =20 -----Original Message----- From: Frank W. Miller [mailto:fmiller@sentito.com] Sent: Monday, November 17, 2003 6:18 PM To: 'McCandless, Kevin' Cc: sip@ietf.org Subject: RE: [Sip] Sip support for TCAP queries =20 You mean other than us implementing it? No, I don't think so. I think its considered Rosemary's Baby by most... =20 FM =20 =20 Frank W. Miller, Ph.D. Chief Technical Officer sentitO Networks, Inc. fmiller@sentito.com =20 -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of McCandless, Kevin Sent: Monday, November 17, 2003 4:11 PM To: sip@ietf.org Subject: [Sip] Sip support for TCAP queries =20 Has any progress been taken on the draft by Frank Miller on Carrying TCAP in SIP messages? Are there other drafts that address SIP access to SS7 database information through TCAP or another method? =20 Thanks, =20 Kevin=20 ------_=_NextPart_001_01C3ADF0.D33915A5 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Message
 
A=20 couple specific questions:
 
What=20 is the recommendation on how a SIP network element can access the = callers' name=20 databases (CNAM in US) in PSTN after the SIP element has determined that = the=20 called parties have subscribed to Caller ID?
 
How=20 about interworking with CLASS Auto-Recall/Callback (CCBS in ITU?)=20 procedures?
 
Assume=20 TCAP over SIGTRAN is a bit long long term....
 
Koan
Koan=20 S.Chong
AT&T
1-732-420-4557
 
-----Original Message-----
From: Frank W. Miller=20 [mailto:fmiller@sentito.com]
Sent: Monday, November 17, 2003 = 6:18=20 PM
To: 'McCandless, Kevin'
Cc:=20 sip@ietf.org
Subject: RE: [Sip] Sip support for TCAP=20 queries

 

You mean = other than=20 us implementing it?  No, I don’t think so.  I think = its considered=20 Rosemary’s Baby by most…

 

FM

 

 

Frank W. = Miller,=20 Ph.D.

Chief = Technical=20 Officer

sentitO = Networks,=20 Inc.

fmiller@sentito.com

 

-----Original=20 Message-----
From:=20 sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of McCandless,=20 Kevin
Sent: Monday, = November=20 17, 2003 4:11 PM
To:=20 sip@ietf.org
Subject: [Sip]=20 Sip support for TCAP queries

 

Has any progress been = taken on the=20 draft by Frank Miller on Carrying TCAP in SIP messages?  Are = there other=20 drafts that address SIP access to SS7 database information through = TCAP or=20 another method?

 

Thanks,

 

Kevin=20

------_=_NextPart_001_01C3ADF0.D33915A5-- _______________________________________________ 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 exim@www1.ietf.org Tue Nov 18 11:52:04 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29915 for ; Tue, 18 Nov 2003 11:52:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM94r-00084g-B5 for sip-archive@odin.ietf.org; Tue, 18 Nov 2003 11:51:45 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIGpjWd031039 for sip-archive@odin.ietf.org; Tue, 18 Nov 2003 11:51:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM94A-0007s9-K2; Tue, 18 Nov 2003 11:51:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM93w-0007rM-Be for sip@optimus.ietf.org; Tue, 18 Nov 2003 11:50:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29865 for ; Tue, 18 Nov 2003 11:50:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM93v-0000eL-00 for sip@ietf.org; Tue, 18 Nov 2003 11:50:47 -0500 Received: from airwolf.sentito.com ([65.202.222.11]) by ietf-mx with smtp (Exim 4.12) id 1AM93u-0000e5-00 for sip@ietf.org; Tue, 18 Nov 2003 11:50:46 -0500 Received: (qmail 28794 invoked from network); 18 Nov 2003 16:51:36 -0000 Received: from unknown (HELO frankgks0u6mmz) (relay@65.202.222.2) by airwolf.sentito.com with SMTP; 18 Nov 2003 16:51:36 -0000 From: "Frank W. Miller" To: "'Chong, Koan S, ALABS'" Cc: Subject: RE: [Sip] Sip support for TCAP queries Date: Tue, 18 Nov 2003 11:50:15 -0500 Message-ID: <004201c3adf4$0a6e4490$9100000a@frankgks0u6mmz> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0043_01C3ADCA.21983C90" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <73656AE8EE4C9C4D9FFF9DBFEAE9A00F0B1C3C@KCCLUST06EVS1.ugd.att.com> Importance: Normal Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0043_01C3ADCA.21983C90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 The main idea of this draft was to provide a capability for SIP = endpoints to do TCAP queries without having to implement the binary TCAP protocol. = The motivation is that there are a lot of TCAP queries that take place (800, LNP, CNAME) that are really simple and that major carriers may not want = to go and reimplement in an ENUM database in the short term. These = carriers have spent a lot of money on their SCPs and converting the to ENUM is non-trivial. Now, the SCPs could be front-ended and conversion can be automated but this draft provides an alternative. So, to answer the = first question, the SIP endpoint formats the correct query in the XML format specified and sends if using an INFO to a Signaling Gateway (SG). The = SG then converts the query to binary TCAP and dips the SCP. The XML format = can be templated in the implementation so the effort is quite minimal on the = SIP endpoint. To answer the second question, the draft talks about a couple = of examples but the specification encompasses the entire TCAP message set = so you can format the appropriate dip for AR/C. One caveat is that the = draft is Telcordia based. It would need to be extended to take into account = other variants. On the third question, I'm a believer in translation over tunneling, tunneling just puts off work and mixes = messaging from different signaling networks unnecessarily. =20 FM =20 =20 =20 Frank W. Miller, Ph.D. Chief Technical Officer sentitO Networks, Inc. fmiller@sentito.com =20 -----Original Message----- From: Chong, Koan S, ALABS [mailto:kschong@att.com]=20 Sent: Tuesday, November 18, 2003 11:27 AM To: Frank W. Miller; McCandless, Kevin Cc: sip@ietf.org Subject: RE: [Sip] Sip support for TCAP queries =20 =20 A couple specific questions: =20 What is the recommendation on how a SIP network element can access the callers' name databases (CNAM in US) in PSTN after the SIP element has determined that the called parties have subscribed to Caller ID? =20 How about interworking with CLASS Auto-Recall/Callback (CCBS in ITU?) procedures? =20 Assume TCAP over SIGTRAN is a bit long long term.... =20 Koan Koan S.Chong AT&T 1-732-420-4557 =20 -----Original Message----- From: Frank W. Miller [mailto:fmiller@sentito.com] Sent: Monday, November 17, 2003 6:18 PM To: 'McCandless, Kevin' Cc: sip@ietf.org Subject: RE: [Sip] Sip support for TCAP queries =20 You mean other than us implementing it? No, I don't think so. I think = its considered Rosemary's Baby by most. =20 FM =20 =20 Frank W. Miller, Ph.D. Chief Technical Officer sentitO Networks, Inc. fmiller@sentito.com =20 -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of McCandless, Kevin Sent: Monday, November 17, 2003 4:11 PM To: sip@ietf.org Subject: [Sip] Sip support for TCAP queries =20 Has any progress been taken on the draft by Frank Miller on Carrying = TCAP in SIP messages? Are there other drafts that address SIP access to SS7 database information through TCAP or another method? =20 Thanks, =20 Kevin=20 ------=_NextPart_000_0043_01C3ADCA.21983C90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message

 

The main idea of this draft was to = provide a capability for SIP endpoints to do TCAP queries without having to = implement the binary TCAP protocol.  The motivation is that there are a lot of = TCAP queries that take place (800, LNP, CNAME) that are really simple and = that major carriers may not want to go and reimplement in an ENUM database in the = short term.  These carriers have spent a lot of money on their SCPs and converting the to ENUM is non-trivial.  Now, the SCPs could be = front-ended and conversion can be automated but this draft provides an = alternative.  So, to answer the first question, the SIP endpoint formats the correct = query in the XML format specified and sends if using an INFO to a Signaling = Gateway (SG).  The SG then converts the query to binary TCAP and dips the SCP.  The XML format can be templated in the implementation so the = effort is quite minimal on the SIP endpoint.  To answer the second = question, the draft talks about a couple of examples but the specification encompasses = the entire TCAP message set so you can format the appropriate dip for = AR/C.  One caveat is that the draft is Telcordia based.  It would need to be = extended to take into account other variants.  On the third question, = <personal view> I’m a believer in translation over tunneling, tunneling = just puts off work and mixes messaging from different signaling networks = unnecessarily</personal view>.

 

FM

 

 

 

Frank W. Miller, = Ph.D.

Chief Technical = Officer

sentitO Networks, = Inc.

fmiller@sentito.com

 

-----Original = Message-----
From: Chong, Koan S, = ALABS [mailto:kschong@att.com]
Sent: Tuesday, November = 18, 2003 11:27 AM
To: Frank W. Miller; = McCandless, Kevin
Cc: sip@ietf.org
Subject: RE: [Sip] Sip = support for TCAP queries

 

 

A = couple specific questions:

 

What is the recommendation on how a SIP network element can access the callers' name databases (CNAM in US) in PSTN after the SIP element has determined that = the called parties have subscribed to Caller ID?

 

How about = interworking with CLASS Auto-Recall/Callback (CCBS in ITU?) = procedures?

 

Assume TCAP over SIGTRAN is a bit long long term....

 

Koan

Koan = S.Chong

AT&T

1-732-420-4557

 

=

-----Original Message-----
From: Frank W. Miller [mailto:fmiller@sentito.com]
Sent: Monday, November = 17, 2003 6:18 PM
To: 'McCandless, = Kevin'
Cc: sip@ietf.org
Subject: RE: [Sip] Sip = support for TCAP queries

 

You mean other = than us implementing it?  No, I don’t think so.  I think its = considered Rosemary’s Baby by most…

 

FM<= /p>

 

 

Frank = W. Miller, Ph.D.

Chief Technical = Officer

sentitO = Networks, Inc.

fmiller@sentito.c= om

 

-----Original = Message-----
From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On = Behalf Of McCandless, Kevin
Sent: Monday, November = 17, 2003 4:11 PM
To: sip@ietf.org
Subject: [Sip] Sip = support for TCAP queries

 

Has any progress been taken = on the draft by Frank Miller on Carrying TCAP in SIP messages?  Are there = other drafts that address SIP access to SS7 database information through TCAP or = another method?

 

Thanks,

 

Kevin

------=_NextPart_000_0043_01C3ADCA.21983C90-- _______________________________________________ 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 exim@www1.ietf.org Tue Nov 18 12:07:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01193 for ; Tue, 18 Nov 2003 12:07:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM9Jg-00016M-Im for sip-archive@odin.ietf.org; Tue, 18 Nov 2003 12:07:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAIH71B9004166 for sip-archive@odin.ietf.org; Tue, 18 Nov 2003 12:07:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM9Ih-0000qC-G5; Tue, 18 Nov 2003 12:06:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AM9Ib-0000or-AY for sip@optimus.ietf.org; Tue, 18 Nov 2003 12:05:57 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01105 for ; Tue, 18 Nov 2003 12:05:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AM9IZ-00015n-00 for sip@ietf.org; Tue, 18 Nov 2003 12:05:55 -0500 Received: from pooh.ulticom.com ([208.255.120.2] helo=chuckie.dgms.com) by ietf-mx with esmtp (Exim 4.12) id 1AM9IY-00015b-00 for sip@ietf.org; Tue, 18 Nov 2003 12:05:54 -0500 Received: from pcasveren (localhost [127.0.0.1]) by chuckie.dgms.com (8.9.3/8.9.3) with SMTP id MAA17755; Tue, 18 Nov 2003 12:05:52 -0500 (EST) From: "Tolga Asveren" To: "Frank W. Miller" , "'Chong, Koan S, ALABS'" Cc: Subject: RE: [Sip] Sip support for TCAP queries Date: Tue, 18 Nov 2003 12:05:45 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AD_01C3ADCC.4BDACCF0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <004201c3adf4$0a6e4490$9100000a@frankgks0u6mmz> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_00AD_01C3ADCC.4BDACCF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of Frank W. Miller Sent: Tuesday, November 18, 2003 11:50 AM To: 'Chong, Koan S, ALABS' Cc: sip@ietf.org Subject: RE: [Sip] Sip support for TCAP queries The main idea of this draft was to provide a capability for SIP endpoints to do TCAP queries without having to implement the binary TCAP protocol. The motivation is that there are a lot of TCAP queries that take place (800, LNP, CNAME) that are really simple and that major carriers may not want to go and reimplement in an ENUM database in the short term. These carriers have spent a lot of money on their SCPs and converting the to ENUM is non-trivial. Now, the SCPs could be front-ended and conversion can be automated but this draft provides an alternative. So, to answer the first question, the SIP endpoint formats the correct query in the XML format specified and sends if using an INFO to a Signaling Gateway (SG). The SG then converts the query to binary TCAP and dips the SCP. The XML format can be templated in the implementation so the effort is quite minimal on the SIP endpoint. To answer the second question, the draft talks about a couple of examples but the specification encompasses the entire TCAP message set so you can format the appropriate dip for AR/C. One caveat is that the draft is Telcordia based. It would need to be extended to take into account other variants. On the third question, I'm a believer in translation over tunneling, tunneling just puts off work and mixes messaging from different signaling networks unnecessarily. [TOLGA]-Although I believe this comment would fit more to SIGTRAN WG- SIGTRAN is not tunneling, it just uses SCTP as transport, like SIP uses TCAP/UDP/SCTP. If you consider SS7 messages tunneled with SIGTRAN, the same should apply also for SIP messages. So, I don't see any disadvantage of using it to do a TCAP query to a database. And I would think, SIP is also not the best way to do it, considering that it is a protocol about "sessions". If one wants to reuse existing equipment -which talks TCAP-, traditional SS7 or SIGTRAN are IMO the best two choices. FM Frank W. Miller, Ph.D. Chief Technical Officer sentitO Networks, Inc. fmiller@sentito.com -----Original Message----- From: Chong, Koan S, ALABS [mailto:kschong@att.com] Sent: Tuesday, November 18, 2003 11:27 AM To: Frank W. Miller; McCandless, Kevin Cc: sip@ietf.org Subject: RE: [Sip] Sip support for TCAP queries A couple specific questions: What is the recommendation on how a SIP network element can access the callers' name databases (CNAM in US) in PSTN after the SIP element has determined that the called parties have subscribed to Caller ID? How about interworking with CLASS Auto-Recall/Callback (CCBS in ITU?) procedures? Assume TCAP over SIGTRAN is a bit long long term.... Koan Koan S.Chong AT&T 1-732-420-4557 -----Original Message----- From: Frank W. Miller [mailto:fmiller@sentito.com] Sent: Monday, November 17, 2003 6:18 PM To: 'McCandless, Kevin' Cc: sip@ietf.org Subject: RE: [Sip] Sip support for TCAP queries You mean other than us implementing it? No, I don't think so. I think its considered Rosemary's Baby by most. FM Frank W. Miller, Ph.D. Chief Technical Officer sentitO Networks, Inc. fmiller@sentito.com -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of McCandless, Kevin Sent: Monday, November 17, 2003 4:11 PM To: sip@ietf.org Subject: [Sip] Sip support for TCAP queries Has any progress been taken on the draft by Frank Miller on Carrying TCAP in SIP messages? Are there other drafts that address SIP access to SS7 database information through TCAP or another method? Thanks, Kevin ------=_NextPart_000_00AD_01C3ADCC.4BDACCF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
 
-----Original Message-----
From: sip-admin@ietf.org = [mailto:sip-admin@ietf.org]On Behalf Of Frank W. = Miller
Sent:=20 Tuesday, November 18, 2003 11:50 AM
To: 'Chong, Koan S,=20 ALABS'
Cc: sip@ietf.org
Subject: RE: [Sip] Sip = support for=20 TCAP queries

 

The main = idea of this=20 draft was to provide a capability for SIP endpoints to do TCAP queries = without=20 having to implement the binary TCAP protocol.  The motivation is = that=20 there are a lot of TCAP queries that take place (800, LNP, CNAME) that = are=20 really simple and that major carriers may not want to go and = reimplement in an=20 ENUM database in the short term.  These carriers have spent a lot = of=20 money on their SCPs and converting the to ENUM is non-trivial.  = Now, the=20 SCPs could be front-ended and conversion can be automated but this = draft=20 provides an alternative.  So, to answer the first question, the = SIP=20 endpoint formats the correct query in the XML format specified and = sends if=20 using an INFO to a Signaling Gateway (SG).  The SG then converts = the=20 query to binary TCAP and dips the SCP.  The XML format can be = templated=20 in the implementation so the effort is quite minimal on the SIP=20 endpoint.  To answer the second question, the draft talks about a = couple=20 of examples but the specification encompasses the entire TCAP message = set so=20 you can format the appropriate dip for AR/C.  One caveat is that = the=20 draft is Telcordia based.  It would need to be extended to take = into=20 account other variants.  On the third question, <personal = view> I’m=20 a believer in translation over tunneling, tunneling just puts off work = and=20 mixes messaging from different signaling networks = unnecessarily</personal=20 view>. 

[TOLGA]-Although I = believe=20 this comment would fit more to SIGTRAN WG- SIGTRAN is not = tunneling, it=20 just uses SCTP as transport, like SIP uses TCAP/UDP/SCTP. If you = consider=20 SS7 messages tunneled with SIGTRAN, the same should apply also for SIP = messages. So, I don't see any disadvantage of using it = to do a=20 TCAP query to a database. And I would think,  SIP is also not the best way to do it, considering = that it is a=20 protocol about "sessions". If one wants to reuse existing equipment = -which=20 talks TCAP-, traditional SS7 or SIGTRAN are IMO the best two=20 choices.

 

FM

 

 

 

Frank W. = Miller,=20 Ph.D.

Chief = Technical=20 Officer

sentitO = Networks,=20 Inc.

fmiller@sentito.com

 

-----Original=20 Message-----
From: = Chong,=20 Koan S, ALABS [mailto:kschong@att.com]
Sent: Tuesday, November 18, = 2003 11:27=20 AM
To: Frank W. = Miller;=20 McCandless, Kevin
Cc:=20 sip@ietf.org
Subject: RE:=20 [Sip] Sip support for TCAP queries

 

 

A=20 couple specific questions:

 

What is=20 the recommendation on how a SIP network element can access the = callers' name=20 databases (CNAM in US) in PSTN after the SIP element has determined = that the=20 called parties have subscribed to Caller ID?

 

How=20 about interworking with CLASS Auto-Recall/Callback (CCBS in ITU?)=20 procedures?

 

Assume=20 TCAP over SIGTRAN is a bit long long = term....

 

Koan

Koan=20 S.Chong

AT&T

1-732-420-4557

 

-----Original=20 Message-----
From: Frank W.=20 Miller [mailto:fmiller@sentito.com]
Sent: Monday, November 17, = 2003 6:18=20 PM
To: = 'McCandless,=20 Kevin'
Cc:=20 sip@ietf.org
Subject: RE:=20 [Sip] Sip support for TCAP queries

 

You=20 mean other than us implementing it?  No, I don’t think = so.  I=20 think its considered Rosemary’s Baby by = most…

 

FM

 

 

Frank W. = Miller,=20 Ph.D.

Chief=20 Technical Officer

sentitO = Networks,=20 Inc.

fmiller@sentito.com

 

-----Original=20 Message-----
From:=20 sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of McCandless,=20 Kevin
Sent: = Monday,=20 November 17, 2003 4:11 PM
To: sip@ietf.org
Subject: [Sip] Sip support = for TCAP=20 queries

 

Has any progress been = taken on=20 the draft by Frank Miller on Carrying TCAP in SIP messages?  = Are there=20 other drafts that address SIP access to SS7 database information = through=20 TCAP or another method?

 

Thanks,

 

Kevin=20

------=_NextPart_000_00AD_01C3ADCC.4BDACCF0-- _______________________________________________ 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 exim@www1.ietf.org Tue Nov 18 23:55:15 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06388 for ; Tue, 18 Nov 2003 23:55:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMKMj-0007gS-6I for sip-archive@odin.ietf.org; Tue, 18 Nov 2003 23:54:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAJ4svvm029477 for sip-archive@odin.ietf.org; Tue, 18 Nov 2003 23:54:57 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMKLq-0007VW-0R; Tue, 18 Nov 2003 23:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMKLX-0007V8-4K for sip@optimus.ietf.org; Tue, 18 Nov 2003 23:53:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06364 for ; Tue, 18 Nov 2003 23:53:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMKLU-00002P-00 for sip@ietf.org; Tue, 18 Nov 2003 23:53:40 -0500 Received: from law12-f77.law12.hotmail.com ([64.4.19.77] helo=hotmail.com) by ietf-mx with esmtp (Exim 4.12) id 1AMKLU-00002M-00 for sip@ietf.org; Tue, 18 Nov 2003 23:53:40 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 18 Nov 2003 20:53:10 -0800 Received: from 203.197.98.3 by lw12fd.law12.hotmail.msn.com with HTTP; Wed, 19 Nov 2003 04:53:10 GMT X-Originating-IP: [203.197.98.3] X-Originating-Email: [rajarshi_chakraborty@hotmail.com] From: "Rajarshi Chakraborty" To: sip@ietf.org Date: Wed, 19 Nov 2003 04:53:10 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 19 Nov 2003 04:53:10.0816 (UTC) FILETIME=[08204200:01C3AE59] Subject: [Sip] Are the models in draft-schulzrinne-sip-register obsolete? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Hi, We have implemented mobility using SIP and that too based on a couple of registration models from the Internet Draft - draft-schulzrinne-sip-register-01. I figured no more versions of this draft have been released. This draft expired on October 2001. I would like to know if the models proposed in this draft have been incorporated in some RFC or if have they been completely rejected. If there is any such RFC, which one is it? Thanks in advance. regards, Rajarshi Rajarshi Chakraborty B-196, IIT Campus, Kharagpur, West Bengal, India PIN-721302 _________________________________________________________________ Enjoy shopping online? Get this e credit card. http://server1.msn.co.in/features/amex/ It cuts cost & adds value! _______________________________________________ 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 exim@www1.ietf.org Thu Nov 20 11:56:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13240 for ; Thu, 20 Nov 2003 11:56:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMs6J-0007ys-U4 for sip-archive@odin.ietf.org; Thu, 20 Nov 2003 11:56:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKGuF9x030674 for sip-archive@odin.ietf.org; Thu, 20 Nov 2003 11:56:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMs66-0007xp-8u; Thu, 20 Nov 2003 11:56:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMs5y-0007xM-8b for sip@optimus.ietf.org; Thu, 20 Nov 2003 11:55:54 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13209 for ; Thu, 20 Nov 2003 11:55:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMs5x-00066h-00 for sip@ietf.org; Thu, 20 Nov 2003 11:55:53 -0500 Received: from zrc2s0jx.nortelnetworks.com ([47.103.122.112]) by ietf-mx with esmtp (Exim 4.12) id 1AMs5w-000661-00 for sip@ietf.org; Thu, 20 Nov 2003 11:55:52 -0500 Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id hAKGsk916761; Thu, 20 Nov 2003 10:54:47 -0600 (CST) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 20 Nov 2003 10:54:47 -0600 Message-ID: <870397D7C140C84DB081B88396458DAF578E36@zrc2c000.us.nortel.com> From: "Mary Barnes" To: "'Ben Campbell'" Cc: Paul Kyzivat , Cullen Jennings , Adam Roach , Markus.Isomaki@nokia.com, Dean Willis , Jonathan Rosenberg , "'sip@ietf.org'" Date: Thu, 20 Nov 2003 10:54:47 -0600 X-Mailer: Internet Mail Service (5.5.2653.19) Subject: [Sip] RE: What does 3087 say (Was Re: [Simple] ad-hoc list subscription s) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Ben, I think rather than being taken private, this discussion needs to be discussed in SIP (or SIPPING) since it is relevant to the History-Info draft and I think it's this topic that has been one of the primary concerns folks have had with this work. Although, I want to clearly state that VM is not at all the only use case we have for this and isn't the primary motivation at this point (and it's unfortunate that it was the initial use case that we had when we first approached this topic). Mary. -----Original Message----- From: Ben Campbell [mailto:bcampbell@dynamicsoft.com] Sent: Thursday, November 20, 2003 10:31 AM To: Jonathan Rosenberg Cc: Paul Kyzivat; Cullen Jennings; Adam Roach; Markus.Isomaki@nokia.com; Dean Willis; simple@ietf.org Subject: Re: What does 3087 say (Was Re: [Simple] ad-hoc list subscriptions) As I commented in a previous note, this seems to be vearing a bit off topic for SIMPLE. I am trimming the simple list from this response. If anyone things this discussion is really relevant to the list at large, feel free to put it back. More inline: Jonathan Rosenberg wrote: > > > Paul Kyzivat wrote: > >> >> >> Ben Campbell wrote: >> >>> >>> VM is sort of in a gray area, as I think there is room for all sorts >>> of interesting, non-conventional approaches. One _really_ big problem >>> facing carriers these days is difficulty in deploying new services. I >>> think this will be the death of some of the "conventional" telecom >>> carriers in the long run. 3087 is all about trying to make it easier >>> to create new (hopefully innovative) services. This was something >>> that my employer (at the time of the original writing) was really >>> worrying about. >> >> >> >> This makes a lot of sense, and I like the approach. But I can see how >> a supplier of VM systems would want to hedge its bets. This approach >> depends on the user having a configurable proxy that can select among >> all the VM alternatives. Much of the intelligence has been moved from >> the VM to the proxy. > > > Well, this is perhaps the essence of the long standing dispute on > history vs. URI-invocation as the way to talk to voicemail systems. > >> >> That is great if the VM provider is also the proxy provider. It is >> also probably ok if all the possible proxy providers that the VM is >> likely to find itself deployed with provide that functionality. But >> today those aren't necessarily good assumptions. To hedge the bets, >> the VM provider will probably want to have an alternative way to >> discriminate the different services on its own. >> >> So the tricky part is getting all the pieces to a stage where they can >> smoothly interoperate with one another. > > > The other issue is that, even if you dont standardize the syntax, and > leave that up to configuration, there needs to be common understanding > of the semantics. Going back to the VM case, if invocation of a > voicemail drop requires the VM server to get the subscriber ID, the > reason for the voicemail connection, and the desired prompt, there needs > to be sufficient logic in the proxy to extract that information from the > request and make sure it finds its way into the r-uri. > > As such, I think the 3087 model only works for cases where the service > invocation is parameterless; i.e., its a pure proxy function, without > the need for the proxy to know how to pull information out of messages > or other context, and shove it into an r-uri. The scenario you describe is _exactly_ what 3087 was intended to cover. In this particular case, the VM system associates a mailbox and menu tree entry point with a key, in the form of a specific, arbitrarily named URI. The only reason it needs to be encoded in the URI is for human-readability. I agree with your comment for things like ad-hoc list exploders, in that the list membership cannot be known in advance, so it must be encoded in someway. Also, to reiterate, there were 2 concepts in 3261. The first was to use the r-URI for this sort of things in the first place. The second was the arbitrariness of said URIs. Exploders can fit into the first concept, but not the second. So even here, 3087 partially applies. > > -Jonathan R. > _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple _______________________________________________ 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 exim@www1.ietf.org Thu Nov 20 12:54:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15575 for ; Thu, 20 Nov 2003 12:54:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMt0K-0004Hl-06 for sip-archive@odin.ietf.org; Thu, 20 Nov 2003 12:54:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKHs7CH016445 for sip-archive@odin.ietf.org; Thu, 20 Nov 2003 12:54:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMt0E-0004GL-43; Thu, 20 Nov 2003 12:54:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMszq-0004Fc-EB for sip@optimus.ietf.org; Thu, 20 Nov 2003 12:53:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15550 for ; Thu, 20 Nov 2003 12:53:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AMszo-00074B-00 for sip@ietf.org; Thu, 20 Nov 2003 12:53:36 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AMszo-000732-00 for sip@ietf.org; Thu, 20 Nov 2003 12:53:36 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 20 Nov 2003 09:53:40 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAKHr3jq004800; Thu, 20 Nov 2003 09:53:03 -0800 (PST) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKC98057; Thu, 20 Nov 2003 09:53:03 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 20 Nov 2003 09:53:03 -0800 Subject: Re: [Sip] RE: What does 3087 say (Was Re: [Simple] ad-hoc list subscription s) From: Cullen Jennings To: Mary Barnes , "'Ben Campbell'" CC: Paul Kyzivat , Adam Roach , , Dean Willis , Jonathan Rosenberg , Message-ID: In-Reply-To: <870397D7C140C84DB081B88396458DAF578E36@zrc2c000.us.nortel.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I think Jonathan really nailed this exactly right in the comment below. > Jonathan Rosenberg wrote: > >> As such, I think the 3087 model only works for cases where the service >> invocation is parameterless; i.e., its a pure proxy function, without >> the need for the proxy to know how to pull information out of messages >> or other context, and shove it into an r-uri. _______________________________________________ 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 exim@www1.ietf.org Thu Nov 20 15:31:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24318 for ; Thu, 20 Nov 2003 15:31:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMvSK-0008Nh-Bs for sip-archive@odin.ietf.org; Thu, 20 Nov 2003 15:31:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAKKVC5w032209 for sip-archive@odin.ietf.org; Thu, 20 Nov 2003 15:31:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMvS9-0008LO-Ml; Thu, 20 Nov 2003 15:31:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AMvRE-00081d-5q for sip@optimus.ietf.org; Thu, 20 Nov 2003 15:30:04 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24170; Thu, 20 Nov 2003 15:29:51 -0500 (EST) Message-Id: <200311202029.PAA24170@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 20 Nov 2003 15:29:50 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-sctp-04.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --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 : The Stream Control Transmission Protocol as a Transport for for the Session Initiation Protocol Author(s) : J. Rosenberg, H. Schulzrinne, G. Camarillo Filename : draft-ietf-sip-sctp-04.txt Pages : 8 Date : 2003-11-20 This document specifies a mechanism for usage of SCTP (the Stream Control Transmission Protocol) as the transport between SIP entities. SCTP is a new protocol which provides several features that may prove beneficial for transport between SIP entities which exchange a large amount of messages, including gateways and proxies. As SIP is transport independent, support of SCTP is a relatively straightforward process, nearly identical to support for TCP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-sctp-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-sctp-04.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-sctp-04.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: <2003-11-20154516.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-sctp-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-sctp-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-20154516.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ 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 exim@www1.ietf.org Fri Nov 21 03:19:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04653 for ; Fri, 21 Nov 2003 03:19:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN6VU-0004T0-EF for sip-archive@odin.ietf.org; Fri, 21 Nov 2003 03:19:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAL8JCUr017169 for sip-archive@odin.ietf.org; Fri, 21 Nov 2003 03:19:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN6VK-0004Rn-2t; Fri, 21 Nov 2003 03:19:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ALl6w-0002cQ-6P for sip@optimus.ietf.org; Mon, 17 Nov 2003 10:16:18 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14858 for ; Mon, 17 Nov 2003 10:16:04 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ALl6t-0007ax-00 for sip@ietf.org; Mon, 17 Nov 2003 10:16:16 -0500 Received: from uswgco35.uswest.com ([199.168.32.124]) by ietf-mx with esmtp (Exim 4.12) id 1ALl6t-0007at-00 for sip@ietf.org; Mon, 17 Nov 2003 10:16:15 -0500 Received: from egate-ne2.uswc.uswest.com (egate-ne2.uswc.uswest.com [151.117.64.200]) by uswgco35.uswest.com (8/8) with ESMTP id hAHFG90D014604; Mon, 17 Nov 2003 08:16:10 -0700 (MST) Received: from itomae2ksm02.AD.QINTRA.COM (localhost [127.0.0.1]) by egate-ne2.uswc.uswest.com (8.12.10/8.12.10) with ESMTP id hAHFG80n007514; Mon, 17 Nov 2003 09:16:08 -0600 (CST) Received: from itomae2km01.AD.QINTRA.COM ([10.6.9.150]) by itomae2ksm02.AD.QINTRA.COM with Microsoft SMTPSVC(5.0.2195.5329); Mon, 17 Nov 2003 09:16:07 -0600 content-class: urn:content-classes:message Subject: RE: [Sip] 3-way handshake bad! MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.0.6487.1 Date: Mon, 17 Nov 2003 09:16:07 -0600 Message-ID: Thread-Topic: [Sip] 3-way handshake bad! Thread-Index: AcOtHBE+ri4Wq/3eT6mgp46IP49AXgAAS3Tw From: "Pugaczewski, Jack" To: "Paul D.Smith" , X-OriginalArrivalTime: 17 Nov 2003 15:16:07.0970 (UTC) FILETIME=[B9D1D820:01C3AD1D] Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Question: Why is a 3-way handshake bad ? ISUP has used it successully for call setup and call teardown: Call Setup: Setup -->; Call Proceeding <--; Connect <--- Call Teardown: Disconnect -->; Release <--; Release Complete --> -----Original Message----- From: sip-admin@ietf.org [mailto:sip-admin@ietf.org] On Behalf Of Paul D.Smith Sent: Monday, November 17, 2003 9:01 AM To: 'sip@ietf.org' Subject: [Sip] 3-way handshake bad! All, For context, see IETF 58 minutes. There was a suggestion that the non-INVITE avalanche problem be solved by using a 3-way handshake. I just want to flag that this idea can have unfortunate consequences during congestion. Firstly, consider a server under load. The 3-way handshake requires the following. server processes request - #1 server sends response - #2 server processes request/handshake - #3. By adding the 3rd step, we have _doubled_ the number of requests to be handled by the server increasing the load and increasing the chances it becomes congested. As per my earlier e-mail, for TCP, the chances of the initial request completing can be either 1.0 or 0.0 depending on the congestion. Increasing the congestion at the server, increases the chance of requests failing. For UDP, there is a 1/x (x >=3D 1) chance of the = request being received and processed by the server. Similarly, there is a 1/x chance of the 3rd request/handshake reaching the server. This means the chances of the 3-way handshake completing are 1/(x^2). So adding the third step greatly affects the chances of the 3-way handshake completing. Paul D.Smith Network Protocols Group=20 Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com=20 Fax: +44 20 8363 1039 Web: http://www.dataconnection.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 exim@www1.ietf.org Fri Nov 21 04:11:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06357 for ; Fri, 21 Nov 2003 04:11:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN7Jr-0000P7-0I for sip-archive@odin.ietf.org; Fri, 21 Nov 2003 04:11:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAL9BEa6001493 for sip-archive@odin.ietf.org; Fri, 21 Nov 2003 04:11:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN7Jg-0000ME-7U; Fri, 21 Nov 2003 04:11:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN7JU-0000LA-Nr for sip@optimus.ietf.org; Fri, 21 Nov 2003 04:10:52 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06312 for ; Fri, 21 Nov 2003 04:10:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN7JR-0006fY-00 for sip@ietf.org; Fri, 21 Nov 2003 04:10:49 -0500 Received: from penguin-ext.wise.edt.ericsson.se ([193.180.251.47]) by ietf-mx with esmtp (Exim 4.12) id 1AN7JQ-0006ey-00 for sip@ietf.org; Fri, 21 Nov 2003 04:10:48 -0500 Received: from esealnt612.al.sw.ericsson.se ([153.88.254.118]) by penguin-ext.wise.edt.ericsson.se (8.12.10/8.12.10/WIREfire-1.8) with ESMTP id hAL9A6Ss013251; Fri, 21 Nov 2003 10:10:06 +0100 (MET) Received: from ericsson.com (rvi2-92-168.sw.ericsson.se [153.88.92.168]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id XFFH47DY; Fri, 21 Nov 2003 10:10:05 +0100 Message-ID: <3FBDD66C.5030108@ericsson.com> Date: Fri, 21 Nov 2003 11:10:04 +0200 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Gonzalo Camarillo 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 To: sip CC: William Marshall Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Registries Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Folks, The WGLCs for the registries drafts ended some time ago. I am about to release new versions of the drafts that contain all the comments received during the last calls. One last thing that Bill Mashall pointed out and I want to clarify. The SIP header fields that have to do with authorizations carry credentials or challenges. The ABNF looks like this: Authorization = "Authorization" HCOLON credentials Proxy-Authorization = "Proxy-Authorization" HCOLON credentials WWW-Authenticate = "WWW-Authenticate" HCOLON challenge Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge The definitions for challenge and credentials are: challenge = ("Digest" LWS digest-cln *(COMMA digest-cln)) / other-challenge credentials = ("Digest" LWS digest-response) / other-response Digest defines one format for credentials and challenge that contains a bunch of parameters (username, realm, nonce, etc...) Since these parameters are digest specific, and not Authorization header specific, I chose not to add them to the registry of header field parameters. They are Digest parameters, not header field parameters. 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 exim@www1.ietf.org Fri Nov 21 04:30:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06765 for ; Fri, 21 Nov 2003 04:30:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN7cG-0001Go-1u for sip-archive@odin.ietf.org; Fri, 21 Nov 2003 04:30:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAL9UFBE004881 for sip-archive@odin.ietf.org; Fri, 21 Nov 2003 04:30:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN7c3-0001Fs-GT; Fri, 21 Nov 2003 04:30:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AN7bX-0001En-2s for sip@optimus.ietf.org; Fri, 21 Nov 2003 04:29:31 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06741 for ; Fri, 21 Nov 2003 04:29:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AN7bU-0006sd-00 for sip@ietf.org; Fri, 21 Nov 2003 04:29:28 -0500 Received: from mailserv.intranet.gr ([146.124.14.106]) by ietf-mx with esmtp (Exim 4.12) id 1AN7bS-0006sG-00 for sip@ietf.org; Fri, 21 Nov 2003 04:29:27 -0500 Received: from mailserv.intranet.gr (localhost [127.0.0.1]) by mailserv.intranet.gr (8.11.7/8.11.3) with ESMTP id hAL9WrF25170 for ; Fri, 21 Nov 2003 11:32:53 +0200 (EET) Received: from ifaistos.intranet.gr (ifaistos.intranet.GR [146.124.20.203]) by mailserv.intranet.gr (8.11.7/8.11.3) with ESMTP id hAL9Wpk25155 for ; Fri, 21 Nov 2003 11:32:51 +0200 (EET) Received: from intracom.gr (pcrnd105 [146.124.20.189]) by ifaistos.intranet.gr (8.11.7p1+Sun/8.9.1) with ESMTP id hAL9Osf11116 for ; Fri, 21 Nov 2003 11:24:55 +0200 (EET) Message-ID: <3FBDD9BF.4090308@intracom.gr> Date: Fri, 21 Nov 2003 11:24:15 +0200 From: Paraskevopoulos Pavlos Organization: INTRACOM User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: el, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Sip Transfer and Cisco Gateway Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, I don't know if this is the appropriate list for my case. Assume a connection between a sip endpoint and a POTS peer, AB connection. The access to the POTS is through a cisco gateway. A (pots) ----------- GW (3620)-------------- B sipEndpoint. | | (Transfer the AB connection to AC) | C sipEndpoint Whenever we try to transfer the AB connection to AC, the GW responses with just a 202 Accepted Message. Enabling debugging in the cisco router we get the following messages. cause i = 0x82E0981C Mandatory information Element Missing. Call State i=0x0A The version of the router is: Cisco Internetwork Operating System Software IOS (tm) 3600 Software (C3620-IS-M), Version 12.2(13)T, RELEASE SOFTWARE (fc1) Compiled Sat 16-Nov-02 09:30 by ccai Image text-base: 0x6000891C, data-base: 0x61848000 System image file is "flash:c3620-is-mz.122-13.T.bin" The dial peers are correctly configured. The transfer with Cisco 7960 and ATA188 has no problem. I wonder if someone could help. What is the mandatory element missing? Thanks in advance. The messages flow is following: Request line: REFER sip:002106674342@146.124.120.215:5060 SIP/2.0 Message Header Max-Forwards: 69 Via: SIP/2.0/UDP 146.124.120.212;branch=z9hG4bKf08e.ecd768c1.0 Via: SIP/2.0/UDP 146.124.120.94:5060 From: ;tag=58912 To: ;tag=240DD5C8-2B8 Call-ID: 17952@146.124.120.94 CSeq: 3 REFER Refer-To: Referred-By: Contact: User-Agent: netPhone-2.9 Content-Length: 0 Status line: SIP/2.0 202 Accepted Message Header Via: SIP/2.0/UDP 146.124.120.212;branch=z9hG4bKf08e.ecd768c1.0,SIP/2.0/UDP 146.124.120.94:5060 From: ;tag=58912 To: ;tag=240DD5C8-2B8 Date: Mon, 08 Mar 1993 00:01:36 GMT Call-ID: 17952@146.124.120.94 Server: Cisco-SIPGateway/IOS-12.x CSeq: 3 REFER Content-Length: 0 _______________________________________________ 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 exim@www1.ietf.org Fri Nov 21 11:07:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19304 for ; Fri, 21 Nov 2003 11:07:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANDoU-0007p0-W1 for sip-archive@odin.ietf.org; Fri, 21 Nov 2003 11:07:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALG7Ix1030004 for sip-archive@odin.ietf.org; Fri, 21 Nov 2003 11:07:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANDoE-0007mB-6s; Fri, 21 Nov 2003 11:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANDnk-0007lV-Ar for sip@optimus.ietf.org; Fri, 21 Nov 2003 11:06:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19260 for ; Fri, 21 Nov 2003 11:06:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANDnh-0004DZ-00 for sip@ietf.org; Fri, 21 Nov 2003 11:06:29 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ANDnh-0004D7-00 for sip@ietf.org; Fri, 21 Nov 2003 11:06:29 -0500 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-3.cisco.com (8.12.6/8.12.6) with ESMTP id hALG5srZ016139 for ; Fri, 21 Nov 2003 08:05:56 -0800 (PST) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKD84459; Fri, 21 Nov 2003 08:05:53 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 20 Nov 2003 21:10:03 -0800 From: Cullen Jennings To: Message-ID: In-Reply-To: <200311202029.PAA24170@ietf.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] SCTP and TLS Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit How do you indicate that you want to use SCTP and TLS (assuming a TLS profile for SCTP ...) _______________________________________________ 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 exim@www1.ietf.org Fri Nov 21 15:50:43 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01716 for ; Fri, 21 Nov 2003 15:50:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANIET-0002RI-RT for sip-archive@odin.ietf.org; Fri, 21 Nov 2003 15:50:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALKoPQ8009316 for sip-archive@odin.ietf.org; Fri, 21 Nov 2003 15:50:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANIE6-0002PH-UJ; Fri, 21 Nov 2003 15:50:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANIDo-0002Ov-RU for sip@optimus.ietf.org; Fri, 21 Nov 2003 15:49:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01710 for ; Fri, 21 Nov 2003 15:49:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANIDn-0000av-00 for sip@ietf.org; Fri, 21 Nov 2003 15:49:43 -0500 Received: from vtg-um-e2k1.cisco.com ([171.70.93.55] helo=vtg-um-e2k1.sj21ad.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ANIDm-0000al-00 for sip@ietf.org; Fri, 21 Nov 2003 15:49:42 -0500 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Subject: RE: [Sip] SCTP and TLS Date: Fri, 21 Nov 2003 12:47:55 -0800 Message-ID: <6677B3346233B94EBB11C06093510120024A6536@vtg-um-e2k1.sj21ad.cisco.com> Thread-Topic: [Sip] SCTP and TLS Thread-Index: AcOwSXgFBpZ8E5PNTfmFzxGxbkiwHAAJ1Ojg From: "Amit Bhadoria" To: "Cullen Jennings" , Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Isn't it "sips:user@domain;transport=3Dsctp"? -- Amit Bhadoria Software Engineer http://www.cisco.com=20 -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com]=20 Sent: Thursday, November 20, 2003 9:10 PM To: sip@ietf.org Subject: [Sip] SCTP and TLS How do you indicate that you want to use SCTP and TLS (assuming a TLS profile for SCTP ...) _______________________________________________ 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 exim@www1.ietf.org Fri Nov 21 16:55:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05282 for ; Fri, 21 Nov 2003 16:55:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJF9-0007UK-0X for sip-archive@odin.ietf.org; Fri, 21 Nov 2003 16:55:11 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALLtAD4028778 for sip-archive@odin.ietf.org; Fri, 21 Nov 2003 16:55:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJF0-0007TS-Cy; Fri, 21 Nov 2003 16:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJEA-0007Pd-8I for sip@optimus.ietf.org; Fri, 21 Nov 2003 16:54:10 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05188 for ; Fri, 21 Nov 2003 16:53:56 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANJE8-0001jJ-00 for sip@ietf.org; Fri, 21 Nov 2003 16:54:08 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1ANJE7-0001iD-00 for sip@ietf.org; Fri, 21 Nov 2003 16:54:07 -0500 Received: from cisco.com (64.102.124.12) by sj-iport-5.cisco.com with ESMTP; 21 Nov 2003 13:54:03 -0800 Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hALLrXxg029004; Fri, 21 Nov 2003 16:53:34 -0500 (EST) Received: from cisco.com (rtp-xdm2.cisco.com [64.102.17.79]) by fruitpie.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AUV74419; Fri, 21 Nov 2003 13:53:32 -0800 (PST) Message-ID: <3FBE895A.7B16A832@cisco.com> Date: Fri, 21 Nov 2003 16:53:31 -0500 From: Manoj Bhatia Organization: Cisco Systems, Inc. , RTP, NC, USA X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Paraskevopoulos Pavlos CC: sip@ietf.org, sip-implementors@cs.columbia.edu Subject: Re: [Sip] Sip Transfer and Cisco Gateway References: <3FBDD9BF.4090308@intracom.gr> Content-Type: multipart/alternative; boundary="------------463F61FE043BA1870FE38B16" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --------------463F61FE043BA1870FE38B16 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit You should be sending this to Techincal Assistance Center (TAC) at Cisco. You may also send at cs-sip@cisco.com for help on Cisco related SIP issues . If you send me the 'sh run' config on the gw, I can help you further. thanks -Manoj Paraskevopoulos Pavlos wrote: > Hi, > > I don't know if this is the appropriate list for my case. > > Assume a connection between a sip endpoint and a POTS peer, AB > connection. The access to the POTS is through a cisco gateway. > > A (pots) ----------- GW (3620)-------------- B sipEndpoint. > > | > | (Transfer the AB connection to AC) > | > > C sipEndpoint > > Whenever we try to transfer the AB connection to AC, the GW responses > with just a 202 Accepted Message. > > Enabling debugging in the cisco router we get the following messages. > > cause i = 0x82E0981C Mandatory information Element Missing. > Call State i=0x0A > > The version of the router is: > > Cisco Internetwork Operating System Software > IOS (tm) 3600 Software (C3620-IS-M), Version 12.2(13)T, RELEASE > SOFTWARE (fc1) > > Compiled Sat 16-Nov-02 09:30 by ccai > Image text-base: 0x6000891C, data-base: 0x61848000 > > System image file is "flash:c3620-is-mz.122-13.T.bin" > > The dial peers are correctly configured. > The transfer with Cisco 7960 and ATA188 has no problem. > I wonder if someone could help. What is the mandatory element missing? > > Thanks in advance. > > The messages flow is following: > > Request line: REFER sip:002106674342@146.124.120.215:5060 SIP/2.0 > Message Header > Max-Forwards: 69 > Via: SIP/2.0/UDP 146.124.120.212;branch=z9hG4bKf08e.ecd768c1.0 > Via: SIP/2.0/UDP 146.124.120.94:5060 > From: ;tag=58912 > To: ;tag=240DD5C8-2B8 > Call-ID: 17952@146.124.120.94 > CSeq: 3 REFER > Refer-To: > Referred-By: > Contact: > User-Agent: netPhone-2.9 > Content-Length: 0 > > Status line: SIP/2.0 202 Accepted > Message Header > Via: SIP/2.0/UDP > 146.124.120.212;branch=z9hG4bKf08e.ecd768c1.0,SIP/2.0/UDP > 146.124.120.94:5060 > From: ;tag=58912 > To: ;tag=240DD5C8-2B8 > Date: Mon, 08 Mar 1993 00:01:36 GMT > Call-ID: 17952@146.124.120.94 > Server: Cisco-SIPGateway/IOS-12.x > CSeq: 3 REFER > Content-Length: 0 > > _______________________________________________ > 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 -- Manoj Bhatia | | | manojb@cisco.com | :|: :|: 7025 Kit Creek Road, RTP, NC - 27709 | :|||||: :|||||: Ph: 919-392-3873 Fax:919-392-6801 | C i s c o S y s t e m s --------------463F61FE043BA1870FE38B16 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
You should be sending this to Techincal Assistance Center (TAC)
at Cisco.
You may also send at cs-sip@cisco.com for help on
Cisco related SIP issues .

If you send me the 'sh run' config on the gw, I can help you further.
 

thanks
-Manoj
 

Paraskevopoulos Pavlos wrote:

Hi,

I don't know if this is the appropriate list for my case.

Assume a connection between a sip endpoint and a POTS peer, AB
connection. The access to the POTS is through a cisco gateway.

A (pots) ----------- GW (3620)-------------- B sipEndpoint.

|
|  (Transfer the AB connection to AC)
|

C sipEndpoint

Whenever we try to transfer the AB connection to AC, the GW responses
with just a 202 Accepted Message.

Enabling debugging in the cisco router we get the following messages.

cause i = 0x82E0981C Mandatory information Element Missing.
Call State i=0x0A

The version of the router is:

Cisco Internetwork Operating System Software
IOS (tm) 3600 Software (C3620-IS-M), Version 12.2(13)T,  RELEASE
SOFTWARE (fc1)

Compiled Sat 16-Nov-02 09:30 by ccai
Image text-base: 0x6000891C, data-base: 0x61848000

System image file is "flash:c3620-is-mz.122-13.T.bin"

The dial peers are correctly configured.
The transfer with Cisco 7960 and ATA188 has no problem.
I wonder if someone could help. What is the mandatory element missing?

Thanks in advance.

The messages flow is following:

   Request line: REFER sip:002106674342@146.124.120.215:5060 SIP/2.0
   Message Header
       Max-Forwards: 69
       Via: SIP/2.0/UDP 146.124.120.212;branch=z9hG4bKf08e.ecd768c1.0
       Via: SIP/2.0/UDP 146.124.120.94:5060
       From: <sip:4348@telesip1>;tag=58912
       To: <sip:002106674342@telesip1>;tag=240DD5C8-2B8
       Call-ID: 17952@146.124.120.94
       CSeq: 3 REFER
       Refer-To: <sip:8001@telesip1>
       Referred-By: <sip:4348@telesip1>
       Contact: <sip:4348@telesip1:5060>
       User-Agent: netPhone-2.9
       Content-Length: 0

   Status line: SIP/2.0 202 Accepted
   Message Header
       Via: SIP/2.0/UDP
146.124.120.212;branch=z9hG4bKf08e.ecd768c1.0,SIP/2.0/UDP
146.124.120.94:5060
       From: <sip:4348@telesip1>;tag=58912
       To: <sip:002106674342@telesip1>;tag=240DD5C8-2B8
       Date: Mon, 08 Mar 1993 00:01:36 GMT
       Call-ID: 17952@146.124.120.94
       Server: Cisco-SIPGateway/IOS-12.x
       CSeq: 3 REFER
       Content-Length: 0

_______________________________________________
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

-- 
Manoj Bhatia                           |        |         |
manojb@cisco.com                       |       :|:       :|:
7025 Kit Creek Road, RTP, NC - 27709   |     :|||||:   :|||||:
Ph: 919-392-3873  Fax:919-392-6801     |  C i s c o S y s t e m s
  --------------463F61FE043BA1870FE38B16-- _______________________________________________ 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 exim@www1.ietf.org Fri Nov 21 17:32:21 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08960 for ; Fri, 21 Nov 2003 17:32:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJor-0002Ye-0U for sip-archive@odin.ietf.org; Fri, 21 Nov 2003 17:32:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALMW4df009799 for sip-archive@odin.ietf.org; Fri, 21 Nov 2003 17:32:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJon-0002Wf-3s; Fri, 21 Nov 2003 17:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANJoN-0002W2-Aw for sip@optimus.ietf.org; Fri, 21 Nov 2003 17:31:35 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08905 for ; Fri, 21 Nov 2003 17:31:21 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANJoK-0003BA-00 for sip@ietf.org; Fri, 21 Nov 2003 17:31:32 -0500 Received: from manatick.foretec.com ([4.17.168.5] helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1ANJiJ-0002x6-00 for sip@ietf.org; Fri, 21 Nov 2003 17:25:19 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by manatick with esmtp (Exim 4.24) id 1ANJSf-0003dx-Ny for sip@ietf.org; Fri, 21 Nov 2003 17:09:09 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 21 Nov 2003 14:09:22 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hALM8WAt024832; Fri, 21 Nov 2003 14:08:32 -0800 (PST) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKE22404; Fri, 21 Nov 2003 14:08:30 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Fri, 21 Nov 2003 14:08:30 -0800 Subject: Re: [Sip] SCTP and TLS From: Cullen Jennings To: Amit Bhadoria , Message-ID: In-Reply-To: <6677B3346233B94EBB11C06093510120024A6536@vtg-um-e2k1.sj21ad.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit This will work in some cases where you want to insist that all hops use TLS but if you don't care about that you need something like transport=sctp+tls On 11/21/03 12:47 PM, "Amit Bhadoria" wrote: > Isn't it "sips:user@domain;transport=sctp"? > > -- > Amit Bhadoria > Software Engineer > http://www.cisco.com > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Thursday, November 20, 2003 9:10 PM > To: sip@ietf.org > Subject: [Sip] SCTP and TLS > > > > How do you indicate that you want to use SCTP and TLS (assuming a TLS > profile for SCTP ...) > > > > _______________________________________________ > 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 exim@www1.ietf.org Fri Nov 21 18:02:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10196 for ; Fri, 21 Nov 2003 18:02:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANKI1-0004yH-Iu for sip-archive@odin.ietf.org; Fri, 21 Nov 2003 18:02:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALN2DXd019050 for sip-archive@odin.ietf.org; Fri, 21 Nov 2003 18:02:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANKHp-0004wb-GO; Fri, 21 Nov 2003 18:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANKHD-0004vs-UL for sip@optimus.ietf.org; Fri, 21 Nov 2003 18:01:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10179 for ; Fri, 21 Nov 2003 18:01:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANKHA-0003gL-00 for sip@ietf.org; Fri, 21 Nov 2003 18:01:20 -0500 Received: from hoemail2.lucent.com ([192.11.226.163] helo=hoemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1ANKHA-0003fb-00 for sip@ietf.org; Fri, 21 Nov 2003 18:01:20 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by hoemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hALMxl715330; Fri, 21 Nov 2003 17:00:14 -0600 (CST) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id hALMxkj18752; Fri, 21 Nov 2003 16:59:46 -0600 (CST) Message-ID: <3FBE98D3.5020505@lucent.com> Date: Fri, 21 Nov 2003 16:59:31 -0600 From: "Vijay K. Gurbani" Organization: Wireless Networks Research and Development User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: sip@ietf.org Subject: Re: [Sip] SCTP and TLS References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > This will work in some cases where you want to insist that all hops > use TLS but if you don't care about that you need something like > > transport=sctp+tls Cullen: Where are you heading with this...? Do you forsee cases where the SIP message travels encrypted over portions of the network and in clear over others? I would presume that once a user specifically chose a sips URI, all hops in between need to be secure. No? - 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 exim@www1.ietf.org Fri Nov 21 18:32:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12084 for ; Fri, 21 Nov 2003 18:32:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANKky-0006ih-Cj for sip-archive@odin.ietf.org; Fri, 21 Nov 2003 18:32:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hALNW86o025830 for sip-archive@odin.ietf.org; Fri, 21 Nov 2003 18:32:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANKkq-0006hm-N6; Fri, 21 Nov 2003 18:32:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANKjz-0006h4-6V for sip@optimus.ietf.org; Fri, 21 Nov 2003 18:31:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12057 for ; Fri, 21 Nov 2003 18:30:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANKjw-0003zJ-00 for sip@ietf.org; Fri, 21 Nov 2003 18:31:04 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1ANKjv-0003zG-00 for sip@ietf.org; Fri, 21 Nov 2003 18:31:03 -0500 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hALNUUAt007222; Fri, 21 Nov 2003 15:30:30 -0800 (PST) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKE30986; Fri, 21 Nov 2003 15:30:29 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Fri, 21 Nov 2003 15:30:29 -0800 From: Cullen Jennings To: Dean Willis , Jonathan Rosenberg , Paul Kyzivat CC: "'Ben Campbell'" , Adam Roach , , Message-ID: In-Reply-To: <002301c3b083$7a044390$e1036e3f@txdwillis> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: What does 3087 say (Was Re: [Simple] ad-hoc list subscriptions) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The example you gave below is exactly what I am saying is parameterless. Effectively there are no parameters - the URL is always vlmner@vmhost;boxid=172.198,GR=27. I understand you CPL script could decided to use different parameterless URLs. If you needed to have parameters (ie something that algorithmically changed) this would not work. Cullen On 11/21/03 3:02 PM, "Dean Willis" wrote: >> As such, I think the 3087 model only works for cases where >> the service >> invocation is parameterless; i.e., its a pure proxy function, without >> the need for the proxy to know how to pull information out of >> messages >> or other context, and shove it into an r-uri. > > Not sur we agree here. The Proxy doesn't have to understand ANY of this. > Whoever sets up the forwarding entries on the proxy has to understand it. > > Case in point: > > If you call +1 972 473 5455, this ends up as an INVITE to > sip:dwillis@dynamicsoft.com. > > This SIP URL is served by a proxy -- in fact, it's a really stupid antique > proxy that hasn't been updated in years. All it knows how to do is apply a > primitive version of CPL to the call . . . > > So this week, my CPL says "Fork to all registrations". > > As a result, all my phones ring -- and if none of them answer, after ten > seconds, the Asterisk voice mail server that also registered to > dwillis@dynamicsoft.com asnwers, and the caller gets my voice mail. > > Two weeks ago, my cpl said: "Fork to all registrations, and if not answered > in 8 seconds, cancel all forks and forward to phone number 2142821376", > which diverted it to my cell phone, which if not answered diverts to voice > mail. > > Let's say I go to VoiceMailsRUs and rent a voice mail box. They tell me the > CFBNA URI for my new box is: > > sip:vlmner@voicemailsrus.np;boxid=172.98 > > Cool. My proxy doesn't have to understand this. All I have to do is paste it > into my cpl, and we're good to go. > > Now, let's say I wanted a different greeting for when my one and only SIP > phone is busy. I go back to VoiceMailsRUs, and the tell me to use the > optional code GR with a value of 27 to get the nifty new "Hi, this is Austin > Powers. The swinging cat you have called is too groovy to chat right now. > Behave, and leave a message" message. > > So, I go change my CPL to forward calls, on "busy" at all forks, to > > sip:vlmner@voicemailsrus.np;boxid=172.98,GR=27 > > And once again, despite complete ignorance of anything above the level of > SIP response codes in my proxy, I get the service I wanted. > > THERE IS ABSOLUTELY NO NEED TO MAKE VOICEMAILSRUS CONFORM TO ANY EXTERNAL > SEMANTIC MAP. > > The flip side of the rationale of 3087 is to ask "And how does VoiceMailsRUs > feel about this?" After all they're going to buy some VM boxes from Bob, and > some from Alice, and they want both brands to work with thir provisioning > system, which uses a naming convention made up a demented gnome who retains > his position by controlling incriminating photos from the 1999 company party > . . . > > So VoiceMailsRUs wants their provisioning system to be able to hook up to a > new VM box and say to it "Make me a new box named > vlmner@vmhost;boxid=172.198,GR=27, and provision it with the greeting > APSWCYCISTGTCRNBALM.WAV". > > VoiceMailrsRUs does NOT want to have to change their provisioning system to > understand the behavior-specific mailbox generation semantics of Alice, or > of Bob, or Charlie, or any other smug vendor who thinks they can replace the > entire installed base at VoiceMailsRUs. > > And that's where 3087 came from. > > -- > Dean > > > > _______________________________________________ > Simple mailing list > Simple@ietf.org > https://www1.ietf.org/mailman/listinfo/simple > _______________________________________________ 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 exim@www1.ietf.org Fri Nov 21 19:17:09 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13326 for ; Fri, 21 Nov 2003 19:17:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANLSG-0001F2-KH for sip-archive@odin.ietf.org; Fri, 21 Nov 2003 19:16:52 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAM0Gq7O004714 for sip-archive@odin.ietf.org; Fri, 21 Nov 2003 19:16:52 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANLRS-00019J-DA; Fri, 21 Nov 2003 19:16:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANLRG-000181-3N for sip@optimus.ietf.org; Fri, 21 Nov 2003 19:15:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13298 for ; Fri, 21 Nov 2003 19:15:36 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANLRE-0004WK-00 for sip@ietf.org; Fri, 21 Nov 2003 19:15:48 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1ANLRE-0004W0-00 for sip@ietf.org; Fri, 21 Nov 2003 19:15:48 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 21 Nov 2003 16:16:08 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAM0FGAt014303; Fri, 21 Nov 2003 16:15:16 -0800 (PST) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKE35258; Fri, 21 Nov 2003 16:14:51 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Fri, 21 Nov 2003 16:14:52 -0800 Subject: Re: [Sip] SCTP and TLS From: Cullen Jennings To: Vijay Gurbani CC: Message-ID: In-Reply-To: <3FBE98D3.5020505@lucent.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On 11/21/03 2:59 PM, "Vijay K. Gurbani" wrote: > Cullen Jennings wrote: > >> This will work in some cases where you want to insist that all hops >> use TLS but if you don't care about that you need something like >> >> transport=sctp+tls > > Cullen: > > Where are you heading with this...? Do you forsee cases > where the SIP message travels encrypted over portions of the > network and in clear over others? I would presume that once > a user specifically chose a sips URI, all hops in between need > to be secure. No? > > - vijay Well I very well might phone you with a sip URL because I am not sure you support TLS, however, my preference is TLS and I use TLS over TCP from my UA to my proxy. My proxy does SCTP with TLS to your proxy. And your proxy does UDP over IPSEC to you. A sips would have failed but a sip works and still allows TLS to be used for much of the network. The whole topic is not a big deal, we just need something with the semantic meeting of transport=sctp+tls in the draft. I don't care what the sysntax is. It could be transport=sctps. _______________________________________________ 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 exim@www1.ietf.org Fri Nov 21 19:34:02 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13752 for ; Fri, 21 Nov 2003 19:34:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANLib-0002TG-B9 for sip-archive@odin.ietf.org; Fri, 21 Nov 2003 19:33:46 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAM0Xjmo009440 for sip-archive@odin.ietf.org; Fri, 21 Nov 2003 19:33:45 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANLhu-0002IS-2G; Fri, 21 Nov 2003 19:33:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ANLh7-0002HV-BP for sip@optimus.ietf.org; Fri, 21 Nov 2003 19:32:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13695 for ; Fri, 21 Nov 2003 19:31:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ANLh5-0004jA-00 for sip@ietf.org; Fri, 21 Nov 2003 19:32:11 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1ANLh4-0004j6-00 for sip@ietf.org; Fri, 21 Nov 2003 19:32:11 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAM0VpnG030372; Fri, 21 Nov 2003 18:32:01 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FBEAE6E.1040003@dynamicsoft.com> Date: Fri, 21 Nov 2003 18:31:42 -0600 From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Dean Willis , Jonathan Rosenberg , Paul Kyzivat , Adam Roach , Markus.Isomaki@nokia.com, sip@ietf.org References: In-Reply-To: X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: What does 3087 say (Was Re: [Simple] ad-hoc list subscriptions) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > The example you gave below is exactly what I am saying is parameterless. > Effectively there are no parameters - the URL is always > vlmner@vmhost;boxid=172.198,GR=27. I understand you CPL script could decided > to use different parameterless URLs. > > If you needed to have parameters (ie something that algorithmically changed) > this would not work. OK, just to see if you mean what I think you mean--you speak of situations (exploders, for example) where some input cannot be know in advance, right? This makes sense for ad-hoc exploder lists, since they by nature cannot be known in advance. VM is usually _not_ a good example, since the number of initial states probably can be known in advance. > > Cullen > > > On 11/21/03 3:02 PM, "Dean Willis" wrote: > > >>>As such, I think the 3087 model only works for cases where >>>the service >>>invocation is parameterless; i.e., its a pure proxy function, without >>>the need for the proxy to know how to pull information out of >>>messages >>>or other context, and shove it into an r-uri. >> >>Not sur we agree here. The Proxy doesn't have to understand ANY of this. >>Whoever sets up the forwarding entries on the proxy has to understand it. >> >>Case in point: >> >>If you call +1 972 473 5455, this ends up as an INVITE to >>sip:dwillis@dynamicsoft.com. >> >>This SIP URL is served by a proxy -- in fact, it's a really stupid antique >>proxy that hasn't been updated in years. All it knows how to do is apply a >>primitive version of CPL to the call . . . >> >>So this week, my CPL says "Fork to all registrations". >> >>As a result, all my phones ring -- and if none of them answer, after ten >>seconds, the Asterisk voice mail server that also registered to >>dwillis@dynamicsoft.com asnwers, and the caller gets my voice mail. >> >>Two weeks ago, my cpl said: "Fork to all registrations, and if not answered >>in 8 seconds, cancel all forks and forward to phone number 2142821376", >>which diverted it to my cell phone, which if not answered diverts to voice >>mail. >> >>Let's say I go to VoiceMailsRUs and rent a voice mail box. They tell me the >>CFBNA URI for my new box is: >> >>sip:vlmner@voicemailsrus.np;boxid=172.98 >> >>Cool. My proxy doesn't have to understand this. All I have to do is paste it >>into my cpl, and we're good to go. >> >>Now, let's say I wanted a different greeting for when my one and only SIP >>phone is busy. I go back to VoiceMailsRUs, and the tell me to use the >>optional code GR with a value of 27 to get the nifty new "Hi, this is Austin >>Powers. The swinging cat you have called is too groovy to chat right now. >>Behave, and leave a message" message. >> >>So, I go change my CPL to forward calls, on "busy" at all forks, to >> >>sip:vlmner@voicemailsrus.np;boxid=172.98,GR=27 >> >>And once again, despite complete ignorance of anything above the level of >>SIP response codes in my proxy, I get the service I wanted. >> >>THERE IS ABSOLUTELY NO NEED TO MAKE VOICEMAILSRUS CONFORM TO ANY EXTERNAL >>SEMANTIC MAP. >> >>The flip side of the rationale of 3087 is to ask "And how does VoiceMailsRUs >>feel about this?" After all they're going to buy some VM boxes from Bob, and >>some from Alice, and they want both brands to work with thir provisioning >>system, which uses a naming convention made up a demented gnome who retains >>his position by controlling incriminating photos from the 1999 company party >>. . . >> >>So VoiceMailsRUs wants their provisioning system to be able to hook up to a >>new VM box and say to it "Make me a new box named >>vlmner@vmhost;boxid=172.198,GR=27, and provision it with the greeting >>APSWCYCISTGTCRNBALM.WAV". >> >>VoiceMailrsRUs does NOT want to have to change their provisioning system to >>understand the behavior-specific mailbox generation semantics of Alice, or >>of Bob, or Charlie, or any other smug vendor who thinks they can replace the >>entire installed base at VoiceMailsRUs. >> >>And that's where 3087 came from. >> >>-- >>Dean >> >> >> >>_______________________________________________ >>Simple mailing list >>Simple@ietf.org >>https://www1.ietf.org/mailman/listinfo/simple >> _______________________________________________ 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 exim@www1.ietf.org Mon Nov 24 00:26:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12253 for ; Mon, 24 Nov 2003 00:26:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO9Ei-0005sx-62 for sip-archive@odin.ietf.org; Mon, 24 Nov 2003 00:26:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAO5QCgV022622 for sip-archive@odin.ietf.org; Mon, 24 Nov 2003 00:26:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO9EX-0005rt-Or; Mon, 24 Nov 2003 00:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AO9Dv-0005qm-5Y for sip@optimus.ietf.org; Mon, 24 Nov 2003 00:25:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12175 for ; Mon, 24 Nov 2003 00:25:09 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AO9Ds-0005wf-00 for sip@ietf.org; Mon, 24 Nov 2003 00:25:20 -0500 Received: from [63.113.44.69] (helo=mail3.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AO9Ds-0005wV-00 for sip@ietf.org; Mon, 24 Nov 2003 00:25:20 -0500 Received: from dynamicsoft.com ([63.113.46.108]) by mail3.dynamicsoft.com (8.12.8/8.12.1) with ESMTP id hAO5Ogca021508; Mon, 24 Nov 2003 00:24:43 -0500 (EST) Message-ID: <3FC19616.8010200@dynamicsoft.com> Date: Mon, 24 Nov 2003 00:24:38 -0500 From: Jonathan Rosenberg Organization: dynamicsoft User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Campbell CC: Cullen Jennings , Dean Willis , Paul Kyzivat , Adam Roach , Markus.Isomaki@nokia.com, sip@ietf.org References: <3FBEAE6E.1040003@dynamicsoft.com> In-Reply-To: <3FBEAE6E.1040003@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: What does 3087 say (Was Re: [Simple] ad-hoc list subscriptions) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ben Campbell wrote: > Cullen Jennings wrote: > >> The example you gave below is exactly what I am saying is parameterless. >> Effectively there are no parameters - the URL is always >> vlmner@vmhost;boxid=172.198,GR=27. I understand you CPL script could >> decided >> to use different parameterless URLs. >> >> If you needed to have parameters (ie something that algorithmically >> changed) >> this would not work. > > > OK, just to see if you mean what I think you mean--you speak of > situations (exploders, for example) where some input cannot be know in > advance, right? This makes sense for ad-hoc exploder lists, since they > by nature cannot be known in advance. VM is usually _not_ a good > example, since the number of initial states probably can be known in > advance. I was thinking of different cases, where the information is known at the time a message is received, but is, as Cullen put it, algorithmically derived from some aspect of the request. As an example, consider a message transcoding service that takes SIP MESSAGE requests, and transcodes the content from one type to another type, and then forwards the request to the recipient. In such a case, the service can be viewed like a method invocation that takes two parameters - the recipient and the mime type to convert to: doTranscode(SipURI recipient, MIMEType targetMimeType); so, if a proxy receives a request like: MESSAGE sip:dwillis@dynamicsoft.com SIP/2.0 From: sip:fluffy@cisco.com To: sip:dwillis@dynamicsoft.com Content-Type: image/jpeg ..... the proxy would forward it like this: MESSAGE sip:xcoder-service@xcoders.com;recpt=dwillis@phone.dynamicsoft.com;target=image/tiff In this case, the proxy would need to algorithmically derive the recpt parameter (its equal to the r-uri) and the target (its based on mime types that are listed as supported from the calle caps in the registration from the UA). This service requires the proxy to understand its semantics, and to know how to compute the two parameters used in its invocation. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Chief Technology Officer Parsippany, NJ 07054-2711 dynamicsoft jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.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 exim@www1.ietf.org Mon Nov 24 10:51:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13790 for ; Mon, 24 Nov 2003 10:51:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOIza-00048C-LF for sip-archive@odin.ietf.org; Mon, 24 Nov 2003 10:51:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOFpEti015821 for sip-archive@odin.ietf.org; Mon, 24 Nov 2003 10:51:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOIzP-00043M-Ku; Mon, 24 Nov 2003 10:51:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOIzK-00042e-RU for sip@optimus.ietf.org; Mon, 24 Nov 2003 10:50:58 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13755 for ; Mon, 24 Nov 2003 10:50:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOIzG-0007FA-00 for sip@ietf.org; Mon, 24 Nov 2003 10:50:55 -0500 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AOIzG-0007Ec-00 for sip@ietf.org; Mon, 24 Nov 2003 10:50:54 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hAOFoIg19609; Mon, 24 Nov 2003 09:50:18 -0600 (CST) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id hAOFnOK21941; Mon, 24 Nov 2003 09:49:24 -0600 (CST) Message-ID: <3FC22870.3040305@lucent.com> Date: Mon, 24 Nov 2003 09:49:04 -0600 From: "Vijay K. Gurbani" Organization: Wireless Networks Research and Development User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: sip@ietf.org Subject: Re: [Sip] SCTP and TLS References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > Well I very well might phone you with a sip URL because I am not sure > you support TLS, however, my preference is TLS and I use TLS over TCP > from my UA to my proxy. My proxy does SCTP with TLS to your proxy. > And your proxy does UDP over IPSEC to you. A sips would have failed > but a sip works and still allows TLS to be used for much of the > network. > > The whole topic is not a big deal, we just need something with the > semantic meeting of transport=sctp+tls in the draft. I don't care > what the sysntax is. It could be transport=sctps. OK, I see. However, couple of observations. I seem to recall that "transport=tls" was deprecated in favor of the sips URI which implies it. Second, from your description, is seems to me that the caller is indicating a preference that says "even though the R-URI is a sip URI, use TLS over any transport {SCTP, TCP} wherever possible". Logically, this could be qualified as a caller pref since it gives guidance to intermediaries on how to handle the request. But since draft-ietf-sip-callerpref-10 is in last call, I don't think it has any chance of being included in it. I am unsure where is the best place to indicate these semantics: in the transport parameter of the R-URI or a new header. I lean towards the latter. - 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 exim@www1.ietf.org Mon Nov 24 11:47:42 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15425 for ; Mon, 24 Nov 2003 11:47:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOJrw-0006zn-EP for sip-archive@odin.ietf.org; Mon, 24 Nov 2003 11:47:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOGlOia026831 for sip-archive@odin.ietf.org; Mon, 24 Nov 2003 11:47:24 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOJrZ-0006xk-Ep; Mon, 24 Nov 2003 11:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOJr8-0006wV-Iq for sip@optimus.ietf.org; Mon, 24 Nov 2003 11:46:34 -0500 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15354 for ; Mon, 24 Nov 2003 11:46:16 -0500 (EST) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 1AOJhg-0007wO-6N; Mon, 24 Nov 2003 11:36:48 -0500 X-test-idtracker: no To: IETF-Announce :; Cc: sip@ietf.org From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Mon, 24 Nov 2003 11:36:48 -0500 Subject: [Sip] Last Call: 'Session Timers in the Session Initiation Protocol (SIP) to Proposed Standard Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Session Initiation Protocol WG to consider the following document: - 'Session Timers in the Session Initiation Protocol (SIP) ' 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 2003-12-08. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-session-timer-12.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 exim@www1.ietf.org Mon Nov 24 11:52:22 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15665 for ; Mon, 24 Nov 2003 11:52:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOJwV-0007ca-7I for sip-archive@odin.ietf.org; Mon, 24 Nov 2003 11:52:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOGq7xv029264 for sip-archive@odin.ietf.org; Mon, 24 Nov 2003 11:52:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOJwP-0007ZB-H5; Mon, 24 Nov 2003 11:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOJvd-0007Vt-BM for sip@optimus.ietf.org; Mon, 24 Nov 2003 11:51:13 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15569 for ; Mon, 24 Nov 2003 11:50:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOJvc-0000CX-00 for sip@ietf.org; Mon, 24 Nov 2003 11:51:12 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AOJvb-0000CL-00 for sip@ietf.org; Mon, 24 Nov 2003 11:51:11 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hAOGoNci014593; Mon, 24 Nov 2003 10:50:23 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Mon, 24 Nov 2003 10:50:23 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86650@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Vijay K. Gurbani'" , Cullen Jennings Cc: sip@ietf.org Subject: RE: [Sip] SCTP and TLS Date: Mon, 24 Nov 2003 10:50:22 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Vijay K. Gurbani [mailto:vkg@lucent.com] wrote: > I seem to recall that "transport=tls" was deprecated in favor > of the sips URI which implies it. Yes, this is precisely the correct answer to Cullen's question. Section 26.2.2 of RFC 3261 addresses this: Note that in the SIPS URI scheme, transport is independent of TLS, and thus "sips:alice@atlanta.com;transport=tcp" and "sips:alice@atlanta.com;transport=sctp" are both valid (although note that UDP is not a valid transport for SIPS). The use of "transport=tls" has consequently been deprecated, partly because it was specific to a single hop of the request. This is a change since RFC 2543. Personally, I couldn't be more pleased, since calling tls a transport always puts my teeth on edge. However, this leaves the issue of Via headers. I can say: Via: SIP/2.0/SCTP pc33.example.com;branch=z9hG4bK776asdhds Or: Via: SIP/2.0/TLS pc33.example.com;branch=z9hG4bK776asdhds But there is no standardized syntax that allows me to say both at the same time. /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 exim@www1.ietf.org Mon Nov 24 16:38:45 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02430 for ; Mon, 24 Nov 2003 16:38:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOOPb-0003RT-30 for sip-archive@odin.ietf.org; Mon, 24 Nov 2003 16:38:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAOLcRmS013227 for sip-archive@odin.ietf.org; Mon, 24 Nov 2003 16:38:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOOPC-0003O1-Pl; Mon, 24 Nov 2003 16:38:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOOOz-0003Ks-V9 for sip@optimus.ietf.org; Mon, 24 Nov 2003 16:37:50 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02311 for ; Mon, 24 Nov 2003 16:37:34 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOOOx-0005T1-00 for sip@ietf.org; Mon, 24 Nov 2003 16:37:48 -0500 Received: from magus.nostrum.com ([208.21.192.130] ident=root) by ietf-mx with esmtp (Exim 4.12) id 1AOOOx-0005Sy-00 for sip@ietf.org; Mon, 24 Nov 2003 16:37:47 -0500 Received: from dynamicsoft.com (ben@localhost [127.0.0.1]) by magus.nostrum.com (8.12.9/8.12.9) with ESMTP id hAOLYjnG035188; Mon, 24 Nov 2003 15:34:45 -0600 (CST) (envelope-from bcampbell@dynamicsoft.com) Message-ID: <3FC27972.9010603@dynamicsoft.com> Date: Mon, 24 Nov 2003 15:34:42 -0600 From: Ben Campbell User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031013 Thunderbird/0.3 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Rosenberg CC: Cullen Jennings , Dean Willis , Paul Kyzivat , Adam Roach , Markus.Isomaki@nokia.com, sip@ietf.org References: <3FBEAE6E.1040003@dynamicsoft.com> <3FC19616.8010200@dynamicsoft.com> In-Reply-To: <3FC19616.8010200@dynamicsoft.com> X-Enigmail-Version: 0.81.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] Re: What does 3087 say (Was Re: [Simple] ad-hoc list subscriptions) Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > Ben Campbell wrote: > >> Cullen Jennings wrote: >> >>> The example you gave below is exactly what I am saying is parameterless. >>> Effectively there are no parameters - the URL is always >>> vlmner@vmhost;boxid=172.198,GR=27. I understand you CPL script could >>> decided >>> to use different parameterless URLs. >>> >>> If you needed to have parameters (ie something that algorithmically >>> changed) >>> this would not work. >> >> >> >> OK, just to see if you mean what I think you mean--you speak of >> situations (exploders, for example) where some input cannot be know in >> advance, right? This makes sense for ad-hoc exploder lists, since they >> by nature cannot be known in advance. VM is usually _not_ a good >> example, since the number of initial states probably can be known in >> advance. > > > I was thinking of different cases, where the information is known at the > time a message is received, but is, as Cullen put it, algorithmically > derived from some aspect of the request. > > As an example, consider a message transcoding service that takes SIP > MESSAGE requests, and transcodes the content from one type to another > type, and then forwards the request to the recipient. In such a case, > the service can be viewed like a method invocation that takes two > parameters - the recipient and the mime type to convert to: > > doTranscode(SipURI recipient, MIMEType targetMimeType); > > so, if a proxy receives a request like: > > MESSAGE sip:dwillis@dynamicsoft.com SIP/2.0 > From: sip:fluffy@cisco.com > To: sip:dwillis@dynamicsoft.com > Content-Type: image/jpeg > ..... > > the proxy would forward it like this: > > MESSAGE > sip:xcoder-service@xcoders.com;recpt=dwillis@phone.dynamicsoft.com;target=image/tiff > > > In this case, the proxy would need to algorithmically derive the recpt > parameter (its equal to the r-uri) and the target (its based on mime > types that are listed as supported from the calle caps in the > registration from the UA). > > This service requires the proxy to understand its semantics, and to know > how to compute the two parameters used in its invocation. I think we are talking about the same thing. You cannot know in advance who the final recipient of a message requiring transcoding will be, just like you cannot know in advance what the membership of an ad-hoc list will be. On the other hand, one probably _can_ know the target mime-types in advance, so one could pre-define a separate URI for each. Of course, this gets cumbersome if the number of target types is large. > > -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 exim@www1.ietf.org Mon Nov 24 21:18:25 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16698 for ; Mon, 24 Nov 2003 21:18:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOSmH-0003Em-Gj for sip-archive@odin.ietf.org; Mon, 24 Nov 2003 21:18:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAP2I94v012440 for sip-archive@odin.ietf.org; Mon, 24 Nov 2003 21:18:09 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOSm9-0003Dt-E9; Mon, 24 Nov 2003 21:18:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOSlg-0003D0-Mz for sip@optimus.ietf.org; Mon, 24 Nov 2003 21:17:32 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16682 for ; Mon, 24 Nov 2003 21:17:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOSle-0003Gy-00 for sip@ietf.org; Mon, 24 Nov 2003 21:17:30 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AOSld-0003GS-00 for sip@ietf.org; Mon, 24 Nov 2003 21:17:29 -0500 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id hAP2Gwjq023807; Mon, 24 Nov 2003 18:16:58 -0800 (PST) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKF75058; Mon, 24 Nov 2003 18:16:57 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Mon, 24 Nov 2003 18:16:57 -0800 Subject: Re: [Sip] SCTP and TLS From: Cullen Jennings To: Adam Roach , Vijay Gurbani , Message-ID: In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E86650@dyn-tx-exch-001.dynamicsoft.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit sips means every hop needs TLS, transport=tls is about one hop needing TLS. transport=tls was deprecated in a SIPS uri (because it is redundant there) but I don't believe it was deprecated in a SIP uri. I was taking about the case of a sip uri. Imagine A sends with a sip uri over UDP to B with a preloaded route to C and A wishes to indicated that a TLS protected protocol should be used from B to C. However C can send the message to D any way it wants so we don't want to upgrade to a sips. This is not an unreasonable scenario - A and D could be clients in an enterprise network that is protected in some way and B and C could be enterprise proxies that do TLS protection across the internet. There is also the Via problem... I see a few possibilities for this ... (yes and I agree with Adam on the confounding of transport type and security type into one tag was not the most elegant move but yet that is where we are) We need to be able to indicate in the VIA what the protocol is and also if TLS was used or not. Solution A - define SCTPS to be SCTP with TLS and UDPS to be UDP with TLS and let the via look like Via: SIP/2.0/SCTPS pc33.example.com;branch=z9hG4bK776asdhds Solution B - change the SIP in the via to be either SIP or SIPS and treat this to be sort of like the SIP or SIPS in a NAPTR record Via: SIPS/2.0/SCTP pc33.example.com;branch=z9hG4bK776asdhds Solution C - add a security tag that defines if security TLS is used or not Via: SIP/2.0/SCTP pc33.example.com;branch=z9hG4bK776asdhds;security=TLS There are backwards compatibility issues with all of these. Next we need to be able to represent that we want security for a single hop in a URI ( could be a request URI or route or others) Solution 1 make the transport tag be one of UDP, TCP, SCTP, DCCP and add a security tag that could be TLS sip:fluffy@securityforever.org;transport=SCTP;security=TLS Solution 2 define some more transports of udp+tls sctp+tls, dccp, dccp+tls. Note that tls alone means tls over tcp. sip:fluffy@securityforever.org;transport=SCTP+TLS Also a URL with transport=+TLS would mean that any transport could be used but it must include TLS. Given we have two security protocols (nothing and tls) and a handful of transports (UDP, TCP, SCTP, DCCP) - Solution A and 2 could work without an explosion of labels. Solution 1 is tricky to make sure no one ever sends transport=tcp;security=tls to someone expecting transport=tls. Solution B will no doubt break someone who gets a "Via: SIPS/2.0/TCP" on a TLS connection. Solution C would be the right things if we went with Solution 2 instead of Solution 1. Sorry this is such a disorganized email. Thoughts? Thanks, Cullen On 11/24/03 8:50 AM, "Adam Roach" wrote: > Vijay K. Gurbani [mailto:vkg@lucent.com] wrote: > >> I seem to recall that "transport=tls" was deprecated in favor >> of the sips URI which implies it. > > Yes, this is precisely the correct answer to Cullen's question. > Section 26.2.2 of RFC 3261 addresses this: > > Note that in the SIPS URI scheme, transport is independent of TLS, > and thus "sips:alice@atlanta.com;transport=tcp" and > "sips:alice@atlanta.com;transport=sctp" are both valid (although > note that UDP is not a valid transport for SIPS). The use of > "transport=tls" has consequently been deprecated, partly because > it was specific to a single hop of the request. This is a change > since RFC 2543. > > Personally, I couldn't be more pleased, since calling tls a transport > always puts my teeth on edge. > > However, this leaves the issue of Via headers. > > I can say: > > Via: SIP/2.0/SCTP pc33.example.com;branch=z9hG4bK776asdhds > > Or: > > Via: SIP/2.0/TLS pc33.example.com;branch=z9hG4bK776asdhds > > But there is no standardized syntax that allows me to say > both at the same time. > > /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 > > _______________________________________________ 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 exim@www1.ietf.org Tue Nov 25 01:31:53 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22677 for ; Tue, 25 Nov 2003 01:31:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOWjY-0005Lc-LE for sip-archive@odin.ietf.org; Tue, 25 Nov 2003 01:31:36 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAP6VaQS020496 for sip-archive@odin.ietf.org; Tue, 25 Nov 2003 01:31:36 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOWj0-0005Ec-M5; Tue, 25 Nov 2003 01:31:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOWih-0005DV-DD for sip@optimus.ietf.org; Tue, 25 Nov 2003 01:30:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22629 for ; Tue, 25 Nov 2003 01:30:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOWie-0006MK-00 for sip@ietf.org; Tue, 25 Nov 2003 01:30:40 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AOWid-0006LO-00 for sip@ietf.org; Tue, 25 Nov 2003 01:30:39 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hAP6Sgci018088; Tue, 25 Nov 2003 00:28:42 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Nov 2003 00:28:41 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86659@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Cullen Jennings'" , Adam Roach , Vijay Gurbani , sip@ietf.org Subject: RE: [Sip] SCTP and TLS Date: Tue, 25 Nov 2003 00:28:37 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Cullen Jennings [mailto:fluffy@cisco.com] wrote: > transport=tls was deprecated in a SIPS uri (because it is > redundant there) > but I don't believe it was deprecated in a SIP uri. I think the intention was to deprecate it everywhere, not just in sips: URIs. To emphasize the final sentence of the passage I quoted (regarding deprecation of the "transport=tls" indication): "This is a change since RFC 2543." Since the "sips:" scheme is not defined in 2543, it seems a bit of a stretch to call this deprecation a change unless it applies at least to "sip:" URIs. If you find 3261 less than coherent on this topic, there is a perfectly reasonable explanation, best summarized as: "We apologise for the fault in the hop-by-hop security model. Those responsible have been sacked, and hop-by-hop security has been completed in an entirely different style at great expense at the last minute." /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 exim@www1.ietf.org Tue Nov 25 06:15:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12803 for ; Tue, 25 Nov 2003 06:15:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AObAB-00022Z-IM for sip-archive@odin.ietf.org; Tue, 25 Nov 2003 06:15:24 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPBFNnb007839 for sip-archive@odin.ietf.org; Tue, 25 Nov 2003 06:15:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOb9q-0001zM-FG; Tue, 25 Nov 2003 06:15:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOb9D-0001yj-Jl for sip@optimus.ietf.org; Tue, 25 Nov 2003 06:14:23 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12737 for ; Tue, 25 Nov 2003 06:14:07 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOb99-00026f-00 for sip@ietf.org; Tue, 25 Nov 2003 06:14:19 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AOb98-00026c-00 for sip@ietf.org; Tue, 25 Nov 2003 06:14:18 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAPBEG612329 for ; Tue, 25 Nov 2003 13:14:16 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Nov 2003 13:14:15 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 13:14:14 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SCTP and TLS Date: Tue, 25 Nov 2003 13:14:14 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797436@esebe019.ntc.nokia.com> Thread-Topic: [Sip] SCTP and TLS Thread-Index: AcOy+nI0jKqu/8XiSjG+Y6/IfNP/cAASc6GA To: , , , X-OriginalArrivalTime: 25 Nov 2003 11:14:14.0965 (UTC) FILETIME=[42B30650:01C3B345] Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext > Cullen Jennings > Sent: 25.November.2003 04:17 > To: Adam Roach; Vijay Gurbani; sip@ietf.org > Subject: Re: [Sip] SCTP and TLS >=20 >=20 >=20 > sips means every hop needs TLS, transport=3Dtls is about one=20 > hop needing TLS. >=20 > transport=3Dtls was deprecated in a SIPS uri (because it is=20 > redundant there) > but I don't believe it was deprecated in a SIP uri. I was=20 > taking about the > case of a sip uri. Imagine A sends with a sip uri over UDP=20 > to B with a > preloaded route to C and A wishes to indicated that a TLS=20 > protected protocol > should be used from B to C. However C can send the message to=20 > D any way it > wants so we don't want to upgrade to a sips. A can insert a route-header with a sips URI. What is wrong with that? /Hisham >=20 > This is not an unreasonable scenario - A and D could be clients in an > enterprise network that is protected in some way and B and C could be > enterprise proxies that do TLS protection across the internet. >=20 > There is also the Via problem... >=20 > I see a few possibilities for this ... (yes and I agree with=20 > Adam on the > confounding of transport type and security type into one tag=20 > was not the > most elegant move but yet that is where we are) >=20 > We need to be able to indicate in the VIA what the protocol=20 > is and also if > TLS was used or not. >=20 > Solution A > - define SCTPS to be SCTP with TLS and UDPS to be UDP with=20 > TLS and let the > via look like >=20 > Via: SIP/2.0/SCTPS pc33.example.com;branch=3Dz9hG4bK776asdhds >=20 > Solution B > - change the SIP in the via to be either SIP or SIPS and=20 > treat this to be > sort of like the SIP or SIPS in a NAPTR record >=20 > Via: SIPS/2.0/SCTP pc33.example.com;branch=3Dz9hG4bK776asdhds >=20 > Solution C > - add a security tag that defines if security TLS is used or not > Via: SIP/2.0/SCTP=20 > pc33.example.com;branch=3Dz9hG4bK776asdhds;security=3DTLS >=20 > There are backwards compatibility issues with all of these. >=20 > Next we need to be able to represent that we want security=20 > for a single hop > in a URI ( could be a request URI or route or others) >=20 > Solution 1 > make the transport tag be one of UDP, TCP, SCTP, DCCP and add=20 > a security tag > that could be TLS > sip:fluffy@securityforever.org;transport=3DSCTP;security=3DTLS >=20 > Solution 2 > define some more transports of udp+tls sctp+tls, dccp,=20 > dccp+tls. Note that > tls alone means tls over tcp. > sip:fluffy@securityforever.org;transport=3DSCTP+TLS > Also a URL with transport=3D+TLS would mean that any transport=20 > could be used > but it must include TLS. >=20 > Given we have two security protocols (nothing and tls) and a=20 > handful of > transports (UDP, TCP, SCTP, DCCP) - Solution A and 2 could=20 > work without an > explosion of labels. Solution 1 is tricky to make sure no one=20 > ever sends > transport=3Dtcp;security=3Dtls to someone expecting=20 > transport=3Dtls. Solution B > will no doubt break someone who gets a "Via: SIPS/2.0/TCP" on a TLS > connection. Solution C would be the right things if we went=20 > with Solution 2 > instead of Solution 1. >=20 > Sorry this is such a disorganized email. Thoughts? >=20 > Thanks, Cullen >=20 >=20 >=20 > On 11/24/03 8:50 AM, "Adam Roach" wrote: >=20 > > Vijay K. Gurbani [mailto:vkg@lucent.com] wrote: > >=20 > >> I seem to recall that "transport=3Dtls" was deprecated in favor > >> of the sips URI which implies it. > >=20 > > Yes, this is precisely the correct answer to Cullen's question. > > Section 26.2.2 of RFC 3261 addresses this: > >=20 > > Note that in the SIPS URI scheme, transport is independent of TLS, > > and thus "sips:alice@atlanta.com;transport=3Dtcp" and > > "sips:alice@atlanta.com;transport=3Dsctp" are both valid (although > > note that UDP is not a valid transport for SIPS). The use of > > "transport=3Dtls" has consequently been deprecated, partly because > > it was specific to a single hop of the request. This is a change > > since RFC 2543. > >=20 > > Personally, I couldn't be more pleased, since calling tls a=20 > transport > > always puts my teeth on edge. > >=20 > > However, this leaves the issue of Via headers. > >=20 > > I can say: > >=20 > > Via: SIP/2.0/SCTP pc33.example.com;branch=3Dz9hG4bK776asdhds > >=20 > > Or: > >=20 > > Via: SIP/2.0/TLS pc33.example.com;branch=3Dz9hG4bK776asdhds > >=20 > > But there is no standardized syntax that allows me to say > > both at the same time. > >=20 > > /a > >=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 >=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 From exim@www1.ietf.org Tue Nov 25 11:42:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26236 for ; Tue, 25 Nov 2003 11:42:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgGV-0006vw-Dv for sip-archive@odin.ietf.org; Tue, 25 Nov 2003 11:42:15 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPGgFXV026646 for sip-archive@odin.ietf.org; Tue, 25 Nov 2003 11:42:15 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgGH-0006ra-RO; Tue, 25 Nov 2003 11:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgFg-0006ql-NQ for sip@optimus.ietf.org; Tue, 25 Nov 2003 11:41:24 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26129 for ; Tue, 25 Nov 2003 11:41:10 -0500 (EST) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOgFf-0000gV-00 for sip@ietf.org; Tue, 25 Nov 2003 11:41:23 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AOgFe-0000gR-00 for sip@ietf.org; Tue, 25 Nov 2003 11:41:22 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAPGfLA16380 for ; Tue, 25 Nov 2003 18:41:21 +0200 (EET) Received: from esebh003.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Tue, 25 Nov 2003 18:41:17 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Tue, 25 Nov 2003 18:41:17 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] PUBLISH message rates Date: Tue, 25 Nov 2003 18:41:10 +0200 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D592C7@esebe013.ntc.nokia.com> Thread-Topic: [Sip] PUBLISH message rates Thread-Index: AcOqu8UC2YIGGfwATFiXANwkoKPYVQItexRQ To: , Cc: , , , X-OriginalArrivalTime: 25 Nov 2003 16:41:17.0305 (UTC) FILETIME=[F2867E90:01C3B372] Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi Paul, > -----Original Message----- > From: ext Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: 14 November, 2003 16:30 > To: Henning Schulzrinne > Cc: Khartabil Hisham (NMP-MSW/Helsinki); Niemi Aki (NMP/Helsinki); > jdrosen@dynamicsoft.com; adam@dynamicsoft.com; sip@ietf.org > Subject: Re: [Sip] PUBLISH message rates >=20 >=20 >=20 >=20 > > hisham.khartabil@nokia.com wrote: > >=20 > >> The only way to do this right is to do what RTCP does with report > >> interval, and that is to adjust the rate of PUBLISH using some > >> formula that takes into account the number of publishers=20 > at a given > >> time. The more publishers that join, the less the rate at which > >> PUBLISH is sent at. The compositors need to communicate that > >> calculated rate to the publishers somehow. Do we want to=20 > make it that > >> complicated? If not, then I suggest adding text the says if the > >> compositor is overloaded, it can send a 5xx response with > >> retry-after. >=20 > Of course use of 5xx with retry-after wastes the effort the=20 > compositor=20 > has already expended in processing the publish up to that point. >=20 > It might be interesting to make a change permitting use of the=20 > Retry-After header with a 2xx response. Then the compositor=20 > could accept=20 > a publish and at the same time ensure that the next one=20 > doesn't come=20 > too soon. This wouldn't be useful in all cases, but maybe in some. I think this is an interesting idea. However, it doesn't seem to quite = fit the Retry-After meaning. After all, the request did succeed since it = received a 200 OK.=20 Cheers, Aki > Paul >=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 exim@www1.ietf.org Tue Nov 25 11:52:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26755 for ; Tue, 25 Nov 2003 11:52:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgQ4-0007jo-Bq for sip-archive@odin.ietf.org; Tue, 25 Nov 2003 11:52:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPGq82f029708 for sip-archive@odin.ietf.org; Tue, 25 Nov 2003 11:52:08 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgPy-0007hP-Oc; Tue, 25 Nov 2003 11:52:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOgPg-0007gY-2u for sip@optimus.ietf.org; Tue, 25 Nov 2003 11:51:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26705 for ; Tue, 25 Nov 2003 11:51:29 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOgPe-0000tU-00 for sip@ietf.org; Tue, 25 Nov 2003 11:51:42 -0500 Received: from brazilnut.cc.columbia.edu ([128.59.59.203] ident=cu41754) by ietf-mx with esmtp (Exim 4.12) id 1AOgPe-0000tL-00 for sip@ietf.org; Tue, 25 Nov 2003 11:51:42 -0500 Received: from cs.columbia.edu (path.cs.columbia.edu [128.59.19.143]) (user=hgs10 mech=PLAIN bits=0) by brazilnut.cc.columbia.edu (8.12.10/8.12.10) with ESMTP id hAPGpd2d010367 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 25 Nov 2003 11:51:40 -0500 (EST) Message-ID: <3FC3889B.6060808@cs.columbia.edu> Date: Tue, 25 Nov 2003 11:51:39 -0500 From: Henning Schulzrinne User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6a) Gecko/20031030 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sip@ietf.org Subject: Re: [Sip] PUBLISH message rates References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D592C7@esebe013.ntc.nokia.com> In-Reply-To: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D592C7@esebe013.ntc.nokia.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.35 Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit [Trimming the cc ballast] > I think this is an interesting idea. However, it doesn't seem to > quite fit the Retry-After meaning. After all, the request did succeed > since it received a 200 OK. I think general SIP design philosophy is to avoid overloading of distinct meanings on the same parameter. We don't want to have to say 'if the moon is in the first quarter, header Foo means that, but otherwise it means something different'. If this is valuable, then it deserves its own header field. The particular approach also has the problem of introducing additional error cases and state: "sorry, PUBLISH, you were 5 seconds too early, please try again in 5 seconds". That said, I share the doubts raised that any unconditional and content-unaware filtering is all that useful in practice. _______________________________________________ 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 exim@www1.ietf.org Tue Nov 25 15:28:02 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07925 for ; Tue, 25 Nov 2003 15:28:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjmh-0006Up-P6 for sip-archive@odin.ietf.org; Tue, 25 Nov 2003 15:27:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPKRhUK024961 for sip-archive@odin.ietf.org; Tue, 25 Nov 2003 15:27:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjm3-0006FR-HD; Tue, 25 Nov 2003 15:27:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjls-00069S-BD for sip@optimus.ietf.org; Tue, 25 Nov 2003 15:26:52 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07745; Tue, 25 Nov 2003 15:26:37 -0500 (EST) Message-Id: <200311252026.PAA07745@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 25 Nov 2003 15:26:37 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-uri-parameter-reg-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --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 : The Internet Assigned Number Authority Universal Resource Identifier Parameter Registry for the Session Initiation Protocol Author(s) : G. Camarillo Filename : draft-ietf-sip-uri-parameter-reg-01.txt Pages : 5 Date : 2003-11-25 This document creates an IANA registry for SIP URI and SIPS URI parameters. It also lists the already existing parameters to be used as initial values for that registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-uri-parameter-reg-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-uri-parameter-reg-01.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-uri-parameter-reg-01.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: <2003-11-25152014.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-uri-parameter-reg-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-uri-parameter-reg-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-25152014.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ 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 exim@www1.ietf.org Tue Nov 25 15:44:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08813 for ; Tue, 25 Nov 2003 15:44:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOk2f-0008M5-1H for sip-archive@odin.ietf.org; Tue, 25 Nov 2003 15:44:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPKiCXa032056 for sip-archive@odin.ietf.org; Tue, 25 Nov 2003 15:44:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOk2T-0008Gl-I3; Tue, 25 Nov 2003 15:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOk2L-0008Fl-Cj for sip@optimus.ietf.org; Tue, 25 Nov 2003 15:43:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08777 for ; Tue, 25 Nov 2003 15:43:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOk2J-0005TW-00 for sip@ietf.org; Tue, 25 Nov 2003 15:43:51 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AOk2J-0005Ss-00 for sip@ietf.org; Tue, 25 Nov 2003 15:43:51 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hAPKhCcn021030 for ; Tue, 25 Nov 2003 14:43:20 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Nov 2003 14:43:10 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86661@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: sip@ietf.org Subject: RE: [Sip] PUBLISH message rates Date: Tue, 25 Nov 2003 13:58:57 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Paul Kyzivat [mailto:pkyzivat@cisco.com] wrote: > It might be interesting to make a change permitting use of the > Retry-After header with a 2xx response. Then the compositor > could accept > a publish and at the same time ensure that the next one > doesn't come > too soon. This wouldn't be useful in all cases, but maybe in some. I think you're starting down the same path that Robert has already put some good work into. You probably want to take a look at: http://www.ietf.org/internet-drafts/draft-sparks-sipping-load-00.txt /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 exim@www1.ietf.org Tue Nov 25 16:13:58 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07926 for ; Tue, 25 Nov 2003 15:28:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjmh-0006Uq-SM for sip-archive@odin.ietf.org; Tue, 25 Nov 2003 15:27:43 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPKRhTE024959 for sip-archive@odin.ietf.org; Tue, 25 Nov 2003 15:27:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjm8-0006J4-Mh; Tue, 25 Nov 2003 15:27:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOjle-00067a-Dz for sip@optimus.ietf.org; Tue, 25 Nov 2003 15:26:38 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07715; Tue, 25 Nov 2003 15:26:23 -0500 (EST) Message-Id: <200311252026.PAA07715@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 25 Nov 2003 15:26:23 -0500 Subject: [Sip] I-D ACTION:draft-ietf-sip-parameter-registry-01.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --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 : The Internet Assigned Number Authority Header Field Parameter Registry for the Session Initiation Protocol Author(s) : G. Camarillo Filename : draft-ietf-sip-parameter-registry-01.txt Pages : 6 Date : 2003-11-25 This document creates an IANA registry for SIP header field parameters. It also lists the already existing parameters to be used as initial values for that registry. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-parameter-registry-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-parameter-registry-01.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-parameter-registry-01.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: <2003-11-25151950.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-parameter-registry-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-parameter-registry-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-11-25151950.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ 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 exim@www1.ietf.org Tue Nov 25 16:28:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11601 for ; Tue, 25 Nov 2003 16:28:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOkjL-0002Gk-Fn for sip-archive@odin.ietf.org; Tue, 25 Nov 2003 16:28:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPLSJgL008718 for sip-archive@odin.ietf.org; Tue, 25 Nov 2003 16:28:19 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOkj4-0002Fc-3l; Tue, 25 Nov 2003 16:28:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOkiD-0002Ea-8b for sip@optimus.ietf.org; Tue, 25 Nov 2003 16:27:09 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11558 for ; Tue, 25 Nov 2003 16:26:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOkiB-0006nK-00 for sip@ietf.org; Tue, 25 Nov 2003 16:27:07 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AOkiA-0006mi-00 for sip@ietf.org; Tue, 25 Nov 2003 16:27:07 -0500 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hAPLQXxg017831; Tue, 25 Nov 2003 16:26:33 -0500 (EST) Received: from cisco.com ([161.44.79.239]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AEG36270; Tue, 25 Nov 2003 16:26:33 -0500 (EST) Message-ID: <3FC3C909.6010403@cisco.com> Date: Tue, 25 Nov 2003 16:26:33 -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: Henning Schulzrinne CC: sip@ietf.org Subject: Re: [Sip] PUBLISH message rates References: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD902D592C7@esebe013.ntc.nokia.com> <3FC3889B.6060808@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > >> I think this is an interesting idea. However, it doesn't seem to >> quite fit the Retry-After meaning. After all, the request did succeed >> since it received a 200 OK. > > I think general SIP design philosophy is to avoid overloading of > distinct meanings on the same parameter. We don't want to have to say > 'if the moon is in the first quarter, header Foo means that, but > otherwise it means something different'. If this is valuable, then it > deserves its own header field. I agree that bundling Retry-After with a 2xx response is kind of zany, and there are probably better ways to solve the problem. > The particular approach also has the problem of introducing additional > error cases and state: "sorry, PUBLISH, you were 5 seconds too early, > please try again in 5 seconds". > > That said, I share the doubts raised that any unconditional and > content-unaware filtering is all that useful in practice. At least when the problem is pushed back to the publisher (however that is achieved), it is in the best position to deal with the problem in an intelligent way. Adam Roach wrote: > > I think you're starting down the same path that Robert has already > put some good work into. You probably want to take a look at: > > http://www.ietf.org/internet-drafts/draft-sparks-sipping-load-00.txt Yes, this is clearly a special case of what Robert is talking about, and he has put way more thought into it than I did. One difference - I *think* robert is trying to put pressure on a source to slow down everything from it. But maybe the pressure needs to be more selective, as in: slow down the PUBLISH requests, but its still ok to send an INVITE right away. Of course that also makes an already intractible problem even harder. I have the feeling we are just groping in the dark here, but maybe that is how it has to start. 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 exim@www1.ietf.org Tue Nov 25 17:37:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14816 for ; Tue, 25 Nov 2003 17:37:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOlny-00079w-Pr for sip-archive@odin.ietf.org; Tue, 25 Nov 2003 17:37:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAPMbApo027455 for sip-archive@odin.ietf.org; Tue, 25 Nov 2003 17:37:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOlnq-000760-4N; Tue, 25 Nov 2003 17:37:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOlmx-00073D-CN for sip@optimus.ietf.org; Tue, 25 Nov 2003 17:36:07 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14783 for ; Tue, 25 Nov 2003 17:35:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOlmu-0000ro-00 for sip@ietf.org; Tue, 25 Nov 2003 17:36:04 -0500 Received: from ihemail2.lucent.com ([192.11.222.163] helo=ihemail2.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AOlmu-0000qq-00 for sip@ietf.org; Tue, 25 Nov 2003 17:36:04 -0500 Received: from ihmail.ih.lucent.com (h135-1-218-70.lucent.com [135.1.218.70]) by ihemail2.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hAPMZU004673; Tue, 25 Nov 2003 16:35:30 -0600 (CST) Received: from lucent.com (il0015vkg1.ih.lucent.com [135.185.173.147]) by ihmail.ih.lucent.com (8.11.7+Sun/EMS-1.5 sol2) id hAPMZT712342; Tue, 25 Nov 2003 16:35:29 -0600 (CST) Message-ID: <3FC3D92F.5080206@lucent.com> Date: Tue, 25 Nov 2003 16:35:27 -0600 From: "Vijay K. Gurbani" Organization: Wireless Networks Research and Development User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Cullen Jennings CC: Adam Roach , sip@ietf.org Subject: Re: [Sip] SCTP and TLS References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Cullen Jennings wrote: > sips means every hop needs TLS, transport=tls is about one hop needing > TLS. > This is not an unreasonable scenario - A and D could be clients in an > enterprise network that is protected in some way and B and C could be > enterprise proxies that do TLS protection across the internet. At least this particular configuration is mitigated by loose- routing the enterprise proxies. The problem is, of course, how does A know the URI of B's enterprise proxy in any authoritative manner (outside of the 3GPP extensions)? It could always guess and construct a request of the form: INVITE sip:B@domain-b.com SIP/2.0 Route: ... and send it using TLS to B's enterprise proxy, which then delivers it to B. At least the request transits the network in a secure manner. Alternatively, B can publish a URI of the form: sip:B@domain-b.com?Route=sips:domain-B.com But I am unsure how many current UACs would form the correct request given the above URI. And furthermore, B has to be cognizant enough to know that her UA does not support TLS but her enterprise proxy does so she can leverage this knowledge in publishing such a URI. > There is also the Via problem... [...] > There are backwards compatibility issues with all of these. Yes, although Solution C is probably the least intrusive. Implementations that don't understand "security=TLS" parameter will simply ignore it (and hopefully, re-generate it if they are an intermediary). > Next we need to be able to represent that we want security for a single > hop in a URI ( could be a request URI or route or others) > > Solution 1 > make the transport tag be one of UDP, TCP, SCTP, DCCP and add a security > tag that could be TLS > sip:fluffy@securityforever.org;transport=SCTP;security=TLS > > Solution 2 > define some more transports of udp+tls sctp+tls, dccp, dccp+tls. Note that > tls alone means tls over tcp. > sip:fluffy@securityforever.org;transport=SCTP+TLS > Also a URL with transport=+TLS would mean that any transport could be used > but it must include TLS. > > Given we have two security protocols (nothing and tls) and a handful of > transports (UDP, TCP, SCTP, DCCP) - Solution A and 2 could work without an > explosion of labels. Solution 1 is tricky to make sure no one ever sends > transport=tcp;security=tls to someone expecting transport=tls. For that reason I prefer Solution 2 since it specifies a transport plus a security tag. But, the biggest problem is that these are not backwards compatible to deployed gear. So, besides an academic exercise in curiosity, what are the chances of implementation? It appears to me that the most ubiquitous and least intrusive solution is to use some form of loose source routing to protect the requests in portions of the network that are not completely trustworthy. - 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 exim@www1.ietf.org Tue Nov 25 20:16:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20574 for ; Tue, 25 Nov 2003 20:16:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOoHs-0007F9-Go for sip-archive@odin.ietf.org; Tue, 25 Nov 2003 20:16:12 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQ1GCsJ027787 for sip-archive@odin.ietf.org; Tue, 25 Nov 2003 20:16:12 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOoHj-0007Ct-2G; Tue, 25 Nov 2003 20:16:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOoGl-0007Bc-TQ for sip@optimus.ietf.org; Tue, 25 Nov 2003 20:15:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20509 for ; Tue, 25 Nov 2003 20:14:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOoGj-0004F8-00 for sip@ietf.org; Tue, 25 Nov 2003 20:15:01 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx with esmtp (Exim 4.12) id 1AOoGj-0004El-00 for sip@ietf.org; Tue, 25 Nov 2003 20:15:01 -0500 Received: from cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 25 Nov 2003 17:14:14 -0800 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hAQ1ETw5024960; Tue, 25 Nov 2003 17:14:29 -0800 (PST) Received: from [128.107.171.228] ([128.107.171.228]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKG62432; Tue, 25 Nov 2003 17:14:28 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Tue, 25 Nov 2003 17:14:27 -0800 Subject: Re: [Sip] SCTP and TLS From: Cullen Jennings To: Vijay Gurbani CC: Adam Roach , Message-ID: In-Reply-To: <3FC3D92F.5080206@lucent.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > plus a security tag. But, the biggest problem is that these are > not backwards compatible to deployed gear. So, besides an > academic exercise in curiosity, what are the chances of > implementation? > There is not really any SCTP or TLS over SCTP or UDP or DCCP deployed so I think we could be backwards compatible with existing TLS stuff. I'm not seeing a way to be backwards compatible with everything but the current stuff looks broken so I think the odds of something other than what is currently specified deploying are fairly high. This is not a "I don't like the current thing issues" this is the current thing can't construct a usable via for a stateless proxy using SCTP with TLS. _______________________________________________ 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 exim@www1.ietf.org Wed Nov 26 00:05:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25272 for ; Wed, 26 Nov 2003 00:05:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOrrW-0007wX-9G for sip-archive@odin.ietf.org; Wed, 26 Nov 2003 00:05:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQ55EuY030527 for sip-archive@odin.ietf.org; Wed, 26 Nov 2003 00:05:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOrrL-0007ve-7p; Wed, 26 Nov 2003 00:05:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOrqv-0007v9-Jp for sip@optimus.ietf.org; Wed, 26 Nov 2003 00:04:37 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25267 for ; Wed, 26 Nov 2003 00:04:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOrqt-0006bJ-00 for sip@ietf.org; Wed, 26 Nov 2003 00:04:35 -0500 Received: from [63.110.3.64] (helo=dyn-tx-arch-crash.dfw.dynamicsoft.com) by ietf-mx with esmtp (Exim 4.12) id 1AOrqs-0006b9-00 for sip@ietf.org; Wed, 26 Nov 2003 00:04:34 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by dyn-tx-arch-crash.dfw.dynamicsoft.com (8.11.6/8.11.6) with ESMTP id hAQ53pd23811; Tue, 25 Nov 2003 23:03:51 -0600 Subject: RE: [Sip] SCTP and TLS From: Robert Sparks To: Adam Roach Cc: "'Cullen Jennings'" , Vijay Gurbani , sip@ietf.org In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3E86659@dyn-tx-exch-001.dynamicsoft.com> References: <9BF66EBF6BEFD942915B4D4D45C051F3E86659@dyn-tx-exch-001.dynamicsoft.com> Content-Type: text/plain Message-Id: <1069823028.967.28.camel@RjS.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Tue, 25 Nov 2003 23:03:48 -0600 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit ;transport=tls was utterly deprecated. This was done quickly, and it missed the case that somebody wanted to specify using tls for just the next hop by putting something in the URI. All we have available for that now is DNS SRV which operates at the whole-host level, not the individual resource level. I see this as an unnecessary shortcoming. RjS On Tue, 2003-11-25 at 00:28, Adam Roach wrote: > Cullen Jennings [mailto:fluffy@cisco.com] wrote: > > > transport=tls was deprecated in a SIPS uri (because it is > > redundant there) > > but I don't believe it was deprecated in a SIP uri. > > I think the intention was to deprecate it everywhere, not just > in sips: URIs. To emphasize the final sentence of the passage > I quoted (regarding deprecation of the "transport=tls" > indication): > > "This is a change since RFC 2543." > > Since the "sips:" scheme is not defined in 2543, it seems a > bit of a stretch to call this deprecation a change unless it > applies at least to "sip:" URIs. > > If you find 3261 less than coherent on this topic, there > is a perfectly reasonable explanation, best summarized as: > > "We apologise for the fault in the hop-by-hop security model. > Those responsible have been sacked, and hop-by-hop security > has been completed in an entirely different style at great > expense at the last minute." > > /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 _______________________________________________ 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 exim@www1.ietf.org Wed Nov 26 00:11:26 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25431 for ; Wed, 26 Nov 2003 00:11:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOrxG-00008R-LU for sip-archive@odin.ietf.org; Wed, 26 Nov 2003 00:11:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQ5BAUO000459 for sip-archive@odin.ietf.org; Wed, 26 Nov 2003 00:11:10 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOrx8-0008Ue-IY; Wed, 26 Nov 2003 00:11:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOrwz-0008UF-Ns for sip@optimus.ietf.org; Wed, 26 Nov 2003 00:10:53 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25396 for ; Wed, 26 Nov 2003 00:10:38 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOrwx-0006fH-00 for sip@ietf.org; Wed, 26 Nov 2003 00:10:51 -0500 Received: from mail4.dynamicsoft.com ([63.110.3.100]) by ietf-mx with esmtp (Exim 4.12) id 1AOrww-0006et-00 for sip@ietf.org; Wed, 26 Nov 2003 00:10:50 -0500 Received: from DYN-TX-EXCH-001.dynamicsoft.com (dyn-tx-exch-001 [63.110.3.8]) by mail4.dynamicsoft.com (8.12.8/8.12.8) with ESMTP id hAQ5AAci022714; Tue, 25 Nov 2003 23:10:10 -0600 (CST) Received: by dyn-tx-exch-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Tue, 25 Nov 2003 23:10:10 -0600 Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3E86669@dyn-tx-exch-001.dynamicsoft.com> From: Adam Roach To: "'Cullen Jennings'" , Vijay Gurbani Cc: Adam Roach , sip@ietf.org Subject: RE: [Sip] SCTP and TLS Date: Tue, 25 Nov 2003 23:10:08 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Cullen Jennings [mailto:fluffy@cisco.com] wrote: > There is not really any SCTP or TLS over SCTP or UDP or DCCP > deployed so I think we could be backwards compatible with > existing TLS stuff. I'm not seeing a way to be backwards > compatible with everything but the current stuff looks broken > so I think the odds of something other than what is currently > specified deploying are fairly high. This is not a "I don't > like the current thing issues" this is the current thing can't > construct a usable via for a stateless proxy using SCTP with TLS. Actually, I think we have a choice between backwards-compatibility and elegance. For example, we could choose designations like the following for a sort of elegance: UDP: SIP/2.0/UDP UDP+TLS: SIP/2.0/TLS/UDP TCP: SIP/2.0/TCP TCP+TLS: SIP/2.0/TLS/TCP SCTP: SIP/2.0/SCTP SCTP+TLS: SIP/2.0/TLS/SCTP DCCP: SIP/2.0/DCCP DCCP+TLS: SIP/2.0/TLS/DCCP Alternately, we could retain backwards compatibility (but have people forever wonder about the TCP aberration) by using designations like: UDP: SIP/2.0/UDP UDP+TLS: SIP/2.0/TLS/UDP TCP: SIP/2.0/TCP TCP+TLS: SIP/2.0/TLS SCTP: SIP/2.0/SCTP SCTP+TLS: SIP/2.0/TLS/SCTP DCCP: SIP/2.0/DCCP DCCP+TLS: SIP/2.0/TLS/DCCP Because of practical considerations, I would propose that the second approach is probably the best path forward. /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 exim@www1.ietf.org Wed Nov 26 02:03:44 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02066 for ; Wed, 26 Nov 2003 02:03:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOthv-0005Sn-I7 for sip-archive@odin.ietf.org; Wed, 26 Nov 2003 02:03:27 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQ73RVE020936 for sip-archive@odin.ietf.org; Wed, 26 Nov 2003 02:03:27 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOthX-0005Nc-LI; Wed, 26 Nov 2003 02:03:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOtgb-0005Kf-Uo for sip@optimus.ietf.org; Wed, 26 Nov 2003 02:02:06 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00030 for ; Wed, 26 Nov 2003 02:01:51 -0500 (EST) From: hisham.khartabil@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOtgX-0000GM-00 for sip@ietf.org; Wed, 26 Nov 2003 02:02:01 -0500 Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx with esmtp (Exim 4.12) id 1AOtgX-0000GH-00 for sip@ietf.org; Wed, 26 Nov 2003 02:02:01 -0500 Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAQ721603515 for ; Wed, 26 Nov 2003 09:02:01 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Wed, 26 Nov 2003 09:01:59 +0200 Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 26 Nov 2003 09:01:59 +0200 Received: from esebe019.NOE.Nokia.com ([172.21.138.58]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 26 Nov 2003 09:01:58 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Sip] SCTP and TLS Date: Wed, 26 Nov 2003 09:01:57 +0200 Message-ID: <2038BCC78B1AD641891A0D1AE133DBB701797441@esebe019.ntc.nokia.com> Thread-Topic: [Sip] SCTP and TLS Thread-Index: AcOz28EwsZXxnJXBQ8iqK1bXZdMH+gADwlcQ To: , , Cc: X-OriginalArrivalTime: 26 Nov 2003 07:01:58.0567 (UTC) FILETIME=[2F1DBB70:01C3B3EB] Content-Transfer-Encoding: quoted-printable Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Why isn't it enough to state that if a request was received using TLS, = the response must sent using TLS? It requires proxies and UASs to keep a = state though. Regards, Hisham > -----Original Message----- > From: sip-admin@ietf.org [mailto:sip-admin@ietf.org]On Behalf Of ext > Adam Roach > Sent: 26.November.2003 07:10 > To: 'Cullen Jennings'; Vijay Gurbani > Cc: Adam Roach; sip@ietf.org > Subject: RE: [Sip] SCTP and TLS >=20 >=20 > Cullen Jennings [mailto:fluffy@cisco.com] wrote: >=20 > > There is not really any SCTP or TLS over SCTP or UDP or DCCP=20 > > deployed so I think we could be backwards compatible with > > existing TLS stuff. I'm not seeing a way to be backwards > > compatible with everything but the current stuff looks broken > > so I think the odds of something other than what is currently > > specified deploying are fairly high. This is not a "I don't > > like the current thing issues" this is the current thing can't=20 > > construct a usable via for a stateless proxy using SCTP with TLS. >=20 > Actually, I think we have a choice between backwards-compatibility > and elegance. >=20 > For example, we could choose designations like the following > for a sort of elegance: >=20 > UDP: SIP/2.0/UDP > UDP+TLS: SIP/2.0/TLS/UDP > TCP: SIP/2.0/TCP > TCP+TLS: SIP/2.0/TLS/TCP > SCTP: SIP/2.0/SCTP > SCTP+TLS: SIP/2.0/TLS/SCTP > DCCP: SIP/2.0/DCCP > DCCP+TLS: SIP/2.0/TLS/DCCP >=20 > Alternately, we could retain backwards compatibility (but have > people forever wonder about the TCP aberration) by using > designations like: >=20 > UDP: SIP/2.0/UDP > UDP+TLS: SIP/2.0/TLS/UDP > TCP: SIP/2.0/TCP > TCP+TLS: SIP/2.0/TLS > SCTP: SIP/2.0/SCTP > SCTP+TLS: SIP/2.0/TLS/SCTP > DCCP: SIP/2.0/DCCP > DCCP+TLS: SIP/2.0/TLS/DCCP >=20 > Because of practical considerations, I would propose that the > second approach is probably the best path forward. >=20 > /a >=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 From exim@www1.ietf.org Wed Nov 26 07:32:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04333 for ; Wed, 26 Nov 2003 07:32:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOyqC-0006c9-RJ for sip-archive@odin.ietf.org; Wed, 26 Nov 2003 07:32:21 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAQCWKMw025419 for sip-archive@odin.ietf.org; Wed, 26 Nov 2003 07:32:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOypu-0006al-I2; Wed, 26 Nov 2003 07:32:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AOypO-0006Z3-JD for sip@optimus.ietf.org; Wed, 26 Nov 2003 07:31:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04300 for ; Wed, 26 Nov 2003 07:31:17 -0500 (EST) From: aki.niemi@nokia.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AOypN-0004dm-00 for sip@ietf.org; Wed, 26 Nov 2003 07:31:29 -0500 Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx with esmtp (Exim 4.12) id 1AOypN-0004dj-00 for sip@ietf.org; Wed, 26 Nov 2003 07:31:29 -0500 Received: from esvir05nok.ntc.nokia.com (esvir05nokt.ntc.nokia.com [172.21.143.37]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id hAQCVRM28757 for ; Wed, 26 Nov 2003 14:31:27 +0200 (EET) Received: from esebh004.NOE.Nokia.com (unverified) by esvir05nok.ntc.nokia.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 26 Nov 2003 14:31:14 +0200 Received: from esebe013.NOE.Nokia.com ([172.21.138.52]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6747); Wed, 26 Nov 2003 13:36:33 +0200 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 26 Nov 2003 13:36:31 +0200 Message-ID: <98C7D2E5BCD2374C9AAE0BCD2E9C1DD9027D917F@esebe013.ntc.nokia.com> Thread-Topic: Entity-tags in PUBLISH Thread-Index: AcO0ATmpz8UFRh2XRcqDSej7Vbpn8w== To: X-OriginalArrivalTime: 26 Nov 2003 11:36:33.0496 (UTC) FILETIME=[8AF06580:01C3B411] Content-Transfer-Encoding: quoted-printable Subject: [Sip] Entity-tags in PUBLISH Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Hi, As we discussed in Minneapolis, the PUBLISH draft needs additional text = covering the use of etags, and the relationship to HTTP in this respect. = One related thing that came up was that although the etags in PUBLISH = have been copied from RFC 2616, there are some minor differences, mainly = due to the fact that with PUBLISH, we don't have use for features used = with for example the GET and HEAD methods: - We have dropped the weak etag concept, because PUBLISH etags are = basically=20 always strong. As a side effect, the syntax is also different, = i.e., an etag=20 is a token, instead of quoted-string with an optional "weakness" = tag prefix.=20 This seemed reasonable, since this is the common way to = representing=09 similar things in SIP, and after removing the weak tag, the quotes = were=20 superfluous. - We have dropped multiple etags in If-Match header, because in = PUBLISH, the=20 EPA will always only modify/remove/refresh its own publications. = This=20 corresponds to a conditional PUT in HTTP/1.1, where only a single = entity-tag=20 is present in If-Match. - We have dropped the "*" valued If-Match. An "If-Match: *" = corresponds to a=20 PUBLISH without the If-Match header, so there is no need for this = special=20 value. - In HTTP/1.1, the origin server SHOULD create an etag, whereas in = PUBLISH,=20 the ESC MUST always create an etag. The main functionality of etags is the same in my opinion, even with the = above "focused" use of them. But I would still like some input on = whether the working group feels these differences are considerable = enough that we should *not* inherit the syntax for these headers from = HTTP/1.1, but create similar but distinct header field names, and = response code. 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 exim@www1.ietf.org Wed Nov 26 23:26:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11357 for ; Wed, 26 Nov 2003 23:26:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APDjT-0000bb-LW for sip-archive@odin.ietf.org; Wed, 26 Nov 2003 23:26:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAR4QNO5002267 for sip-archive@odin.ietf.org; Wed, 26 Nov 2003 23:26:23 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APDj7-0000Zc-Km; Wed, 26 Nov 2003 23:26:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APDiR-0000ZH-VQ for sip@optimus.ietf.org; Wed, 26 Nov 2003 23:25:19 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11349 for ; Wed, 26 Nov 2003 23:25:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APDiP-0002Et-00 for sip@ietf.org; Wed, 26 Nov 2003 23:25:17 -0500 Received: from leviathan.cnchost.com ([207.155.252.18]) by ietf-mx with esmtp (Exim 4.12) id 1APDiP-0002Eq-00 for sip@ietf.org; Wed, 26 Nov 2003 23:25:17 -0500 Received: from laptopeng3 (pool-138-88-37-7.res.east.verizon.net [138.88.37.7]) by leviathan.cnchost.com id XAA12164; Wed, 26 Nov 2003 23:25:17 -0500 (EST) [ConcentricHost SMTP Relay 1.16] Message-ID: <035801c3b49f$561f2fb0$0200a8c0@laptopeng3> From: "Medhavi Bhatia" To: Date: Wed, 26 Nov 2003 23:21:37 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0350_01C3B474.0A2B4600" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Sip] draft-ietf-iptel-trunk-group-00.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0350_01C3B474.0A2B4600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Folks, Is this draft being revived ? We had some questions/comments on the syntax specified in it and were wondering if this was being worked on or dropped. Medhavi. ------=_NextPart_000_0350_01C3B474.0A2B4600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Folks,
 
Is this draft being revived ? We had = some=20 questions/comments on the syntax specified in it and were wondering if = this was=20 being worked on or dropped.
 
Medhavi.
------=_NextPart_000_0350_01C3B474.0A2B4600-- _______________________________________________ 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 exim@www1.ietf.org Thu Nov 27 02:42:57 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28868 for ; Thu, 27 Nov 2003 02:42:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APGnN-0002By-Lf for sip-archive@odin.ietf.org; Thu, 27 Nov 2003 02:42:40 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAR7gbSa008415 for sip-archive@odin.ietf.org; Thu, 27 Nov 2003 02:42:37 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APGmv-000297-31; Thu, 27 Nov 2003 02:42:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APGmQ-00024j-Pe for sip@optimus.ietf.org; Thu, 27 Nov 2003 02:41:38 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28709 for ; Thu, 27 Nov 2003 02:41:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APGmM-0004RQ-00 for sip@ietf.org; Thu, 27 Nov 2003 02:41:34 -0500 Received: from david.siemens.com.cn ([194.138.202.3]) by ietf-mx with esmtp (Exim 4.12) id 1APGmL-0004RA-00 for sip@ietf.org; Thu, 27 Nov 2003 02:41:33 -0500 Received: from ns.siemens.com.cn (ns.siemens.com.cn [194.138.237.52]) by david.siemens.com.cn (8.11.7/8.11.7) with ESMTP id hAR7eOU23685 for ; Thu, 27 Nov 2003 15:40:25 +0800 (CST) Received: from pekw096e.cn001.siemens.net (pekw096e.cn001.siemens.net [140.231.51.134]) by ns.siemens.com.cn (8.11.7/8.11.7) with ESMTP id hAR7fh622760 for ; Thu, 27 Nov 2003 15:41:44 +0800 (CST) Received: by pekw096e with Internet Mail Service (5.5.2653.19) id ; Thu, 27 Nov 2003 15:41:29 +0800 Message-ID: <31F31018FE2DC941A70BD30477510B0C19D53A@biscm02> From: "Hu Yijun,BISC R&D SA(BJ)" To: "'sip@ietf.org'" Date: Thu, 27 Nov 2003 15:42:55 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3B4BA.120F29EA" Subject: [Sip] a question about offer/answer model Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , 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_01C3B4BA.120F29EA Content-Type: text/plain hi all, I have a question about the SDP offer/answer model. In the section 6 of rfc3264, it claimed that the answerer can reject an offer stream by setting the port number to zero. My question is: if an SDP offer, included in INVITE, is reject by the answerer, and the corresponding SDP answer is included in 200 OK, then how to deal with this answer in the offerer(UAC)? Should the UAC treat it as a successful SDP negotiation, or send a BYE immediately after sending the ACK? ----------------------------------------------------------------------------- Best regards, Hu Yijun BISC, R&D SA Tel.:+86-10-64346-660 E-mail: yijun.hu@bisc.siemens.com.cn ------_=_NextPart_001_01C3B4BA.120F29EA Content-Type: text/html
hi all,
 
I have a question about the SDP offer/answer model.
 
In the section 6 of rfc3264, it claimed that the answerer can reject an offer stream by setting the port number to zero.
 
My question is: if an SDP offer, included in INVITE, is reject by the answerer, and the corresponding SDP answer is included in 200 OK, then how to deal with this answer in the offerer(UAC)? Should the UAC treat it as a successful SDP negotiation, or send a BYE immediately after sending the ACK?

-----------------------------------------------------------------------------
Best regards,
Hu Yijun
BISC, R&D SA
Tel.:+86-10-64346-660
E-mail: yijun.hu@bisc.siemens.com.cn

 
------_=_NextPart_001_01C3B4BA.120F29EA-- _______________________________________________ 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 exim@www1.ietf.org Thu Nov 27 07:32:36 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05222 for ; Thu, 27 Nov 2003 07:32:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APLJi-0006sw-9V for sip-archive@odin.ietf.org; Thu, 27 Nov 2003 07:32:18 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hARCWIeX026406 for sip-archive@odin.ietf.org; Thu, 27 Nov 2003 07:32:18 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APLJR-0006qh-UW; Thu, 27 Nov 2003 07:32:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APLJ2-0006qF-1N for sip@optimus.ietf.org; Thu, 27 Nov 2003 07:31:36 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05167 for ; Thu, 27 Nov 2003 07:31:23 -0500 (EST) From: sip_new@dacafe.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APLJ1-0007W8-00 for sip@ietf.org; Thu, 27 Nov 2003 07:31:35 -0500 Received: from cafemail1.ibsystems.com ([67.121.116.231]) by ietf-mx with esmtp (Exim 4.12) id 1APLJ0-0007Vk-00 for sip@ietf.org; Thu, 27 Nov 2003 07:31:35 -0500 Received: from cafemail_www by cafemail1.ibsystems.com with local (Exim 4.24) id 1APLJI-0007ZU-99 for sip@ietf.org; Thu, 27 Nov 2003 04:31:52 -0800 Received: from 164.164.94.123 (proxying for 139.85.229.204) (SquirrelMail authenticated user sip_new) by cafemail1.ibsystems.com with HTTP; Thu, 27 Nov 2003 04:31:52 -0800 (PST) Message-ID: <14584.164.164.94.123.1069936312.squirrel@cafemail1.ibsystems.com> Date: Thu, 27 Nov 2003 04:31:52 -0800 (PST) To: sip@ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal Content-Transfer-Encoding: 8bit Subject: [Sip] Question:transaction layer: timer B Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit implementation question.. when shud timer B be stopped after reaching "proceeding" state or "confirmed" state? ----------------------------------------- This email was sent using DACafeMail. Get Your FREE 25 MB eMail Account Now. http://cafemail.mcadcafe.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 exim@www1.ietf.org Thu Nov 27 12:45:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13681 for ; Thu, 27 Nov 2003 12:45:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APQCX-000413-JX for sip-archive@odin.ietf.org; Thu, 27 Nov 2003 12:45:13 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hARHjDcx015433 for sip-archive@odin.ietf.org; Thu, 27 Nov 2003 12:45:13 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APQCM-000408-UW; Thu, 27 Nov 2003 12:45:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APQBg-0003vZ-FE for sip@optimus.ietf.org; Thu, 27 Nov 2003 12:44:20 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13614 for ; Thu, 27 Nov 2003 12:44:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APQBe-00037E-00 for sip@ietf.org; Thu, 27 Nov 2003 12:44:18 -0500 Received: from natsmtp01.rzone.de ([81.169.145.166]) by ietf-mx with esmtp (Exim 4.12) id 1APQBe-00037B-00 for sip@ietf.org; Thu, 27 Nov 2003 12:44:18 -0500 Received: from sip (pD9055984.dip.t-dialin.net [217.5.89.132]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id hARHiG9j025794 for ; Thu, 27 Nov 2003 18:44:16 +0100 (MET) From: "Christian Stredicke" To: Date: Thu, 27 Nov 2003 18:44:22 +0100 Message-ID: <05d001c3b50e$17b4f290$3900a8c0@sip> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_05D1_01C3B516.79795A90" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: [Sip] From and To-header confusion in draft-ietf-sip-replaces-04.txt Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_05D1_01C3B516.79795A90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi! I think there is some from and to-header confusion in the Replaces header. Depending on who initiates the call, the to and from must be exchanged. Maybe it would be better to use the term local and remote-tag instead or to allow mixing from and to. Christian -- Christian Stredicke tel:+49.30.39833.401 (ENUM & PSTN) ------=_NextPart_000_05D1_01C3B516.79795A90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi!

 

I think there is some from and to-header = confusion in the Replaces header.

 

Depending on who initiates the call, the to = and from must be exchanged. Maybe it would be better to use the term local = and remote-tag instead or to allow mixing from and to.

 

Christian

--

Christian Stredicke

tel:+49.30.39833.401 (ENUM & = PSTN)

------=_NextPart_000_05D1_01C3B516.79795A90-- _______________________________________________ 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 exim@www1.ietf.org Fri Nov 28 05:08:01 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21485 for ; Fri, 28 Nov 2003 05:08:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APfXL-0006hv-SE for sip-archive@odin.ietf.org; Fri, 28 Nov 2003 05:07:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hASA7h33025782 for sip-archive@odin.ietf.org; Fri, 28 Nov 2003 05:07:43 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APfWg-0006Xl-T6; Fri, 28 Nov 2003 05:07:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APfVh-0006SU-SV for sip@optimus.ietf.org; Fri, 28 Nov 2003 05:06:01 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21299 for ; Fri, 28 Nov 2003 05:05:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APfVe-0006XX-00 for sip@ietf.org; Fri, 28 Nov 2003 05:05:58 -0500 Received: from smtp.dataconnection.com ([192.91.191.4] helo=coltrane.dataconnection.com) by ietf-mx with esmtp (Exim 4.12) id 1APfVd-0006X7-00 for sip@ietf.org; Fri, 28 Nov 2003 05:05:57 -0500 Received: by coltrane.datcon.co.uk with Internet Mail Service (5.5.2656.59) id ; Fri, 28 Nov 2003 10:05:24 -0000 Message-ID: <53F74F5A7B94D511841C00B0D0AB16F80261FD15@baker.datcon.co.uk> From: "Paul D.Smith" To: "'Christian Stredicke'" Cc: "'sip@ietf.org'" Subject: RE: [Sip] From and To-header confusion in draft-ietf-sip-replaces -04.txt Date: Fri, 28 Nov 2003 10:05:24 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C3B597.23E141C0" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , 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_01C3B597.23E141C0 Content-Type: text/plain Christian, If I understand you correctly, you are pointing out the following. If a target receives an INVITE with Replaces headers, it has to somehow use the Replaces To/From fields to identify a dialog. If this dialog were originally started by the target then there may be a mapping of: To field of original INVITE ==> target's idea of remote tag From field of original INVITE ==> target's idea of local tag. However if the target did not start the dialog, the mapping is reversed. To field of original INVITE ==> target's idea of local tag From field of original INVITE ==> target's idea of remote tag. And your question is... how does the Replaces To/From get mapped to the targets idea of local/remote tags? Unfortunately, this can't be resolved into a simple mapping. A third party REFER modifying an INVITE may not know who started the dialog and so renaming the Replaces fields makes no difference since the referrer still doesn't know which tag to place in which field. The target has to perform a lookup using both mappings - often one will find a dialog and the other will not. There is a possible issue with "loopback" type dialogs where a UA, with multiple personalities (i.e. a gateway) may have two dialogs, one in each direction. In this case, it may be impossible to map to a single dialog, which is where the following sentence from page 5 of the draft is headed... "If the Replaces header field matches more than one dialog, the UA MUST act as if no match is found." Is this a correct understanding of your posting? Regards, Paul DS. Paul D.Smith Network Protocols Group Data Connection Ltd (DCL) Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com Fax: +44 20 8363 1039 Web: http://www.dataconnection.com -----Original Message----- From: Christian Stredicke [mailto:stredicke@snom.de] Sent: 27 November 2003 17:45 To: SIP (E-mail) Subject: [Sip] From and To-header confusion in draft-ietf-sip-replaces-04.txt Hi! I think there is some from and to-header confusion in the Replaces header. Depending on who initiates the call, the to and from must be exchanged. Maybe it would be better to use the term local and remote-tag instead or to allow mixing from and to. Christian -- Christian Stredicke tel:+49.30.39833.401 (ENUM & PSTN) ------_=_NextPart_001_01C3B597.23E141C0 Content-Type: text/html
Christian,
 
If I understand you correctly, you are pointing out the following.
 
If a target receives an INVITE with Replaces headers, it has to somehow use the Replaces To/From fields to identify a dialog.  If this dialog were originally started by the target then there may be a mapping of:
 
To field of original INVITE ==> target's idea of remote tag
From field of original INVITE ==> target's idea of local tag.
 
However if the target did not start the dialog, the mapping is reversed.
 
To field of original INVITE ==> target's idea of local tag
From field of original INVITE ==> target's idea of remote tag.
 
And your question is... how does the Replaces To/From get mapped to the targets idea of local/remote tags?
 
Unfortunately, this can't be resolved into a simple mapping.  A third party REFER modifying an INVITE may not know who started the dialog and so renaming the Replaces fields makes no difference since the referrer still doesn't know which tag to place in which field.  The target has to perform a lookup using both mappings - often one will find a dialog and the other will not.
 
There is a possible issue with "loopback" type dialogs where a UA, with multiple personalities (i.e. a gateway) may have two dialogs, one in each direction.  In this case, it may be impossible to map to a single dialog, which is where the following sentence from page 5 of the draft is headed...
 
  "If the Replaces header field matches more than one dialog, the UA MUST act as if no match is found."
 
Is this a correct understanding of your posting?
 
Regards,
Paul DS.

Paul D.Smith
Network Protocols Group
Data Connection Ltd (DCL)
Tel: +44 20 8366 1177  Email: paul.d.smith@dataconnection.com
Fax: +44 20 8363 1039  Web:   http://www.dataconnection.com
-----Original Message-----
From: Christian Stredicke [mailto:stredicke@snom.de]
Sent: 27 November 2003 17:45
To: SIP (E-mail)
Subject: [Sip] From and To-header confusion in draft-ietf-sip-replaces-04.txt

Hi!

 

I think there is some from and to-header confusion in the Replaces header.

 

Depending on who initiates the call, the to and from must be exchanged. Maybe it would be better to use the term local and remote-tag instead or to allow mixing from and to.

 

Christian

--

Christian Stredicke

tel:+49.30.39833.401 (ENUM & PSTN)

------_=_NextPart_001_01C3B597.23E141C0-- _______________________________________________ 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 exim@www1.ietf.org Fri Nov 28 05:21:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22084 for ; Fri, 28 Nov 2003 05:21:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APfkS-0007gc-8B for sip-archive@odin.ietf.org; Fri, 28 Nov 2003 05:21:16 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hASALGTx029545 for sip-archive@odin.ietf.org; Fri, 28 Nov 2003 05:21:16 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APfkD-0007fX-EI; Fri, 28 Nov 2003 05:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APfjM-0007ej-5L for sip@optimus.ietf.org; Fri, 28 Nov 2003 05:20:08 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22030 for ; Fri, 28 Nov 2003 05:19:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APfjI-0006sl-00 for sip@ietf.org; Fri, 28 Nov 2003 05:20:04 -0500 Received: from natsmtp01.rzone.de ([81.169.145.166]) by ietf-mx with esmtp (Exim 4.12) id 1APfjH-0006si-00 for sip@ietf.org; Fri, 28 Nov 2003 05:20:03 -0500 Received: from sip (pD9055984.dip.t-dialin.net [217.5.89.132]) by post.webmailer.de (8.12.10/8.12.10) with ESMTP id hASAJlvw012613; Fri, 28 Nov 2003 11:19:49 +0100 (MET) From: "Christian Stredicke" To: "'Paul D.Smith'" Cc: Subject: AW: [Sip] From and To-header confusion in draft-ietf-sip-replaces-04.txt Date: Fri, 28 Nov 2003 11:19:46 +0100 Message-ID: <062f01c3b599$2a085a00$3900a8c0@sip> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0630_01C3B5A1.8BCCC200" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 Importance: Normal In-Reply-To: <53F74F5A7B94D511841C00B0D0AB16F80261FD15@baker.datcon.co.uk> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0630_01C3B5A1.8BCCC200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Paul, =20 correct. The problem is that users get angry if the pickup does not work just because of standards confusion.=20 =20 Our current workaround is to relax the requirement a little bit and accept to- and from-tags exchanged. That works fine, however there is some risk that this can lead to some false pickups. However, I don=92t know a scenario where this can be an issue. =20 Christian =20 -----Urspr=FCngliche Nachricht----- Von: Paul D.Smith [mailto:Paul.D.Smith@dataconnection.com]=20 Gesendet: Freitag, 28. November 2003 11:05 An: 'Christian Stredicke' Cc: 'sip@ietf.org' Betreff: RE: [Sip] From and To-header confusion in draft-ietf-sip-replaces-04.txt =20 Christian, =20 If I understand you correctly, you are pointing out the following. =20 If a target receives an INVITE with Replaces headers, it has to somehow use the Replaces To/From fields to identify a dialog. If this dialog were originally started by the target then there may be a mapping of: =20 To field of original INVITE =3D=3D> target's idea of remote tag From field of original INVITE =3D=3D> target's idea of local tag. =20 However if the target did not start the dialog, the mapping is reversed. =20 To field of original INVITE =3D=3D> target's idea of local tag From field of original INVITE =3D=3D> target's idea of remote tag. =20 And your question is... how does the Replaces To/From get mapped to the targets idea of local/remote tags? =20 Unfortunately, this can't be resolved into a simple mapping. A third party REFER modifying an INVITE may not know who started the dialog and so renaming the Replaces fields makes no difference since the referrer still doesn't know which tag to place in which field. The target has to perform a lookup using both mappings - often one will find a dialog and the other will not. =20 There is a possible issue with "loopback" type dialogs where a UA, with multiple personalities (i.e. a gateway) may have two dialogs, one in each direction. In this case, it may be impossible to map to a single dialog, which is where the following sentence from page 5 of the draft is headed... =20 "If the Replaces header field matches more than one dialog, the UA MUST act as if no match is found." =20 Is this a correct understanding of your posting? =20 Regards, Paul DS. Paul D.Smith=20 Network Protocols Group=20 Data Connection Ltd (DCL)=20 Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com=20 Fax: +44 20 8363 1039 Web: http://www.dataconnection.com =20 -----Original Message----- From: Christian Stredicke [mailto:stredicke@snom.de] Sent: 27 November 2003 17:45 To: SIP (E-mail) Subject: [Sip] From and To-header confusion in draft-ietf-sip-replaces-04.txt Hi! =20 I think there is some from and to-header confusion in the Replaces header. =20 Depending on who initiates the call, the to and from must be exchanged. Maybe it would be better to use the term local and remote-tag instead or to allow mixing from and to. =20 Christian -- Christian Stredicke tel:+49.30.39833.401 (ENUM & PSTN) ------=_NextPart_000_0630_01C3B5A1.8BCCC200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Paul,

 

correct. The = problem is that users get angry if the pickup does not work just because of = standards confusion.

 

Our current = workaround is to relax the requirement a little bit and accept to- and from-tags = exchanged. That works fine, however there is some risk that this can lead to some = false pickups. However, I don’t know a scenario where this can be an = issue.

 

Christian

 

-----Urspr=FCngliche Nachricht-----
Von: Paul = D.Smith [mailto:Paul.D.Smith@dataconnection.com]
Gesendet: Freitag, 28. = November 2003 11:05
An: 'Christian = Stredicke'
Cc: 'sip@ietf.org<= font size=3D2 face=3DTahoma>'
Betreff: RE: [Sip] From = and To-header confusion in draft-ietf-sip-replaces-04.txt

 

Christian,

 

If I understand you = correctly, you are pointing out the following.

 

If a target receives an INVITE = with Replaces headers, it has to somehow use the Replaces To/From fields to = identify a dialog.  If this dialog were originally started by the target = then there may be a mapping of:

 

To field of original INVITE = =3D=3D> target's idea of remote tag

From field of original INVITE = =3D=3D> target's idea of local tag.

 

However if the target did not = start the dialog, the mapping is reversed.

 

To field of original INVITE = =3D=3D> target's idea of local tag

From field of original INVITE = =3D=3D> target's idea of remote tag.

 

And your question is... how does = the Replaces To/From get mapped to the targets idea of local/remote = tags?

 

Unfortunately, this can't be resolved into a simple mapping.  A third party REFER modifying an = INVITE may not know who started the dialog and so renaming the Replaces fields = makes no difference since the referrer still doesn't know which tag to place = in which field.  The target has to perform a lookup using both mappings - = often one will find a dialog and the other will not.

 

There is a possible issue with "loopback" type dialogs where a UA, with multiple = personalities (i.e. a gateway) may have two dialogs, one in each direction.  In this = case, it may be impossible to map to a single dialog, which is where the = following sentence from page 5 of the draft is headed...

 

  "If the Replaces = header field matches more than one dialog, the UA MUST act as if no match is found."

 

Is this a correct understanding of = your posting?

 

Regards,

Paul DS.

Paul = D.Smith
Network Protocols Group
Data = Connection Ltd (DCL)
Tel: = +44 20 8366 1177  Email: paul.d.smith@dataconnection.com
Fax: = +44 20 8363 1039  Web:   http://www.dataconnection.com
-----Original Message-----
From: Christian Stredicke [mailto:stredicke@snom.de]
Sent: 27 November 2003 = 17:45
To: SIP (E-mail)
Subject: [Sip] From and = To-header confusion in draft-ietf-sip-replaces-04.txt

Hi!

 

I think there is some from and to-header = confusion in the Replaces header.

 

Depending on who initiates the call, the to = and from must be exchanged. Maybe it would be better to use the term local = and remote-tag instead or to allow mixing from and to.

 

Christian

--

Christian Stredicke

tel:+49.30.39833.401 (ENUM & = PSTN)

------=_NextPart_000_0630_01C3B5A1.8BCCC200-- _______________________________________________ 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 exim@www1.ietf.org Fri Nov 28 21:14:40 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19447 for ; Fri, 28 Nov 2003 21:14:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APuco-0006mN-LP for sip-archive@odin.ietf.org; Fri, 28 Nov 2003 21:14:23 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hAT2EMip026054 for sip-archive@odin.ietf.org; Fri, 28 Nov 2003 21:14:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APucT-0006lQ-Vf; Fri, 28 Nov 2003 21:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1APubX-0006ko-IN for sip@optimus.ietf.org; Fri, 28 Nov 2003 21:13:03 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19435 for ; Fri, 28 Nov 2003 21:12:50 -0500 (EST) From: vhegde@san.rr.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1APubU-000590-00 for sip@ietf.org; Fri, 28 Nov 2003 21:13:00 -0500 Received: from ms-smtp-02-qfe0.socal.rr.com ([66.75.162.134] helo=ms-smtp-02-eri0.socal.rr.com) by ietf-mx with esmtp (Exim 4.12) id 1APubU-00058x-00 for sip@ietf.org; Fri, 28 Nov 2003 21:13:00 -0500 Received: from ganaka (dt014n38.san.rr.com [24.30.129.56]) by ms-smtp-02-eri0.socal.rr.com (8.12.10/8.12.7) with SMTP id hAT2CtiF007963 for ; Fri, 28 Nov 2003 18:12:55 -0800 (PST) Message-ID: <000c01c3b61e$4e1b4530$010110ac@ganaka> To: Date: Fri, 28 Nov 2003 18:12:56 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C3B5DB.3FA10B90" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: [Sip] Session timer question Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C3B5DB.3FA10B90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi: I have a question on session timer message flow. If a UA does not support session timer and if it receives=20 Require: timer Session Expires: 3600=20 in the 200 OK to re-INVITE what is the correct way to process this = response?=20 Should UAC Ack the 200 OK and then send a bye or ignore the Require and = session Expires: headers and continue with rest of the processing? Veda ------=_NextPart_000_0009_01C3B5DB.3FA10B90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi:
I have a question on session = timer message=20 flow.
 
 If a UA does not support session = timer and if=20 it receives
 
Require: timer
Session Expires: 3600
 
in the 200 OK to re-INVITE what is the = correct way=20 to process this response?
 
Should UAC Ack the 200 OK and then send = a bye or=20 ignore the Require and session Expires: headers and continue with rest = of the=20 processing?
 
Veda
 
 
 
------=_NextPart_000_0009_01C3B5DB.3FA10B90-- _______________________________________________ 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 exim@www1.ietf.org Sat Nov 29 07:14:42 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14163 for ; Sat, 29 Nov 2003 07:14:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQ3zV-0006Hf-FT for sip-archive@odin.ietf.org; Sat, 29 Nov 2003 07:14:25 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hATCEPNc024151 for sip-archive@odin.ietf.org; Sat, 29 Nov 2003 07:14:25 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQ3z7-0006Gg-JU; Sat, 29 Nov 2003 07:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQ3yq-0006GF-3H for sip@optimus.ietf.org; Sat, 29 Nov 2003 07:13:44 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14143 for ; Sat, 29 Nov 2003 07:13:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQ3yp-0004J9-00 for sip@ietf.org; Sat, 29 Nov 2003 07:13:43 -0500 Received: from web12701.mail.yahoo.com ([216.136.173.238]) by ietf-mx with smtp (Exim 4.12) id 1AQ3yo-0004J6-00 for sip@ietf.org; Sat, 29 Nov 2003 07:13:43 -0500 Message-ID: <20031129121341.53454.qmail@web12701.mail.yahoo.com> Received: from [128.107.253.40] by web12701.mail.yahoo.com via HTTP; Sat, 29 Nov 2003 04:13:41 PST Date: Sat, 29 Nov 2003 04:13:41 -0800 (PST) From: Gokul Krishnan To: sip@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-829354121-1070108021=:50247" Subject: [Sip] Query on PRACK Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , --0-829354121-1070108021=:50247 Content-Type: text/plain; charset=us-ascii Hi All, Does PRACK trigger another 2XX response ? If yes, does that mean UAC should send an ACK? Can any one please provide a message sequence flow? If a PRACK request is received by the UA core that does not match any unacknowledged reliable provisional response, the UAS MUST respond to the PRACK with a 481 response. If the PRACK does match an unacknowledged reliable provisional response, it MUST be responded to with a 2xx response. (RFC 3262, Page 5) Thanks and Regards Gokul --------------------------------- Do you Yahoo!? Free Pop-Up Blocker - Get it now --0-829354121-1070108021=:50247 Content-Type: text/html; charset=us-ascii
Hi All,
 
Does PRACK trigger another 2XX response ? If yes, does that mean UAC should send an ACK? Can any one please provide a message sequence flow?
 
  If a PRACK request is received by the UA core that does not
  match any unacknowledged reliable provisional response, the
  UAS MUST respond to the PRACK with a 481 response.  If the
  PRACK does match an unacknowledged reliable provisional
  response, it MUST be responded to with a 2xx response. 
  (RFC 3262, Page 5)
Thanks and Regards
Gokul

Do you Yahoo!?
Free Pop-Up Blocker - Get it now --0-829354121-1070108021=:50247-- _______________________________________________ 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 exim@www1.ietf.org Sat Nov 29 12:20:48 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20948 for ; Sat, 29 Nov 2003 12:20:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQ8lk-0001BM-7c for sip-archive@odin.ietf.org; Sat, 29 Nov 2003 12:20:33 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hATHKWEb004541 for sip-archive@odin.ietf.org; Sat, 29 Nov 2003 12:20:32 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQ8lI-0001AE-Nj; Sat, 29 Nov 2003 12:20:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQ8kj-00019C-UJ for sip@optimus.ietf.org; Sat, 29 Nov 2003 12:19:30 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20896 for ; Sat, 29 Nov 2003 12:19:14 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQ8ki-0007e3-00 for sip@ietf.org; Sat, 29 Nov 2003 12:19:28 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AQ8kh-0007du-00 for sip@ietf.org; Sat, 29 Nov 2003 12:19:27 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 29 Nov 2003 09:21:17 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hATHIsAt020755; Sat, 29 Nov 2003 09:18:55 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn3-511.cisco.com [10.21.65.255]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKI10527; Sat, 29 Nov 2003 09:18:53 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sat, 29 Nov 2003 09:18:51 -0800 Subject: Re: AW: [Sip] From and To-header confusion in draft-ietf-sip-replaces-04.txt From: Cullen Jennings To: Christian Stredicke , "'Paul D.Smith'" CC: Message-ID: In-Reply-To: <062f01c3b599$2a085a00$3900a8c0@sip> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3152942332_167840" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > 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. --B_3152942332_167840 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Sounds like we need to fix the draft. On 11/28/03 2:19 AM, "Christian Stredicke" wrote: > Hi Paul, > =20 > correct. The problem is that users get angry if the pickup does not work = just > because of standards confusion. > =20 > Our current workaround is to relax the requirement a little bit and accep= t to- > and from-tags exchanged. That works fine, however there is some risk that= this > can lead to some false pickups. However, I don=B9t know a scenario where th= is > can be an issue. > =20 > Christian > =20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: Paul D.Smith [mailto:Paul.D.Smith@dataconnection.com] > Gesendet: Freitag, 28. November 2003 11:05 > An: 'Christian Stredicke' > Cc: 'sip@ietf.org' > Betreff: RE: [Sip] From and To-header confusion in > draft-ietf-sip-replaces-04.txt > =20 >=20 > Christian, >=20 > =20 >=20 > If I understand you correctly, you are pointing out the following. >=20 > =20 >=20 > If a target receives an INVITE with Replaces headers, it has to somehow u= se > the Replaces To/From fields to identify a dialog. If this dialog were > originally started by the target then there may be a mapping of: >=20 > =20 >=20 > To field of original INVITE =3D=3D> target's idea of remote tag >=20 > From field of original INVITE =3D=3D> target's idea of local tag. >=20 > =20 >=20 > However if the target did not start the dialog, the mapping is reversed. >=20 > =20 >=20 > To field of original INVITE =3D=3D> target's idea of local tag >=20 > From field of original INVITE =3D=3D> target's idea of remote tag. >=20 > =20 >=20 > And your question is... how does the Replaces To/From get mapped to the > targets idea of local/remote tags? >=20 > =20 >=20 > Unfortunately, this can't be resolved into a simple mapping. A third par= ty > REFER modifying an INVITE may not know who started the dialog and so rena= ming > the Replaces fields makes no difference since the referrer still doesn't = know > which tag to place in which field. The target has to perform a lookup us= ing > both mappings - often one will find a dialog and the other will not. >=20 > =20 >=20 > There is a possible issue with "loopback" type dialogs where a UA, with > multiple personalities (i.e. a gateway) may have two dialogs, one in each > direction. In this case, it may be impossible to map to a single dialog, > which is where the following sentence from page 5 of the draft is headed.= .. >=20 > =20 >=20 > "If the Replaces header field matches more than one dialog, the UA MUST= act > as if no match is found." >=20 > =20 >=20 > Is this a correct understanding of your posting? >=20 > =20 >=20 > Regards, >=20 > Paul DS. >=20 > Paul D.Smith=20 > Network Protocols Group > Data Connection Ltd (DCL) > Tel: +44 20 8366 1177 Email: paul.d.smith@dataconnection.com > Fax: +44 20 8363 1039 Web: http://www.dataconnection.com > > -----Original Message----- > From: Christian Stredicke [mailto:stredicke@snom.de] > Sent: 27 November 2003 17:45 > To: SIP (E-mail) > Subject: [Sip] From and To-header confusion in draft-ietf-sip-replaces-04= .txt >>=20 >> Hi! >> =20 >> I think there is some from and to-header confusion in the Replaces heade= r. >> =20 >> Depending on who initiates the call, the to and from must be exchanged. = Maybe >> it would be better to use the term local and remote-tag instead or to al= low >> mixing from and to. >> =20 >> Christian >> -- >> Christian Stredicke >> tel:+49.30.39833.401 (ENUM & PSTN) >=20 --B_3152942332_167840 Content-type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Re: AW: [Sip] From and To-header confusion in draft-ietf-sip-replace= s-04.txt
Sounds like we need to fix the draft.

On 11/28/03 2:19 AM, "Christian Stredicke" <stredicke@snom.de&= gt; wrote:

Hi Paul,
 
correct. The problem is that users get angry if the pickup does not work ju= st because of standards confusion.
 
Our current workaround is to relax the requirement a little bit and accept = to- and from-tags exchanged. That works fine, however there is some risk tha= t this can lead to some false pickups. However, I don’t know a scenari= o where this can be an issue.
 
Christian
 

-----Urspr= üngliche Nachricht-----
Von: Paul D.Smith [mailto:Paul.D.Smith@dataconnection.com]
Gesendet: Freitag, 28. November 2003 11:05
An: 'Christian Stredicke'
Cc: 'sip@ietf.org'
Betreff: RE: [Sip] From and To-header confusion in draft-ietf-sip-re= places-04.txt
Christian,
If I understand you correctly, you are pointing out the following= .
If a target receives an INVITE with Replaces headers, it has to s= omehow use the Replaces To/From fields to identify a dialog.  If this d= ialog were originally started by the target then there may be a mapping of:<= BR>

To field of original INVITE =3D=3D> target's idea of remote tag
From field of original INVI= TE =3D=3D> target's idea of local tag.
However if the target did not start the dialog, the mapping is re= versed.

To field of original INVITE= =3D=3D> target's idea of local tag

From field of original INVI= TE =3D=3D> target's idea of remote tag.
And your question is... how does the Replaces To/From get mapped = to the targets idea of local/remote tags?
Unfortunately, this can't be resolved into a simple mapping. &nbs= p;A third party REFER modifying an INVITE may not know who started the dialo= g and so renaming the Replaces fields makes no difference since the referrer= still doesn't know which tag to place in which field.  The target has = to perform a lookup using both mappings - often one will find a dialog and t= he other will not.
There is a possible issue with "loopback" type dialogs = where a UA, with multiple personalities (i.e. a gateway) may have two dialog= s, one in each direction.  In this case, it may be impossible to map to= a single dialog, which is where the following sentence from page 5 of the d= raft is headed...
 "If the Replaces header field matches more than one d= ialog, the UA MUST act as if no match is found."
Is this a correct understanding of your posting?
Regards,

Paul DS.

Paul D.Smith
Network Protocols Group
Data Connection Ltd (DCL)
Tel: +44 20 8366 1177  Email: paul.d.s= mith@dataconnection.com
Fax: +44 20 8363 1039  Web:   http://www.dataconnection.com <http://www.dataconnection.com/>
-----Original Message-----
From: Christian Stredicke [mailt= o:stredicke@snom.de]
Sent: 27 November 2003 17:45
To: SIP (E-mail)
Subject: [Sip] From and To-header confusion in draft-ietf-sip-replac= es-04.txt

Hi!
I = think there is some from and to-header confusion in the Replaces header.
De= pending on who initiates the call, the to and from must be exchanged. Maybe = it would be better to use the term local and remote-tag instead or to allow = mixing from and to.
Ch= ristian
--
Christian Stredicke
tel:+49.30.39833.401 (ENUM & PSTN)


 --B_3152942332_167840-- _______________________________________________ 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 exim@www1.ietf.org Sat Nov 29 12:26:02 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21077 for ; Sat, 29 Nov 2003 12:26:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQ8qB-0001WU-P2 for sip-archive@odin.ietf.org; Sat, 29 Nov 2003 12:25:47 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hATHP7BW005778 for sip-archive@odin.ietf.org; Sat, 29 Nov 2003 12:25:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQ8q7-0001SD-11; Sat, 29 Nov 2003 12:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQ8pn-0001QP-Kb for sip@optimus.ietf.org; Sat, 29 Nov 2003 12:24:43 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21021; Sat, 29 Nov 2003 12:23:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQ8ot-0007gq-00; Sat, 29 Nov 2003 12:23:47 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AQ8os-0007gL-00; Sat, 29 Nov 2003 12:23:46 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 29 Nov 2003 09:25:26 +0000 Received: from mira-sjc5-e.cisco.com (IDENT:mirapoint@mira-sjc5-e.cisco.com [171.71.163.15]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hATHN4At022024; Sat, 29 Nov 2003 09:23:04 -0800 (PST) Received: from [192.168.1.100] (sjc-vpn3-511.cisco.com [10.21.65.255]) by mira-sjc5-e.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKI10558; Sat, 29 Nov 2003 09:20:58 -0800 (PST) User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sat, 29 Nov 2003 09:20:57 -0800 Subject: Re: [Sip] draft-ietf-iptel-trunk-group-00.txt From: Cullen Jennings To: Medhavi Bhatia , CC: Message-ID: In-Reply-To: <035801c3b49f$561f2fb0$0200a8c0@laptopeng3> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3152942458_164695" Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , > 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. --B_3152942458_164695 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable It is being revised right now =AD it is an IPTEL draft =AD please use that emai= l list. If you reply to this, please take the sip mailing list off the email thread. Thanks, Cullen =20 On 11/26/03 8:21 PM, "Medhavi Bhatia" wrote: > Folks, > =20 > Is this draft being revived ? We had some questions/comments on the synta= x > specified in it and were wondering if this was being worked on or dropped= . > =20 > Medhavi. >=20 --B_3152942458_164695 Content-type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Sip] draft-ietf-iptel-trunk-group-00.txt
It is being revised right now – it is an IPTEL draft – please u= se that email list. If you reply to this, please take the sip mailing list o= ff the email thread. Thanks, Cullen
 


On 11/26/03 8:21 PM, "Medhavi Bhatia" <mbhatia@nextone.com>= wrote:

Folks,
Is this draft being revived ? We had some quest= ions/comments on the syntax specified in it and were wondering if this was b= eing worked on or dropped.
Medhavi.


 --B_3152942458_164695-- _______________________________________________ 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 exim@www1.ietf.org Sat Nov 29 14:27:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24201 for ; Sat, 29 Nov 2003 14:27:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQAkM-0006Fs-Dz for sip-archive@odin.ietf.org; Sat, 29 Nov 2003 14:27:14 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hATJREPh023983 for sip-archive@odin.ietf.org; Sat, 29 Nov 2003 14:27:14 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQAk9-0006E1-JC; Sat, 29 Nov 2003 14:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AQAjw-0006Dl-1B for sip@optimus.ietf.org; Sat, 29 Nov 2003 14:26:48 -0500 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24178 for ; Sat, 29 Nov 2003 14:26:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AQAjt-0001bP-00 for sip@ietf.org; Sat, 29 Nov 2003 14:26:45 -0500 Received: from brandt-online.net ([217.160.90.205] helo=p10088371.pureserver.de) by ietf-mx with esmtp (Exim 4.12) id 1AQAjs-0001bM-00 for sip@ietf.org; Sat, 29 Nov 2003 14:26:45 -0500 Received: from bartschnet.de (p5080AB94.dip0.t-ipconnect.de [80.128.171.148]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by p10088371.pureserver.de (Postfix) with ESMTP id A322C420118 for ; Sat, 29 Nov 2003 20:26:43 +0100 (CET) Message-ID: <3FC8F2B2.8050009@bartschnet.de> Date: Sat, 29 Nov 2003 20:25:38 +0100 From: Rene Bartsch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.3) Gecko/20030312 X-Accept-Language: de-at, de, en-us, en MIME-Version: 1.0 To: sip@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Sip] ENUM-support in SIP-protocol? Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: Session Initiation Protocol List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi, first I'm new to the list, so hello to all! :-) My question is if there is any draft of plan to implement ENUM-lookups into the SIP-protocol? Rene Bartsch _______________________________________________ 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