From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 1 03:32:04 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08722 for ; Tue, 1 Feb 2000 03:32:03 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 3238252E6; Tue, 1 Feb 2000 03:29:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 99E0652E8; Tue, 1 Feb 2000 03:29:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id C29B652E6 for ; Tue, 1 Feb 2000 03:29:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Feb 1 03:28:38 EST 2000 Received: from www14.gmx.net ([194.221.183.54]) by dusty; Tue Feb 1 03:26:28 EST 2000 Received: (qmail 10598 invoked by uid 0); 1 Feb 2000 08:28:37 -0000 Date: Tue, 1 Feb 2000 09:28:37 +0100 (MET) From: Michael Teroerde To: sip@lists.research.bell-labs.com MIME-Version: 1.0 X-Authenticated-Sender: #0003572868@gmx.net X-Authenticated-IP: [195.37.70.1] Message-ID: <10592.949393717@www14.gmx.net> X-Mailer: WWW-Mail 1.5 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hello !! I have searched your Email-list for Questions like mine, but there wasn't a posting which answerd all my questions. I would know something about the REGISTER- Request in the SIP-Language. 1. Could a Server send me an De-Register message if he want (e.g. if he wants to reboot)?? 2. Could a Server change the "Expires"- Header field (and therefore change the Register- Time)?? 3. Did the Server send somthing as "Keep Alive" to the registerd UserAgent??(or did he make a "ping" to the IP or something else to determine that my UA is still active) 4. What happens if my UserAgent hangs up?? 5. Is there a generelly timout when the Server delets the register-entry (e.g. after 48 hours) ?? 6. Did the server MUST send a "200 OK"- Response if the UserAgent send a De-register(REGISTER with Expires=0) ?? Please help me !!! If you know an interesting Paper about generelly Sever behavior, please tell it to me. Thanks for your effort Michael Teroerde (instead of posting it on the List , you can also send it to my NEC-Email-Adress) ---------------------------------------------------------------- Michael Teroerde Student at NEC- Heidelberg michael.teroerde@ccrle.nec.de -- Sent through Global Message Exchange - http://www.gmx.net From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 1 04:33:51 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09068 for ; Tue, 1 Feb 2000 04:33:51 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A0C0152E7; Tue, 1 Feb 2000 04:31:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1734552E9; Tue, 1 Feb 2000 04:31:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 7B35652E7 for ; Tue, 1 Feb 2000 04:31:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 1 04:29:28 EST 2000 Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Tue Feb 1 04:27:17 EST 2000 Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id PAA09929; Tue, 1 Feb 2000 15:27:09 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256878.00345B25 ; Tue, 1 Feb 2000 15:01:52 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Michael Teroerde Cc: sip@lists.research.bell-labs.com Message-ID: <65256878.00345A36.00@sampark.hss.hns.com> Date: Tue, 1 Feb 2000 15:01:49 +0530 Subject: Re: SIP Questions Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk 1. Could a Server send me an De-Register message if he want (e.g. if he wants to reboot)?? Arjun> Actually this issue did come up before and I think it was decided then Arjun> that its not important (however, I would have preferred if there were a well stated Arjun> way, which you could use if you want) Arjun> I have a question- since INFO can carry any information, can I use INFO for this purpose ? 2. Could a Server change the "Expires"- Header field (and therefore change the Register- Time)?? Arjun> Yes, the Registrar can select a higher value of Expires, but not a lower one. (4.2.6, RFC 2543) 3. Did the Server send somthing as "Keep Alive" to the registerd UserAgent??(or did he make a "ping" to the IP or something else to determine that my UA is still active) Arjun> Is there any defined message for this from server-client ? Or is it that inactivity Arjun> can be figured out by other means (eg no RTP packets during call, timeout, etc ?) 4. What happens if my UserAgent hangs up?? Arjun> In what state ? 5. Is there a generelly timout when the Server delets the register-entry (e.g. after 48 hours) ?? Arjun> If nothing is specified in the REGISTER request, 60 mins is the default (4.2.6, RFC 2543) 6. Did the server MUST send a "200 OK"- Response if the UserAgent send a De-register(REGISTER with Expires=0) ?? Arjun> Yes - This OK is to tell the sender that it received the REGISTER message. Arjun> You are probably wondering what happens if the client sends and immediately exits Arjun> without waiting for a response - then registrar transmits 200OK once and stops anyway Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 1 04:57:48 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09201 for ; Tue, 1 Feb 2000 04:57:48 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id B1ACD52E8; Tue, 1 Feb 2000 04:55:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3026B52EA; Tue, 1 Feb 2000 04:55:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 94CC752E8 for ; Tue, 1 Feb 2000 04:55:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 1 04:54:42 EST 2000 Received: from mail.speedventures.com ([212.75.74.99]) by dusty; Tue Feb 1 04:52:32 EST 2000 Received: from FOOBAR ([192.168.24.129]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id DY6AASLA; Tue, 1 Feb 2000 10:52:49 +0100 Message-ID: <000b01bf6c9a$99e75020$8118a8c0@foobar.speedventures.com> From: "Christian Jansson" To: "Michael Teroerde" , Subject: Re: Date: Tue, 1 Feb 2000 10:56:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Read the section about the REGISTER request, or have a look at my answers below. >1. Could a Server send me an De-Register message if he want (e.g. if he >wants to reboot)?? No. >2. Could a Server change the "Expires"- Header field (and therefore > change the Register- Time)?? Yes, if it is done while handeling a register request. "A server SHOULD NOT use a higher lifetime than the one requested, but MAY use a lower one. "As the server SOULD return the current list of registrations in the 200 response, the client can find out what Expire value the server chose. If the question is, "Can the server change the Expires value _after_ the 200 response has been sent?", the answer is no. >3. Did the Server send somthing as "Keep Alive" to the registerd > UserAgent??(or did he make a "ping" to the IP or something else to >determine that my UA is still active) No. >4. What happens if my UserAgent hangs up?? Depends on your implementation of "hang up". If you mean that the UserAgent abruptly dies, the location server will not get any notification of that. >5. Is there a generelly timout when the Server delets the >register-entry (e.g. after 48 hours) ?? If no Expires header or expires Contact parameter is present, one hour is assumed by the server. >6. Did the server MUST send a "200 OK"- Response if the UserAgent send a > De-register(REGISTER with Expires=0) ?? Yes. > >Please help me !!! >If you know an interesting Paper about generelly Sever behavior, please >tell it to me. > > >Thanks for your effort > >Michael Teroerde > -- Christian Jansson (christian@hotsip.com) HotSip AB phone: +46 (0)8 555 10 704 mobile: +46 (0)70 558 1038 From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 1 07:32:01 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12780 for ; Tue, 1 Feb 2000 07:32:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A73D952EA; Tue, 1 Feb 2000 07:29:20 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 211D452EB; Tue, 1 Feb 2000 07:29:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id AF2DA52EA for ; Tue, 1 Feb 2000 07:29:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 1 07:28:03 EST 2000 Received: from alpha.netvision.net.il ([194.90.1.13]) by dusty; Tue Feb 1 07:25:53 EST 2000 Received: from sendout.icomverse.com (Efrat-FR3.ser.netvision.net.il [199.203.174.65]) by alpha.netvision.net.il (8.9.3/8.8.6) with ESMTP id OAA18372 for ; Tue, 1 Feb 2000 14:27:49 +0200 (IST) Received: from ismail1.icomverse.com (ismail1.icomverse.com [190.190.110.2]) by sendout.icomverse.com (8.9.3/8.8.7) with ESMTP id OAA06371 for ; Tue, 1 Feb 2000 14:28:00 +0200 Received: by ismail1.icomverse.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 Feb 2000 14:27:50 +0200 Message-ID: From: "Gazal, Elly" To: sip@lists.research.bell-labs.com Subject: Media payload type Date: Tue, 1 Feb 2000 14:27:49 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-8-i" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Does anyone know where can I find the media payload type list/table (0=mlaw PCM, .....,3=GSM, etc.)? Elly Gazal System Engineer Signaling R&D Group Comverse Network Systems Ltd. Tel: 972-3-6458994 Fax: 972-3-6458915 Email: Elly_Gazal@icomverse.com From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 1 07:37:58 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12969 for ; Tue, 1 Feb 2000 07:37:57 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 916D552EB; Tue, 1 Feb 2000 07:35:27 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 0299C52EC; Tue, 1 Feb 2000 07:35:26 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id D13D952EB for ; Tue, 1 Feb 2000 07:35:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Feb 1 07:33:40 EST 2000 Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by dusty; Tue Feb 1 07:31:29 EST 2000 Received: from purple.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 1 Feb 2000 12:33:02 +0000 Received: from cperkins-d.cs.ucl.ac.uk (localhost [127.0.0.1]) by cperkins-d.cs.ucl.ac.uk (8.9.3/8.8.7) with ESMTP id MAA23378; Tue, 1 Feb 2000 12:34:00 GMT Message-Id: <200002011234.MAA23378@cperkins-d.cs.ucl.ac.uk> To: "Gazal, Elly" Cc: sip@lists.research.bell-labs.com Subject: Re: Media payload type In-Reply-To: Message from "Gazal, Elly" of "Tue, 01 Feb 2000 14:27:49 +0200." Date: Tue, 01 Feb 2000 12:34:00 +0000 From: Colin Perkins Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --> "Gazal, Elly" writes: >Does anyone know where can I find the media payload type list/table (0=mlaw >PCM, .....,3=GSM, etc.)? See RFC 1890. This question is best asked on the AVT working group's list rem-conf@es.net since it's not directly SIP related. Colin From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 1 11:23:52 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23880 for ; Tue, 1 Feb 2000 11:23:52 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 81F0252EC; Tue, 1 Feb 2000 11:21:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 01F8852ED; Tue, 1 Feb 2000 11:21:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id D59C652EC for ; Tue, 1 Feb 2000 11:21:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 1 11:19:40 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Tue Feb 1 11:17:30 EST 2000 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.5]) id QQianp23965; Tue, 1 Feb 2000 16:19:29 GMT Message-ID: <389706D8.EC92EE1D@dynamicsoft.com> Date: Tue, 01 Feb 2000 11:16:24 -0500 From: Igor Slepchin Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: archow@hss.hns.com Cc: Michael Teroerde , sip@lists.research.bell-labs.com Subject: Re: SIP Questions References: <65256878.00345A36.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit archow@hss.hns.com wrote: > 2. Could a Server change the "Expires"- Header field (and therefore > change the Register- Time)?? > > Arjun> Yes, the Registrar can select a higher value of Expires, but not a > lower one. (4.2.6, RFC 2543) It's the other way around (a quote from 4.3.6 below): A server SHOULD NOT use a higher lifetime than the one requested, but MAY use a lower one. --- Igor Slepchin From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 1 14:48:10 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00454 for ; Tue, 1 Feb 2000 14:48:10 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 3576D52ED; Tue, 1 Feb 2000 14:45:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A7DA352EF; Tue, 1 Feb 2000 14:45:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 774F552ED for ; Tue, 1 Feb 2000 14:45:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 1 14:43:30 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Tue Feb 1 14:41:20 EST 2000 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.56]) id QQiaoc05632; Tue, 1 Feb 2000 19:43:26 GMT Message-ID: <389737F6.519FA634@dynamicsoft.com> Date: Tue, 01 Feb 2000 14:45:58 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Teroerde Cc: sip@lists.research.bell-labs.com Subject: Re: References: <10592.949393717@www14.gmx.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit To add a few comments to what has been said already: Michael Teroerde wrote: > > Hello !! > > I have searched your Email-list for Questions like mine, but there > wasn't > a posting which answerd all my questions. > > I would know something about the REGISTER- Request in the SIP-Language. > > 1. Could a Server send me an De-Register message if he want (e.g. if he > wants to reboot)?? The decision was made not to include such a function as it can be accomplished in many other ways. For example, by changing the DNS entries for the server, or by mandating multicast for registrations. The latter makes reboot handling really easy. Adding a de-register message has other problems. To what clients is it sent? What about clients that aren't registered right now but are going to do so after the server reboots? You need to tell them to try a different server also. > 2. Could a Server change the "Expires"- Header field (and therefore > change the Register- Time)?? This has been answered by others. > 3. Did the Server send somthing as "Keep Alive" to the registerd > UserAgent??(or did he make a "ping" to the IP or something else to > determine that my UA is still active) Registrations are kept alive through refresh. The server can reduce the refresh interval by placing it in the 200 response to the registration, as has been mentioned. SIP sessions, right now, have no keepalive. It is done at the moment through the media session itself. However, a specification is in development for a keepalive within SIP itself: http://www.ietf.org/internet-drafts/draft-ietf-sip-session-timer-00.txt Note that the call is always up so long as the end systems believe it is. If a proxy uses the session timer, and the call times out, the call may still be up if the end systems think it is. > 4. What happens if my UserAgent hangs up?? Like others, I don't understand this question. > 5. Is there a generelly timout when the Server delets the > register-entry (e.g. after 48 hours) ?? Been answered by others. > 6. Did the server MUST send a "200 OK"- Response if the UserAgent send a > De-register(REGISTER with Expires=0) ?? All requests generate responses. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 1 17:28:08 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07794 for ; Tue, 1 Feb 2000 17:28:07 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4778F52EF; Tue, 1 Feb 2000 17:25:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id B184352F1; Tue, 1 Feb 2000 17:25:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 6233052EF for ; Tue, 1 Feb 2000 17:25:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 1 17:23:46 EST 2000 Received: from howler.tri.sbc.com ([205.173.58.4]) by dusty; Tue Feb 1 17:21:36 EST 2000 Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.9.3/8.9.3) with ESMTP id QAA25684 for ; Tue, 1 Feb 2000 16:25:00 -0600 (CST) Received: from trimail2.tri.sbc.com (trimail2 [144.60.55.227]) by sbctri.tri.sbc.com (8.9.3/8.9.3) with ESMTP id QAA14810 for ; Tue, 1 Feb 2000 16:23:09 -0600 (CST) Received: by trimail2.tri.sbc.com with Internet Mail Service (5.5.2448.0) id ; Tue, 1 Feb 2000 16:23:08 -0600 Message-ID: <4D45BA2A58A7D3119E050008C7E69E29079068@trimail2.tri.sbc.com> From: "Schroeder, Tim" To: sip@lists.research.bell-labs.com Subject: RE: Content-Length header and Multipart MIME Date: Tue, 1 Feb 2000 16:23:05 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk >> However, if 6.6 states it as a MUST, which implies that a person who sends >> CR orLF only is not SIP compliant. > It's one of the overarching philosophies of IETF protocols: > be strict in what you generate, but lenient in what you accept. > That way, for two implementations of a protocol to be > non-interoperable, they must *both* be broken. Or one of them must be broken in a way other than one of the few specific minor ways in which it's "OK" to be broken, despite the fact that it's not compliant to be broken. > This is one of the reasons occasionally cited why IETF protocols > tend to interoperate more sucessfully than those of other > standards bodies. Can't argue with that, though I have a lot of sympathy for the other side. If I can't trust my counterpart to be able to follow the standard well enough to send the proper CRLF (even though I can cover for it), can I trust it to do anything right? Tim. From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 1 18:03:54 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09001 for ; Tue, 1 Feb 2000 18:03:51 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 6087052E9; Tue, 1 Feb 2000 18:01:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id CDEA652F3; Tue, 1 Feb 2000 18:01:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 81DB452E9 for ; Tue, 1 Feb 2000 18:01:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 1 17:59:49 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Tue Feb 1 17:57:39 EST 2000 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.56]) id QQiaop07176; Tue, 1 Feb 2000 22:59:46 GMT Message-ID: <389765FA.2DD1B416@dynamicsoft.com> Date: Tue, 01 Feb 2000 18:02:18 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michelle.Kitchings@ericsson.com Cc: SIP IETF Mailing List Subject: Re: Comments on "Supported:" header draft References: <4D45BA2A58A7D3119E050008C7E69E29079062@trimail2.tri.sbc.com> <3895A1D7.6EAD5985@exu.ericsson.se> <3895AEE6.1D8F0FE5@hpl.hp.com> <3895B208.8DCBB067@dynamicsoft.com> <3895B87F.1297A5BF@exu.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit There are pros and cons. The one and only pro is saving space in the message. The cons are more architectural in nature. It creates a special case for naming conventions, creates an implicit namespace for this first class set of extensions. Henning pointed out to me another interesting issue - lets say RTSP wants to use some new header, foo, defined for SIP. Would this extension be referred to as foo within RTSP, or org.ietf.sip.foo? -Jonathan R. Michelle Kitchings wrote: > > Jonathan, > > I agree with presence-imply and wasn't attempting to re-open that particular > issue. > > But, the whole discussion made me think of the idea of an implied > "org.ietf.sip" in general. Do you think the idea has merit as a means to > shortening messages that have Require, Proxy-require, Supported, and > Unsupported? Like someone said in another post, we could end up having dozens > of IETF extensions. > > Cheers, > Michelle :^) > > Jonathan Rosenberg wrote: > > > > I think we have clear consensus for having the presence of Supported > > imply support for org.ietf.sip.supported. > > > > Issue closed. > > > > -Jonathan R. > > > > > Michelle Kitchings wrote: > > > > > ... > > > > Here is my first post, so bear with me. :) > > > > > > > > If the motivation for making "Supported:" imply "org.ietf.sip.supported" is > > > > because of the extensive length of the feature name, couldn't the feature > > > > lists be interpreted such that any feature without a reverse domain is assumed > > > > to be "org.ietf.sip"? This would mean that > > > > > > > > supported = org.ietf.sip.supported > > > > 100rel = org.ietf.sip.100rel > > > > info = org.ietf.sip.info > > > > etc. ... > > > > > > > > This mechanism makes any/all IETF extension cheaper in terms of bandwidth. > > > > > > > > The downfall to my idea is that if a provider (eg, Ericsson) defines an > > > > extension called "info" without using a reverse domain, then the servers could > > > > inadvertantly interpet that as the wrong kind of info--which would happen > > > > anyway if some other provider (eg, MCI) was also using info without reverse > > > > domain. Perhaps this default domain interpretation would "blackmail" > > > > providers into making sure that they fully-qualify all features? > > > > > > > > Cheers, > > > > Michelle :^) > > > > > > > > -- > > > > Michelle Kitchings | Ph: +1 972 583 7101 | 1010 E. Arapaho, MS L-04 > > > > Ericsson, Inc. | Fax: +1 972 669 0154 | Richardson, TX 75081 USA -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 1 22:26:11 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14344 for ; Tue, 1 Feb 2000 22:26:10 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 25FF352F0; Tue, 1 Feb 2000 22:23:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9E74E52F2; Tue, 1 Feb 2000 22:23:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 8481152F0 for ; Tue, 1 Feb 2000 22:23:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 1 22:22:35 EST 2000 Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Tue Feb 1 22:20:25 EST 2000 Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id JAA25636 for ; Wed, 2 Feb 2000 09:20:42 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256879.0012CDF9 ; Wed, 2 Feb 2000 08:55:23 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: sip@lists.research.bell-labs.com Message-ID: <65256879.0012CC89.00@sampark.hss.hns.com> Date: Wed, 2 Feb 2000 08:55:19 +0530 Subject: RESEND: Encryption of From Header Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Hi, I had posted this some time earlier - never received my own mail thru the list - maybe it got swallowed somewhere. Regds Arjun ---------------------- Forwarded by Arjun Roychowdhury/HSSBLR on 02/02/2000 08:55 AM --------------------------- Arjun Roychowdhury 01/31/2000 07:05 PM To: sip@lists.research.bell-labs.com cc: Subject: Encryption of From Header Hi, Please refer to section 13.1.1 of RFC 2543 "The From header field SHOULD normally remain in the clear, but MAY be encrypted if required, in which case some proxies MAY return a 401 (Unauthorized) status if they require a From field." The above indicates that its possible for FROM Header to be encrypted if so desired. Now, please refer to Section 6 Table 4 which clearly mentions From (and others) to have an "n" status in the enc colum implying they MUST NOT be encrypted. So which is the correct statememt ? Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 2 05:54:13 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02648 for ; Wed, 2 Feb 2000 05:54:13 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id F3E8552EE; Wed, 2 Feb 2000 05:51:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 67E1552F1; Wed, 2 Feb 2000 05:51:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id B68B252EE for ; Wed, 2 Feb 2000 05:51:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Feb 2 05:50:45 EST 2000 Received: from palrel1.hp.com ([156.153.255.242]) by dusty; Wed Feb 2 05:48:35 EST 2000 Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by palrel1.hp.com (Postfix) with ESMTP id 74B67BCF; Wed, 2 Feb 2000 02:50:42 -0800 (PST) Received: from hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238]) by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id KAA27731; Wed, 2 Feb 2000 10:50:41 GMT Message-ID: <38980C02.19C2F376@hpl.hp.com> Date: Wed, 02 Feb 2000 10:50:42 +0000 From: Anders Kristensen Organization: HP Labs X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Michelle.Kitchings@ericsson.com, SIP IETF Mailing List Subject: Re: Comments on "Supported:" header draft References: <4D45BA2A58A7D3119E050008C7E69E29079062@trimail2.tri.sbc.com> <3895A1D7.6EAD5985@exu.ericsson.se> <3895AEE6.1D8F0FE5@hpl.hp.com> <3895B208.8DCBB067@dynamicsoft.com> <3895B87F.1297A5BF@exu.ericsson.se> <389765FA.2DD1B416@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Right, so there's one pro and one cons. Neither is entirely compelling in itself. I would point out, though, that the large majority of extensions to come into wide use will likely become standardized under the org.ietf.sip namespace. I believe this is true for all extensions currently planned and this IMHO somewhat weakens the cons argument. Jonathan Rosenberg wrote: > > There are pros and cons. The one and only pro is saving space in the > message. > > The cons are more architectural in nature. It creates a special case for > naming conventions, creates an implicit namespace for this first class > set of extensions. Henning pointed out to me another interesting issue - > lets say RTSP wants to use some new header, foo, defined for SIP. Would > this extension be referred to as foo within RTSP, or org.ietf.sip.foo? Presumably, if an extension *would* have fallen under the org.ietf.sip namespace under the proposed scheme it would fall under the "default" namespace. Anders -- Anders Kristensen , http://www-uk.hpl.hp.com/people/ak/ Hewlett-Packard Labs, Bristol, UK From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 2 08:22:13 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07049 for ; Wed, 2 Feb 2000 08:22:13 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id DE27052C4; Wed, 2 Feb 2000 08:19:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 4629852D5; Wed, 2 Feb 2000 08:19:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 4E81852C4 for ; Wed, 2 Feb 2000 08:19:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 2 08:18:25 EST 2000 Received: from jupiter.iwatsu.co.jp ([202.248.35.18]) by dusty; Wed Feb 2 08:16:15 EST 2000 Received: from moon.iwatsu.co.jp (moon [172.20.12.25]) by jupiter.iwatsu.co.jp (8.9.1a/3.7W) with ESMTP id WAA16046 for ; Wed, 2 Feb 2000 22:22:27 +0900 (JST) Received: from nt02.iwatsu.co.jp (localhost [127.0.0.1]) by moon.iwatsu.co.jp (8.9.1a/3.7W) with SMTP id WAA08300 for ; Wed, 2 Feb 2000 22:11:27 +0900 (JST) Received: from spc13080 ([192.168.13.80] (may be forged)) by nt02.iwatsu.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/3.7W) with SMTP id WAA01098 for ; Wed, 02 Feb 2000 22:17:25 +0900 Message-ID: <001501bf6d80$11d6e240$500da8c0@spc13080> From: "Masanori Inui" To: "SIP-MailingList" Subject: Regarding the reliability via UDP Date: Wed, 2 Feb 2000 22:17:56 +0900 Organization: IWATSU Electric CO.,LTD. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi, The spec. of SIP define how to ensure the reliability, if the entity is using UDP. My understanding of reliability is bellow. Please see those diagrams. So, I have questions. -Is my understanding correct? -On (2),(3) and (4),the server goes to initial state(no cache the result) ,once the server send a 1st response.If the server receive the re-transmitted request, the server send a 481 final response.Is the SIP allow this implementation? I worry that the server can not accept a new call depend on cache space(real memory), because, I think that the cache time is too long. (1)200 or 3xx response for INVITE UAC UAS ---INVITE----> <--100-------- <--180-------- <--200-------- + start of the timer for reliability | (T1 * 2^n) <--200-------- + if UAS has not received ACK, BYE or CANCEL then retransmit | | + if UAS has not received ACK, BYE or CANCEL then retransmit | v and, so on until the response has been transmitted 7times (2)no-200 or non-3xx final response for INVITE UAC UAS ---INVITE----> <--100-------- <--180-------- <--xxx-------- + start of the timer for reliability | (T1 * 2^n) <--xxx-------- + if UAS has not received ACK, BYE or CANCEL then retransmit | | + if UAS has not received ACK, BYE or CANCEL then retransmit | v and, so on until the response has been transmitted 7times (3)200 response for BYE,CANCEL,OPTIONS,REGISTER UAC SERVER ---BYE-------> <--100-------- <--200-------- + start of the timer for reliability | (T2 * 10) ---BYE-------> + if SERVER has received BYE(re-transmit), then retransmit <--200-------- | | v and, so on until the response has been elapsed T2*10 (4)no-200 final response for BYE,CANCEL,OPTIONS,REGISTER The same behavior as (3) Best regards, =========================== Masanori Inui IWATSU Electric CO.,LTD Project Team No.2 Solution Engineering Dept. Engineering Division --------------------------- 1-7-41 Kugayama Suginami-ku Tokyo, 168-8501, Japan --------------------------- Tel.+81-3-5370-5211 Fax.+81-3-5370-5193 Email inui@iwatsu.co.jp =========================== From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 2 08:49:44 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08492 for ; Wed, 2 Feb 2000 08:49:43 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 7F6EA52F1; Wed, 2 Feb 2000 08:47:19 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 0325852F2; Wed, 2 Feb 2000 08:47:18 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id A272E52F1 for ; Wed, 2 Feb 2000 08:47:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 2 08:46:06 EST 2000 Received: from Ballad.GSC.GTE.com ([204.162.124.66]) by dusty; Wed Feb 2 08:43:56 EST 2000 Received: from gscex03.gsc.gte.com ("port 3913"@gscex03.mtv.gtegsc.com [156.23.150.121]) by Ballad.GSC.GTE.Com (PMDF V5.2-30 #38013) with ESMTP id <01JLF6AWGBDA00225W@Ballad.GSC.GTE.Com> for sip@lists.research.bell-labs.com; Wed, 2 Feb 2000 05:45:51 PST Received: by gscex03.mtv.gtegsc.com with Internet Mail Service (5.5.2448.0) id ; Wed, 02 Feb 2000 05:45:52 -0800 Content-return: allowed Date: Wed, 02 Feb 2000 05:45:50 -0800 From: "Liberati, Ernest" Subject: Call legs and Cseq To: "'sip@lists.research.bell-labs.com'" Message-id: <8160010C5363D0118D3B00805FC184044F03FD@mtvex03.mtv.gtegsc.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-type: text/plain; charset="iso-8859-1" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Hi, For a SIP call that involves phone with UAC, host with UAS, and Proxy Server components, shown below, I need some help to clear my confusion on call legs and Cseq. 1. Do call legs exist between all adjacent components (e.g., A - B, B - C, ...)? 2. Does a call leg include the requests in both directions (e.g., B - C and C - B)? 3. The most recent definition of a call leg, that I have found, is a combination of local- and remote-addresses (including tags) and the Call-ID. How do the Request URI, To, and From address relate to local- and remote-addresses? 4. Within a call leg, is the Cseq incremented for each transaction in each direction? Thanks in advance, Ernest Liberati General Dynamics Electronic Systems 301 310-0344 ernest.liberati@gd-es.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 2 09:11:52 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09670 for ; Wed, 2 Feb 2000 09:11:52 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 800DA52F2; Wed, 2 Feb 2000 09:09:19 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 06E1E52F3; Wed, 2 Feb 2000 09:09:18 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id E964C52F2 for ; Wed, 2 Feb 2000 09:09:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Feb 2 09:07:54 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Wed Feb 2 09:05:44 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id JAA10097 for ; Wed, 2 Feb 2000 09:07:52 -0500 (EST) Message-ID: <38983A36.27CBA54F@cs.columbia.edu> Date: Wed, 02 Feb 2000 09:07:50 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Subject: From Tag syntax Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit I'm trying to reach closure on a minor syntax issue. Currently, the "tag=" parameter is a hexadecimal string (plus dash). It has been proposed Advantage of the change: - one fewer syntax type to worry about; - currently, the similar-in-spirit Via branch parameter is a token, so this would unify the two; - makes it easy to encode information strings as base64; - higher information density (base64 vs. base16) - it's easy to forget this little hex limitation, so implementations may need to be "forgiving" in any event if one major one gets it wrong; Disadvantage: - it's a change from RFC 2543 and not backwards-compatible. Questions: 1) If you are an implementor: does your implementation in any way depend on tag being hexadecimal? 2) Any other opinions? Thanks. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 2 09:19:49 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09926 for ; Wed, 2 Feb 2000 09:19:49 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id B6FE952F3; Wed, 2 Feb 2000 09:17:20 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 329EB52F4; Wed, 2 Feb 2000 09:17:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id BC13E52F3 for ; Wed, 2 Feb 2000 09:17:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 2 09:15:26 EST 2000 Received: from atlrel2.hp.com ([156.153.255.202]) by dusty; Wed Feb 2 09:13:16 EST 2000 Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by atlrel2.hp.com (Postfix) with ESMTP id 6B68213C2; Wed, 2 Feb 2000 09:15:23 -0500 (EST) Received: from hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238]) by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id OAA08843; Wed, 2 Feb 2000 14:15:21 GMT Message-ID: <38983BFB.AD7018E6@hpl.hp.com> Date: Wed, 02 Feb 2000 14:15:23 +0000 From: Anders Kristensen Organization: HP Labs X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Liberati, Ernest" Cc: "'sip@lists.research.bell-labs.com'" Subject: Re: Call legs and Cseq References: <8160010C5363D0118D3B00805FC184044F03FD@mtvex03.mtv.gtegsc.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Ernest, Your confusion is quite understandable. A SIP call leg denotes the (abstract) notion of an end-to-end connection, regardless of whether any proxies are on the signaling path. This means that (in SIP terminology) there are no A-B and B-C legs but only an A-C leg. Obviously a (forking) proxy needs to know about those other "leg segments" but they are not considered legs as such. This is different from the PSTN switch notion of legs. As for the CSeq number, the UAs involved in a leg choose CSeq numbers in increasing order for different transactions but independent of each other. The fact that they can initiate transactions at overlapping points in time implies that the CSeq number spaces are separate in the two directions, i.e. the transaction {i,A,C,42} is *not* the same transaction as {i,C,A,42} even though the legs {i,A,C} is the same as the leg {i,C,A} where i is the Call-ID and 42 is the CSeq. "Liberati, Ernest" wrote: > > Hi, > > For a SIP call that involves phone with UAC, host with UAS, and Proxy Server > components, shown below, I need some help to clear my confusion on call legs > and Cseq. > > 1. Do call legs exist between all adjacent components (e.g., A - B, B - C, > ...)? > > 2. Does a call leg include the requests in both directions (e.g., B - C and > C - B)? > > 3. The most recent definition of a call leg, that I have found, is a > combination of local- and remote-addresses (including tags) and the Call-ID. > How do the Request URI, To, and From address relate to local- and > remote-addresses? > > 4. Within a call leg, is the Cseq incremented for each transaction in each > direction? > -- Anders Kristensen , http://www-uk.hpl.hp.com/people/ak/ Hewlett-Packard Labs, Bristol, UK From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 2 09:25:55 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10255 for ; Wed, 2 Feb 2000 09:25:55 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id DA78D52F4; Wed, 2 Feb 2000 09:23:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 5E0F452F6; Wed, 2 Feb 2000 09:23:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 3304152F4 for ; Wed, 2 Feb 2000 09:23:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Feb 2 09:21:11 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Wed Feb 2 09:19:01 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id JAA10814 for ; Wed, 2 Feb 2000 09:21:09 -0500 (EST) Message-ID: <38983D53.CC6120C@cs.columbia.edu> Date: Wed, 02 Feb 2000 09:21:07 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Subject: Re: From Tag syntax References: <38983A36.27CBA54F@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote before having his first dose of caffeine: > > Currently, the "tag=" parameter is a hexadecimal string (plus dash). > > It has been proposed > and forgot to add: to change this to "token" instead (which is a superset of the hexadecimal + hyphen syntax currently allowed). -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 2 09:29:58 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10483 for ; Wed, 2 Feb 2000 09:29:58 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 1471952F6; Wed, 2 Feb 2000 09:27:28 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 7115A52F5; Wed, 2 Feb 2000 09:27:27 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id B749552F6 for ; Wed, 2 Feb 2000 09:27:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 2 09:25:24 EST 2000 Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Wed Feb 2 09:23:13 EST 2000 Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id UAA29633; Wed, 2 Feb 2000 20:22:07 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 65256879.004F4B9A ; Wed, 2 Feb 2000 19:56:06 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Henning Schulzrinne Cc: sip@lists.research.bell-labs.com Message-ID: <65256879.004F4A8A.00@sampark.hss.hns.com> Date: Wed, 2 Feb 2000 19:56:03 +0530 Subject: Re: From Tag syntax Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Hi, My 2c : Id prefer token for tag. Advantages: as you mentioned Let the originator of the tag decide how he wants to correlate - I dont see any reason why it _must_ be hex - infact its easy to simply apply functions of say getpid()+time() or something and generate a corresponding tag correlator hgs> 1) If you are an implementor: does your implementation in any way depend hgs> on tag being hexadecimal? No, it does not. Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems Henning Schulzrinne on 02/02/2000 07:37:50 PM To: sip@lists.research.bell-labs.com cc: Subject: From Tag syntax I'm trying to reach closure on a minor syntax issue. Currently, the "tag=" parameter is a hexadecimal string (plus dash). It has been proposed Advantage of the change: - one fewer syntax type to worry about; - currently, the similar-in-spirit Via branch parameter is a token, so this would unify the two; - makes it easy to encode information strings as base64; - higher information density (base64 vs. base16) - it's easy to forget this little hex limitation, so implementations may need to be "forgiving" in any event if one major one gets it wrong; Disadvantage: - it's a change from RFC 2543 and not backwards-compatible. Questions: 1) If you are an implementor: does your implementation in any way depend on tag being hexadecimal? 2) Any other opinions? Thanks. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 2 10:00:02 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11393 for ; Wed, 2 Feb 2000 10:00:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4CEE352D5; Wed, 2 Feb 2000 09:57:18 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C1F1852F7; Wed, 2 Feb 2000 09:57:17 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 1E17552D5 for ; Wed, 2 Feb 2000 09:57:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 2 09:55:53 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Wed Feb 2 09:53:43 EST 2000 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.56]) id QQiarb22594; Wed, 2 Feb 2000 14:55:47 GMT Message-ID: <38984613.95EC7469@dynamicsoft.com> Date: Wed, 02 Feb 2000 09:58:27 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: sip@lists.research.bell-labs.com Subject: Re: From Tag syntax References: <38983A36.27CBA54F@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit I also want to add that we'll be taking a poll on this at the next bakeoff. We don't want to make this change if implementations are adversely affected. So long as none are, I think this change is good (our implementation doesn't depend on hex either). -Jonathan R. Henning Schulzrinne wrote: > > Questions: > > 1) If you are an implementor: does your implementation in any way depend > on tag being hexadecimal? > > 2) Any other opinions? > > Thanks. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 2 10:08:05 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11694 for ; Wed, 2 Feb 2000 10:08:04 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 29B6052F7; Wed, 2 Feb 2000 10:05:30 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 99DCE52F8; Wed, 2 Feb 2000 10:05:29 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id DDE8252F7 for ; Wed, 2 Feb 2000 10:05:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 2 10:04:04 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Wed Feb 2 10:01:54 EST 2000 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.56]) id QQiarc16371; Wed, 2 Feb 2000 15:03:39 GMT Message-ID: <389847EB.4C77F89B@dynamicsoft.com> Date: Wed, 02 Feb 2000 10:06:19 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Anders Kristensen Cc: "Liberati, Ernest" , "'sip@lists.research.bell-labs.com'" Subject: Re: Call legs and Cseq References: <8160010C5363D0118D3B00805FC184044F03FD@mtvex03.mtv.gtegsc.com> <38983BFB.AD7018E6@hpl.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Anders has it right. Some additional clarifications: Anders Kristensen wrote: > > > 2. Does a call leg include the requests in both directions (e.g., B - C and > > C - B)? As Anders has pointed out, call legs really refer to end to end connections. So, B and C are user agents. Given that, the call leg just refers to the relationship between them. Within a call leg, there are numerous transactions in both directions. > > > > 3. The most recent definition of a call leg, that I have found, is a > > combination of local- and remote-addresses (including tags) and the Call-ID. > > How do the Request URI, To, and From address relate to local- and > > remote-addresses? The request URI does not used in call leg identification. The To and From field relate to local and remote in the following way. WHen I send a request on a call leg, the From field contains the local address, and the To field the remote address. When a request is received, the To field is matched to the local address, and the From field to the remote address. > > > > 4. Within a call leg, is the Cseq incremented for each transaction in each > > direction? As Anders has pointed out, the CSeq space in the two directions are independent. Within a single direction (A to B), they do increment for each transaction. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 2 10:28:37 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12427 for ; Wed, 2 Feb 2000 10:28:36 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C0D2752F8; Wed, 2 Feb 2000 10:25:33 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 2184D52FA; Wed, 2 Feb 2000 10:25:33 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 0458252F8 for ; Wed, 2 Feb 2000 10:25:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Feb 2 10:23:32 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Wed Feb 2 10:21:21 EST 2000 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.56]) id QQiard13910; Wed, 2 Feb 2000 15:23:13 GMT Message-ID: <38984C82.FF95B371@dynamicsoft.com> Date: Wed, 02 Feb 2000 10:25:54 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Masanori Inui Cc: SIP-MailingList Subject: Re: Regarding the reliability via UDP References: <001501bf6d80$11d6e240$500da8c0@spc13080> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Masanori Inui wrote: > > Hi, > > The spec. of SIP define how to ensure the reliability, if the entity is > using UDP. > My understanding of reliability is bellow. Please see those diagrams. > So, I have questions. > > -Is my understanding correct? Generally looks right. There is no difference in user agent behavior for the differing final responses to INVITE and non-INVITE requests (you have two diagrams for INVITE, one for 200 or 3xx, and another for everything else, but they are the same). Your diagrams don't show it, but for INVITE the requests are retransmitted with an exponentially increasing interval until a response is received (provisional or otherwise). Also, whilst the spec talks about stopping retransmissions of the INVITE response if a BYE is received, I think the next revision of the spec will not recommend this. The problem is for proxies. Since they don't necessarily have call state, they will end up having two transactions, one of which never completes. This causes stale transaction state to be held in a proxy for longer than needed. As much as possible, I'd like to keep transactions independent of each other. For a similar reason, the new recommended behavior for receiving CANCEL is to keep retransmitting the final response if you've already sent it. Otherwise, if the final response and the CANCEL cross on the wire, but the final response is lost, the server thinks the call is set up, but the client won't know since it will never receive a response to the INVITE. Similarly, if the server hasn't sent a final response to an INVITE, the server should send a 487 response to the INVITE when a CANCEL comes. This ensures that the original INVITE transaction completes like a normal transaction; CANCEL just speeds it up. > -On (2),(3) and (4),the server goes to initial state(no cache the result) > ,once the server send a 1st response.If the server receive the > re-transmitted request, > the server send a 481 final response.Is the SIP allow this implementation? For a user agent server, no. It must cache the response (I think for 60 seconds), or regenerate the same response (possible if the initial response was some kind of error because the request was bad). Otherwise, the reliability doesn't work. For a proxy or redirect server which generates its own response, its the same as UAS. For a stateful proxy that forwards a response it received, it must also cache the response. A stateless proxy need not cache a response. When a request retransmission is received, it forwards it as if it was the initial request (it can't tell the difference between a retransmission and the original request). > > I worry that the server can not accept a new call depend on cache space(real > memory), > because, I think that the cache time is too long. What kind of server? For a UAS, you still need to store call state anyway. You will need to store things like CSeq numbers, routes, credentials, To and From fields, and so on. I can't imagine that for a UAS handling high call volumes (a gateway typically) the memory requirements for the responses are a bottleneck. If you are worried about memory requirements in a proxy, use a stateless proxy. They don't need to cache anything. > > (1)200 or 3xx response for INVITE > > UAC UAS > ---INVITE----> > <--100-------- > <--180-------- > <--200-------- + start of the timer for reliability > | (T1 * 2^n) > <--200-------- + if UAS has not received ACK, BYE or CANCEL then > retransmit > | > | > + if UAS has not received ACK, BYE or CANCEL then > retransmit > | > v and, so on until the response has been transmitted 7times > > (2)no-200 or non-3xx final response for INVITE > > UAC UAS > ---INVITE----> > <--100-------- > <--180-------- > <--xxx-------- + start of the timer for reliability > | (T1 * 2^n) > <--xxx-------- + if UAS has not received ACK, BYE or CANCEL then retransmit > | > | > + if UAS has not received ACK, BYE or CANCEL then retransmit > | > v and, so on until the response has been transmitted 7times > > (3)200 response for BYE,CANCEL,OPTIONS,REGISTER > > UAC SERVER > ---BYE-------> > <--100-------- > <--200-------- + start of the timer for reliability > | (T2 * 10) > ---BYE-------> + if SERVER has received BYE(re-transmit), then retransmit > <--200-------- | > | > v and, so on until the response has been elapsed T2*10 > > (4)no-200 final response for BYE,CANCEL,OPTIONS,REGISTER > > The same behavior as (3) > > Best regards, > > =========================== > Masanori Inui > IWATSU Electric CO.,LTD > Project Team No.2 > Solution Engineering Dept. > Engineering Division > --------------------------- > 1-7-41 Kugayama Suginami-ku > Tokyo, 168-8501, Japan > --------------------------- > Tel.+81-3-5370-5211 > Fax.+81-3-5370-5193 > Email inui@iwatsu.co.jp > =========================== -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 2 11:03:05 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13520 for ; Wed, 2 Feb 2000 11:03:04 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 25D3952F5; Wed, 2 Feb 2000 11:00:31 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 959F452FA; Wed, 2 Feb 2000 11:00:30 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id AE30752F5 for ; Wed, 2 Feb 2000 10:59:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 2 10:58:58 EST 2000 Received: from penguin.wise.edt.ericsson.se ([194.237.142.110]) by dusty; Wed Feb 2 10:56:48 EST 2000 Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id QAA27770; Wed, 2 Feb 2000 16:58:51 +0100 (MET) Received: from upc1390.uab.ericsson.se (upc1390 [134.138.231.135]) by ms.uab.ericsson.se (8.9.3/8.9.3/uab-2.21) with ESMTP id QAA01772; Wed, 2 Feb 2000 16:58:51 +0100 (MET) Date: Wed, 02 Feb 2000 16:58:52 +0100 From: Rabbe Fogelholm Reply-To: Rabbe Fogelholm To: sip@lists.research.bell-labs.com, sip@cslab.ericsson.se, sipfactory@uab.ericsson.se Cc: schulzrinne@cs.columbia.edu Subject: New public SIP server Message-ID: <322959594.949510732@upc1390.uab.ericsson.se> Originator-Info: login-id=eubrafo; server=orange.datacom-lab.uab.ericsson.se X-Mailer: Mulberry (Win32) [1.4.5, s/n U-300918] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit This message is to announce a "new" public SIP server (actually it is a reincarnation of the Ellemtel SIP server that used to be running at sip.pcs.ellemtel.net:5060 in 1999). Apologies if you receive this message in duplicate. Henning, here are data for your SIP server page (http://www.cs.columbia.edu/~hgs/sip/servers.html): Organization: Ericsson (http://www.ericsson.se) SIP URL: sip:Robot@iponax.com SRV records: iponax.com Transport: UDP, TCP Modes: redirect Accept registrations from other domains? yes Remarks: The sip:Robot@iponax.com accepts INVITEs to VoIP sessions. It will play a voice announcement of about 30 s length. Comments etc are welcome. Enjoy, Rabbe.Fogelholm@ericsson.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 2 11:49:54 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14816 for ; Wed, 2 Feb 2000 11:49:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 30F7A52F9; Wed, 2 Feb 2000 11:47:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A35C252FB; Wed, 2 Feb 2000 11:47:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id E259952F9 for ; Wed, 2 Feb 2000 11:47:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 2 11:46:39 EST 2000 Received: from tlv.radvision.com ([192.116.213.132]) by dusty; Wed Feb 2 11:44:28 EST 2000 Received: by firewall.tlv.radvision.com id <115204>; Wed, 2 Feb 2000 17:43:22 +0200 Message-Id: <00Feb2.174322ist.115204@firewall.tlv.radvision.com> From: Itamar Gilad To: "'Anders Kristensen'" Cc: "'sip@lists.research.bell-labs.com'" Subject: RE: Call legs and Cseq MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 2 Feb 2000 17:43:21 +0200 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Just to make sure: reqMsg1 == reqMsg2 (duplicate requests) IFF the To, From, Call-ID and CSeq headers are identical (addresses and tags only in the To and From headers). msg1 and msg2 belong to the same Call-leg if the Call-ID is the same and (msg1.To == msg2.To && msg1.From == msg2.From) || (msg1.To == msg2.From && msg1.From == msg2.To) ( == means the addresses and tags are the same) Is that right? BTW, you cannot identify duplicate responses using the first rule. Itamar > -----Original Message----- > From: Anders Kristensen [mailto:ak@hplb.hpl.hp.com] > Sent: Wednesday, February 02, 2000 3:17 PM > To: Liberati, Ernest > Cc: 'sip@lists.research.bell-labs.com' > Subject: Re: Call legs and Cseq > > > Ernest, > > Your confusion is quite understandable. > > A SIP call leg denotes the (abstract) notion of an end-to-end > connection, regardless of whether any proxies are on the > signaling path. > This means that (in SIP terminology) there are no A-B and B-C legs but > only an A-C leg. Obviously a (forking) proxy needs to know about those > other "leg segments" but they are not considered legs as such. This is > different from the PSTN switch notion of legs. > > As for the CSeq number, the UAs involved in a leg choose CSeq > numbers in > increasing order for different transactions but independent of each > other. The fact that they can initiate transactions at overlapping > points in time implies that the CSeq number spaces are separate in the > two directions, i.e. the transaction {i,A,C,42} is *not* the same > transaction as {i,C,A,42} even though the legs {i,A,C} is the same as > the leg {i,C,A} where i is the Call-ID and 42 is the CSeq. > > "Liberati, Ernest" wrote: > > > > Hi, > > > > For a SIP call that involves phone with UAC, host with UAS, > and Proxy Server > > components, shown below, I need some help to clear my > confusion on call legs > > and Cseq. > > > > 1. Do call legs exist between all adjacent components > (e.g., A - B, B - C, > > ...)? > > > > 2. Does a call leg include the requests in both directions > (e.g., B - C and > > C - B)? > > > > 3. The most recent definition of a call leg, that I have found, is a > > combination of local- and remote-addresses (including tags) > and the Call-ID. > > How do the Request URI, To, and From address relate to local- and > > remote-addresses? > > > > 4. Within a call leg, is the Cseq incremented for each > transaction in each > > direction? > > > > -- > Anders Kristensen , > http://www-uk.hpl.hp.com/people/ak/ > Hewlett-Packard Labs, Bristol, UK > From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 2 12:07:29 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15425 for ; Wed, 2 Feb 2000 12:07:28 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 8BD7D52FF; Wed, 2 Feb 2000 12:04:07 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A2D0A52FD; Wed, 2 Feb 2000 12:04:06 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C61F652FC for ; Wed, 2 Feb 2000 12:03:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 2 12:02:31 EST 2000 Received: from gwu.ericy.com ([208.196.3.162]) by dusty; Wed Feb 2 12:00:20 EST 2000 Received: from mr3.exu.ericsson.se (mr3u.ericy.com [208.238.116.100]) by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id LAA19443; Wed, 2 Feb 2000 11:02:24 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id LAA10499; Wed, 2 Feb 2000 11:02:23 -0600 (CST) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA25568; Wed, 2 Feb 2000 11:02:22 -0600 (CST) Received: (from exuadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id LAA02741; Wed, 2 Feb 2000 11:02:20 -0600 (CST) Message-Id: <200002021702.LAA02741@b04a24.exu.ericsson.se> Subject: Re: From Tag syntax To: schulzrinne@cs.columbia.edu (Henning Schulzrinne) Date: Wed, 2 Feb 2000 11:02:20 -0600 (CST) Cc: sip@lists.research.bell-labs.com In-Reply-To: <38983A36.27CBA54F@cs.columbia.edu> from "Henning Schulzrinne" at Feb 02, 2000 09:07:50 AM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit >1) If you are an implementor: does your implementation in any way depend >on tag being hexadecimal? Ours does not. While helping another team to debug what was going on at the most recent bakeoff, we discovered that at least one implementation sends back a 500 class message when they receive a tag which contains non-hex. However, it is also worth noting that this problem surfaced with *only* one implementation -- so, we can probably assume that all of the implementations at the bakeoff except for one accepted non-hex tags. I'm all for allowing the tags to be tokens. -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 2 12:10:45 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15536 for ; Wed, 2 Feb 2000 12:10:44 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4367052FB; Wed, 2 Feb 2000 12:04:08 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 2DD7E52FC; Wed, 2 Feb 2000 12:04:07 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 7554E52FB for ; Wed, 2 Feb 2000 12:03:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 2 12:02:10 EST 2000 Received: from atlrel2.hp.com ([156.153.255.202]) by dusty; Wed Feb 2 11:59:59 EST 2000 Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by atlrel2.hp.com (Postfix) with ESMTP id 292852B05; Wed, 2 Feb 2000 12:02:04 -0500 (EST) Received: from hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238]) by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id RAA20523; Wed, 2 Feb 2000 17:02:02 GMT Message-ID: <3898630B.85AF6F03@hpl.hp.com> Date: Wed, 02 Feb 2000 17:02:03 +0000 From: Anders Kristensen Organization: HP Labs X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Itamar Gilad Cc: "'Anders Kristensen'" , "'sip@lists.research.bell-labs.com'" Subject: Re: Call legs and Cseq References: <00Feb2.174322ist.115204@firewall.tlv.radvision.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Itamar Gilad wrote: > > Just to make sure: > > reqMsg1 == reqMsg2 (duplicate requests) IFF the To, From, Call-ID and CSeq > headers are identical (addresses and tags only in the To and From headers). Yes. Obviously, reqMsg1 and reqMsg2 may in fact differ in other headers (although this should never happen), but for the purpose of identifying and filtering out retransmissions they're the same. > > msg1 and msg2 belong to the same Call-leg if > the Call-ID is the same and > (msg1.To == msg2.To && msg1.From == msg2.From) || > (msg1.To == msg2.From && msg1.From == msg2.To) > > ( == means the addresses and tags are the same) > > Is that right? Yes. > > BTW, you cannot identify duplicate responses using the first rule. No, not quite. If the request was sent without a To tag the UAC needs to take into account the possibility that a UAS has added this to the response, and must also be prepared to handle multiple responses with different To tags (these belonging to different legs). -- Anders Kristensen , http://www-uk.hpl.hp.com/people/ak/ Hewlett-Packard Labs, Bristol, UK From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 2 12:25:52 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15906 for ; Wed, 2 Feb 2000 12:25:51 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 0005952FC; Wed, 2 Feb 2000 12:23:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 7506752FD; Wed, 2 Feb 2000 12:23:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 9054352FC for ; Wed, 2 Feb 2000 12:23:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 2 12:22:51 EST 2000 Received: from tlv.radvision.com ([192.116.213.132]) by dusty; Wed Feb 2 12:20:41 EST 2000 Received: by firewall.tlv.radvision.com id <115207>; Wed, 2 Feb 2000 18:19:32 +0200 Message-Id: <00Feb2.181932ist.115207@firewall.tlv.radvision.com> From: Itamar Gilad To: "'Anders Kristensen'" , Itamar Gilad Cc: "'sip@lists.research.bell-labs.com'" Subject: RE: Call legs and Cseq MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 2 Feb 2000 18:19:30 +0200 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk > -----Original Message----- > From: Anders Kristensen [mailto:ak@hplb.hpl.hp.com] > Sent: Wednesday, February 02, 2000 5:59 PM > To: Itamar Gilad > Cc: 'Anders Kristensen'; 'sip@lists.research.bell-labs.com' > Subject: Re: Call legs and Cseq > > > > Itamar Gilad wrote: > > > > Just to make sure: > > > > reqMsg1 == reqMsg2 (duplicate requests) IFF the To, From, > Call-ID and CSeq > > headers are identical (addresses and tags only in the To > and From headers). > > Yes. Obviously, reqMsg1 and reqMsg2 may in fact differ in > other headers > (although this should never happen), but for the purpose of > identifying > and filtering out retransmissions they're the same. > > > > > msg1 and msg2 belong to the same Call-leg if > > the Call-ID is the same and > > (msg1.To == msg2.To && msg1.From == msg2.From) || > > (msg1.To == msg2.From && msg1.From == msg2.To) > > > > ( == means the addresses and tags are the same) > > > > Is that right? > > Yes. > > > > > BTW, you cannot identify duplicate responses using the first rule. > > No, not quite. If the request was sent without a To tag the > UAC needs to > take into account the possibility that a UAS has added this to the > response, and must also be prepared to handle multiple responses with > different To tags (these belonging to different legs). > Right, but what I meant is that even if two responses have the same To, From, Call-ID and CSeq values (including tags where applicable) it still doesn't mean these are identical messages. The Status line may be different (and usually is). Cheers Itamar From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 2 12:32:17 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16139 for ; Wed, 2 Feb 2000 12:32:17 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 60D2352FD; Wed, 2 Feb 2000 12:29:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id BA8BC52FE; Wed, 2 Feb 2000 12:29:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 89C5B52FD for ; Wed, 2 Feb 2000 12:29:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 2 12:28:14 EST 2000 Received: from atlrel2.hp.com ([156.153.255.202]) by dusty; Wed Feb 2 12:26:04 EST 2000 Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by atlrel2.hp.com (Postfix) with ESMTP id A04862DE6; Wed, 2 Feb 2000 12:28:11 -0500 (EST) Received: from hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238]) by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id RAA22141; Wed, 2 Feb 2000 17:28:10 GMT Message-ID: <3898692B.633DD762@hpl.hp.com> Date: Wed, 02 Feb 2000 17:28:11 +0000 From: Anders Kristensen Organization: HP Labs X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Itamar Gilad Cc: "'Anders Kristensen'" , "'sip@lists.research.bell-labs.com'" Subject: Re: Call legs and Cseq References: <00Feb2.181932ist.115207@firewall.tlv.radvision.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Itamar Gilad wrote: > > > > > > > BTW, you cannot identify duplicate responses using the first rule. > > > > No, not quite. If the request was sent without a To tag the > > UAC needs to > > take into account the possibility that a UAS has added this to the > > response, and must also be prepared to handle multiple responses with > > different To tags (these belonging to different legs). > > > > Right, but what I meant is that even if two responses have the same To, > From, Call-ID and CSeq values (including tags where applicable) it still > doesn't mean these are identical messages. The Status line may be > different (and usually is). Right, of course. You don't want to filter out those final responses ;-) -- Anders Kristensen , http://www-uk.hpl.hp.com/people/ak/ Hewlett-Packard Labs, Bristol, UK From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 2 12:47:57 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16579 for ; Wed, 2 Feb 2000 12:47:56 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C2A1352FA; Wed, 2 Feb 2000 12:45:26 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 446DF5300; Wed, 2 Feb 2000 12:45:26 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 5C39052FA for ; Wed, 2 Feb 2000 12:45:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Feb 2 12:44:30 EST 2000 Received: from ix.netcorps.com ([207.1.125.106]) by dusty; Wed Feb 2 12:42:20 EST 2000 Received: from indigo-software.com (pool02b-194-7-149-210.uunet.be [194.7.149.210]) by ix.netcorps.com (8.9.0/8.9.0) with ESMTP id JAA26581; Wed, 2 Feb 2000 09:32:03 -0800 (PST) Message-ID: <38986BEE.2E7004EA@indigo-software.com> Date: Wed, 02 Feb 2000 18:39:58 +0100 From: Emmanuel Bertrand Organization: Indigo X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: sip@lists.research.bell-labs.com Subject: Re: From Tag syntax References: <38983A36.27CBA54F@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: [snip] > > Questions: > > 1) If you are an implementor: does your implementation in any way depend > on tag being hexadecimal? > Not at all in our case. So, a token is perfect for us too. Manu. > > 2) Any other opinions? > > Thanks. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs -- Emmanuel Bertrand mailto:eb@indigo-software.com http://www.indigo-software.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 2 15:16:05 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20193 for ; Wed, 2 Feb 2000 15:16:05 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 6FEC85300; Wed, 2 Feb 2000 15:13:25 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E4F6E5301; Wed, 2 Feb 2000 15:13:24 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 926AC5300 for ; Wed, 2 Feb 2000 15:13:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 2 15:12:13 EST 2000 Received: from repulse.cnchost.com ([207.155.248.4]) by dusty; Wed Feb 2 15:10:02 EST 2000 Received: from vovida.com (w178.z216112071.sjc-ca.dsl.cnc.net [216.112.71.178]) by repulse.cnchost.com id PAA22294; Wed, 2 Feb 2000 15:12:01 -0500 (EST) [ConcentricHost SMTP Relay 1.8] Message-ID: <38988F93.75A3FBB7@vovida.com> Date: Wed, 02 Feb 2000 12:12:03 -0800 From: Sunitha Kumar Organization: Vovida Networks X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: sip@lists.research.bell-labs.com Subject: Re: From Tag syntax References: <38983A36.27CBA54F@cs.columbia.edu> Content-Type: multipart/alternative; boundary="------------03AF9C00D67D15270E01F98C" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --------------03AF9C00D67D15270E01F98C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Our implementation does not have the hex limitation, for the Tag field. regards sunitha Henning Schulzrinne wrote: > I'm trying to reach closure on a minor syntax issue. > > Currently, the "tag=" parameter is a hexadecimal string (plus dash). > > It has been proposed > > Advantage of the change: > - one fewer syntax type to worry about; > - currently, the similar-in-spirit Via branch parameter is a token, so > this would unify the two; > - makes it easy to encode information strings as base64; > - higher information density (base64 vs. base16) > - it's easy to forget this little hex limitation, so implementations may > need to be "forgiving" in any event if one major one gets it wrong; > > Disadvantage: > - it's a change from RFC 2543 and not backwards-compatible. > > Questions: > > 1) If you are an implementor: does your implementation in any way depend > on tag being hexadecimal? > > 2) Any other opinions? > > Thanks. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs -- Sunitha Kumar Software Engineer Vovida Networks (408) 957 - 6374 --------------03AF9C00D67D15270E01F98C Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Our implementation does not have  the hex limitation, for the Tag field.

regards
sunitha
 

Henning Schulzrinne wrote:

I'm trying to reach closure on a minor syntax issue.

Currently, the "tag=" parameter is a hexadecimal string (plus dash).

It has been proposed

Advantage of the change:
- one fewer syntax type to worry about;
- currently, the similar-in-spirit Via branch parameter is a token, so
this would unify the two;
- makes it easy to encode information strings as base64;
- higher information density (base64 vs. base16)
- it's easy to forget this little hex limitation, so implementations may
need to be "forgiving" in any event if one major one gets it wrong;

Disadvantage:
- it's a change from RFC 2543 and not backwards-compatible.

Questions:

1) If you are an implementor: does your implementation in any way depend
on tag being hexadecimal?

2) Any other opinions?

Thanks.
--
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

-- 
Sunitha Kumar
Software Engineer
Vovida Networks
(408) 957 - 6374
  --------------03AF9C00D67D15270E01F98C-- From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 2 16:25:56 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21796 for ; Wed, 2 Feb 2000 16:25:55 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C6D3352FE; Wed, 2 Feb 2000 16:23:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 42E575302; Wed, 2 Feb 2000 16:23:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 711EC52FE for ; Wed, 2 Feb 2000 16:23:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 2 16:21:52 EST 2000 Received: from ns.fmmo.ca ([207.253.160.156]) by dusty; Wed Feb 2 16:19:42 EST 2000 Received: from localhost (fm-listproc@localhost) by ns.fmmo.ca (8.9.3/8.9.3) with ESMTP id QAA06792; Wed, 2 Feb 2000 16:27:41 -0500 Date: Wed, 2 Feb 2000 16:27:40 -0500 (EST) From: Francois Menard List Account To: Rabbe Fogelholm Cc: sip@lists.research.bell-labs.com, sip@cslab.ericsson.se, sipfactory@uab.ericsson.se, schulzrinne@cs.columbia.edu Subject: Re: New public SIP server In-Reply-To: <322959594.949510732@upc1390.uab.ericsson.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Does IPonAX means that Ericsson is playing with putting TCP/IP in an AXE ? -=Francois=- On Wed, 2 Feb 2000, Rabbe Fogelholm wrote: > This message is to announce a "new" public SIP server (actually it is a > reincarnation of the Ellemtel SIP server that used to be running at > sip.pcs.ellemtel.net:5060 in 1999). Apologies if you receive this > message in duplicate. > > Henning, here are data for your SIP server page > (http://www.cs.columbia.edu/~hgs/sip/servers.html): > > Organization: > Ericsson (http://www.ericsson.se) > > SIP URL: > sip:Robot@iponax.com > > SRV records: > iponax.com > > Transport: > UDP, TCP > > Modes: > redirect > > Accept registrations from other domains? > yes > > Remarks: > The sip:Robot@iponax.com accepts INVITEs to VoIP sessions. > It will play a voice announcement of about 30 s length. > > Comments etc are welcome. Enjoy, > > Rabbe.Fogelholm@ericsson.com > From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 2 22:53:57 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27829 for ; Wed, 2 Feb 2000 22:53:57 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 8601C52E4; Wed, 2 Feb 2000 22:51:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 049D552E6; Wed, 2 Feb 2000 22:51:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 1D5FF52E4 for ; Wed, 2 Feb 2000 22:51:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Feb 2 22:50:07 EST 2000 Received: from jupiter.iwatsu.co.jp ([202.248.35.18]) by dusty; Wed Feb 2 22:47:57 EST 2000 Received: from moon.iwatsu.co.jp (moon [172.20.12.25]) by jupiter.iwatsu.co.jp (8.9.1a/3.7W) with ESMTP id MAA23055; Thu, 3 Feb 2000 12:54:06 +0900 (JST) Received: from nt02.iwatsu.co.jp (localhost [127.0.0.1]) by moon.iwatsu.co.jp (8.9.1a/3.7W) with SMTP id MAA04830; Thu, 3 Feb 2000 12:43:05 +0900 (JST) Received: from spc13080 ([192.168.13.80] (may be forged)) by nt02.iwatsu.co.jp (2.5 Build 2640 (Berkeley 8.8.6)/3.7W) with SMTP id MAA01506; Thu, 03 Feb 2000 12:49:02 +0900 Message-ID: <003601bf6df9$d7193160$500da8c0@spc13080> From: "Masanori Inui" To: "Jonathan Rosenberg" Cc: "SIP-MailingList" References: <001501bf6d80$11d6e240$500da8c0@spc13080> <38984C82.FF95B371@dynamicsoft.com> Subject: Re: Regarding the reliability via UDP Date: Thu, 3 Feb 2000 12:48:11 +0900 Organization: IWATSU Electric CO.,LTD. MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Jonathan, Thank you, for your reply, I almost understood your explanation. I will implement which the server remember the result(what kind of response) , and retransmit it when the server needs to send a response. Further more, I would like to know how the server treat a request for new call when the server cache space is empty. My idea is: (1)The server send a 500 response(Server Internal Error) with Retry-After. In this case the server is not cache. (2)The server silently drop a request for new call. In this case, the client will retransmit a request. What do you think about these? If you have any idea, please tell me them. Thanks, =========================== Masanori Inui IWATSU Electric CO.,LTD Project Team No.2 Solution Engineering Dept. Engineering Division --------------------------- 1-7-41 Kugayama Suginami-ku Tokyo, 168-8501, Japan --------------------------- Tel.+81-3-5370-5211 Fax.+81-3-5370-5193 Email inui@iwatsu.co.jp WEB http://www.iwatsu.co.jp =========================== From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 3 00:56:07 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29226 for ; Thu, 3 Feb 2000 00:56:06 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 8D31D52E5; Thu, 3 Feb 2000 00:53:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 0404152EA; Thu, 3 Feb 2000 00:53:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 7531352E5 for ; Thu, 3 Feb 2000 00:53:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 3 00:52:34 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Thu Feb 3 00:50:24 EST 2000 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: 1Cust233.tnt1.freehold.nj.da.uu.net [63.17.113.233]) id QQiatj28181; Thu, 3 Feb 2000 05:52:24 GMT Message-ID: <3899183A.DD1F0000@dynamicsoft.com> Date: Thu, 03 Feb 2000 00:55:06 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Masanori Inui Cc: SIP-MailingList Subject: Re: Regarding the reliability via UDP References: <001501bf6d80$11d6e240$500da8c0@spc13080> <38984C82.FF95B371@dynamicsoft.com> <003601bf6df9$d7193160$500da8c0@spc13080> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Masanori Inui wrote: > > Further more, I would like to know how the server treat a request for new > call > when the server cache space is empty. > > My idea is: > (1)The server send a 500 response(Server Internal Error) with Retry-After. > In this case the server is not cache. > (2)The server silently drop a request for new call. > In this case, the client will retransmit a request. The decision is yours. Its an implementation choice. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 3 01:17:57 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00248 for ; Thu, 3 Feb 2000 01:17:57 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 9995C52EB; Thu, 3 Feb 2000 01:15:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id F255E52EA; Thu, 3 Feb 2000 01:15:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 800CB52EB for ; Thu, 3 Feb 2000 01:15:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 3 01:13:34 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Thu Feb 3 01:11:24 EST 2000 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: 1Cust233.tnt1.freehold.nj.da.uu.net [63.17.113.233]) id QQiatk21841; Thu, 3 Feb 2000 06:13:08 GMT Message-ID: <38991D17.32B6188E@dynamicsoft.com> Date: Thu, 03 Feb 2000 01:15:51 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Anders Kristensen Cc: Itamar Gilad , "'sip@lists.research.bell-labs.com'" Subject: Re: Call legs and Cseq References: <00Feb2.174322ist.115204@firewall.tlv.radvision.com> <3898630B.85AF6F03@hpl.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Anders Kristensen wrote: > > Itamar Gilad wrote: > > > > Just to make sure: > > > > reqMsg1 == reqMsg2 (duplicate requests) IFF the To, From, Call-ID and CSeq > > headers are identical (addresses and tags only in the To and From headers). > > Yes. Obviously, reqMsg1 and reqMsg2 may in fact differ in other headers > (although this should never happen), but for the purpose of identifying > and filtering out retransmissions they're the same. This is the case as specified in RFC2543, but two issues have been discovered since, and discussed on the list, which probably require two more fields thrown in there. First is loop detection. As we discussed on the list, there are valid cases where a message is not a loop even though it hits the same server twice; namely, when the request URI is different between the two. In this case, the request and its looped version will differ by the request URI (and parts of the Via too). Here, the fact that the request URI is different is important. Another issue is request merging (the reverse of forking). In this case, two messages arrive from different upstream servers, with the same request URI, To, From, Call-ID and CSeq. Whilst it is OK to effectively ignore this problem, and treat the two as retransmissions, better performance is achieved by considering them as separate requests. See: http://www.cs.columbia.edu/~jdrosen/sip/multiple_requests.txt for a discussion of the options and their various consequences. Thus, one could include the topmost Via in the determination of equality. > > > > > msg1 and msg2 belong to the same Call-leg if > > the Call-ID is the same and > > (msg1.To == msg2.To && msg1.From == msg2.From) || > > (msg1.To == msg2.From && msg1.From == msg2.To) > > > > ( == means the addresses and tags are the same) > > > > Is that right? Almost. One would not compare two messages to determine if they are part of the same call-leg. Rather, when an INVITE is sent and/or received for the first time, the call leg is established by extracting the local and remote addresses. Whether they are extracted from the To or From depends on whether the INVITE was sent or received. Then, subsequent messages are determined to be part of the call leg by matching the To (From) to the remote (local) participant if the message is a request (response), and the From (To) to the local (remote) participate if the message is a response (request). > > > > BTW, you cannot identify duplicate responses using the first rule. > > No, not quite. If the request was sent without a To tag the UAC needs to > take into account the possibility that a UAS has added this to the > response, and must also be prepared to handle multiple responses with > different To tags (these belonging to different legs). For a proxy, the branch ID parameter will also need to be looked at if the proxy forked, to determine which forked request the response corresponds to. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 3 01:39:40 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01651 for ; Thu, 3 Feb 2000 01:39:39 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 093E052EA; Thu, 3 Feb 2000 01:35:12 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 775B252F7; Thu, 3 Feb 2000 01:35:11 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (grubby.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 359A452D6 for ; Mon, 31 Jan 2000 08:51:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Jan 31 08:50:11 EST 2000 Received: from yamato.ccrle.nec.de ([195.37.70.1]) by dusty; Mon Jan 31 08:48:03 EST 2000 Received: from ccrle.nec.de (yamato1.berlin.ccrle.nec.de [192.168.100.29]) by yamato.ccrle.nec.de (8.8.7/3.6W980303HK) with ESMTP id OAA13311 for ; Mon, 31 Jan 2000 14:53:22 +0100 (CET) Message-ID: <38959310.A7C9728B@ccrle.nec.de> Date: Mon, 31 Jan 2000 14:50:08 +0100 From: Michael =?iso-8859-1?Q?Ter=F6rde?= X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Subject: Problems with SIP-REGISTER Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hello !! I have searched your Email-list for Questions like mine, but there wasn't a posting which answerd all my questions. I woul know something about the REGISTER- Request in the SIP-Language. 1. Could a Server send me an De-Register message if he want (e.g. if he wants to reboot)?? 2. Could a Server change the "Expires"- Header field (and therefore change the Register- Time)?? 3. Did the Server send somthing as "Keep Alive" to the registerd UserAgent??(or did he make a "ping" to the IP or something else to determine that my UA is still active) 4. What happens if my UserAgent hangs up?? 5. Is there a generelly timout when the Server delets the register-entry (e.g. after 48 hours) ?? 6. Did the server MUST send a "200 OK"- Response if the UserAgent send a De-register(REGISTER with Expires=0) ?? Please help me !!! If you know an interesting Paper about generelly Sever behavior, please tell it to me. Thanks for your effort Michael Teroerde (instead of posting it on the List , you can also send it to my NEC-Email-Adress) ---------------------------------------------------------------- Michael Teroerde Student at NEC- Heidelberg michael.teroerde@ccrle.nec.de From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 3 06:27:56 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13076 for ; Thu, 3 Feb 2000 06:27:55 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 7D0B152E4; Thu, 3 Feb 2000 06:25:20 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E02C352E6; Thu, 3 Feb 2000 06:25:19 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 8797D52E4 for ; Thu, 3 Feb 2000 06:25:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 3 06:23:46 EST 2000 Received: from mail.Sophia.8x8.COM ([195.154.106.54]) by dusty; Thu Feb 3 06:21:36 EST 2000 Received: from 8x8.com (tarantula.sophia.8x8.com [192.168.2.20]) by mail.Sophia.8x8.COM (8.9.1b+Sun/8.9.1) with ESMTP id MAA25170 for ; Thu, 3 Feb 2000 12:23:25 GMT Message-ID: <389964F7.56D4EB68@8x8.com> Date: Thu, 03 Feb 2000 11:22:31 +0000 From: Marc Petit-Huguenin Organization: 8x8 - Network Software Division X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: fr-FR, fr, en MIME-Version: 1.0 To: IETF SIP Subject: Question on subsequent requests Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, First, thank for all your responses to my previous answers. I have a question about sending subsequent requests from the callee. Section 11.4 in the SIP draft give the following rules: - If the previous request contains a Record-Route, use the infos in this header. - Otherwise use the previous Contact received (if existing) - Otherwise use the provisioned proxy server (if provisioned) - Otherwise use the value in the From header field. As the rules 1, 2 and 3 can fail, we must be sure that the rule 4 works. The problem is that the "transport=" parameter is forbidden in a From header field, so there is no way to known which transport protocol to use. So do we must use : - Any protocol? - The same protocol that was use for the last received request? Thank you for your answers. Regards, -- Marc Petit-Huguenin Home: mailto:petithug@cyberservices.com Work: mailto:petithug@8x8.com "Everything I love is either immoral, illegal or makes you fat" From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 3 10:43:57 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20821 for ; Thu, 3 Feb 2000 10:43:56 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4305A52B6; Thu, 3 Feb 2000 10:41:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 87B0352EB; Thu, 3 Feb 2000 10:41:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 121D952B6 for ; Thu, 3 Feb 2000 10:41:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 3 10:39:44 EST 2000 Received: from penguin.wise.edt.ericsson.se ([194.237.142.110]) by dusty; Thu Feb 3 10:37:34 EST 2000 Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id QAA24900; Thu, 3 Feb 2000 16:39:38 +0100 (MET) Received: from uabs28 (uabs28i3 [134.138.201.3]) by ms.uab.ericsson.se (8.9.3/8.9.3/uab-2.21) with ESMTP id QAA24295; Thu, 3 Feb 2000 16:39:38 +0100 (MET) Received: from uab.ericsson.se by uabs28 (8.8.8+Sun/client-1.3uab2) id QAA18774; Thu, 3 Feb 2000 16:39:37 +0100 (MET) Message-ID: <3899A13A.BFC6D0FD@uab.ericsson.se> Date: Thu, 03 Feb 2000 16:39:38 +0100 From: Rabbe Fogelholm Organization: Ericsson Utvecklings AB X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: Francois Menard List Account Cc: sip@lists.research.bell-labs.com, sip@cslab.ericsson.se, sipfactory@uab.ericsson.se, schulzrinne@cs.columbia.edu Subject: Re: New public SIP server References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit The story behind the domain name is that it was to be read "IP Only Access". The domain was acquired for a different project, and we have started using it mostly since it was there and unused. --Rabbe Fogelholm Francois Menard List Account wrote: > > Does IPonAX means that Ericsson is playing with putting TCP/IP in an AXE ? > > -=Francois=- > > On Wed, 2 Feb 2000, Rabbe Fogelholm wrote: > > > This message is to announce a "new" public SIP server (actually it is a > > reincarnation of the Ellemtel SIP server that used to be running at > > sip.pcs.ellemtel.net:5060 in 1999). Apologies if you receive this > > message in duplicate. > > > > Henning, here are data for your SIP server page > > (http://www.cs.columbia.edu/~hgs/sip/servers.html): > > > > Organization: > > Ericsson (http://www.ericsson.se) > > > > SIP URL: > > sip:Robot@iponax.com > > > > SRV records: > > iponax.com > > > > Transport: > > UDP, TCP > > > > Modes: > > redirect > > > > Accept registrations from other domains? > > yes > > > > Remarks: > > The sip:Robot@iponax.com accepts INVITEs to VoIP sessions. > > It will play a voice announcement of about 30 s length. > > > > Comments etc are welcome. Enjoy, > > > > Rabbe.Fogelholm@ericsson.com > > From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 3 10:48:20 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20915 for ; Thu, 3 Feb 2000 10:48:19 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 71DCF52EB; Thu, 3 Feb 2000 10:45:31 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 5C8C452F7; Thu, 3 Feb 2000 10:45:30 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 9720652EB for ; Thu, 3 Feb 2000 10:45:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 3 10:44:49 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Thu Feb 3 10:42:39 EST 2000 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.5]) id QQiauw08625; Thu, 3 Feb 2000 15:44:44 GMT Message-ID: <3899A1B5.5B4D1960@dynamicsoft.com> Date: Thu, 03 Feb 2000 10:41:41 -0500 From: Igor Slepchin Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Marc Petit-Huguenin Cc: IETF SIP Subject: Re: Question on subsequent requests References: <389964F7.56D4EB68@8x8.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Marc Petit-Huguenin wrote: > As the rules 1, 2 and 3 can fail, we must be sure that the rule 4 works. > The problem is that the "transport=" parameter is forbidden in a From > header field, so there is no way to known which transport protocol to > use. > So do we must use : > - Any protocol? > - The same protocol that was use for the last received request? You should use the same algorithm you used for the first request, see 1.4.2 and appendix D for details. If the other side wants to be contacted differently (different transport, requestURI, port etc.), it must specify so in the Contact field. --- Igor Slepchin From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 3 15:13:54 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28809 for ; Thu, 3 Feb 2000 15:13:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id D07365303; Thu, 3 Feb 2000 15:11:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6BFD852F7; Thu, 3 Feb 2000 15:11:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id B343452F7 for ; Thu, 3 Feb 2000 15:11:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Feb 3 15:10:49 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Thu Feb 3 15:08:39 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id PAA19934; Thu, 3 Feb 2000 15:10:47 -0500 (EST) Message-ID: <3899E0C5.3C72025@cs.columbia.edu> Date: Thu, 03 Feb 2000 15:10:45 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Cc: Jennifer_Wade@3com.com Subject: SIP Bakeoff 4: April 17-19, 2000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Dear SIP bakers: The 4th SIP bake-off will be held in Rolling Meadows, Illinois, hosted by 3Com, from April 17 to 19, 2000. Further logistical details will be available shortly at http://www.sipbakeoff.org/ Registration is set to begin around March 1st. Please contact Jennifer Wade at Jennifer_Wade@3com.com for further details. Regards, Henning -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 4 11:20:53 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01555 for ; Fri, 4 Feb 2000 11:20:52 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id EF41F52B6; Fri, 4 Feb 2000 11:18:03 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6DE4652C4; Fri, 4 Feb 2000 11:18:02 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from bronx.dnrc.bell-labs.com (bronx [135.180.160.8]) by lists.research.bell-labs.com (Postfix) with ESMTP id D9F0352B6 for ; Fri, 4 Feb 2000 11:17:46 -0500 (EST) Received: from cs.columbia.edu (ume [135.180.240.103]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id LAA18959; Fri, 4 Feb 2000 11:17:45 -0500 (EST) Message-ID: <389AFBA9.FE312DEE@cs.columbia.edu> Date: Fri, 04 Feb 2000 11:17:45 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Cc: dhcp-v4@bucknell.edu Subject: DHCP options for locating outbound SIP servers Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Gautam Nair and I have submitted an Internet draft for using DHCP to configure SIP clients with the address of outbound SIP servers. Until the draft appears in the I-D directories, it can also be found at http://www.cs.columbia.edu/sip/drafts/draft-nair-sip-dhcp-00.txt (For the DHCP experts: SIP, the Session Initiation Protocol, is used for setting up, modifying and terminating multimedia sessions, including Internet telephone calls. It is an IETF Proposed Standard document in RFC 2543, with information available at http://www.cs.columbia.edu/sip) We have documented a number of approaches in the draft, some of which may well be dropped if deemed to be redundant. A particular concern of ours are low-complexity embedded systems (such as http://www.cs.columbia.edu/~hgs/ephone) that may not support DNS and do not have the computational resources to host an SLP implementation. (Indeed, the outbound SIP server may well handle DNS resolution for the client.) Since SIP domains can be rather large (a whole ISP), we considered it important to provide a load balancing mechanism. Since this operates in a telephony context, reliability is very important, leading us to include the notion of backup servers and the ability to operate even when local DNS service is interrupted. There may well be better mechanisms to address either of these concerns. Feedback and comments are appreciated. Henning From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 4 11:30:06 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01768 for ; Fri, 4 Feb 2000 11:30:05 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 1276452C8; Fri, 4 Feb 2000 11:27:25 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 56CE552C4; Fri, 4 Feb 2000 11:27:24 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 243FF52C8 for ; Fri, 4 Feb 2000 11:27:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Feb 4 11:26:40 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Fri Feb 4 11:24:27 EST 2000 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.56]) id QQiayr17087 for ; Fri, 4 Feb 2000 16:26:38 GMT Message-ID: <389AFE69.1B4BA96C@dynamicsoft.com> Date: Fri, 04 Feb 2000 11:29:29 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Subject: [Fwd: 47th IETF: Agenda] Content-Type: multipart/mixed; boundary="------------B56AD8A3C698FBC4A4DB0F4A" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk This is a multi-part message in MIME format. --------------B56AD8A3C698FBC4A4DB0F4A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks, The SIP wg meeting in IETF 47 in Adelaide has been tentatively scheduled for Monday, March 27, 9:30 - 11:30 and Tuesday, March 28, 1-3:15. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com --------------B56AD8A3C698FBC4A4DB0F4A Content-Type: message/rfc822 Content-Disposition: inline Received: from wodc7mr4.ffx.ops.us.uu.net by wodc7ps1.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: wodc7mr4.ffx.ops.us.uu.net [192.48.96.29]) id QQiavu27068 for ; Thu, 3 Feb 2000 21:37:09 GMT Received: from ietf.org by wodc7mr4.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: odin.ietf.org [132.151.1.176]) id QQiavu13589 for ; Thu, 3 Feb 2000 21:37:08 GMT Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29689; Thu, 3 Feb 2000 16:12:05 -0500 (EST) Message-Id: <200002032112.QAA29689@ietf.org> To: wgchairs@ietf.org, bofchairs@ietf.org From: agenda@ietf.org Subject: 47th IETF: Agenda Date: Thu, 03 Feb 2000 16:12:04 -0500 Sender: mbeaulie@cnri.reston.va.us X-Mozilla-Status2: 00000000 MIME-Version: 1.0 Working Group and BOF Chairs, Here is the current Agenda including all of the requests I have received as of today, February 3, 2000. All scheduling is tentative and subject to change. If a change needs to be made to your working group, I will notify you. All attempts will be made to keep the working group as close as possible to its current scheduled time. Please submit an agenda for your working group as soon as possible to: agenda@ietf.org The deadline for submitting an agenda is March 17 at 1200 ET. Draft Agenda of the Forty-seventh IETF March 26-31, 2000 As of 2/3/00 SUNDAY, March 26, 2000 1200-1900 Registration - 1530-1600 Newcomer's Orientation - 1600-1630 IETF Standards Process Orientation - 1700-1900 Welcome Reception - MONDAY, March 27, 2000 0800-1930 IETF Registration - 0800-0900 Continental Breakfast 0900-0930 Opening Plenary Session - 0930-1130 Morning Sessions APP apparea Applications Area Meeting INT frnetmib Frame Relay Service MIB WG SEC cat Common Authentication Technology WG TSV sip Session Initiation Protocol WG * 1130-1300 Break 1300-1500 Afternoon Sessions I APP ldapext LDAP Extension WG RTG manet Mobile Ad-hoc Networks WG SEC xmldsig XML Digital Signatures WG TSV nat Network Address Translators WG USV uswg User Services WG 1500-1530 Break (Refreshments provided) - 1530-1730 Afternoon Sessions II APP conneg Content Negotiation WG INT ipcdn IP over Cable Data Networks WG OPS mboned MBONE Deployment WG * RTG mobileip IP Routing for Wireless/Mobile Hosts WG TSV diffserv Differentiated Services WG * TSV spirits Service in the PSTN/IN Requesting Internet Service WG 1730-1930 Break 1930-2200 Evening Sessions OPS ngtrans Next Generation Transition WG RTG mpls Multiprotocol Label Switching WG TSV iptel IP Telephony WG * TSV nfsv4 Network File System Version 4 WG * Designates Multicast Sessions TUESDAY, March 28, 2000 0800-1700 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Sessions APP calsch Calendaring and Scheduling WG INT dnsext DNS Extensions WG * OPS rap Resource Allocation Protocol WG RTG mobileip IP Routing for Wireless/Mobile Hosts WG TSV enum Telephone Number Mapping WG TSV megaco Media Gateway Control WG 1130-1300 Break 1300-1400 Afternoon Sessions I TSV diffserv Differentiated Services WG * TSV sip Session Initiation Protocol WG * 1415-1515 Afternoon Sessions II RTG vrrp Virtual Router Redundancy Protocol WG TSV nfsv4 Network File System Version 4 TSV sip Session Initiation Protocol WG * 1515-1545 Break (Refreshments provided) - 1545-1645 Afternoon Sessions III OPS snmpconf Configuration Management with SNMP WG TSV rmt Reliable Multicast Transport WG * 1700-1800 Afternoon Sessions IV OPS snmpconf Configuration Management with SNMP WG TSV pilc Performance Implications of Link Characteristics WG TSV rmt Reliable Multicast Transport WG * * Designates Multicast Sessions WEDNESDAY, March 29, 2000 0800-1700 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Sessions APP trade Internet Open Trading Protocol WG INT ipngwg IPNG WG * OPS bmwg Benchmarking Methodology WG RTG mpls Multiprotocol Label Switching WG TSV rmt Reliable Multicast Transport WG * TSV sigtran Signaling Transport WG 1130-1300 Break 1300-1500 Afternoon Sessions I INT ipfc IP Over Fibre Channel WG OPS ngtrans Next Generation Transition WG RTG msdp Multicast Source Discovery Protocol WG * SEC pkix Public-Key Infrastructure (X.509) WG TSV tsvwg Transport Area Working Group WG 1500-1530 Break (Refreshments provided) - 1530-1730 Afternoon Sessions II INT l2tpext Layer Two Tunneling Protocol Extensions WG RTG rtgarea Routing Area Meeting SEC smime S/MIME Mail Security WG TSV avt Audio/Video Transport WG * 1730-1930 Break 1930-2200 Open Plenary - o Welcome - Fred Baker, IETF Chair o IAB Open Plenary o IESG Open Plenary * Designates Multicast Sessions THURSDAY, March 30, 2000 0800-1700 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Sessions APP blocks An Application Protocol Framework & A Model Application BOF OPS snmpconf Configuration Management with SNMP WG TSV malloc Multicast-Address Allocation WG * 1130-1300 Break 1300-1500 Afternoon Sessions I OPS snmpv3 SNMP Version 3 SEC saag Open Security Area Directorate Meeting TSV avt Audio/Video Transport WG * 1500-1530 Break (Refreshments provided) - 1530-1730 Afternoon Sessions II SEC idwg Intrusion Detection Exchange Format WG TSV mmusic Multiparty Multimedia Session Control WG FRIDAY, March 31, 2000 0800-1000 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Sessions SEC idwg Intrusion Detection Exchange Format WG TSV ecm Endpoint Congestion Management WG * Designates Multicast Sessions --------------B56AD8A3C698FBC4A4DB0F4A-- From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 7 03:12:05 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00601 for ; Mon, 7 Feb 2000 03:12:05 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 01EDB52BB; Mon, 7 Feb 2000 03:09:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 63FAD52D4; Mon, 7 Feb 2000 03:09:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 4861452BB for ; Mon, 7 Feb 2000 03:09:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 7 03:07:21 EST 2000 Received: from mail.speedventures.com ([212.75.74.99]) by dusty; Mon Feb 7 03:05:06 EST 2000 Received: from FOOBAR ([192.168.24.129]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1GWWV3CP; Mon, 7 Feb 2000 09:05:27 +0100 Message-ID: <013201bf7142$5fc21b80$8118a8c0@foobar.speedventures.com> From: "Christian Jansson" To: Subject: Question about REGISTER Date: Mon, 7 Feb 2000 09:07:27 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit From 4.2.6: All current registrations MUST share the same action value. Registrations that have a different action than current registrations for the same user MUST be rejected with status of 409 (Conflict). 1.What about a REGISTER request that does not have an action value: Does that match any of "redirect" or "proxy"? Is it then up to the server to chose the action, and indicate the choice in the response? Or is it the first REGISTER with an action that sets the rule (also for earlier REGISTERS that did not have an action value)? 2. Why do they have to share the same action at all? 3. A server that only supports one of the redirect/proxy behaviors receives a REGISTER with the unsupported action indicated. What is it supposed to do, send a 409 response? -- Christian Jansson (christian@hotsip.com) HotSip AB phone: +46 (0)8 555 10 704 mobile: +46 (0)70 558 1038 From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 7 05:53:55 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01777 for ; Mon, 7 Feb 2000 05:53:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 7851E52AB; Mon, 7 Feb 2000 05:51:18 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id CF48D52D5; Mon, 7 Feb 2000 05:51:17 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 7F0C652AB for ; Mon, 7 Feb 2000 05:51:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 7 05:50:53 EST 2000 Received: from www7.gmx.net ([194.221.183.47]) by dusty; Mon Feb 7 05:48:38 EST 2000 Received: (qmail 27114 invoked by uid 0); 7 Feb 2000 10:50:51 -0000 Date: Mon, 7 Feb 2000 11:50:51 +0100 (MET) From: Michael Teroerde To: sip@lists.research.bell-labs.com MIME-Version: 1.0 Subject: From- Header X-Authenticated-Sender: #0003572868@gmx.net X-Authenticated-IP: [195.37.70.1] Message-ID: <27081.949920651@www7.gmx.net> X-Mailer: WWW-Mail 1.5 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hello !! If I want to make an "third-party registration" could I write another domain in the From-header field as in the To- header ??? Example: ... To: alice@acme.com From: michael@nec.de ... (In the RFC- Example are the domains equal) If it is possible, is the OK- response send to alice@nec.de or michael@acme.com or to both people? If it is impossible, is there another way to register a user from another Domain as where the UA is running (and get all Responses regarding the registration, but no Message about the Call)? Thank you !! Michael Teroerde (instead of posting it on the List , you can also send it to my NEC-Email-Adress) ---------------------------------------------------------------- Michael Teroerde Student at NEC- Heidelberg michael.teroerde@ccrle.nec.de -- Sent through Global Message Exchange - http://www.gmx.net From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 7 09:50:08 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11306 for ; Mon, 7 Feb 2000 09:50:05 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 1B53B52D5; Mon, 7 Feb 2000 09:47:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8594852D6; Mon, 7 Feb 2000 09:47:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id D21FF52D5 for ; Mon, 7 Feb 2000 09:47:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 7 09:45:45 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Mon Feb 7 09:43:30 EST 2000 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.56]) id QQibjn27167; Mon, 7 Feb 2000 14:45:37 GMT Message-ID: <389EDB50.64DB5E4A@dynamicsoft.com> Date: Mon, 07 Feb 2000 09:48:48 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Michael Teroerde Cc: sip@lists.research.bell-labs.com, michael.teroerde@ccrle.nec.de Subject: Re: From- Header References: <27081.949920651@www7.gmx.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Michael Teroerde wrote: > > Hello !! > > If I want to make an "third-party registration" could I write another > domain > in the From-header field as in the To- header ??? Absolutely. > > Example: > ... > To: alice@acme.com > From: michael@nec.de > ... > > (In the RFC- Example are the domains equal) > > If it is possible, is the OK- response send to alice@nec.de or > michael@acme.com or to both people? Neither. Like all SIP requests, the response is sent to the address in the Via header. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 7 09:58:00 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11634 for ; Mon, 7 Feb 2000 09:57:58 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id BDEA852D6; Mon, 7 Feb 2000 09:55:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3C1E752DA; Mon, 7 Feb 2000 09:55:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id A109352D6 for ; Mon, 7 Feb 2000 09:55:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Feb 7 09:54:10 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Mon Feb 7 09:51:54 EST 2000 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.56]) id QQibjn20601; Mon, 7 Feb 2000 14:54:03 GMT Message-ID: <389EDD4A.4ADE422C@dynamicsoft.com> Date: Mon, 07 Feb 2000 09:57:14 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Christian Jansson Cc: sip@lists.research.bell-labs.com Subject: Re: Question about REGISTER References: <013201bf7142$5fc21b80$8118a8c0@foobar.speedventures.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Christian Jansson wrote: > > >From 4.2.6: > > All current registrations MUST share the same action value. Registrations > that have a different action than current registrations for the same user > MUST be rejected with status of 409 (Conflict). > > 1.What about a REGISTER request that does not have an action value: > Does that match any of "redirect" or "proxy"? > Is it then up to the server to chose the action, and indicate the choice > in the response? > Or is it the first REGISTER with an action that sets the rule (also for > earlier REGISTERS that did not have an action value)? If no action is present in the initial registration, the server does whatever it likes and returns that in the response. From the spec: > action: The "action" parameter is used only when registering with the > REGISTER request. It indicates whether the client wishes that > the server proxy or redirect future requests intended for the > client. If this parameter is not specified the action taken > depends on server configuration. In its response, the registrar > SHOULD indicate the mode used. This parameter is ignored for > other requests. Subsequent registrations with no action will take the same value. > > 2. Why do they have to share the same action at all? It doesn't make sense for them not to. If a server has two URLs, one with proxy, and one with redirect, and then an INVITE comes, what does it do? Does it ignore the proxy and then redirect? Would it redirect to one or the other or both URLS? Would it first proxy, and then on failure, redirect? These are the kinds of things CPL can specify. Rather than build arbitrary and complex meaning into the action parameter, we kept it simple. > > 3. A server that only supports one of the redirect/proxy behaviors receives > a REGISTER with the unsupported action indicated. What is it supposed > to do, send a 409 response? 403 Forbidden is probably better. It doesn't much matter, unless you want to have the client resubmit the request with a different action tag. There is currently no way to do this; I'm not sure its a big deal (tend to think its not generally needed) -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 7 10:22:58 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12434 for ; Mon, 7 Feb 2000 10:22:57 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id AD43252DA; Mon, 7 Feb 2000 10:20:26 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 2E7F452DB; Mon, 7 Feb 2000 10:20:26 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 1DD2052B6 for ; Fri, 4 Feb 2000 10:51:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Feb 4 10:51:00 EST 2000 Received: from mail.speedventures.com ([212.75.74.99]) by dusty; Fri Feb 4 10:48:48 EST 2000 Received: from FOOBAR ([192.168.24.129]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1GWWVNG6; Fri, 4 Feb 2000 16:48:54 +0100 Message-ID: <00dc01bf6f27$bbb3e580$8118a8c0@foobar.speedventures.com> From: "Christian Jansson" To: Subject: Question about REGISTER Date: Fri, 4 Feb 2000 16:51:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit >From 4.2.6: All current registrations MUST share the same action value. Registrations that have a different action than current registrations for the same user MUST be rejected with status of 409 (Conflict). 1.What about a REGISTER request that does not have an action value: Does that match any of "redirect" or "proxy"? Is it then up to the server to chose the action, and indicate the choice in the response? Or is it the first REGISTER with an action that sets the rule (also for earlier REGISTERS that did not have an action value)? 2. Why do they have to share the same action at all? 3. A server that only supports one of the redirect/proxy behaviors receives a REGISTER with the unsupported action indicated. What does it do, send a 409 response? -- Christian Jansson (christian@hotsip.com) HotSip AB phone: +46 (0)8 555 10 704 mobile: +46 (0)70 558 1038 From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 8 04:18:14 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12788 for ; Tue, 8 Feb 2000 04:18:13 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C23AE52B6; Tue, 8 Feb 2000 04:15:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3850152BB; Tue, 8 Feb 2000 04:15:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 4E2DB52B6 for ; Tue, 8 Feb 2000 04:15:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 8 04:13:44 EST 2000 Received: from www2.gmx.net ([195.63.104.42]) by dusty; Tue Feb 8 04:11:29 EST 2000 Received: (qmail 2966 invoked by uid 0); 8 Feb 2000 09:13:42 -0000 Date: Tue, 8 Feb 2000 10:13:42 +0100 (MET) From: Michael Teroerde To: sip@lists.research.bell-labs.com MIME-Version: 1.0 Subject: Via-Header in a REGISTER-request X-Authenticated-Sender: #0003572868@gmx.net X-Authenticated-IP: [195.37.70.1] Message-ID: <2933.950001222@www2.gmx.net> X-Mailer: WWW-Mail 1.5 (Global Message Exchange) X-Flags: 0001 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hello !!! If I send an REGISTER and add an additional Via-header. Does the Server remember the Via headers for sending an INVITE trough the same route ?? For example: REGISTER sip:tu-berlin.de SIP/2.0 Via: SIP/2.0/UDP bell.de Via: SIP/2.0/UDP nec.de From: sip:michael@nec.de ..... Did the proxy forward an incomming INVITE for michael@nec.de to bell.de or did he tries to connect directly to nec.de ?? Thanks for your effort Michael Teroerde ---------------------------------------------------------------- Michael Teroerde Student at NEC- Heidelberg michael.teroerde@ccrle.nec.de -- Sent through Global Message Exchange - http://www.gmx.net From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 8 08:27:58 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18954 for ; Tue, 8 Feb 2000 08:27:57 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 51E5D52BB; Tue, 8 Feb 2000 08:25:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id BF71F52C8; Tue, 8 Feb 2000 08:25:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 7E1C352BB for ; Tue, 8 Feb 2000 08:25:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Feb 8 08:24:33 EST 2000 Received: from penguin.wise.edt.ericsson.se ([194.237.142.110]) by dusty; Tue Feb 8 08:22:18 EST 2000 Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id OAA19944; Tue, 8 Feb 2000 14:24:27 +0100 (MET) Received: from umail.lmf.ericsson.se (umail.lmf.ericsson.se [131.160.11.2]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id PAA14898; Tue, 8 Feb 2000 15:24:26 +0200 (EET) Received: from lmf.ericsson.se (E005004B57CE1 [131.160.73.131]) by umail.lmf.ericsson.se (8.8.8+Sun/8.8.8) with ESMTP id PAA15557; Tue, 8 Feb 2000 15:24:23 +0200 (EET) Message-ID: <38A01900.E9AD224A@lmf.ericsson.se> Date: Tue, 08 Feb 2000 15:24:16 +0200 From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: michael.teroerde@gmx.de Cc: sip@lists.research.bell-labs.com Subject: Re: Via-Header in a REGISTER-request References: <2933.950001222@www2.gmx.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Michael, michael.teroerde@gmx.de wrote: > > Hello !!! > > If I send an REGISTER and add an additional Via-header. Does the Server > remember the Via headers for sending an INVITE trough the same route ?? > Via headers are used just for routing responses. The INVITE is a request. > For example: > > REGISTER sip:tu-berlin.de SIP/2.0 > Via: SIP/2.0/UDP bell.de > Via: SIP/2.0/UDP nec.de > From: sip:michael@nec.de > ...... > > Did the proxy forward an incomming INVITE for michael@nec.de to bell.de or > > did he tries to connect directly to nec.de ?? The proxy will use the Contact header in the REGISTER. Regards, Gonzalo > > Thanks for your effort > > Michael Teroerde > ---------------------------------------------------------------- > Michael Teroerde > Student at NEC- Heidelberg > michael.teroerde@ccrle.nec.de > > -- > Sent through Global Message Exchange - http://www.gmx.net -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 8 11:07:21 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29399 for ; Tue, 8 Feb 2000 11:07:19 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C7B0952AB; Tue, 8 Feb 2000 11:04:31 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3CC9452D4; Tue, 8 Feb 2000 11:04:31 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 5689D52C8 for ; Tue, 8 Feb 2000 10:25:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 8 10:24:56 EST 2000 Received: from mgw-x2.nokia.com ([131.228.20.22]) by dusty; Tue Feb 8 10:22:41 EST 2000 Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id RAA02258 for ; Tue, 8 Feb 2000 17:24:52 +0200 (EET) From: Denis.Dagenais@nokia.com Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id RAA14220 for ; Tue, 8 Feb 2000 17:24:48 +0200 (EET) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id <1RM3DBJK>; Tue, 8 Feb 2000 09:24:46 -0600 Message-ID: To: sip@lists.research.bell-labs.com Subject: SIP Stacks Date: Tue, 8 Feb 2000 09:24:31 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Can somebody tell me who are the SIP Vendors?? Thanks Denis From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 8 11:12:05 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29601 for ; Tue, 8 Feb 2000 11:12:03 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C925652D4; Tue, 8 Feb 2000 11:07:18 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 0A1FC52DC; Tue, 8 Feb 2000 11:07:17 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 5E46552E6 for ; Thu, 3 Feb 2000 13:47:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Feb 3 13:46:00 EST 2000 Received: from mgw-x2.nokia.com ([131.228.20.22]) by dusty; Thu Feb 3 13:43:50 EST 2000 Received: from mgw-i2.ntc.nokia.com (mgw-i2.ntc.nokia.com [131.228.118.61]) by mgw-x2.nokia.com (8.9.3/8.9.3/o) with ESMTP id UAA15146 for ; Thu, 3 Feb 2000 20:45:57 +0200 (EET) From: Denis.Dagenais@nokia.com Received: from daebh02nok.americas.nokia.com (daebh02nok.americas.nokia.com [172.18.242.183]) by mgw-i2.ntc.nokia.com (8.9.3/8.9.3) with ESMTP id UAA26388 for ; Thu, 3 Feb 2000 20:45:56 +0200 (EET) Received: by daebh02nok with Internet Mail Service (5.5.2448.0) id <1B3WDXLA>; Thu, 3 Feb 2000 12:45:54 -0600 Message-ID: To: sip@lists.research.bell-labs.com Subject: SIP Stacks Date: Thu, 3 Feb 2000 12:45:48 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk I need to know, who has SIP stacks (available) that include User Agents and Proxies Denis Dagenais From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 8 11:15:34 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29748 for ; Tue, 8 Feb 2000 11:15:31 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4CCCC52DF; Tue, 8 Feb 2000 11:08:06 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id CAA6452DE; Tue, 8 Feb 2000 11:08:04 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 9375352E6 for ; Thu, 3 Feb 2000 05:57:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 3 05:56:01 EST 2000 Received: from mail.speedventures.com ([212.75.74.99]) by dusty; Thu Feb 3 05:53:51 EST 2000 Received: from FOOBAR ([192.168.24.129]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1GWWVL7R; Thu, 3 Feb 2000 11:54:03 +0100 Message-ID: <005d01bf6e35$74565440$8118a8c0@foobar.speedventures.com> From: "Christian Jansson" To: Subject: Question about REGISTER Date: Thu, 3 Feb 2000 11:57:24 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3155.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit >From 4.2.6: All current registrations MUST share the same action value. Registrations that have a different action than current registrations for the same user MUST be rejected with status of 409 (Conflict). 1.What about a REGISTER request that does not have an action value: Does that match any of "redirect" or "proxy"? Is it then up to the server to chose the action, and indicate the choice in the response? Or is it the first REGISTER with an action that sets the rule (also for earlier REGISTERS that did not have an action value)? 2. Why do they have to share the same action at all? 3. A server that only supports one of the redirect/proxy behaviors receives a REGISTER with the unsupported action indicated. What does it do, send a 409 response? -- Christian Jansson (christian@hotsip.com) HotSip AB phone: +46 (0)8 555 10 704 mobile: +46 (0)70 558 1038 From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 8 11:18:46 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29878 for ; Tue, 8 Feb 2000 11:18:45 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 2055B52DD; Tue, 8 Feb 2000 11:13:36 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 7F88A52E2; Tue, 8 Feb 2000 11:13:35 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id D58A652DD for ; Tue, 8 Feb 2000 11:13:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 8 11:12:30 EST 2000 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by dusty; Tue Feb 8 11:10:15 EST 2000 Received: from fokus.gmd.de (jobe [193.175.132.219]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id RAA01389; Tue, 8 Feb 2000 17:11:39 +0100 (MET) Message-ID: <38A04068.A61F74FD@fokus.gmd.de> Date: Tue, 08 Feb 2000 17:12:24 +0100 From: Jiri Kuthan Organization: GMD Fokus X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Denis.Dagenais@nokia.com Cc: sip@lists.research.bell-labs.com Subject: Re: SIP Stacks References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Check Henning's SIP site [1] and my iptel products page [2]. The former includes SIP products only, the latter both SIP and H.323. Jiri [1] http://www.cs.columbia.edu/~hgs/sip/implementations.html [2] http://www.fokus.gmd.de/research/cc/glone/projects/ipt/products.php3 Denis.Dagenais@nokia.com wrote: > > Can somebody tell me who are the SIP Vendors?? > > Thanks > > Denis -- Jiri Kuthan Phone: ++49 / (0)30 / 3463 - 7 271 GMD FOKUS Fax : ++49 / (0)30 / 3463 - 8 271 Kaiserin-Augusta-Allee 31 E-Mail : kuthan@fokus.gmd.de D-10589 Berlin, Germany WWW : http://www.fokus.gmd.de/usr/kuthan From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 8 12:38:04 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03902 for ; Tue, 8 Feb 2000 12:38:04 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id DF69152D6; Tue, 8 Feb 2000 12:35:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 503F452DA; Tue, 8 Feb 2000 12:35:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 6006E52D6 for ; Tue, 8 Feb 2000 12:35:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 8 12:34:41 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Tue Feb 8 12:32:26 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA10520; Tue, 8 Feb 2000 12:34:44 -0500 (EST) Message-ID: <38A05304.F8B338AB@dynamicsoft.com> Date: Tue, 08 Feb 2000 12:31:48 -0500 From: Igor Slepchin Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Christian Jansson Cc: sip@lists.research.bell-labs.com Subject: Re: Question about REGISTER References: <005d01bf6e35$74565440$8118a8c0@foobar.speedventures.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Christian Jansson wrote: > > 1.What about a REGISTER request that does not have an action value: > Does that match any of "redirect" or "proxy"? > Is it then up to the server to chose the action, and indicate the choice > in the response? Or is it the first REGISTER with an action that sets > the rule (also for earlier REGISTERS that did not have an action value)? From 6.13: If this parameter (i.e., action) is not specified the action taken depends on server configuration. I guess it makes sense to assume the action parameter that does not conflict with the existing registrations for the same address of record. > 2. Why do they have to share the same action at all? Consider the situation when john.doe@dynamicsoft.com is registered with john.doe@ietf.org;action=proxy and john.doe@acm.org;action=redirect. The proxy receives an INVITE for john.doe@dynamicsoft.com; what should it do now? It cannot both redirect and proxy at the same time; sending a redirect immediately would mean that the second address is not even tried; proxying first means that the redirect is at least delayed. Generally, there is a conflict between desired actions for john.doe@dynamicsoft.com between registering entities. > 3. A server that only supports one of the redirect/proxy behaviors receives > a REGISTER with the unsupported action indicated. What does it do, > send a 409 response? This would work. Another option is something like 501 Not implemented: action=proxy . --- Igor Slepchin From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 8 13:26:08 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06138 for ; Tue, 8 Feb 2000 13:26:08 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 1022D52D5; Tue, 8 Feb 2000 13:23:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 7A4DC52DB; Tue, 8 Feb 2000 13:23:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id B8C7352D5 for ; Tue, 8 Feb 2000 13:23:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 8 13:21:20 EST 2000 Received: from PMESMTP02.wcom.com ([199.249.20.2]) by dusty; Tue Feb 8 13:19:04 EST 2000 Received: from omzrelay.mcit.com ([166.37.204.49]) by firewall.mcit.com (PMDF V5.2-32 #41713) with ESMTP id <0FPM00824IZ9JI@firewall.mcit.com> for sip@lists.research.bell-labs.com; Tue, 8 Feb 2000 18:21:09 +0000 (GMT) Received: from omzmta04.mcit.com (omzmta04.mcit.com [166.37.194.122]) by omzrelay.mcit.com (8.8.7/) with ESMTP id SAA29459; Tue, 08 Feb 2000 18:21:15 +0000 (GMT) Received: from C25766A ([166.35.227.110]) by omzmta04.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000208182106.OVHH24911@C25766A>; Tue, 08 Feb 2000 18:21:06 +0000 Date: Tue, 08 Feb 2000 12:21:06 -0600 From: Henry Sinnreich Subject: RE: SIP Stacks In-reply-to: <38A04068.A61F74FD@fokus.gmd.de> To: Jiri Kuthan , Denis.Dagenais@nokia.com Cc: sip@lists.research.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit >http://www.fokus.gmd.de/research/cc/glone/projects/ipt/ >products.php3 Is a good site for products. Small nit: Have also seen public demos and SIP bake-off tests of SIP phones from 3Com, Nortel (Etherset cluster) and Pingtel. Henry >-----Original Message----- >From: owner-sip@lists.research.bell-labs.com >[mailto:owner-sip@lists.research.bell-labs.com]On >Behalf Of Jiri Kuthan >Sent: Tuesday, February 08, 2000 10:12 AM >To: Denis.Dagenais@nokia.com >Cc: sip@lists.research.bell-labs.com >Subject: Re: SIP Stacks > > >Check Henning's SIP site [1] and my iptel products page [2]. >The former includes SIP products only, the latter both >SIP and H.323. > >Jiri > >[1] http://www.cs.columbia.edu/~hgs/sip/implementations.html >[2] >http://www.fokus.gmd.de/research/cc/glone/projects/ipt/ >products.php3 > >Denis.Dagenais@nokia.com wrote: >> >> Can somebody tell me who are the SIP Vendors?? >> >> Thanks >> >> Denis > >-- >Jiri Kuthan Phone: ++49 / (0)30 / 3463 - 7 271 >GMD FOKUS Fax : ++49 / (0)30 / 3463 - 8 271 >Kaiserin-Augusta-Allee 31 E-Mail : kuthan@fokus.gmd.de >D-10589 Berlin, Germany WWW : >http://www.fokus.gmd.de/usr/kuthan > From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 8 14:02:02 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07834 for ; Tue, 8 Feb 2000 14:02:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4229F52DA; Tue, 8 Feb 2000 13:59:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id B54DF52DC; Tue, 8 Feb 2000 13:59:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 7ACAB52DA for ; Tue, 8 Feb 2000 13:59:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 8 13:57:14 EST 2000 Received: from smtprtp1.ntcom.nortel.net ([137.118.22.14]) by dusty; Tue Feb 8 13:54:59 EST 2000 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by smtprtp1.ntcom.nortel.net; Tue, 8 Feb 2000 13:55:32 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2650.21) id <1NWN6MDC>; Tue, 8 Feb 2000 13:55:29 -0500 Message-ID: From: "Andrew Chalupka" To: "'SIP List'" Subject: Question about media desinations Date: Tue, 8 Feb 2000 13:55:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7266.10E60466" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk 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_01BF7266.10E60466 Content-Type: text/plain Hi all, Apologies if this question isn't appropriate for the SIP list... Assume a user, "caller", initiates a SIP call with a second user, "callee", through the usual means (INVITE, 200 OK, ACK). During this message exchange, each end speficies the IP address and UDP port number(s) to which the other end should send his audio stream. Would it be a violation of the SIP standard for one of the participants to send his audio stream to a third party (say to a server which might transcode the sender's audio packets into a format the other end can understand) and then have that third party forward the packets on to the appropriate destination? Section B.2 of RFC 2543 (pg 138) mentions... "For receive-only and send-or-receive streams, the port number and address in the session description indicate where the media stream should be sent to by the recipient of the session description, either caller or callee." ...which isn't as strong as saying the port-address pair supplied by the other end *must* be used. Any clarifications? - Andrew ------_=_NextPart_001_01BF7266.10E60466 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Question about media desinations

Hi all,

Apologies if this question isn't = appropriate for the SIP list...

Assume a user, "caller", = initiates a SIP call with a second user, "callee", through = the usual means (INVITE, 200 OK, ACK).  During this message = exchange, each end speficies the IP address and UDP port number(s) to = which the other end should send his audio stream.  Would it be a = violation of the SIP standard for one of the participants to send his = audio stream to a third party (say to a server which might transcode = the sender's audio packets into a format the other end can understand) = and then have that third party forward the packets on to the = appropriate destination?

Section B.2 of RFC 2543 (pg 138) = mentions...

"For receive-only and = send-or-receive streams, the port number and address in the session = description indicate where the media stream should be sent to by the = recipient of the session description, either caller or = callee."

...which isn't as strong as saying the = port-address pair supplied by the other end *must* be used.  =

Any clarifications?

- Andrew
 


------_=_NextPart_001_01BF7266.10E60466-- From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 8 14:25:58 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08533 for ; Tue, 8 Feb 2000 14:25:58 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 5829652B6; Tue, 8 Feb 2000 14:23:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id CFE6552BB; Tue, 8 Feb 2000 14:23:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 668AF52B6 for ; Tue, 8 Feb 2000 14:23:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 8 14:21:43 EST 2000 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by dusty; Tue Feb 8 14:19:27 EST 2000 Received: from fokus.gmd.de (jobe [193.175.132.219]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id UAA14900; Tue, 8 Feb 2000 20:20:48 +0100 (MET) Message-ID: <38A06CBC.5FD66D93@fokus.gmd.de> Date: Tue, 08 Feb 2000 20:21:32 +0100 From: Jiri Kuthan Organization: GMD Fokus X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Henry Sinnreich Cc: sip@lists.research.bell-labs.com Subject: Re: SIP Stacks References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit My website is open and the vendors are invited to send me links to their SIP phones webpages. Unfortunately, I was not able to find the webpages on the particular products. Regards, Jiri Henry Sinnreich wrote: > > >http://www.fokus.gmd.de/research/cc/glone/projects/ipt/ > >products.php3 > Is a good site for products. Small nit: > Have also seen public demos and SIP bake-off tests of SIP phones > from 3Com, Nortel (Etherset cluster) and Pingtel. > > Henry > -- Jiri Kuthan Phone: ++49 / (0)30 / 3463 - 7 271 GMD FOKUS Fax : ++49 / (0)30 / 3463 - 8 271 Kaiserin-Augusta-Allee 31 E-Mail : kuthan@fokus.gmd.de D-10589 Berlin, Germany WWW : http://www.fokus.gmd.de/usr/kuthan From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 8 14:34:04 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08832 for ; Tue, 8 Feb 2000 14:34:04 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 1F38F52D6; Tue, 8 Feb 2000 14:31:25 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 7B39A52BB; Tue, 8 Feb 2000 14:31:24 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 9B48C52D6 for ; Tue, 8 Feb 2000 14:31:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Feb 8 14:29:04 EST 2000 Received: from smtprich.nortel.com ([192.135.215.8]) by dusty; Tue Feb 8 14:26:48 EST 2000 Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprich.nortel.com; Tue, 8 Feb 2000 13:28:53 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id <13LQ2NBJ>; Tue, 8 Feb 2000 13:28:07 -0600 Message-ID: From: "Paul Defrain" To: "Andrew Chalupka" , "'SIP List'" Subject: RE: Question about media desinations Date: Tue, 8 Feb 2000 13:28:02 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF726A.9F53F966" X-Orig: Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk 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_01BF726A.9F53F966 Content-Type: text/plain Andrew, Our application operates in the manner you suggest. The bearer is not terminated to both participants in the SIP session (the endpoints of the respective SDP and SIP sessions are not necessarilly the same). This is not a violation of the standard as I've interpreted it. In some cases it is absolutely necessary for the SDP participants to be different than the SIP participants which furthers my conviction on this point. I'm interested to hear of any other opinions concerning this matter. Paul DeFrain Nortel Networks, IP Services > -----Original Message----- > From: Chalupka, Andrew [CAR:6M42:EXCH] > Sent: Tuesday, February 08, 2000 12:55 PM > To: 'SIP List' > Subject: Question about media desinations > > Hi all, > > Apologies if this question isn't appropriate for the SIP list... > > Assume a user, "caller", initiates a SIP call with a second user, > "callee", through the usual means (INVITE, 200 OK, ACK). During this > message exchange, each end speficies the IP address and UDP port number(s) > to which the other end should send his audio stream. Would it be a > violation of the SIP standard for one of the participants to send his > audio stream to a third party (say to a server which might transcode the > sender's audio packets into a format the other end can understand) and > then have that third party forward the packets on to the appropriate > destination? > > Section B.2 of RFC 2543 (pg 138) mentions... > > "For receive-only and send-or-receive streams, the port number and address > in the session description indicate where the media stream should be sent > to by the recipient of the session description, either caller or callee." > > ...which isn't as strong as saying the port-address pair supplied by the > other end *must* be used. > > Any clarifications? > > - Andrew > > > ------_=_NextPart_001_01BF726A.9F53F966 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: Question about media desinations

Andrew,

Our application = operates in the manner you suggest. The bearer is not terminated to = both participants in the SIP session (the endpoints of the respective = SDP and SIP sessions are not necessarilly the same). This is not a = violation of the standard as I've interpreted it. In some cases it is = absolutely necessary for the SDP participants to be different than the = SIP participants which furthers my conviction on this point. I'm = interested to hear of any other opinions concerning this = matter.

Paul DeFrain
Nortel Networks, IP = Services


    -----Original Message-----
    From:   Chalupka, Andrew [CAR:6M42:EXCH]
    Sent:   Tuesday, February 08, 2000 12:55 PM
    To:     'SIP List'
    Subject:       = Question about media = desinations

    Hi all, =

    Apologies if this question isn't = appropriate for the SIP list...

    Assume a user, "caller", = initiates a SIP call with a second user, "callee", through = the usual means (INVITE, 200 OK, ACK).=A0 During this message exchange, = each end speficies the IP address and UDP port number(s) to which the = other end should send his audio stream.=A0 Would it be a violation of = the SIP standard for one of the participants to send his audio stream = to a third party (say to a server which might transcode the sender's = audio packets into a format the other end can understand) and then have = that third party forward the packets on to the appropriate = destination?

    Section B.2 of RFC 2543 (pg 138) = mentions...

    "For receive-only and = send-or-receive streams, the port number and address in the session = description indicate where the media stream should be sent to by the = recipient of the session description, either caller or = callee."

    ...which isn't as strong as saying the = port-address pair supplied by the other end *must* be used.=A0=20

    Any clarifications?

    - Andrew
    =A0 =


------_=_NextPart_001_01BF726A.9F53F966-- From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 8 15:10:15 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09841 for ; Tue, 8 Feb 2000 15:10:14 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 5ECD052AB; Tue, 8 Feb 2000 15:07:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C9FA252C8; Tue, 8 Feb 2000 15:07:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 522C752AB for ; Tue, 8 Feb 2000 15:07:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 8 15:06:16 EST 2000 Received: from elmls01.ce.mediaone.net ([24.131.128.25]) by dusty; Tue Feb 8 15:04:01 EST 2000 Received: from cybertron.div8.net (el01-24-131-149-38.ce.mediaone.net [24.131.149.38]) by elmls01.ce.mediaone.net (8.8.7/8.8.7) with ESMTP id OAA04179; Tue, 8 Feb 2000 14:08:48 -0600 (CST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.research.bell-labs.com; Tue, 8 Feb 2000 14:06:07 -0600 (CST) Date: Tue, 8 Feb 2000 14:06:07 -0600 From: Billy Biggs To: Andrew Chalupka Cc: "'SIP List'" Subject: Re: Question about media desinations Message-ID: <20000208140607.A17103@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from andcha@nortelnetworks.com on Tue, Feb 08, 2000 at 01:55:25PM -0500 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Andrew Chalupka (andcha@nortelnetworks.com): > [...] Would it be a violation of the SIP standard for one of the > participants to send his audio stream to a third party (say to a server which > might transcode the sender's audio packets into a format the other end can > understand) and then have that third party forward the packets on to the > appropriate destination? > > Section B.2 of RFC 2543 (pg 138) mentions... > > "For receive-only and send-or-receive streams, the port number and address > in the session description indicate where the media stream should be sent to > by the recipient of the session description, either caller or callee." > > ...which isn't as strong as saying the port-address pair supplied by the > other end *must* be used. Maybe I am misunderstanding your questions, but we frequently send SIP to a proxy which is different then the UA we exchange media with. So, yes. This brings up an interesting issue that I think is relevant to the sip list. Is there any sane policy that a client can enforce to prevent unsolicited audio to be played? One policy we came up with was that a client should only accept audio from whomever it is sending audio to. This policy seems to be broken. I think the example Andrew gives above is I think close. What if we're receiving audio locally, but our audio is sent to a third party and then sent to the far end. Given that there is no required method of dictating where audio will come from, a client is therefore in my eyes forced to accept and play whatever audio receives. Following on that, once audio is being received, in my mind there isn't anything stopping someone from blabbing into an existing conversation. Since you can't be assured about where audio is to come from, is a sane policy that once you start receiving audio from a foreign party that it must always come from that host? I don't think that works either. Why can't you have hold music come from a different host while still receiving audio? No re-INVITE required... In that case, you can't even be assured of a common SSRC. So, what's stopping a haxor like me from strobbing a gateway with random audio... ?? -- Billy Biggs vektor@div8.net http://www.div8.net/billy wbiggs@uwaterloo.ca From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 8 15:23:55 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10160 for ; Tue, 8 Feb 2000 15:23:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4348852DB; Tue, 8 Feb 2000 15:21:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A056F52C8; Tue, 8 Feb 2000 15:21:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id C446652DB for ; Tue, 8 Feb 2000 15:21:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Feb 8 15:19:56 EST 2000 Received: from hubbub.cisco.com ([171.69.11.2]) by dusty; Tue Feb 8 15:17:41 EST 2000 Received: from ORANLT ([171.69.210.5]) by hubbub.cisco.com (8.8.5-Cisco.2-SunOS.5.5.1.sun4/CISCO.GATE.1.1) with SMTP id MAA18219; Tue, 8 Feb 2000 12:19:33 -0800 (PST) From: "David Oran" To: "Billy Biggs" , "Andrew Chalupka" Cc: "'SIP List'" Subject: RE: Question about media desinations Date: Tue, 8 Feb 2000 15:19:32 -0500 Keywords: IETF 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) Importance: Normal In-Reply-To: <20000208140607.A17103@div8.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit > So, what's stopping a haxor like me from strobbing a gateway with random > audio... ?? > Crypto. From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 8 15:51:57 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10855 for ; Tue, 8 Feb 2000 15:51:56 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 9150052BB; Tue, 8 Feb 2000 15:49:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 0E0B752DC; Tue, 8 Feb 2000 15:49:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 8A17652BB for ; Tue, 8 Feb 2000 15:49:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 8 15:48:18 EST 2000 Received: from elmls01.ce.mediaone.net ([24.131.128.25]) by dusty; Tue Feb 8 15:46:03 EST 2000 Received: from cybertron.div8.net (el01-24-131-149-38.ce.mediaone.net [24.131.149.38]) by elmls01.ce.mediaone.net (8.8.7/8.8.7) with ESMTP id OAA02383; Tue, 8 Feb 2000 14:49:54 -0600 (CST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for oran@cisco.com; Tue, 8 Feb 2000 14:47:18 -0600 (CST) Date: Tue, 8 Feb 2000 14:47:18 -0600 From: Billy Biggs To: David Oran Cc: Andrew Chalupka , "'SIP List'" Subject: Re: Question about media desinations Message-ID: <20000208144718.A17534@div8.net> References: <20000208140607.A17103@div8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: ; from oran@cisco.com on Tue, Feb 08, 2000 at 03:19:32PM -0500 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk David Oran (oran@cisco.com): > > So, what's stopping a haxor like me from strobbing a gateway with random > > audio... ?? > > Crypto. Ok, so lets think about how that's going to work. It's well defined how you encrypt and authenticate your SIP messages, no big deal. But what about media? SDP provides a k= line to convey an encryption key, but it does not describe how to practically make use of it. I admit I'm not up to speed on this, but is there a draft on how to interoperably initiate an encrypted audio stream using G.711 encoding? Is the vagueness of draft-ietf-avt-profile-new-08.txt what I should be going on? Regardless, if I find the IP address of a SIP-PSTN gateway, it's bound to also support unencrypted connections. Sending audio probes at it seems to be a completely reasonable tactic as far as I'm concerned. -- Billy Biggs vektor@div8.net http://www.div8.net/billy wbiggs@uwaterloo.ca From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 8 16:07:52 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11131 for ; Tue, 8 Feb 2000 16:07:51 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 2B3C652DC; Tue, 8 Feb 2000 16:05:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9DC3B52DD; Tue, 8 Feb 2000 16:05:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 69D2A52DC for ; Tue, 8 Feb 2000 16:05:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 8 16:04:38 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Tue Feb 8 16:02:23 EST 2000 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.56]) id QQiboe04795; Tue, 8 Feb 2000 21:03:38 GMT Message-ID: <38A08566.EBD04A08@dynamicsoft.com> Date: Tue, 08 Feb 2000 16:06:46 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Billy Biggs Cc: David Oran , Andrew Chalupka , "'SIP List'" Subject: Re: Question about media desinations References: <20000208140607.A17103@div8.net> <20000208144718.A17534@div8.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Billy Biggs wrote: > > SDP provides a k= line to convey an encryption key, but it does not describe > how to practically make use of it. True enough. The original idea is that the SIP INVITE would be encrypted, and the body contains the key for the media session. The key is used for RTP level encryption. No particular algorithm is specified for SIP, a hole we are working to plug. As an alternative, one can set up an ipsec association for the media. This just requires the SDP to somehow indicate that ipsec is desired; the rest is up to ike, ipsec and its related friends. This is described in: http://www.normos.org/ietf/draft/draft-ietf-mmusic-sdp-qos-00.txt although the ipsec/ike stuff is not described, just the SIP/SDP component. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 8 16:34:02 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11804 for ; Tue, 8 Feb 2000 16:34:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 9C88A52DE; Tue, 8 Feb 2000 16:31:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 17EE652DD; Tue, 8 Feb 2000 16:31:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id F136C52E0 for ; Tue, 8 Feb 2000 16:31:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 8 16:30:36 EST 2000 Received: from PMESMTP02.wcom.com ([199.249.20.2]) by dusty; Tue Feb 8 16:28:21 EST 2000 Received: from ndcrelay.mcit.com ([166.37.172.49]) by firewall.mcit.com (PMDF V5.2-32 #41713) with ESMTP id <0FPM00ANNRMKI7@firewall.mcit.com> for sip@lists.research.bell-labs.com; Tue, 8 Feb 2000 21:27:56 +0000 (GMT) Received: from omzmta04.mcit.com (omzmta04.mcit.com [166.37.194.122]) by ndcrelay.mcit.com (8.8.7/) with ESMTP id VAA24491; Tue, 08 Feb 2000 21:28:00 +0000 (GMT) Received: from dwillispc8 ([166.35.148.173]) by omzmta04.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000208212747.QXOX24911@dwillispc8>; Tue, 08 Feb 2000 21:27:47 +0000 Date: Tue, 08 Feb 2000 15:26:49 -0600 From: Dean Willis Subject: RE: Question about media desinations In-reply-to: <20000208140607.A17103@div8.net> To: Billy Biggs , Andrew Chalupka Cc: "'SIP List'" Message-id: <000301bf727b$358f7080$ad9423a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit > So, what's stopping a haxor like me from strobbing a gateway with random > audio... ?? This came up in the SIP security design team. We have some hope that the receiver can pay attention to the SSRC and discard your spam. Of course, if you can guess the SSRC, you can get in. I once pointed out that one solution would be to extend SDP to include the source address. Of course, this could always be spoofed. -- Dean From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 8 16:41:51 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11957 for ; Tue, 8 Feb 2000 16:41:51 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 3701B52C8; Tue, 8 Feb 2000 16:39:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9716B52E0; Tue, 8 Feb 2000 16:39:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 2466152C8 for ; Tue, 8 Feb 2000 16:39:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 8 16:37:44 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Tue Feb 8 16:35:29 EST 2000 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.56]) id QQibog01401; Tue, 8 Feb 2000 21:37:37 GMT Message-ID: <38A08D5E.367C3CD1@dynamicsoft.com> Date: Tue, 08 Feb 2000 16:40:46 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Chalupka Cc: "'SIP List'" Subject: Re: Question about media desinations References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit > Andrew Chalupka wrote: > > Assume a user, "caller", initiates a SIP call with a second user, > "callee", through the usual means (INVITE, 200 OK, ACK). During this > message exchange, each end speficies the IP address and UDP port > number(s) to which the other end should send his audio stream. Would > it be a violation of the SIP standard for one of the participants to > send his audio stream to a third party (say to a server which might > transcode the sender's audio packets into a format the other end can > understand) and then have that third party forward the packets on to > the appropriate destination? No, its not a violation at all. If security is being used for the media streams, there are key distribution issues, but there is nothing that stops you from doing this. In fact, sending media to a different IP address than the one which terminates the SIP is needed for MGCP/megaco - perhaps that is what you are talking about. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 8 16:46:03 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12159 for ; Tue, 8 Feb 2000 16:46:02 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 355A252E0; Tue, 8 Feb 2000 16:43:25 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9A38352E1; Tue, 8 Feb 2000 16:43:24 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 9E39752E0 for ; Tue, 8 Feb 2000 16:43:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 8 16:42:12 EST 2000 Received: from elmls01.ce.mediaone.net ([24.131.128.25]) by dusty; Tue Feb 8 16:39:57 EST 2000 Received: from cybertron.div8.net (el01-24-131-149-38.ce.mediaone.net [24.131.149.38]) by elmls01.ce.mediaone.net (8.8.7/8.8.7) with ESMTP id PAA11539; Tue, 8 Feb 2000 15:44:44 -0600 (CST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.research.bell-labs.com; Tue, 8 Feb 2000 15:42:05 -0600 (CST) Date: Tue, 8 Feb 2000 15:42:05 -0600 From: Billy Biggs To: Dean Willis Cc: Andrew Chalupka , "'SIP List'" Subject: Re: Question about media desinations Message-ID: <20000208154204.A17839@div8.net> References: <20000208140607.A17103@div8.net> <000301bf727b$358f7080$ad9423a6@mcit.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <000301bf727b$358f7080$ad9423a6@mcit.com>; from dean.willis@wcom.com on Tue, Feb 08, 2000 at 03:26:49PM -0600 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Dean Willis (dean.willis@wcom.com): > > So, what's stopping a haxor like me from strobbing a gateway with random > > audio... ?? > > This came up in the SIP security design team. > > We have some hope that the receiver can pay attention to the SSRC and > discard your spam. Of course, if you can guess the SSRC, you can get in. Well, I don't think you can count on the SSRC being constant throughout the call. Why can't I stop sending audio from one source and begin sending it from another with a different SSRC? It wouldn't violate the context of the SIP call if I'm still receiving media at the address I specified in my SDP. > I once pointed out that one solution would be to extend SDP to include the > source address. Of course, this could always be spoofed. Which SDP? Would my sipcaster, which just sends media, have to send SDP just to indicate where media would come from? A field like that wouldn't make sense in the context of SDP. It also wouldn't make sense in the context of SIP though, since SIP isn't meant to discuss the media at all. So, you're kinda screwed there too... There really isn't any place that you should put it... The only solution is crypto, which at this point seems too undefined for practical use. -- Billy Biggs vektor@div8.net http://www.div8.net/billy wbiggs@uwaterloo.ca From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 8 17:13:53 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12651 for ; Tue, 8 Feb 2000 17:13:52 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4ACFE52E1; Tue, 8 Feb 2000 17:11:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3E08352E2; Tue, 8 Feb 2000 17:11:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id EC84852E1 for ; Tue, 8 Feb 2000 17:11:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 8 17:09:30 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Tue Feb 8 17:07:15 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id RAA15330; Tue, 8 Feb 2000 17:09:22 -0500 (EST) Message-ID: <38A0940F.EF3DEE1F@cs.columbia.edu> Date: Tue, 08 Feb 2000 17:09:19 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Billy Biggs Cc: Dean Willis , Andrew Chalupka , "'SIP List'" Subject: Re: Question about media desinations References: <20000208140607.A17103@div8.net> <000301bf727b$358f7080$ad9423a6@mcit.com> <20000208154204.A17839@div8.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Billy Biggs wrote: > > > So, you're kinda screwed there too... There really isn't any place that you > should put it... The only solution is crypto, which at this point seems too > undefined for practical use. RTP crypto is sufficiently defined to have been interworking since the early 90's, as long as you stick to encrypting the whole RTP packet using DES or 3DES, not just the payload. Indeed, vat, rat and nevot have used encryption for at least five years. (Just encrypting the payload is useless for preventing attacks since one can't tell whether the decryption transformation yielded a valid packet or not, at least for codecs whose bit streams are not heavily structured. This includes G.711 and probably most other audio codecs.) RTP-level encryption has the advantage that it doesn't inflate the packet size and doesn't require OS support. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 8 18:22:11 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13415 for ; Tue, 8 Feb 2000 18:22:11 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 3B00152DD; Tue, 8 Feb 2000 18:19:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id AA98E52E2; Tue, 8 Feb 2000 18:19:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 74BFC52DD for ; Tue, 8 Feb 2000 18:19:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 8 18:17:46 EST 2000 Received: from elmls01.ce.mediaone.net ([24.131.128.25]) by dusty; Tue Feb 8 18:15:31 EST 2000 Received: from cybertron.div8.net (el01-24-131-149-38.ce.mediaone.net [24.131.149.38]) by elmls01.ce.mediaone.net (8.8.7/8.8.7) with ESMTP id RAA27517; Tue, 8 Feb 2000 17:20:13 -0600 (CST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for schulzrinne@cs.columbia.edu; Tue, 8 Feb 2000 17:17:37 -0600 (CST) Date: Tue, 8 Feb 2000 17:17:37 -0600 From: Billy Biggs To: Henning Schulzrinne Cc: Dean Willis , "'SIP List'" Subject: Re: Question about media desinations Message-ID: <20000208171737.A18193@div8.net> References: <20000208140607.A17103@div8.net> <000301bf727b$358f7080$ad9423a6@mcit.com> <20000208154204.A17839@div8.net> <38A0940F.EF3DEE1F@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <38A0940F.EF3DEE1F@cs.columbia.edu>; from schulzrinne@cs.columbia.edu on Tue, Feb 08, 2000 at 05:09:19PM -0500 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Henning Schulzrinne (schulzrinne@cs.columbia.edu): > Billy Biggs wrote: > > > > So, you're kinda screwed there too... There really isn't any place that you > > should put it... The only solution is crypto, which at this point seems too > > undefined for practical use. > > RTP crypto is sufficiently defined to have been interworking since the > early 90's, as long as you stick to encrypting the whole RTP packet > using DES or 3DES, not just the payload. Indeed, vat, rat and nevot have > used encryption for at least five years. (Just encrypting the payload is > useless for preventing attacks since one can't tell whether the > decryption transformation yielded a valid packet or not, at least for > codecs whose bit streams are not heavily structured. This includes G.711 > and probably most other audio codecs.) So, are you suggesting that for building a SIP client that receives encrypted media it should attempt to decrypt every incomming packet and see if it 'works'? I guess this should be only attempted if an encryption key is specified inside the SDP, or if the user explicitly sets a shared secret key... Assuming that the k= line will be encrypted inside a secure SIP message, we still need to specify at some point the algorithm to be used for the encryption. As far as I can tell, this is unspecified. So, again, should a client keep trying supported algorithms until it 'works'? -- Billy Biggs vektor@div8.net http://www.div8.net/billy wbiggs@uwaterloo.ca From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 8 18:31:59 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13537 for ; Tue, 8 Feb 2000 18:31:59 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id B7A4552E3; Tue, 8 Feb 2000 18:29:25 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3C6A852E2; Tue, 8 Feb 2000 18:29:25 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 2DB8D52E3 for ; Tue, 8 Feb 2000 18:29:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 8 18:28:18 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Tue Feb 8 18:26:03 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id SAA22968; Tue, 8 Feb 2000 18:28:13 -0500 (EST) Message-ID: <38A0A68A.693D6181@cs.columbia.edu> Date: Tue, 08 Feb 2000 18:28:10 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Billy Biggs Cc: Dean Willis , "'SIP List'" Subject: Re: Question about media desinations References: <20000208140607.A17103@div8.net> <000301bf727b$358f7080$ad9423a6@mcit.com> <20000208154204.A17839@div8.net> <38A0940F.EF3DEE1F@cs.columbia.edu> <20000208171737.A18193@div8.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Billy Biggs wrote: > > > So, are you suggesting that for building a SIP client that receives encrypted > media it should attempt to decrypt every incomming packet and see if it > 'works'? I guess this should be only attempted if an encryption key is > specified inside the SDP, or if the user explicitly sets a shared secret key... Indeed, this assumes that the key is known to the other side. RFC 1890 describes how the key and algorithm are encoded, with the name space given in RFC 1423. This string is then included in SDP. > > Assuming that the k= line will be encrypted inside a secure SIP message, we > still need to specify at some point the algorithm to be used for the > encryption. As far as I can tell, this is unspecified. So, again, should a > client keep trying supported algorithms until it 'works'? No. Please reread RFC 1890. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 8 20:54:04 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14632 for ; Tue, 8 Feb 2000 20:54:00 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id ACE0F52D4; Tue, 8 Feb 2000 20:51:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 286A052D5; Tue, 8 Feb 2000 20:51:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 94EB752D4 for ; Tue, 8 Feb 2000 20:51:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 8 20:50:00 EST 2000 Received: from repulse.cnchost.com ([207.155.248.4]) by dusty; Tue Feb 8 20:47:45 EST 2000 Received: from vovida.com (w178.z216112071.sjc-ca.dsl.cnc.net [216.112.71.178]) by repulse.cnchost.com id UAA18340; Tue, 8 Feb 2000 20:49:46 -0500 (EST) [ConcentricHost SMTP Relay 1.8] Message-ID: <38A0C7BA.B01AB065@vovida.com> Date: Tue, 08 Feb 2000 17:49:46 -0800 From: Sunitha Kumar Organization: Vovida Networks X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: Denis.Dagenais@nokia.com Cc: sip@lists.research.bell-labs.com Subject: Re: SIP Stacks References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi Denis: Vovida has SIP stacks, with user Agents, available as open source on our web site. Hope that helps. regards sunitha Denis.Dagenais@nokia.com wrote: > I need to know, who has SIP stacks (available) that include User Agents and > Proxies > > Denis Dagenais From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 8 20:58:27 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14677 for ; Tue, 8 Feb 2000 20:58:25 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 829A552DA; Tue, 8 Feb 2000 20:53:40 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id AB54152E2; Tue, 8 Feb 2000 20:53:39 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 2E60D52DA for ; Tue, 8 Feb 2000 20:53:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 8 20:52:42 EST 2000 Received: from repulse.cnchost.com ([207.155.248.4]) by dusty; Tue Feb 8 20:50:27 EST 2000 Received: from vovida.com (w178.z216112071.sjc-ca.dsl.cnc.net [216.112.71.178]) by repulse.cnchost.com id UAA18894; Tue, 8 Feb 2000 20:52:34 -0500 (EST) [ConcentricHost SMTP Relay 1.8] Message-ID: <38A0C862.4D58D5E0@vovida.com> Date: Tue, 08 Feb 2000 17:52:34 -0800 From: Sunitha Kumar Organization: Vovida Networks X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: SIPbell-labs Subject: SIP security mailing list Content-Type: multipart/alternative; boundary="------------F00F3151697AE01B955A3BCB" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --------------F00F3151697AE01B955A3BCB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi : does anybody know of a mailing list for the SIP security design Thanks. -- Sunitha Kumar Software Engineer Vovida Networks (408) 957 - 6374 --------------F00F3151697AE01B955A3BCB Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi :

does anybody know of a mailing list for the SIP security design

Thanks. 

-- 
Sunitha Kumar
Software Engineer
Vovida Networks
(408) 957 - 6374
  --------------F00F3151697AE01B955A3BCB-- From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 8 20:59:49 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14700 for ; Tue, 8 Feb 2000 20:59:47 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A25D352E8; Tue, 8 Feb 2000 20:57:32 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id EAA0852EA; Tue, 8 Feb 2000 20:57:31 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 58F0B52E8 for ; Tue, 8 Feb 2000 20:57:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Feb 8 20:56:49 EST 2000 Received: from repulse.cnchost.com ([207.155.248.4]) by dusty; Tue Feb 8 20:54:34 EST 2000 Received: from vovida.com (w178.z216112071.sjc-ca.dsl.cnc.net [216.112.71.178]) by repulse.cnchost.com id UAA19795; Tue, 8 Feb 2000 20:56:41 -0500 (EST) [ConcentricHost SMTP Relay 1.8] Message-ID: <38A0C959.5E1074CF@vovida.com> Date: Tue, 08 Feb 2000 17:56:41 -0800 From: Sunitha Kumar Organization: Vovida Networks X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: SIPbell-labs Subject: Question on BYE msgs traversing proxies. Content-Type: multipart/alternative; boundary="------------894AF97565BB8729EDBC55F6" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --------------894AF97565BB8729EDBC55F6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi : In this case, should the 200 OK response be generated locally by each proxy, and then the BYE be forwarded. Or, should the proxy in concern wait for the 200 OK from the far end, and then propagate this on. Thanks much! -- Sunitha Kumar Software Engineer Vovida Networks (408) 957 - 6374 --------------894AF97565BB8729EDBC55F6 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi :

In this case, should the 200 OK response be generated locally by each proxy, and then the BYE be forwarded.
Or, should the proxy in concern wait for the 200 OK from the far end, and then propagate this on.

Thanks much! 

-- 
Sunitha Kumar
Software Engineer
Vovida Networks
(408) 957 - 6374
  --------------894AF97565BB8729EDBC55F6-- From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 8 23:53:59 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18494 for ; Tue, 8 Feb 2000 23:53:59 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A327452B6; Tue, 8 Feb 2000 23:51:20 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 27C3852D6; Tue, 8 Feb 2000 23:51:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 39E7452B6 for ; Tue, 8 Feb 2000 23:51:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Feb 8 23:50:26 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Tue Feb 8 23:48:11 EST 2000 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: 1Cust188.tnt2.freehold.nj.da.uu.net [63.17.114.188]) id QQibpj16717; Wed, 9 Feb 2000 04:50:02 GMT Message-ID: <38A0F2B8.62042DF5@dynamicsoft.com> Date: Tue, 08 Feb 2000 23:53:12 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sunitha Kumar Cc: SIPbell-labs Subject: Re: Question on BYE msgs traversing proxies. References: <38A0C959.5E1074CF@vovida.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit The proxy waits for the 200 OK and then propagates that on. The response to BYE (and any other request) may not be a 200 OK. The request needs to go to the UAS where it can be answered correctly. -Jonathan R. Sunitha Kumar wrote: > > Hi : > > In this case, should the 200 OK response be generated locally by each > proxy, and then the BYE be forwarded. > Or, should the proxy in concern wait for the 200 OK from the far end, > and then propagate this on. > > Thanks much! > > -- > Sunitha Kumar > Software Engineer > Vovida Networks > (408) 957 - 6374 > > -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 9 00:23:35 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18784 for ; Wed, 9 Feb 2000 00:23:35 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 6EF3D52D6; Wed, 9 Feb 2000 00:18:03 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 5186B52DF; Wed, 9 Feb 2000 00:18:02 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 0CDA552D6 for ; Wed, 9 Feb 2000 00:17:10 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 9 00:15:31 EST 2000 Received: from www.resilience.com ([209.245.157.1]) by dusty; Wed Feb 9 00:13:16 EST 2000 Received: from [207.213.213.113] (stat213-109.coastside.net [207.213.213.109]) by www.resilience.com (8.8.8+Sun/8.8.8) with ESMTP id VAA05598 for ; Tue, 8 Feb 2000 21:16:30 -0800 (PST) Mime-Version: 1.0 X-Sender: jlundell@resilience.com (Unverified) Message-Id: In-Reply-To: References: Date: Tue, 8 Feb 2000 21:15:36 -0800 To: sip@lists.research.bell-labs.com From: Jonathan Lundell Subject: RE: Question about media desinations Content-Type: text/plain; charset="us-ascii" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk > > So, what's stopping a haxor like me from strobbing a gateway with random >> audio... ?? >> > >Crypto. I'm ignorant of the capabilities of the specific relevant protocols here, but isn't (simpler and cheaper) authentication, rather than encryption, called for here? /Jonathan Lundell. From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 9 00:47:52 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19126 for ; Wed, 9 Feb 2000 00:47:52 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A5D0C52D5; Wed, 9 Feb 2000 00:45:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 2155152E2; Wed, 9 Feb 2000 00:45:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id EA16052D5 for ; Wed, 9 Feb 2000 00:45:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 9 00:43:14 EST 2000 Received: from PMESMTP02.wcom.com ([199.249.20.2]) by dusty; Wed Feb 9 00:40:58 EST 2000 Received: from ndcrelay2.mcit.com ([166.37.172.6]) by firewall.mcit.com (PMDF V5.2-32 #41713) with ESMTP id <0FPN006K9EJYEI@firewall.mcit.com> for sip@lists.research.bell-labs.com; Wed, 9 Feb 2000 05:43:10 +0000 (GMT) Received: from omta3.mcit.com (omta3.mcit.com [166.37.204.5]) by ndcrelay2.mcit.com (8.8.7/) with ESMTP id FAA01987; Wed, 09 Feb 2000 05:43:56 +0000 (GMT) Received: from dwillispc8 ([166.44.185.43]) by omta3.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000209054322.KSTL631@dwillispc8>; Wed, 09 Feb 2000 05:43:22 +0000 Date: Tue, 08 Feb 2000 23:42:06 -0600 From: Dean Willis Subject: RE: Question about media desinations In-reply-to: <20000208154204.A17839@div8.net> To: Billy Biggs Cc: Andrew Chalupka , "'SIP List'" Message-id: <001101bf72c0$66011ee0$2bb92ca6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit > Which SDP? Would my sipcaster, which just sends media, have to > send SDP just > to indicate where media would come from? A field like that > wouldn't make sense > in the context of SDP. Actually, I would propose the answer to that question should be "yes". And if the source changes, a reinvite is needed to change the describing SDP. Here's why -- lots of people are trying to build dynamic firewall rules. They'd like to be able to inspect (not interact with) the SIP packets going past and be able to deduce the minimal access lists that would allow the associated RTP/UDP streams to pass. With the current usage, we have only three elements of the 5-tuple (source address, source port, destination address, destination port, protocol) that describes each flow (one 5-tuple for each direction or media half-leg). We have protocol, destination address, and destination port number. One really needs at least the source IP address to make a reasonable ACL entry, and that doesn't protect calls originating from multisuer machines from being jammed by other users on that machine. Ideally, we should have the whole 5-tuple, or multiple 5-tuples that describe additional peerings such as might be experienced from a multihomed host that load balances its transmitting interfaces. So, how do the firewall people work around it? They start making assumptions, such as that each endpoint will send and receive media from the same IP address. This is potentially a very bad assumption, but it appears to be likely to be the state-of-the-art in SIP-aware packet filtering firewalls for some time. I'd rather give the the data to do the job closer to right. The good news is that even at its worst, SIP is still easier to deal with in the firewall than is H.323. -- Dean From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 9 02:57:59 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02130 for ; Wed, 9 Feb 2000 02:57:59 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 521A652E2; Wed, 9 Feb 2000 02:55:25 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id B6ED052E4; Wed, 9 Feb 2000 02:55:24 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id BAFA252E2 for ; Wed, 9 Feb 2000 02:55:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 9 02:54:24 EST 2000 Received: from penguin.wise.edt.ericsson.se ([194.237.142.110]) by dusty; Wed Feb 9 02:52:09 EST 2000 Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id IAA12131; Wed, 9 Feb 2000 08:54:12 +0100 (MET) Received: from umail.lmf.ericsson.se (umail.lmf.ericsson.se [131.160.11.2]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id JAA02213; Wed, 9 Feb 2000 09:54:07 +0200 (EET) Received: from lmf.ericsson.se (E005004B57CE1 [131.160.73.131]) by umail.lmf.ericsson.se (8.8.8+Sun/8.8.8) with ESMTP id JAA11288; Wed, 9 Feb 2000 09:54:02 +0200 (EET) Message-ID: <38A11D0E.F17D3555@lmf.ericsson.se> Date: Wed, 09 Feb 2000 09:53:50 +0200 From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: dean.willis@wcom.com Cc: vektor@div8.net, andcha@nortelnetworks.com, sip@lists.research.bell-labs.com Subject: Re: Question about media desinations References: <001101bf72c0$66011ee0$2bb92ca6@mcit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I guess the question in the first mail of this thread was something like: A sends an INVITE to B, and B answers with a 200 OK. There is no codec that both can support. A transcoding unit is necessary. 1) A proxy server can monitor the SDPs of both parties, and modify them in order the media stream to go though the transcoding point. For doing that, the proxy should be able to understand the SDP (decrypt it). Firewalls work like this. See example "Successful SIP to SIP through SIP Firewall Proxy" in page 34 of http://www.cs.columbia.edu/sip/drafts/draft-johnston-sip-call-flows-00.txt 2) A could INVITE the trasnscoding point (SIP capable) using an "also" header for B. This way the user is in control and knows that transcoding is being peformed. About encrypting RTP streams: Henning wrote the following when http://www.cs.columbia.edu/sip/drafts/draft-nair-sip-dhcp-00.txt was released: "A particular concern of ours are low-complexity embedded systems (such as http://www.cs.columbia.edu/~hgs/ephone) that may not support DNS and do not have the computational resources to host an SLP implementation." Probably low-processing power devices will not be able to cope with RTP encryption/decryption in real time. Best regards, Gonzalo dean.willis@wcom.com wrote: > > > Which SDP? Would my sipcaster, which just sends media, have to > > send SDP just > > to indicate where media would come from? A field like that > > wouldn't make sense > > in the context of SDP. > > Actually, I would propose the answer to that question should be "yes". And > if the source changes, a reinvite is needed to change the describing SDP. > > Here's why -- lots of people are trying to build dynamic firewall rules. > They'd like to be able to inspect (not interact with) the SIP packets going > past and be able to deduce the minimal access lists that would allow the > associated RTP/UDP streams to pass. With the current usage, we have only > three elements of the 5-tuple (source address, source port, destination > address, destination port, protocol) that describes each flow (one 5-tuple > for each direction or media half-leg). We have protocol, destination > address, and destination port number. One really needs at least the source > IP address to make a reasonable ACL entry, and that doesn't protect calls > originating from multisuer machines from being jammed by other users on that > machine. Ideally, we should have the whole 5-tuple, or multiple 5-tuples > that describe additional peerings such as might be experienced from a > multihomed host that load balances its transmitting interfaces. > > So, how do the firewall people work around it? They start making > assumptions, such as that each endpoint will send and receive media from the > same IP address. This is potentially a very bad assumption, but it appears > to be likely to be the state-of-the-art in SIP-aware packet filtering > firewalls for some time. I'd rather give the the data to do the job closer > to right. > > The good news is that even at its worst, SIP is still easier to deal with in > the firewall than is H.323. > > -- > Dean -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 9 04:27:59 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02690 for ; Wed, 9 Feb 2000 04:27:58 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 65C0B52BB; Wed, 9 Feb 2000 04:25:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id CF0ED52C8; Wed, 9 Feb 2000 04:25:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id E894952BB for ; Wed, 9 Feb 2000 04:25:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 9 04:23:35 EST 2000 Received: from tlv.radvision.com ([192.116.213.132]) by dusty; Wed Feb 9 04:21:19 EST 2000 Received: by firewall.tlv.radvision.com id <115209>; Wed, 9 Feb 2000 10:20:07 +0200 Message-Id: <00Feb9.102007ist.115209@firewall.tlv.radvision.com> From: Itamar Gilad To: "'Dean Willis'" Cc: "'SIP List'" Subject: RE: Question about media desinations MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Date: Wed, 9 Feb 2000 10:20:03 +0200 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk > -----Original Message----- > From: Dean Willis [mailto:dean.willis@wcom.com] > Sent: Wednesday, February 09, 2000 6:45 AM > To: Billy Biggs > Cc: Andrew Chalupka; 'SIP List' > Subject: RE: Question about media desinations > > > The good news is that even at its worst, SIP is still easier > to deal with in > the firewall than is H.323. > > -- > Dean > > If I'm not mistaken RTP is as much of an headache in both cases. Leaving the H.323 vs. SIP debate aside, I'm not sure I understand how SIP is supposed to traverse a Firewall. I found some scattered references to this in RFC2543 and also something in Henning's FAQ, but nothing concrete enough to be used as a guideline for SIP/firewall implementors. Anyone knows of other relevant documents on this subject? Itamar From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 9 08:05:56 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05232 for ; Wed, 9 Feb 2000 08:05:55 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 257CC52C8; Wed, 9 Feb 2000 08:03:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8FABA52D4; Wed, 9 Feb 2000 08:03:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 7704152C8 for ; Wed, 9 Feb 2000 08:03:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 9 08:01:45 EST 2000 Received: from felix.intertex.se ([195.22.82.2]) by dusty; Wed Feb 9 07:59:30 EST 2000 Date: Wed, 9 Feb 2000 14:00:55 +0100 (CET) From: Lars Berggren To: Jonathan Rosenberg Cc: Billy Biggs , David Oran , Andrew Chalupka , "'SIP List'" Subject: Re: Question about media desinations In-Reply-To: <38A08566.EBD04A08@dynamicsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk On Tue, 8 Feb 2000, Jonathan Rosenberg wrote: > > > Billy Biggs wrote: > > > > SDP provides a k= line to convey an encryption key, but it does not describe > > how to practically make use of it. > > True enough. The original idea is that the SIP INVITE would be > encrypted, and the body contains the key for the media session. The key > is used for RTP level encryption. No particular algorithm is specified > for SIP, a hole we are working to plug. > If the SIP INVITE is encrypted using the callee's public key things will not work when traversing a firewall proxy or any other SIP-hop that needs to change the SDP addresses in order to proxy media streams. To support RTP level encryption through a firewall proxy (FW), is the caller supposed to encrypt the SIP INVITE using the FW's public key so that the FW can decrypt, change SDP, and encrypt again using the callee's public key? It doesn't seem realistic to do this amount of processing in the FW, I think. I'm not sure how RTP works, but assuming the FW does not need to inspect/change RTP packets going through it in order for RTP-things to work, RTP level encryption through firewalls can be supported if the encryption key can be transferred encrypted without having to encrypt the whole SDP. I think some kind of mechanism for transferring the RTP-encryption-key encrypted without having the whole SDP encrypted would be useful. The kind of mechanisms I can come up with are: 1) The value of k= in SDP is encrypted using the recipients public key. 2) A SIP-header for transferring the RTP-key encrypted. 3) An additional body with the RTP-key encrypted. 4) Some kind of change to the SIP-end-to-end-encryption mechanism can solve the problems of encryption through firewalls in a more general way. 5) Extra SIP re-INVITE round-trip with SDP k= only. 6) Using k=uri or k=prompt to obtain the key. This is already specified in SDP. Or will ipsec behave well through firewalls? Comments? /Lars. > As an alternative, one can set up an ipsec association for the media. > This just requires the SDP to somehow indicate that ipsec is desired; > the rest is up to ike, ipsec and its related friends. This is described > in: > > http://www.normos.org/ietf/draft/draft-ietf-mmusic-sdp-qos-00.txt > > although the ipsec/ike stuff is not described, just the SIP/SDP > component. > > -Jonathan R. > > > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > Lars Berggren Intertex Data AB tel: +46-8-6282828 Sundbyberg, Sweden fax: +46-8-6286414 From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 9 08:32:03 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05715 for ; Wed, 9 Feb 2000 08:32:02 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 3788752D4; Wed, 9 Feb 2000 08:29:29 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A9F0152DA; Wed, 9 Feb 2000 08:29:28 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 61B4C52D4 for ; Wed, 9 Feb 2000 08:29:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 9 08:27:16 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Wed Feb 9 08:25:02 EST 2000 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: 1Cust81.tnt2.freehold.nj.da.uu.net [63.17.114.81]) id QQibqr07984; Wed, 9 Feb 2000 13:26:56 GMT Message-ID: <38A16BE9.7BD259AF@dynamicsoft.com> Date: Wed, 09 Feb 2000 08:30:17 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Itamar Gilad Cc: "'Dean Willis'" , "'SIP List'" Subject: Re: Question about media desinations References: <00Feb9.102007ist.115209@firewall.tlv.radvision.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Itamar Gilad wrote: > > If I'm not mistaken RTP is as much of an headache in both cases. Leaving > the H.323 vs. SIP debate aside, I'm not sure I understand how SIP is > supposed to traverse a Firewall. I found some scattered references to this > in RFC2543 and also something in Henning's FAQ, but nothing concrete enough > to be used as a guideline for SIP/firewall implementors. Anyone knows of > other relevant documents on this subject? Actually, yes. I am finishing writing up, along with some colleagues, a comprehensive guide on getting SIP through NATs and firewalls. Expect an I-D in the next few weeks. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 9 08:35:59 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05825 for ; Wed, 9 Feb 2000 08:35:58 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 47D0852DE; Wed, 9 Feb 2000 08:31:44 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A0C4052DA; Wed, 9 Feb 2000 08:31:42 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id D07DD52DE for ; Wed, 9 Feb 2000 08:31:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 9 08:30:51 EST 2000 Received: from marvin.axion.bt.co.uk ([132.146.16.82]) by dusty; Wed Feb 9 08:28:36 EST 2000 Received: from cbtlipnt01.btlabs.bt.co.uk by marvin (local) with ESMTP; Wed, 9 Feb 2000 13:13:19 +0000 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2448.0) id <1PDG4D4Q>; Wed, 9 Feb 2000 13:14:18 -0000 Message-ID: From: richard.swale@bt.com To: ItamarG@tlv.radvision.com, dean.willis@wcom.com Cc: sip@lists.research.bell-labs.com Subject: RE: Question about media desinations Date: Wed, 9 Feb 2000 13:14:12 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Itamar, You might like to look at a paper I wrote for the ETSI TIPHON project and the associated presentation. Althought the presentation is predicated on H.323 the problem is in fact not. The documents are:- 16TD115 16TD137 Both of these documents can be downloaded from the ETSI website at:- http://docbox.etsi.org/Tech-Org/TIPHON/Document/tiphon/ARCHIVES/1999/05-9912 -San_Diego/ regards Richard > -----Original Message----- > From: Itamar Gilad [SMTP:ItamarG@tlv.radvision.com] > Sent: Wednesday, February 09, 2000 08:20 > To: 'Dean Willis' > Cc: 'SIP List' > Subject: RE: Question about media desinations > > > > -----Original Message----- > > From: Dean Willis [mailto:dean.willis@wcom.com] > > Sent: Wednesday, February 09, 2000 6:45 AM > > To: Billy Biggs > > Cc: Andrew Chalupka; 'SIP List' > > Subject: RE: Question about media desinations > > > > > > > The good news is that even at its worst, SIP is still easier > > to deal with in > > the firewall than is H.323. > > > > -- > > Dean > > > > > > If I'm not mistaken RTP is as much of an headache in both cases. Leaving > the H.323 vs. SIP debate aside, I'm not sure I understand how SIP is > supposed to traverse a Firewall. I found some scattered references to this > in RFC2543 and also something in Henning's FAQ, but nothing concrete > enough > to be used as a guideline for SIP/firewall implementors. Anyone knows of > other relevant documents on this subject? > > Itamar From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 9 08:47:54 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06069 for ; Wed, 9 Feb 2000 08:47:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 565B952AB; Wed, 9 Feb 2000 08:45:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C906052DB; Wed, 9 Feb 2000 08:45:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 3636552AB for ; Wed, 9 Feb 2000 08:45:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Feb 9 08:44:56 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Wed Feb 9 08:42:41 EST 2000 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: 1Cust81.tnt2.freehold.nj.da.uu.net [63.17.114.81]) id QQibqs04507; Wed, 9 Feb 2000 13:44:34 GMT Message-ID: <38A1700A.D13585D2@dynamicsoft.com> Date: Wed, 09 Feb 2000 08:47:54 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Lars Berggren Cc: Billy Biggs , David Oran , Andrew Chalupka , "'SIP List'" Subject: Re: Question about media desinations References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Lars Berggren wrote: > > If the SIP INVITE is encrypted using the callee's public key things will > not work when traversing a firewall proxy or any other SIP-hop that needs > to change the SDP addresses in order to proxy media streams. Thats correct. > > To support RTP level encryption through a firewall proxy (FW), is the > caller supposed to encrypt the SIP INVITE using the FW's public key so > that the FW can decrypt, change SDP, and encrypt again using the callee's > public key? It doesn't seem realistic to do this amount of processing in > the FW, I think. No. How would the caller know it needs to do this? Rather, I believe the right solution is one of the following: 1. Don't encrypt the SDP. Use some new paramters in an SDP extension to do a diffie helman exchange to arrive at a shared session key. Then, use RTP encryption for the media. Benefits: still works through firewalls, no ipsec overheads. Drawbacks: yet another SDP extension, may introduce security holes by doing diffie helman ourselves. 2. Don't encrypt SDP or use it for key exchange. Based on http://www.cs.columbia.edu/~jdrosen/papers/draft-ietf-mmusic-sdp-qos-00.txt, make security an optional precondition for call setup. This will result in ike/ipsec stuff to exchange keys and set up an ipsec connection for the media. Benefits: also works through firewalls, uses standard ipsec stuff. Drawbacks: ipsec, especially tunnel mode, adds a lot of overhead to already small RTP packets. > Or will ipsec behave well through firewalls? Firewalls can be traversed. NATs are not a good story. NATs rewrite headers which are protected by ipsec. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 9 09:26:02 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06888 for ; Wed, 9 Feb 2000 09:26:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 44A2C52DB; Wed, 9 Feb 2000 09:23:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id AC25452DC; Wed, 9 Feb 2000 09:23:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id EDEC352DB for ; Wed, 9 Feb 2000 09:23:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 9 09:21:55 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Wed Feb 9 09:19:40 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id JAA11545; Wed, 9 Feb 2000 09:19:54 -0500 (EST) Message-ID: <38A17787.E61E7309@cs.columbia.edu> Date: Wed, 09 Feb 2000 09:19:51 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Lars Berggren , Billy Biggs , David Oran , Andrew Chalupka , "'SIP List'" Subject: Re: Question about media desinations References: <38A1700A.D13585D2@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > No. How would the caller know it needs to do this? Rather, I believe the > right solution is one of the following: > > 1. Don't encrypt the SDP. Use some new paramters in an SDP extension to > do a diffie helman exchange to arrive at a shared session key. Then, use > RTP encryption for the media. Benefits: still works through firewalls, > no ipsec overheads. Drawbacks: yet another SDP extension, may introduce > security holes by doing diffie helman ourselves. > > 2. Don't encrypt SDP or use it for key exchange. Based on > http://www.cs.columbia.edu/~jdrosen/papers/draft-ietf-mmusic-sdp-qos-00.txt, > make security an optional precondition for call setup. This will result > in ike/ipsec stuff to exchange keys and set up an ipsec connection for > the media. Benefits: also works through firewalls, uses standard ipsec > stuff. Drawbacks: ipsec, especially tunnel mode, adds a lot of overhead > to already small RTP packets. A third solution which is far simpler: Don't encrypt inside the firewall - we don't do this for other internal traffic anyway. The FW (more precisely, the outbound proxy) encrypts the SIP message using the recipient's public key, after modifying the SDP IP address appropriately. This even allows the FW to insist on media encryption between it and the outside world, even if the inside device is not encryption-capable (as might be the case for embedded devices, although DES support is far simpler than a complete SLP implementation, in terms of code-space...). Having simple end systems implement IKE is, in my view, pretty hopeless, given its complexity. DH is subject to man-in-the-middle attacks, unless the parties have a public number that the other party can look up securely. Not that different from a public key in that case. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 9 10:26:01 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08039 for ; Wed, 9 Feb 2000 10:26:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 97A1B52DA; Wed, 9 Feb 2000 10:23:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 11B8C52DD; Wed, 9 Feb 2000 10:23:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 4CC5052DA for ; Wed, 9 Feb 2000 10:23:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 9 10:22:25 EST 2000 Received: from alpha.netvision.net.il ([194.90.1.13]) by dusty; Wed Feb 9 10:20:10 EST 2000 Received: from sendout.icomverse.com (Efrat-FR3.ser.netvision.net.il [199.203.174.65]) by alpha.netvision.net.il (8.9.3/8.8.6) with ESMTP id RAA17960 for ; Wed, 9 Feb 2000 17:20:44 +0200 (IST) Received: from ismail1.icomverse.com (ismail1.icomverse.com [190.190.110.2]) by sendout.icomverse.com (8.9.3/8.8.7) with ESMTP id RAA18087 for ; Wed, 9 Feb 2000 17:21:19 +0200 Received: by ismail1.icomverse.com with Internet Mail Service (5.5.2650.21) id <1RMLNRQD>; Wed, 9 Feb 2000 17:20:26 +0200 Message-ID: From: "Gazal, Elly" To: "'SIP_ML'" Subject: voicemail packaging Date: Wed, 9 Feb 2000 17:20:24 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-8-i" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk What is Voicemail packaging? Are SIP+ and SIP-TGCP related to VM packaging? if so, how? Please help! Regards, Elly Gazal System Engineer From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 9 11:12:01 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09185 for ; Wed, 9 Feb 2000 11:12:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 0231152B6; Wed, 9 Feb 2000 11:09:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A0C0552BB; Wed, 9 Feb 2000 11:09:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id B0DF752B6 for ; Wed, 9 Feb 2000 11:09:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 9 11:08:35 EST 2000 Received: from sj-mailhub-3.cisco.com ([171.68.224.215]) by dusty; Wed Feb 9 11:06:20 EST 2000 Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id IAA05350; Wed, 9 Feb 2000 08:27:07 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id IAA26004; Wed, 9 Feb 2000 08:06:05 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14497.36973.637899.472650@thomasm-u1.cisco.com> Date: Wed, 9 Feb 2000 08:06:05 -0800 (PST) To: Dean Willis Cc: Billy Biggs , Andrew Chalupka , "'SIP List'" Subject: RE: Question about media desinations In-Reply-To: <000301bf727b$358f7080$ad9423a6@mcit.com> References: <20000208140607.A17103@div8.net> <000301bf727b$358f7080$ad9423a6@mcit.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit The packetcable security spec specifies a 2 or 4 byte MAC (using MMH) to be appended to the RTP packet itself. I have argued that RFC 2198 might actually be a cleaner way to append the MAC itself, but so long as the parties agree to the payload format, a relatively weak MAC should make barge in sufficiently difficult that even if an attacker managed to get through every once in a while, they probably wouldn't do anything especially exciting. Mike Dean Willis writes: > > > So, what's stopping a haxor like me from strobbing a gateway with random > > audio... ?? > > This came up in the SIP security design team. > > We have some hope that the receiver can pay attention to the SSRC and > discard your spam. Of course, if you can guess the SSRC, you can get in. > > I once pointed out that one solution would be to extend SDP to include the > source address. Of course, this could always be spoofed. > > -- > Dean > > > > From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 9 13:38:13 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15760 for ; Wed, 9 Feb 2000 13:38:09 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 35FDF52DD; Wed, 9 Feb 2000 13:35:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A68D252DF; Wed, 9 Feb 2000 13:35:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 1447252DD for ; Wed, 9 Feb 2000 13:35:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Feb 9 11:27:40 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Wed Feb 9 11:25:25 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA27203; Wed, 9 Feb 2000 11:23:13 -0500 (EST) Message-ID: <38A1946E.523D22D3@cs.columbia.edu> Date: Wed, 09 Feb 2000 11:23:10 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas Cc: "'SIP List'" , rem-conf@es.net Subject: Re: Question about media desinations References: <20000208140607.A17103@div8.net> <000301bf727b$358f7080$ad9423a6@mcit.com> <14497.36973.637899.472650@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > The packetcable security spec specifies a 2 or 4 > byte MAC (using MMH) to be appended to the RTP Is this simply hash(RTP packet | shared secret)? Could the bad guy record a conversation, including the hash, and then mix in the old data with the "real" one? > packet itself. I have argued that RFC 2198 might > actually be a cleaner way to append the MAC > itself, but so long as the parties agree to the > payload format, a relatively weak MAC should make > barge in sufficiently difficult that even if an > attacker managed to get through every once in a > while, they probably wouldn't do anything > especially exciting. Since this is an RTP issue, I wonder if this shouldn't be written up for avt. Another possibility is an RTP header extension. That, at least, would be backward compatible with non-MMH implementations. > > > > > > So, what's stopping a haxor like me from strobbing a gateway with random > > > audio... ?? -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 9 13:43:01 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16225 for ; Wed, 9 Feb 2000 13:43:00 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 87F2152E1; Wed, 9 Feb 2000 13:37:39 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id CF89652D5; Wed, 9 Feb 2000 13:37:37 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 5BBCD52D5 for ; Wed, 9 Feb 2000 13:37:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 9 13:04:40 EST 2000 Received: from bells.cs.ucl.ac.uk ([128.16.5.31]) by dusty; Wed Feb 9 13:02:25 EST 2000 Received: from eucharisto.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 9 Feb 2000 18:03:31 +0000 To: Henning Schulzrinne Cc: Michael Thomas , "'SIP List'" , rem-conf@es.net Subject: Re: Question about media desinations In-reply-to: Your message of "Wed, 09 Feb 2000 12:27:20 EST." <38A1A378.469B6FE1@cs.columbia.edu> Date: Wed, 09 Feb 2000 18:03:27 +0000 Message-ID: <4160.950119407@cs.ucl.ac.uk> From: Colin Perkins Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --> Henning Schulzrinne writes: >Michael Thomas wrote: >> I do sort of like the idea of the MAC being a >> payload not entirely unlike a codec payload, >> though I'm not wedded to the notion. It does have >> the advantage that we can offer up the MAC "codec" >> up in SDP m= as being something that the endpoint >> is willing to receive. With RFC 2198, the sender >> would then oblige by sending several different >> "codecs", namely the real codec and the MAC at the >> same time. > >My major concern with this is that there's a fair amount of overhead >just to get 2 or 4 bytes across. It's one more byte than using the RTP header extension..... Still, it may be better to define a new RTP profile which includes the MAC as part of the fixed RTP header. That's probably the solution with the least overhead, and the protocol definition can be straightforward RFC1890 + 4 bytes of MAC header. Colin From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 9 13:46:28 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16373 for ; Wed, 9 Feb 2000 13:46:23 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C636252EB; Wed, 9 Feb 2000 13:43:35 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 181B452EE; Wed, 9 Feb 2000 13:43:35 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 3704A52EB for ; Wed, 9 Feb 2000 13:43:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 9 12:37:33 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Wed Feb 9 12:35:18 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id MAA03407; Wed, 9 Feb 2000 12:27:24 -0500 (EST) Message-ID: <38A1A378.469B6FE1@cs.columbia.edu> Date: Wed, 09 Feb 2000 12:27:20 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas Cc: "'SIP List'" , rem-conf@es.net Subject: Re: Question about media desinations References: <20000208140607.A17103@div8.net> <000301bf727b$358f7080$ad9423a6@mcit.com> <14497.36973.637899.472650@thomasm-u1.cisco.com> <38A1946E.523D22D3@cs.columbia.edu> <14497.40587.553748.584990@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > > Since this is an RTP issue, I wonder if this shouldn't be written up for > > avt. Another possibility is an RTP header extension. That, at least, > > would be backward compatible with non-MMH implementations. > > Whatever way has the least number of bytes is > probably the right answer. Packetcable's only > incurs the cost of the MAC itself since there is > an agreement between the sender and receiver that > there be the MAC tacked on to the end. Since it's > a trailer, it ought not effect a naive > implementation (though it would certainly violate > the "conservative in what you send" principle). Since RTP doesn't have a length field, a "naive" implementation would treat the MAC bytes as G.711 samples. Not good. > > I do sort of like the idea of the MAC being a > payload not entirely unlike a codec payload, > though I'm not wedded to the notion. It does have > the advantage that we can offer up the MAC "codec" > up in SDP m= as being something that the endpoint > is willing to receive. With RFC 2198, the sender > would then oblige by sending several different > "codecs", namely the real codec and the MAC at the > same time. My major concern with this is that there's a fair amount of overhead just to get 2 or 4 bytes across. > > Mike -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 9 14:04:56 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17449 for ; Wed, 9 Feb 2000 14:04:56 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id EC3F352E0; Wed, 9 Feb 2000 14:01:36 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 4D87952E2; Wed, 9 Feb 2000 14:01:35 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 4B63952E0 for ; Wed, 9 Feb 2000 14:01:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 9 14:00:57 EST 2000 Received: from kickme.cisco.com ([198.92.30.42]) by dusty; Wed Feb 9 13:58:42 EST 2000 Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by kickme.cisco.com (8.9.1a/8.9.1) with ESMTP id KAA11764; Wed, 9 Feb 2000 10:50:55 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id LAA26055; Wed, 9 Feb 2000 11:00:03 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14497.47409.853886.712574@thomasm-u1.cisco.com> Date: Wed, 9 Feb 2000 11:00:01 -0800 (PST) To: Colin Perkins Cc: Henning Schulzrinne , Michael Thomas , "'SIP List'" , rem-conf@es.net Subject: Re: Question about media desinations In-Reply-To: <4160.950119407@cs.ucl.ac.uk> References: <38A1A378.469B6FE1@cs.columbia.edu> <4160.950119407@cs.ucl.ac.uk> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Colin Perkins writes: > --> Henning Schulzrinne writes: > >Michael Thomas wrote: > >> I do sort of like the idea of the MAC being a > >> payload not entirely unlike a codec payload, > >> though I'm not wedded to the notion. It does have > >> the advantage that we can offer up the MAC "codec" > >> up in SDP m= as being something that the endpoint > >> is willing to receive. With RFC 2198, the sender > >> would then oblige by sending several different > >> "codecs", namely the real codec and the MAC at the > >> same time. > > > >My major concern with this is that there's a fair amount of overhead > >just to get 2 or 4 bytes across. > > It's one more byte than using the RTP header extension..... > > Still, it may be better to define a new RTP profile which includes the > MAC as part of the fixed RTP header. That's probably the solution with > the least overhead, and the protocol definition can be straightforward > RFC1890 + 4 bytes of MAC header. Would that not lead to a combinatorial explosion of name space with rtpmap in SDP? Ie, G711-MMH2, etc? I'm all for having zero overhead, but not at the expense of making a mess of SDP. That is sort of why I was attracted to RFC 2198. If somebody else has a better way of doing the same thing without requiring, for example, structured names in SDP that would be great too. Mike From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 9 14:07:33 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17665 for ; Wed, 9 Feb 2000 14:07:32 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id DAC5752D5; Wed, 9 Feb 2000 14:01:37 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 38BF452E3; Wed, 9 Feb 2000 14:01:37 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 6A4CA52D5 for ; Wed, 9 Feb 2000 14:01:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Feb 9 11:53:51 EST 2000 Received: from mw.3com.com ([149.112.20.3]) by dusty; Wed Feb 9 11:51:36 EST 2000 Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation) id KAA03820; Wed, 9 Feb 2000 10:53:36 -0600 (CST) Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 86256880.005CE6CE ; Wed, 9 Feb 2000 10:54:43 -0600 X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Jerry Mahler" To: sip@lists.research.bell-labs.com Message-ID: <86256880.005CE532.00@mwgate02.mw.3com.com> Date: Wed, 9 Feb 2000 10:51:58 -0600 Subject: using RADIUS authentication for SIP requests Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Does anyone know of a way to authenticate SIP requests using a RADIUS server? Using a RADIUS server (which uses CHAP) to authenticate SIP requests that use BASIC authentication is not difficult. The SIP Server (user agent or proxy) can simply spoof a CHAP challenge and response based on the username and password contained in the SIP request's Authorization (or Proxy-Authorization) header and submit it to the RADIUS server. However, BASIC authentication is quite weak and therefore many implementations may not support it. Using a RADIUS server to authenticate SIP requests that use DIGEST authentication is impossible. This is because the method of producing the DIGEST response is very different from the method of producing the CHAP response. Therefore, a SIP Server (user agent or proxy) which receives a DIGEST challenge and response cannot spoof a CHAP challenge and response to a RADIUS server. Does anyone have a solution to this problem? Perhaps a new authentication mechanism (such as CHAP, in addition to BASIC and DIGEST) is in order? -Jerry From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 9 14:17:59 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18203 for ; Wed, 9 Feb 2000 14:17:58 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A4CE152E2; Wed, 9 Feb 2000 14:15:26 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1D98B52E3; Wed, 9 Feb 2000 14:15:26 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id B45B652E2 for ; Wed, 9 Feb 2000 14:15:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 9 12:07:22 EST 2000 Received: from sj-mailhub-3.cisco.com ([171.68.224.215]) by dusty; Wed Feb 9 12:05:07 EST 2000 Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id JAA25358; Wed, 9 Feb 2000 09:27:30 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA26012; Wed, 9 Feb 2000 09:06:19 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14497.40587.553748.584990@thomasm-u1.cisco.com> Date: Wed, 9 Feb 2000 09:06:19 -0800 (PST) To: Henning Schulzrinne Cc: Michael Thomas , "'SIP List'" , rem-conf@es.net Subject: Re: Question about media desinations In-Reply-To: <38A1946E.523D22D3@cs.columbia.edu> References: <20000208140607.A17103@div8.net> <000301bf727b$358f7080$ad9423a6@mcit.com> <14497.36973.637899.472650@thomasm-u1.cisco.com> <38A1946E.523D22D3@cs.columbia.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Henning Schulzrinne writes: > Michael Thomas wrote: > > > > The packetcable security spec specifies a 2 or 4 > > byte MAC (using MMH) to be appended to the RTP > > Is this simply hash(RTP packet | shared secret)? Yes. In packetcable, the payload is encrypted with RC4, but the MAC is applied to the entire RTP packet. > Could the bad guy record a conversation, including the hash, and then > mix in the old data with the "real" one? Not if you use the RTP timestamp. Built in replay protection :-) > > packet itself. I have argued that RFC 2198 might > > actually be a cleaner way to append the MAC > > itself, but so long as the parties agree to the > > payload format, a relatively weak MAC should make > > barge in sufficiently difficult that even if an > > attacker managed to get through every once in a > > while, they probably wouldn't do anything > > especially exciting. > > Since this is an RTP issue, I wonder if this shouldn't be written up for > avt. Another possibility is an RTP header extension. That, at least, > would be backward compatible with non-MMH implementations. Whatever way has the least number of bytes is probably the right answer. Packetcable's only incurs the cost of the MAC itself since there is an agreement between the sender and receiver that there be the MAC tacked on to the end. Since it's a trailer, it ought not effect a naive implementation (though it would certainly violate the "conservative in what you send" principle). I do sort of like the idea of the MAC being a payload not entirely unlike a codec payload, though I'm not wedded to the notion. It does have the advantage that we can offer up the MAC "codec" up in SDP m= as being something that the endpoint is willing to receive. With RFC 2198, the sender would then oblige by sending several different "codecs", namely the real codec and the MAC at the same time. Mike From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 9 14:31:54 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19132 for ; Wed, 9 Feb 2000 14:31:51 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id E08C852AB; Wed, 9 Feb 2000 14:29:20 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 596F152E3; Wed, 9 Feb 2000 14:29:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 2CDC952AB for ; Wed, 9 Feb 2000 14:29:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 9 14:27:23 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Wed Feb 9 14:25:09 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id OAA15405; Wed, 9 Feb 2000 14:15:34 -0500 (EST) Message-ID: <38A1BCD2.C4CC7160@cs.columbia.edu> Date: Wed, 09 Feb 2000 14:15:30 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas Cc: Colin Perkins , "'SIP List'" , rem-conf@es.net Subject: Re: Question about media desinations References: <38A1A378.469B6FE1@cs.columbia.edu> <4160.950119407@cs.ucl.ac.uk> <14497.47409.853886.712574@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > Would that not lead to a combinatorial explosion > of name space with rtpmap in SDP? Ie, G711-MMH2, No, not really, this designation would replace the RTP/AVP in SDP with something like RTP/AVP-MMH. The codec names would stay the same, since they are unaffected by this change. . > etc? I'm all for having zero overhead, but not at > the expense of making a mess of SDP. That is sort > of why I was attracted to RFC 2198. If somebody > else has a better way of doing the same thing > without requiring, for example, structured names > in SDP that would be great too. > > Mike -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 9 16:19:12 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24033 for ; Wed, 9 Feb 2000 16:19:10 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4FCC452D4; Wed, 9 Feb 2000 16:15:43 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8A67F52E6; Wed, 9 Feb 2000 16:15:42 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id EEA7552D4 for ; Wed, 9 Feb 2000 16:15:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Feb 9 16:13:51 EST 2000 Received: from elmls01.ce.mediaone.net ([24.131.128.25]) by dusty; Wed Feb 9 16:11:36 EST 2000 Received: from cybertron.div8.net (el01-24-131-149-38.ce.mediaone.net [24.131.149.38]) by elmls01.ce.mediaone.net (8.8.7/8.8.7) with ESMTP id PAA11168; Wed, 9 Feb 2000 15:16:23 -0600 (CST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.research.bell-labs.com; Wed, 9 Feb 2000 15:13:47 -0600 (CST) Date: Wed, 9 Feb 2000 15:13:47 -0600 From: "'Billy Biggs'" To: Robert Sparks Cc: "'Dean Willis'" , "'SIP List'" Subject: Specifying media source Message-ID: <20000209151347.A27233@div8.net> References: <20000208154204.A17839@div8.net> <003a01bf7334$f0d5cba0$8a9223a6@mcit.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <003a01bf7334$f0d5cba0$8a9223a6@mcit.com>; from Robert.Sparks@wcom.com on Wed, Feb 09, 2000 at 01:36:19PM -0600 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Robert Sparks (Robert.Sparks@wcom.com): > Billy - I agree with Dean that you should issue a new INVITE when you change > your source port/address. This only makes sense of course, if the INVITE > contains information about that source port/address. You claim such > information doesn't make sense in the context of SDP. Why not? I can see (yet > another) simple field addition to cover that for unicast sessions. I'm not > proposing that right now btw - but I do strongly believe that we need to make > the media source part of session negotiaton. This should be addressed now, in > parallel with the important encryption discussion. My understanding of SIP's use of SDP is that it is used strictly as an announcement of what you are willing to receive. To indicate any other information would be premature, since one can't speak objectively about the call in full until all signalling has been completed. I personally think it's important that SDP not be used as a negotiation protocol, since that would be well beyond the scope of the protocol. SIP definitely allows changing the media source address without updating either of the session descriptions, since they each only discuss the receiving end of the conversation. Therefore, the media source can change mid-call without an INVITE. This seems completely valid, and even 'clean'. Regardless, the purpose of indicating the source address of where media is invalidated by the simplicity of spoofing RTP. > Billy Biggs (vektor@div8.net) : > > Dean Willis (dean.willis@wcom.com): > > > > > I once pointed out that one solution would be to extend SDP to include > > > the source address. Of course, this could always be spoofed. > > > > Which SDP? Would my sipcaster, which just sends media, have to send SDP > > just to indicate where media would come from? A field like that wouldn't > > make sense in the context of SDP. > > > > It also wouldn't make sense in the context of SIP though, since SIP isn't > > meant to discuss the media at all. > > > > So, you're kinda screwed there too... There really isn't any place that > > you should put it... The only solution is crypto, which at this point > > seems too undefined for practical use. -- Billy Biggs vektor@div8.net http://www.div8.net/billy wbiggs@uwaterloo.ca From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 9 16:57:29 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24886 for ; Wed, 9 Feb 2000 16:57:27 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 80D0D52EF; Wed, 9 Feb 2000 16:52:39 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 0B9F952D6; Wed, 9 Feb 2000 16:52:37 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id F19B552E4 for ; Wed, 9 Feb 2000 14:41:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 9 14:40:24 EST 2000 Received: from PMESMTP02.wcom.com ([199.249.20.2]) by dusty; Wed Feb 9 14:38:09 EST 2000 Received: from omzrelay.mcit.com ([166.37.204.49]) by firewall.mcit.com (PMDF V5.2-32 #41713) with ESMTP id <0FPO00B4GHB7YM@firewall.mcit.com> for sip@lists.research.bell-labs.com; Wed, 9 Feb 2000 19:40:20 +0000 (GMT) Received: from omzmta04.mcit.com (omzmta04.mcit.com [166.37.194.122]) by omzrelay.mcit.com (8.8.7/) with ESMTP id TAA32700; Wed, 09 Feb 2000 19:40:10 +0000 (GMT) Received: from sipdev4 ([166.35.146.138]) by omzmta04.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000209193956.FVVX22989@sipdev4>; Wed, 09 Feb 2000 19:39:56 +0000 Date: Wed, 09 Feb 2000 13:36:19 -0600 From: Robert Sparks Subject: RE: Question about media desinations In-reply-to: <20000208154204.A17839@div8.net> To: "'Billy Biggs'" , "'Dean Willis'" Cc: "'Andrew Chalupka'" , "'SIP List'" Reply-To: Robert.Sparks@wcom.com Message-id: <003a01bf7334$f0d5cba0$8a9223a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit The SSRC may change even when the source does not. An RTP implementation is required to be prepared to do so in the case of SSRC collision detection. IIRC, there's nothing in the RTP spec to prevent an implementation from whimsically changing to a new SSRC at any time. Billy - I agree with Dean that you should issue a new INVITE when you change your source port/address. This only makes sense of course, if the INVITE contains information about that source port/address. You claim such information doesn't make sense in the context of SDP. Why not? I can see (yet another) simple field addition to cover that for unicast sessions. I'm not proposing that right now btw - but I do strongly believe that we need to make the media source part of session negotiaton. This should be addressed now, in parallel with the important encryption discussion. RjS > -----Original Message----- > From: owner-sip@lists.research.bell-labs.com > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of > Billy Biggs > Sent: Tuesday, February 08, 2000 3:42 PM > To: Dean Willis > Cc: Andrew Chalupka; 'SIP List' > Subject: Re: Question about media desinations > > > Dean Willis (dean.willis@wcom.com): > > > > So, what's stopping a haxor like me from strobbing a > gateway with random > > > audio... ?? > > > > This came up in the SIP security design team. > > > > We have some hope that the receiver can pay attention to > the SSRC and > > discard your spam. Of course, if you can guess the SSRC, > you can get in. > > Well, I don't think you can count on the SSRC being > constant throughout the > call. Why can't I stop sending audio from one source and > begin sending it from > another with a different SSRC? It wouldn't violate the > context of the SIP call > if I'm still receiving media at the address I specified in my SDP. > > > I once pointed out that one solution would be to extend SDP > to include the > > source address. Of course, this could always be spoofed. > > Which SDP? Would my sipcaster, which just sends media, > have to send SDP just > to indicate where media would come from? A field like that > wouldn't make sense > in the context of SDP. > > It also wouldn't make sense in the context of SIP though, > since SIP isn't > meant to discuss the media at all. > > So, you're kinda screwed there too... There really isn't > any place that you > should put it... The only solution is crypto, which at this > point seems too > undefined for practical use. > > -- > Billy Biggs vektor@div8.net > http://www.div8.net/billy wbiggs@uwaterloo.ca > From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 9 19:20:00 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27793 for ; Wed, 9 Feb 2000 19:20:00 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 53A9452C4; Wed, 9 Feb 2000 19:17:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C100952DB; Wed, 9 Feb 2000 19:17:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 4681152C4 for ; Wed, 9 Feb 2000 19:17:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 9 19:15:07 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Wed Feb 9 19:12:52 EST 2000 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: 1Cust81.tnt2.freehold.nj.da.uu.net [63.17.114.81]) id QQibsi09114; Thu, 10 Feb 2000 00:14:54 GMT Message-ID: <38A203C0.9CCDF597@dynamicsoft.com> Date: Wed, 09 Feb 2000 19:18:08 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert.Sparks@wcom.com Cc: "'Billy Biggs'" , "'Dean Willis'" , "'Andrew Chalupka'" , "'SIP List'" Subject: Re: Question about media desinations References: <003a01bf7334$f0d5cba0$8a9223a6@mcit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Robert Sparks wrote: > > The SSRC may change even when the source does not. An RTP > implementation is required to be prepared to do so in the > case of SSRC collision detection. IIRC, there's nothing > in the RTP spec to prevent an implementation from whimsically > changing to a new SSRC at any time. > > Billy - I agree with Dean that you should issue a new INVITE when > you change your source port/address. This only makes sense > of course, if the INVITE contains information about that source > port/address. You claim such information doesn't make sense > in the context of SDP. Why not? I can see (yet another) simple field > addition to cover that for unicast sessions. I'm not proposing that > right now btw - but I do strongly believe that we need to make the > media source part of session negotiaton. This should be addressed > now, in parallel with the important encryption discussion. I'm not clear on whether the source port and address are really needed. I thought that firewalls allowed rules without exact values for the 5-tuples. Certainly you'll need that for other applications - for example, getting http out through a firewall via an internal proxy. In that case, your rule only specifies a destination port and source IP address. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 9 19:34:09 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28143 for ; Wed, 9 Feb 2000 19:34:08 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id E73D352DB; Wed, 9 Feb 2000 19:31:33 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 623E852E3; Wed, 9 Feb 2000 19:31:32 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C222F52DB for ; Wed, 9 Feb 2000 19:31:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 9 19:30:47 EST 2000 Received: from elektron.elka.pw.edu.pl ([148.81.63.249]) by dusty; Wed Feb 9 19:28:32 EST 2000 Received: from pb34.warszawa.ppp.tpnet.pl ([212.160.53.34]:1292 "EHLO elka.pw.edu.pl") by elektron.elka.pw.edu.pl with ESMTP id ; Thu, 10 Feb 2000 01:30:32 +0100 Message-ID: <38A20650.8B64F137@elka.pw.edu.pl> Date: Thu, 10 Feb 2000 01:29:04 +0100 From: "Piotr S. Kossowski" Organization: PW - =?ISO-8859-2?Q?Wydzia=B3?= Elektroniki i Technik Informacyjnych - Instytut Telekomunikacji X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Subject: Expiration of draft-ietf-mmusic-sip-new-00.ps Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Good Morning! When and where Is Going to appear new version of draft-ietf-mmusic-sip-new-00.ps? I'v got it and Date of Expiration is February 2000 ? Best Wishes, Piotr Kossowski From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 9 20:22:05 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29106 for ; Wed, 9 Feb 2000 20:21:58 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 9903352DC; Wed, 9 Feb 2000 20:19:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1487452E4; Wed, 9 Feb 2000 20:19:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id BDAE552DC for ; Wed, 9 Feb 2000 20:19:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Feb 9 20:19:02 EST 2000 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by dusty; Wed Feb 9 20:16:47 EST 2000 Received: from fokus.gmd.de (jobe [193.175.132.219]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id CAA00342; Thu, 10 Feb 2000 02:17:36 +0100 (MET) Message-ID: <38A211DC.2E6734B4@fokus.gmd.de> Date: Thu, 10 Feb 2000 02:18:20 +0100 From: Jiri Kuthan Organization: GMD Fokus X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Robert.Sparks@wcom.com, "'Billy Biggs'" , "'Dean Willis'" , "'Andrew Chalupka'" , "'SIP List'" Subject: Re: Question about media desinations References: <003a01bf7334$f0d5cba0$8a9223a6@mcit.com> <38A203C0.9CCDF597@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Robert Sparks wrote: > > > > The SSRC may change even when the source does not. An RTP > > implementation is required to be prepared to do so in the > > case of SSRC collision detection. IIRC, there's nothing > > in the RTP spec to prevent an implementation from whimsically > > changing to a new SSRC at any time. > > > > Billy - I agree with Dean that you should issue a new INVITE when > > you change your source port/address. This only makes sense > > of course, if the INVITE contains information about that source > > port/address. You claim such information doesn't make sense > > in the context of SDP. Why not? I can see (yet another) simple field > > addition to cover that for unicast sessions. I'm not proposing that > > right now btw - but I do strongly believe that we need to make the > > media source part of session negotiaton. This should be addressed > > now, in parallel with the important encryption discussion. > > I'm not clear on whether the source port and address are really needed. > I thought that firewalls allowed rules without exact values for the > 5-tuples. Certainly you'll need that for other applications - for > example, getting http out through a firewall via an internal proxy. In > that case, your rule only specifies a destination port and source IP > address. > > -Jonathan R. Jonathan, it is not a matter of what the firewall allows you to do but what you want them to do. (Most state-of-the-art routers support arbitrary filtering policies. The filtering rules may be based on any subset of src/dst port/address, protocol and even more. I guess that you can even parse deeper and for example, investigate RTP sequence numbers. Of course, the processing overhead grows with number of filtering rules and number of investigated header fields.) Dean's motivation behind indicating sender's port numbers in SIP/SDP (sorry if I misunderstood) is the most restrictive filtering policy 'default-deny-explicit-permit', where the explicit permissions are dynamically controlled by a SIP/SDP-aware entity and describe an authorized IP stream by the 5-tuples. (BTW, could anyone point out a study on how the processing overhead scales with the number of rules?) If the source port number and address of the session flows entering the firewall from the Internet are unknown to the SIP/SDP entity, they cannot be included in the filtering rule and then the firewall allows packets with any source addresses/ports (i.e. even those that do not belong to the session) to reach the receiver. This can be fixed by including source address/port in SIP/SDP, although as Billy pointed out, packets with spoofed src address/port may still fool the firewall. Jiri -- Jiri Kuthan Phone: ++49 / (0)30 / 3463 - 7 271 GMD FOKUS Fax : ++49 / (0)30 / 3463 - 8 271 Kaiserin-Augusta-Allee 31 E-Mail : kuthan@fokus.gmd.de D-10589 Berlin, Germany WWW : http://www.fokus.gmd.de/usr/kuthan From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 10 00:40:20 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04121 for ; Thu, 10 Feb 2000 00:40:20 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 2AE2952BB; Thu, 10 Feb 2000 00:35:47 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 64A5152C8; Thu, 10 Feb 2000 00:35:46 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id ECEF052BB for ; Thu, 10 Feb 2000 00:35:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Feb 10 00:33:23 EST 2000 Received: from ns.fmmo.ca ([207.253.160.156]) by dusty; Thu Feb 10 00:31:08 EST 2000 Received: from localhost (fm-listproc@localhost) by ns.fmmo.ca (8.9.3/8.9.3) with ESMTP id AAA30122; Thu, 10 Feb 2000 00:42:39 -0500 Date: Thu, 10 Feb 2000 00:42:38 -0500 (EST) From: Francois Menard List Account To: Denis.Dagenais@nokia.com Cc: sip@lists.research.bell-labs.com Subject: Re: SIP Stacks In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Mediatrix -=Francois=- On Thu, 3 Feb 2000 Denis.Dagenais@nokia.com wrote: > I need to know, who has SIP stacks (available) that include User Agents and > Proxies > > > Denis Dagenais > From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 10 09:58:59 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28885 for ; Thu, 10 Feb 2000 09:58:57 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 5E0A052BB; Thu, 10 Feb 2000 09:55:38 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id AABEC52C4; Thu, 10 Feb 2000 09:55:37 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 3016C52BB for ; Thu, 10 Feb 2000 09:55:09 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 10 09:53:26 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Thu Feb 10 09:51:09 EST 2000 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.56]) id QQibup28179; Thu, 10 Feb 2000 14:53:16 GMT Message-ID: <38A2D1A9.BBB6C889@dynamicsoft.com> Date: Thu, 10 Feb 2000 09:56:41 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jiri Kuthan Cc: Robert.Sparks@wcom.com, "'Billy Biggs'" , "'Dean Willis'" , "'Andrew Chalupka'" , "'SIP List'" Subject: Re: Question about media desinations References: <003a01bf7334$f0d5cba0$8a9223a6@mcit.com> <38A203C0.9CCDF597@dynamicsoft.com> <38A211DC.2E6734B4@fokus.gmd.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jiri Kuthan wrote: > > If the source port number and address of the session flows > entering the firewall from the Internet are unknown to the SIP/SDP > entity, they cannot be included in the filtering rule and then > the firewall allows packets with any source addresses/ports > (i.e. even those that do not belong to the session) to reach the > receiver. > > This can be fixed by including source address/port in SIP/SDP, although > as Billy pointed out, packets with spoofed src address/port may still > fool the firewall. I see. Another difficulty with sending the source IP address in SDP is that we break one of the very nice features of RTP, the independence of user association from IP address. I recognize the desire for increased security (especially in light of the recent attacks against ebay, yahoo, etc.), but I am wondering if adding this to SDP really buys you much. Without this, an attacker must still guess the destination IP address for media and the destination port and a time during which a call is active. Adding the source means it must also guess that. Is it enough extra? -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 10 10:32:05 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00833 for ; Thu, 10 Feb 2000 10:32:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 8668852AB; Thu, 10 Feb 2000 10:29:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id F162352C4; Thu, 10 Feb 2000 10:29:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 6764752AB for ; Thu, 10 Feb 2000 10:29:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 10 10:28:56 EST 2000 Received: from gwu.ericy.com ([208.196.3.162]) by dusty; Thu Feb 10 10:26:39 EST 2000 Received: from mr4.exu.ericsson.se (mr4u.ericy.com [208.238.116.99]) by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id JAA10497; Thu, 10 Feb 2000 09:28:49 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id JAA28809; Thu, 10 Feb 2000 09:28:49 -0600 (CST) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA29068; Thu, 10 Feb 2000 09:28:48 -0600 (CST) Received: (from exuadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id JAA02712; Thu, 10 Feb 2000 09:28:47 -0600 (CST) Message-Id: <200002101528.JAA02712@b04a24.exu.ericsson.se> Subject: Re: When to send 183? To: ssubbara@cisco.com (Srinath Subbarayan) Date: Thu, 10 Feb 2000 09:28:47 -0600 (CST) Cc: hgs@cs.columbia.edu, jdrosen@dynamicsoft.com, sip@lists.research.bell-labs.com In-Reply-To: <38A26FDC.C713EA51@cisco.com> from "Srinath Subbarayan" at Feb 09, 2000 11:59:25 PM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit >In "draft-ietf-sip-183-00.txt", one of the sections reads as follows: > >"5.11.6. Callee Needs Early Media > > When the called UA receives an(d) INVITE message that results in the > need to report on the status of the media setup through a media > stream, the called UA has the option to send a 183 message with a > session description to the calling UA." > >If the called UA happens to be a PSTN gateway, on what basis will it >determine >if there is a need to report on the status of the media setup (and >hence, send a >183, as opposed to sending the usual 180 ringing)? You would use the 183 only if you: a) Are able to determine that the audio being generated is certainly *not* ringing (e.g. "comfort tone" or "pay tone" as defined in E.18x), or b) Are unable to definitively determine that alerting is occuring. This really should only happen with older CAS protocols. ISUP and ISDN have sufficient information to determine what is happening on the far end. You can also use 183 if you are able to determine that an error has occured, but that there is a tone or announcement accompanying it (e.g. an ACM with a cause code present), you can send a 183 to set up the media for the announcement (ideally with the announcement text as the text string), wait for a timer (on the order of ~30 seconds), and then send an appropriate SIP error message. -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 10 10:50:58 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01597 for ; Thu, 10 Feb 2000 10:50:57 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 0864F52B6; Thu, 10 Feb 2000 10:47:37 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 7845352D4; Thu, 10 Feb 2000 10:47:36 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id C1AE252B6 for ; Thu, 10 Feb 2000 10:47:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Feb 10 10:46:16 EST 2000 Received: from PMESMTP02.wcom.com ([199.249.20.2]) by dusty; Thu Feb 10 10:43:58 EST 2000 Received: from ndcrelay.mcit.com ([166.37.172.49]) by firewall.mcit.com (PMDF V5.2-32 #41713) with ESMTP id <0FPQ00H6B14N2W@firewall.mcit.com> for sip@lists.research.bell-labs.com; Thu, 10 Feb 2000 15:46:00 +0000 (GMT) Received: from omta3.mcit.com (omta3.mcit.com [166.37.204.5]) by ndcrelay.mcit.com (8.8.7/) with ESMTP id PAA07788; Thu, 10 Feb 2000 15:46:08 +0000 (GMT) Received: from sipdev4 ([166.35.146.138]) by omta3.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000210154604.SUAE631@sipdev4>; Thu, 10 Feb 2000 15:46:04 +0000 Date: Thu, 10 Feb 2000 09:42:10 -0600 From: Robert Sparks Subject: 481 response to an unknown tag To: "'SIP List' (E-mail)" Cc: "Henning Schulzrinne (E-mail)" Reply-To: Robert.Sparks@wcom.com Message-id: <003301bf73dd$65951920$8a9223a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit I want to call implementers attention situations like this. User agent A receives the following message having no previous knowledge of the contained Call-ID, To, or From. Agent A INVITE A@there | To: A@there;tag=abcd | From: B@here | Call-ID: 42@here | -------------------------->| A MUST respond to this with a 481 Call Leg/Transaction Does Not Exist. A MUST NOT create a new call leg using the given tag (or multiple endpoints of a forked request will end up sharing a tag, defeating its purpose). Implementers should also take care not to blindly append a tag to the To: line when receiving a request for an unknown Call-ID (rendering something like To: A@there;tag=abcd;tag=1234 in the response). I propose this clarification to the last paragraph of section 10.1.1: "If the Call-ID was not found, the To: field is inspected for a tag parameter. The server rejects the request if a tag is present. Otherwise, a new call leg is created, with entries for the To, From and Call-ID headers. The server returns a response containing the same To value, but with a unique tag added. The tag MAY be omitted if the request contained only one Via header field." From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 10 10:54:02 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01751 for ; Thu, 10 Feb 2000 10:53:59 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id B081752D5; Thu, 10 Feb 2000 10:47:42 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id EF87252C8; Thu, 10 Feb 2000 10:47:37 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 7DB6A52C8 for ; Thu, 10 Feb 2000 10:47:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 10 10:45:09 EST 2000 Received: from PMESMTP01.wcom.com ([199.249.20.1]) by dusty; Thu Feb 10 10:42:51 EST 2000 Received: from omzrelay.mcit.com ([166.37.204.49]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FPQ00LEC12THG@firewall.mcit.com> for sip@lists.research.bell-labs.com; Thu, 10 Feb 2000 15:44:54 +0000 (GMT) Received: from omta3.mcit.com (omta3.mcit.com [166.37.204.5]) by omzrelay.mcit.com (8.8.7/) with ESMTP id PAA21898; Thu, 10 Feb 2000 15:44:51 +0000 (GMT) Received: from sipdev4 ([166.35.146.138]) by omta3.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000210154503.STUS631@sipdev4>; Thu, 10 Feb 2000 15:45:03 +0000 Date: Thu, 10 Feb 2000 09:41:09 -0600 From: Robert Sparks Subject: UAC use of tags received in responses To: "'SIP List' (E-mail)" Cc: "Henning Schulzrinne (E-mail)" Reply-To: Robert.Sparks@wcom.com Message-id: <003201bf73dd$40e24300$8a9223a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Currently, a proxy is required to add a tag to a response it generates locally if the request did not contain one. A UAC is required to use tags it sees in final responses (creating legs for each unique tag received) in subsequent requests to that leg. Taken together, these requirements destroy call progress in the case of a 407 (and several other responses a proxy might generate that shouldn't necessarily clobber call progress, such as 500, 503, 504, 305, 400, 411, 413, maybe even 408). Consider the following: UA A Proxy UA B | INVITE | | | To: B | | | From: A | | | CallID: 1 | | | CSeq: 1 INVITE | |-------------->| | | | | | 407 | | | To: B;tag=1 | | | From: A | | | CallID: 1 | | | CSeq: 1 INVITE | |<--------------| | | | | | ACK | | | To: B;tag=1 | | | From: A | | | CallID: 1 | | | CSeq: 1 ACK | | |-------------->| | | | | | INVITE | | | To: B;tag=1 | | | From:A | | | (appropriate credentials) | | CallID: 1 | | | CSeq: 2 INVITE | |-------------->| | | | | | | INVITE | | | To: B;tag=1| | | From: A | | | CallID: 1 | | | CSeq: 2 INVITE | |----------->| B MUST respond now with a 481 Call Leg/Transaction Does Not Exist - There is no legal way for the session to be successfully established. One of the two requirements above must be modified to allow for this scenario. Changing the requirement on the proxy, having it not add tags for some or all locally generated responses, leads to problems determining the appropriate destination for the subsequent ACK (pointed out by Jonathan Rosenberg). The better solution then (suggested by both Jonathan and Alan Johnston) is to modify the behavior of the UAC such that: A UAC only copies a tag into subsequent requests if it arrives in a 200 OK to an INVITE. So, in the above sequence, the CSeq: 2 INVITE would have no tag. Unless discussion here uncovers a problem with this approach, I propose adding the above sentence to section 11.3 and changing the sentence in Section 6.41 To: from All subsequent transactions between two entities MUST include the "tag" parameter, as described in Section 11. to Section 11 details when the "tag" parameter MUST appear in subsequent requests. NOTE that even though a UAC doesn't use a tag it sees in non-200 responses in subsequent requests, an implementation may need to keep them as part of transaction state. An example is being able to associate 183s with 200s on a forked INVITE. RjS From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 10 11:28:04 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03016 for ; Thu, 10 Feb 2000 11:28:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 3AC0852C8; Thu, 10 Feb 2000 11:25:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A7CE852D4; Thu, 10 Feb 2000 11:25:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 3FF6452C8 for ; Thu, 10 Feb 2000 11:25:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 10 11:24:19 EST 2000 Received: from mail.pingtel.com ([216.91.1.131]) by dusty; Thu Feb 10 11:22:01 EST 2000 Received: from pingtel.com (cdhcp189.pingtel.com [10.1.1.189]) by mail.pingtel.com (8.9.3/8.9.3) with ESMTP id LAA07908; Thu, 10 Feb 2000 11:12:37 -0500 Message-ID: <38A2E5D2.ECE703C4@pingtel.com> Date: Thu, 10 Feb 2000 11:22:42 -0500 From: "Daniel G. Petrie" Organization: Pingtel Corp. http://www.pingtel.com X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Adam B. Roach" Cc: Srinath Subbarayan , hgs@cs.columbia.edu, jdrosen@dynamicsoft.com, sip@lists.research.bell-labs.com Subject: Re: When to send 183? References: <200002101528.JAA02712@b04a24.exu.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit I agree with a) and b). Forgive me as I have not kept up with the lastest on the 183 draft, but I would argue that if it is known that an error has occured, that a 3xx, 4xx or 5xx code should be used. Not telling the UA of a known error, prevents it from handling the call in a means best suited for the user. If we need a two stage error to frame the error media stream then, I would argue that we need a 18x status that means an error is about to occur. 183 should only be used when it is impossible to tell the out come of the call setup. Using 183 when a known error has occured blinds the UA unnecessarily. "Adam B. Roach" wrote: > >In "draft-ietf-sip-183-00.txt", one of the sections reads as follows: > > > >"5.11.6. Callee Needs Early Media > > > > When the called UA receives an(d) INVITE message that results in the > > need to report on the status of the media setup through a media > > stream, the called UA has the option to send a 183 message with a > > session description to the calling UA." > > > >If the called UA happens to be a PSTN gateway, on what basis will it > >determine > >if there is a need to report on the status of the media setup (and > >hence, send a > >183, as opposed to sending the usual 180 ringing)? > > You would use the 183 only if you: > > a) Are able to determine that the audio being generated > is certainly *not* ringing (e.g. "comfort tone" or > "pay tone" as defined in E.18x), or > > b) Are unable to definitively determine that alerting > is occuring. This really should only happen with older > CAS protocols. ISUP and ISDN have sufficient information > to determine what is happening on the far end. > > You can also use 183 if you are able to determine that an error > has occured, but that there is a tone or announcement accompanying > it (e.g. an ACM with a cause code present), you can send a 183 > to set up the media for the announcement (ideally with the > announcement text as the text string), wait for a timer (on the > order of ~30 seconds), and then send an appropriate SIP error > message. > > -- > Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 > adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 10 12:06:00 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04264 for ; Thu, 10 Feb 2000 12:05:59 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 3C25A52D6; Thu, 10 Feb 2000 12:03:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id AEC7652DA; Thu, 10 Feb 2000 12:03:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id D52CB52D6 for ; Thu, 10 Feb 2000 12:03:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 10 12:01:25 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Thu Feb 10 11:59:07 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA06053; Thu, 10 Feb 2000 11:59:43 -0500 (EST) Message-ID: <38A2EE7C.B35AF762@cs.columbia.edu> Date: Thu, 10 Feb 2000 11:59:40 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Adam B. Roach" Cc: Srinath Subbarayan , sip@lists.research.bell-labs.com Subject: Re: When to send 183? References: <200002101528.JAA02712@b04a24.exu.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit "Adam B. Roach" wrote: > > You would use the 183 only if you: > > a) Are able to determine that the audio being generated > is certainly *not* ringing (e.g. "comfort tone" or > "pay tone" as defined in E.18x), or > > b) Are unable to definitively determine that alerting > is occuring. This really should only happen with older > CAS protocols. ISUP and ISDN have sufficient information > to determine what is happening on the far end. > > You can also use 183 if you are able to determine that an error > has occured, but that there is a tone or announcement accompanying > it (e.g. an ACM with a cause code present), you can send a 183 > to set up the media for the announcement (ideally with the > announcement text as the text string), wait for a timer (on the > order of ~30 seconds), and then send an appropriate SIP error > message. There seem to be two somewhat separate cases: - progress tones and announcements - failure tones and announcements In either case, the receiver may or may not care to hear them. (I don't think current telemarketing systems are smart enough to have a voice recognition system translate "The number you have dialed is no longer in service. The new number is ..." into a database update...) Particularly for failure indications, it would seem to be preferable to simply say "give me the error code (even if it's just "failure for unknown reason") and spare me the phone lady". I suppose one way to solve this is to only include the "Supported" header for this feature for non-robots. I believe we had discussed as one alternative for the failure case a 20x variation that says "you haven't reached the real person, but here's a robot; BYE it if you'd rather not talk to one". A potential problem with the current solution is that some messages are infinite-length (repeating), say for number change messages. You don't just want to cut off after 30 seconds, since I may need to run to fetch a pencil... -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 10 13:02:08 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06012 for ; Thu, 10 Feb 2000 13:02:08 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 57E6352BB; Thu, 10 Feb 2000 12:59:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A729C52D4; Thu, 10 Feb 2000 12:59:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id A22E552BB for ; Thu, 10 Feb 2000 12:59:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 10 12:57:26 EST 2000 Received: from gwu.ericy.com ([208.196.3.162]) by dusty; Thu Feb 10 12:55:09 EST 2000 Received: from mr3.exu.ericsson.se (mr3u.ericy.com [208.238.116.100]) by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id LAA06173; Thu, 10 Feb 2000 11:57:14 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id LAA15296; Thu, 10 Feb 2000 11:57:14 -0600 (CST) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA08004; Thu, 10 Feb 2000 11:57:13 -0600 (CST) Received: (from exuadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id LAA03457; Thu, 10 Feb 2000 11:57:12 -0600 (CST) Message-Id: <200002101757.LAA03457@b04a24.exu.ericsson.se> Subject: Re: When to send 183? To: dpetrie@pingtel.com (Daniel G. Petrie) Date: Thu, 10 Feb 2000 11:57:12 -0600 (CST) Cc: ssubbara@cisco.com (Srinath Subbarayan), hgs@cs.columbia.edu, jdrosen@dynamicsoft.com, sip@lists.research.bell-labs.com In-Reply-To: <38A2E5D2.ECE703C4@pingtel.com> from "Daniel G. Petrie" at Feb 10, 2000 11:22:42 AM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit >Forgive me as I have not kept up with the lastest on the 183 >draft, but I would argue that if it is known that an error has >occured, that a 3xx, 4xx or 5xx code should be used. Not telling the >UA of a known error, prevents it from handling the call in a means >best suited for the user. If we need a two stage error to frame >the error media stream then, I would argue that we need a 18x >status that means an error is about to occur. > >183 should only be used when it is impossible to tell the out come >of the call setup. Using 183 when a known error has occured >blinds the UA unnecessarily. But it's not a violation of the protocol. It's an implementation issue. You can design your gateways as you see fit, for the purposes of your customers. You can even make it configurable or based on the particular call (e.g. send pre-failure media only for queries from hosts who have sent me ISUP bodies). Addressing the utility of pre-failure media: if the call is going from PSTN to PSTN with a SIP transit network (possibly providing services), the *media* indication of failure is very important. I don't want a reorder tone when some machine off in the network is helpfully announcing my friend's new phone number. On the other hand, If you're terminating at a native client, they'll want an error code instead (or possibly a 301, as in the above case). My intention was not to tell anyone how the protocol must be used; I meant to inform what it allows you to do. I assume that anyone designing a PSTN gateway has done enough analysis to determine what behavior is appropriate to meet the requirements of their particular customers. -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 10 13:14:09 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06362 for ; Thu, 10 Feb 2000 13:14:08 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 88E2D52DA; Thu, 10 Feb 2000 13:11:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E5EFF52DB; Thu, 10 Feb 2000 13:11:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id B25FF52DA for ; Thu, 10 Feb 2000 13:11:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 10 13:09:52 EST 2000 Received: from gwa.ericsson.com ([198.215.127.2]) by dusty; Thu Feb 10 13:07:30 EST 2000 Received: from mr4.exu.ericsson.se (mr4a.ericsson.com [198.215.127.160]) by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id MAA17683; Thu, 10 Feb 2000 12:09:45 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id MAA01187; Thu, 10 Feb 2000 12:09:44 -0600 (CST) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA08512; Thu, 10 Feb 2000 12:09:43 -0600 (CST) Received: (from exuadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id MAA03521; Thu, 10 Feb 2000 12:09:42 -0600 (CST) Message-Id: <200002101809.MAA03521@b04a24.exu.ericsson.se> Subject: Re: When to send 183? To: schulzrinne@cs.columbia.edu (Henning Schulzrinne) Date: Thu, 10 Feb 2000 12:09:42 -0600 (CST) Cc: ssubbara@cisco.com (Srinath Subbarayan), sip@lists.research.bell-labs.com In-Reply-To: <38A2EE7C.B35AF762@cs.columbia.edu> from "Henning Schulzrinne" at Feb 10, 2000 11:59:40 AM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit >There seem to be two somewhat separate cases: > >- progress tones and announcements > >- failure tones and announcements > >In either case, the receiver may or may not care to hear them. (I don't >think current telemarketing systems are smart enough to have a voice >recognition system translate "The number you have dialed is no longer in >service. The new number is ..." into a database update...) They wouldn't necessarily need to. For ISUP, the ACM message in these circumstances contains a release code of 22 (Number Changed), along with a new number. Whether current telemarketing systems utilize this information is another issue altogether -- one that I have no knowledge about. Getting back on topic... It seems a bit odd that a caller wouldn't want to know about the progress tones (e.g. ringing, "your call has been queued," "your call is being forwarded to a phone outside company premises" [which I beleive may be a legal requirement in some circumstances]). I agree that native clients may not want to know about failure announcements (and certainly wouldn't want to hear failure tones). However, as I argued in my previous message, there is a definite utility to transiting this information between gateways under certain circumstances. The protocol and 183 extension don't currently prohibit this behavior; doing so would cripple the extension for a whole class of PSTN interoperation issues. -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 10 14:12:28 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07968 for ; Thu, 10 Feb 2000 14:12:18 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id DABF152C4; Thu, 10 Feb 2000 14:09:20 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 5E5ED52D4; Thu, 10 Feb 2000 14:09:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 5EA7252C4 for ; Thu, 10 Feb 2000 14:09:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Feb 10 14:08:29 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Thu Feb 10 14:06:11 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id OAA28058; Thu, 10 Feb 2000 14:08:04 -0500 (EST) Message-ID: <38A30C91.ED8433EC@cs.columbia.edu> Date: Thu, 10 Feb 2000 14:08:01 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Robert.Sparks@wcom.com Cc: "'SIP List' (E-mail)" Subject: Re: 481 response to an unknown tag References: <003301bf73dd$65951920$8a9223a6@mcit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit I've updated the draft accordingly, with minor editorial changes. Thanks. Robert Sparks wrote: > > I want to call implementers attention situations like this. User agent A > receives the following message having no previous knowledge of the contained > Call-ID, To, or From. > > Agent > A > INVITE A@there | > To: A@there;tag=abcd | > From: B@here | > Call-ID: 42@here | > -------------------------->| > > A MUST respond to this with a 481 Call Leg/Transaction Does Not Exist. > > A MUST NOT create a new call leg using the given tag (or multiple endpoints > of a forked request will end up sharing a tag, defeating its purpose). > Implementers should also take care not to blindly append a tag to the To: > line when receiving a request for an unknown Call-ID (rendering something > like To: A@there;tag=abcd;tag=1234 in the response). > > I propose this clarification to the last paragraph of section 10.1.1: > > "If the Call-ID was not found, the To: field is inspected for a tag > parameter. The server rejects the request if a tag is present. Otherwise, > a new call leg is created, with entries for the To, From and Call-ID > headers. The server returns a response containing the same To value, but > with a unique tag added. The tag MAY be omitted if the request contained > only one Via header field." -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 10 14:36:13 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08559 for ; Thu, 10 Feb 2000 14:36:07 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id CD3DD52D4; Thu, 10 Feb 2000 14:33:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 5709E52D6; Thu, 10 Feb 2000 14:33:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C5FE052D4 for ; Thu, 10 Feb 2000 14:33:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 10 14:31:47 EST 2000 Received: from repulse.cnchost.com ([207.155.248.4]) by dusty; Thu Feb 10 14:29:29 EST 2000 Received: from vovida.com (w178.z216112071.sjc-ca.dsl.cnc.net [216.112.71.178]) by repulse.cnchost.com id OAA14292; Thu, 10 Feb 2000 14:31:43 -0500 (EST) [ConcentricHost SMTP Relay 1.8] Message-ID: <38A312DB.C0588855@vovida.com> Date: Thu, 10 Feb 2000 11:34:51 -0800 From: Jeff Gao Organization: Vovida Networks X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.9 i686) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Subject: INFO message References: <003301bf73dd$65951920$8a9223a6@mcit.com> <38A30C91.ED8433EC@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit I have two questions with regard to the propsed INFO message. Let's say A and B are two UAs. 1. A calls B 2. A sends B an Info message. Its callleg looks like the following: From: A To: B Call-ID: xxxxxx 3. B receives the info message, compares the callleg with existing callleg and accepts the info message 4. B then sends A an info message that looks like the following: From: B To: A Call-ID: xxxxxx 5. A receives the message and compares the callleg. The existing callleg known to A has the To and From field fliped from the To and From field in the info message A received from B. In this case, the INFO message spec requires A to reject B's info message with a "481 Call Leg/Transaction Does Not Exit" response. My questions are: a. is my interpretation of the INFO message spec correct? b. If my interpretation is correct, then how do I send INFO message from B to A? Thanks in advance for any help. Best Regards, Jeff Gao From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 10 14:55:54 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08873 for ; Thu, 10 Feb 2000 14:55:51 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id D36D052DC; Thu, 10 Feb 2000 14:53:19 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6C98152DB; Thu, 10 Feb 2000 14:53:18 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 84A9B52DB for ; Thu, 10 Feb 2000 14:53:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 10 14:52:31 EST 2000 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by dusty; Thu Feb 10 14:50:14 EST 2000 Received: from fokus.gmd.de (jobe [193.175.132.219]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id UAA24398; Thu, 10 Feb 2000 20:51:04 +0100 (MET) Message-ID: <38A316D5.BF0CA2E@fokus.gmd.de> Date: Thu, 10 Feb 2000 20:51:49 +0100 From: Jiri Kuthan Organization: GMD Fokus X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Robert.Sparks@wcom.com, "'Billy Biggs'" , "'Dean Willis'" , "'Andrew Chalupka'" , "'SIP List'" Subject: Re: Question about media desinations References: <003a01bf7334$f0d5cba0$8a9223a6@mcit.com> <38A203C0.9CCDF597@dynamicsoft.com> <38A211DC.2E6734B4@fokus.gmd.de> <38A2D1A9.BBB6C889@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > Another difficulty with sending the source IP address in SDP is that we > break one of the very nice features of RTP, the independence of user > association from IP address. > > I recognize the desire for increased security (especially in light of > the recent attacks > against ebay, yahoo, etc.), but I am wondering if adding this to SDP > really buys you > much. Without this, an attacker must still guess the destination IP > address for media and > the destination port and a time during which a call is active. Adding > the source means it must also guess that. Is it enough extra? In general, packet filtering reduces the security risks. The more precise the rules the lower the risk. However, even if very precise rules are deployed, spoofing cannot be prevented unless a kind of packet authorization based on a cryptographic method is used. For example, a MAC covering the relevant header fields would have to be included in every packet. The MAC secret key could be signaled with SIP. The questions I see are: 1) Does the benefit of more precise rules justify including the source address/port in SDP? (rewording of what Jonathan asked) 2) Does the packet authorization make sense? Can its computational and bandwidth overhead be kept low? Can be some existing work reused? Are we going to focus on this problem? Jiri From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 10 15:24:03 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09687 for ; Thu, 10 Feb 2000 15:24:00 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 2205352DD; Thu, 10 Feb 2000 15:21:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8127452DE; Thu, 10 Feb 2000 15:21:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id D295852DD for ; Thu, 10 Feb 2000 15:21:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 10 15:20:53 EST 2000 Received: from gwu.ericy.com ([208.196.3.162]) by dusty; Thu Feb 10 15:18:35 EST 2000 Received: from mr3.exu.ericsson.se (mr3u.ericy.com [208.238.116.100]) by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id OAA00066; Thu, 10 Feb 2000 14:20:49 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id OAA10479; Thu, 10 Feb 2000 14:20:49 -0600 (CST) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA15689; Thu, 10 Feb 2000 14:20:47 -0600 (CST) Received: (from exuadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id OAA03854; Thu, 10 Feb 2000 14:20:46 -0600 (CST) Message-Id: <200002102020.OAA03854@b04a24.exu.ericsson.se> Subject: Re: INFO message To: jgao@vovida.com (Jeff Gao) Date: Thu, 10 Feb 2000 14:20:45 -0600 (CST) Cc: sip@lists.research.bell-labs.com In-Reply-To: <38A312DB.C0588855@vovida.com> from "Jeff Gao" at Feb 10, 2000 11:34:51 AM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit >5. A receives the message and compares the callleg. The existing callleg known >to A has the To and From field fliped from the To and From field in the info >message A received from B. In this case, the INFO message spec requires A to >reject B's info message with a "481 Call Leg/Transaction Does Not Exit" >response. This has been hashed over *many* times on the list: A call leg is identified by the tuple of (Call-ID, Remote-URI, Local-URI). -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 10 16:10:00 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10692 for ; Thu, 10 Feb 2000 16:09:59 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 69BDE52DA; Thu, 10 Feb 2000 16:07:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D148C52DB; Thu, 10 Feb 2000 16:07:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id D99A052DA for ; Thu, 10 Feb 2000 16:07:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 10 16:07:03 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Thu Feb 10 16:04:46 EST 2000 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.56]) id QQibvo04748; Thu, 10 Feb 2000 21:06:32 GMT Message-ID: <38A32922.18EEC7CE@dynamicsoft.com> Date: Thu, 10 Feb 2000 16:09:54 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jiri Kuthan Cc: Robert.Sparks@wcom.com, "'Billy Biggs'" , "'Dean Willis'" , "'Andrew Chalupka'" , "'SIP List'" Subject: Re: Question about media desinations References: <003a01bf7334$f0d5cba0$8a9223a6@mcit.com> <38A203C0.9CCDF597@dynamicsoft.com> <38A211DC.2E6734B4@fokus.gmd.de> <38A2D1A9.BBB6C889@dynamicsoft.com> <38A316D5.BF0CA2E@fokus.gmd.de> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jiri Kuthan wrote: > > In general, packet filtering reduces the security risks. The more > precise > the rules the lower the risk. However, even if very precise rules are > deployed, spoofing cannot be prevented unless a kind of packet > authorization based on a cryptographic method is used. For example, > a MAC covering the relevant header fields would have to be included > in every packet. The MAC secret key could be signaled with SIP. > > The questions I see are: > 1) Does the benefit of more precise rules justify including the source > address/port in SDP? (rewording of what Jonathan asked) > 2) Does the packet authorization make sense? Can its computational > and bandwidth overhead be kept low? Can be some existing > work reused? Are we going to focus on this problem? Using a MAC solves a different problem. The firewall stops the attack that has recently been launched - just flooding the host with packets. These packets may fail authentication, but their mere presence may cause the host to be overloaded just verifying and discarding them. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 10 16:14:09 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10797 for ; Thu, 10 Feb 2000 16:14:09 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id BB40752DB; Thu, 10 Feb 2000 16:11:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1383B52DF; Thu, 10 Feb 2000 16:11:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C798652DB for ; Thu, 10 Feb 2000 16:11:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 10 16:10:49 EST 2000 Received: from mw.3com.com ([149.112.20.3]) by dusty; Thu Feb 10 16:08:31 EST 2000 Received: from mwgate02.mw.3com.com by mw.3com.com (8.8.5/3.1.090690-3Com Corporation) id PAA28371; Thu, 10 Feb 2000 15:10:19 -0600 (CST) Received: by mwgate02.mw.3com.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 86256881.00746829 ; Thu, 10 Feb 2000 15:11:28 -0600 X-Lotus-FromDomain: 3COM@3COM-MWGATE From: "Ravandhu Hariram" To: Jonathan Rosenberg Cc: Gonzalo Camarillo , Adam.Roach@ericsson.com, bartw@nortelnetworks.com, Gonzalo.Camarillo@ericsson.com, sip@lists.research.bell-labs.com Message-ID: <86256881.007466E1.00@mwgate02.mw.3com.com> Date: Thu, 10 Feb 2000 15:08:04 -0600 Subject: Re: Comments on draft-camarillo-mmusic-sip-isup-bcp-00.txt Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk For the solution discussed below for overlap signaling, if the proxy is stateless, how do we gaurantee that subsequent INVITE messages (with same CallIdentifier but different call-leg with a different To header) reach the same egress GW? Particularly, this is a problem when multiple egress GWs can be used to reach a particular destination and there is some way of balancing the load on egress GWs. - hariram (3Com) Jonathan Rosenberg on 11/18/99 09:57:31 AM Sent by: Jonathan Rosenberg To: Gonzalo Camarillo cc: Adam.Roach@ericsson.com, bartw@nortelnetworks.com, Gonzalo.Camarillo@ericsson.com, sip@lists.research.bell-labs.com (Ravandhu Hariram/MW/US/3Com) Subject: Re: Comments on draft-camarillo-mmusic-sip-isup-bcp-00.txt What if, rather than encapsulating subsequent digits into INFO, they are added to the request URI in an INVITE? A local proxy for the gateway will respond with 484 to all those that don't have enough digits until it gets one that does have enough. So: Ingress GW P Egress GW INV tel:1 ------------> CSeq: 1 INV tel:12 -----------> CSeq: 2 <---------484 -------- CSeq: 1 INV tel:121 ---------> CSeq: 3 <---------484 ------- CSeq: 2 INV tel:1212 --------> ----------------------> IAM 1212----------> CSeq: 4 <--------------484---- CSeq: 3 INV tel:12125---------> ----------------------> SAM 5 -------------> CSeq: 5 INV tel:121255 -------> ----------------------> SAM 5 -------------> CSeq: 6 INV tel:1212555 ------> -----------------------> SAM 5 ------------> CSeq: 7 .......(same thing for digits 1, 2, 1) INV tel:12125551212----> ---------------------> SAM 2 --------------> CSeq: 11 <---------ACM------- <------484----------- CSeq: 5 <------484----------- CSeq: 6 ....... <------484 CSeq: 10 <---183-------------- CSeq: 11 Ok, so let me explain. Proxies do routing just on longest prefix matches for INVITE's. So, proxy P can be stateless actually, as it just forwards INVITEs that match 1212. The ingress gateway sends a re-INVITE (possibly without waiting for a response to the previous INVITE) every time a new digit is received from the PSTN. Once the proxy has enough digits to route, it won't send 484 anymore, and forwards it to the egress gateway. The egress gateway is smart, and creates an IAM from the first INVITE. Subsequent re-INVITEs cause SAMs to be sent, containing the difference in the set of digits from the previous INVITE. Once the egress gateway receives an ACM (address complete, right?), it responds with a 484 to all the INVITEs but the last, and the final INVITE with a 183. Things progress normally from there. Implications: 1. proxies don't have to know anything about INFO or ISUP. They just have to know longest prefix match routing for phone numbers. They can even be stateless. 2. egress gateways that know ISUP effectively re-generate the SAMs 3. if the egress point is not an ISUP gateway, but a PC terminal or something that happens to have a phone number as its name, it will have to know enough to reject each INVITE until it gets one with a request URI/To field that matches its own number. This, BTW, is normal behavior. A UAS rejects an INVITE if the URI is for an address thats not its own. 4. This works *even* if there is misordering of re-INVITEs. The egress gateway computes the SAMs based on differentials. So, lets say it receives the INVITE with 1555, then the INVITE with 155512. It then sends two SAMs, the first with 1, the next with 2. Lets say, then, that the INVITE with 15551 comes. Based on CSeq, the egress gateway knows its old and rejects it. 5. The ingress gateway doesn't depend on special messages or a completion character, like #, to send an INVITE. Its very possible I've completely missed something, as I'm hardly an ISUP expert. Perhaps there is additional data in SAM such that it MUST be sent across, rather than being regenerated. But, the above solution seems nice, as it doesn't break anything, works with non-ISUP terminating points, doesn't require users to dial a # at the end of the digit string, etc. Comments? -Jonathan R. Gonzalo Camarillo wrote: > > It is nicer to send complete URIs in the "to" header. If the i-gateway > sends the INVITE before receiveing all the digits, the "to" header is > not complete. It would contain just a few digits of the whole telephone > number (this assumes that with just some digits the i-gateway figures > out where to send the INVITE). > > Gonzalo > > Adam.Roach@ericsson.com wrote: > > > > >The use of a timer to force enbloc signaling is not acceptable. In the case > > >of SIP bridging, subscribers originating calls from the PSTN will not accept > > >an artificial post-dial delay (even if it is just a few seconds long). > > >Overlap signaling must be supported. It is essential that the overlap > > >process takes place within the context of a single session - using the > > >suggested INVITE/CANCEL/INVITE approach would result in multiple abortive > > >calls being delivered to the terminating agent, which would not be > > >acceptable. > > > > > >Why not send an INVITE message when the ISUP IAM is received and then send > > >subsequent INFO messages for each ISUP SAM? I understand that "pure" SIP > > >agents will expect the INVITE to contain the complete address of the called > > >party. This could be handled by including support for overlap in the > > >"Require" extensions (draft-roach-mmusic-sip-pstn-require-header-00.txt). If > > >the terminator did not support the PSTN extensions, the originator could > > >then switch to enbloc and wait for the full address to be collected. > > > > There are a variety of problems here. The first is determining how > > intervening proxies will react. If, for example, a proxy is making > > decisions about where to forward messages based on a called party URI, > > your suggestion would require it to understand ISUP (for interpretation > > of SAM message). It also requires it to have number analysis code and > > dialing plan information (potentially for the entire globe). > > > > The problem gets even stranger for redirect servers, which expect to > > be able to send an immediate response to an INVITE -- not sit around > > collecting digits. > > > > Basically, your suggestion forces overlapped dialing deep into each > > and every SIP node in the network that is expected to receive calls > > originating from the PSTN network. > > > > I agree that this is a problem that needs to be solved if we intend > > to use SIP between two PSTN phones; but we need to find a better > > solution than tunelling SAMs all over the place. > > > > We shouldn't overlook human factors: it could be that customers are > > willing to, for example, be trained to press "#" at the end of a > > phone number to skip the post-dial-delay. > > > > -- > > Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 > > adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 31 18 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 10 17:12:01 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11845 for ; Thu, 10 Feb 2000 17:12:00 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 1398D52E0; Thu, 10 Feb 2000 17:09:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 72E1052E1; Thu, 10 Feb 2000 17:09:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id E333552E0 for ; Thu, 10 Feb 2000 17:09:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 10 17:08:09 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Thu Feb 10 17:05:51 EST 2000 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.56]) id QQibvs16606; Thu, 10 Feb 2000 22:08:06 GMT Message-ID: <38A33790.5A052AC6@dynamicsoft.com> Date: Thu, 10 Feb 2000 17:11:28 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert.Sparks@wcom.com Cc: "'SIP List' (E-mail)" , "Henning Schulzrinne (E-mail)" Subject: Re: UAC use of tags received in responses References: <003201bf73dd$40e24300$8a9223a6@mcit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Robert Sparks wrote: > > One of the two requirements above must be modified to allow for this > scenario. Changing the requirement on the proxy, having it not add tags > for some or all locally generated responses, leads to problems determining > the appropriate destination for the subsequent ACK (pointed out by Jonathan > Rosenberg). The better solution then (suggested by both Jonathan and Alan > Johnston) is to modify the behavior of the UAC such that: > > A UAC only copies a tag into subsequent requests if it arrives in a > 200 OK to an INVITE. > I would further clarify this: A UAC copies the tag from the response into the ACK, but it MUST NOT copy the tag into any subsequent requests unless the response was a 200 class response to an INVITE. Since ACK is a "subsequent" request after all. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 10 17:16:21 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11895 for ; Thu, 10 Feb 2000 17:16:20 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4619F52E1; Thu, 10 Feb 2000 17:11:36 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 7376552E6; Thu, 10 Feb 2000 17:11:35 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 1A87152E1 for ; Thu, 10 Feb 2000 17:11:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 10 17:10:07 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Thu Feb 10 17:07:49 EST 2000 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.56]) id QQibvs21573; Thu, 10 Feb 2000 22:10:01 GMT Message-ID: <38A33803.CDE6985F@dynamicsoft.com> Date: Thu, 10 Feb 2000 17:13:23 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Piotr S. Kossowski" Cc: sip@lists.research.bell-labs.com Subject: Re: Expiration of draft-ietf-mmusic-sip-new-00.ps References: <38A20650.8B64F137@elka.pw.edu.pl> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit "Piotr S. Kossowski" wrote: > > Good Morning! > > When and where Is Going to appear new version of > draft-ietf-mmusic-sip-new-00.ps? > I'v got it and Date of Expiration is February 2000 ? Well, the expiration date is really irrelevant since the draft was never even submitted. We have been accumulating fixes and clarifications from the list and bakeoffs into this draft. It might be a good time to release it to officially get people looking at some of them. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 10 17:17:42 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11934 for ; Thu, 10 Feb 2000 17:17:41 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id D5C0B52ED; Thu, 10 Feb 2000 17:15:32 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1C6C552E9; Thu, 10 Feb 2000 17:15:32 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id CDE6D52ED for ; Thu, 10 Feb 2000 17:15:10 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 10 17:13:42 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Thu Feb 10 17:11:25 EST 2000 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: [63.72.186.56]) id QQibvs00239; Thu, 10 Feb 2000 22:13:40 GMT Message-ID: <38A338DF.842376A6@dynamicsoft.com> Date: Thu, 10 Feb 2000 17:17:03 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Robert.Sparks@wcom.com Cc: "'SIP List' (E-mail)" , "Henning Schulzrinne (E-mail)" Subject: Re: 481 response to an unknown tag References: <003301bf73dd$65951920$8a9223a6@mcit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Robert Sparks wrote: > > I propose this clarification to the last paragraph of section 10.1.1: > > "If the Call-ID was not found, the To: field is inspected for a tag > parameter. The server rejects the request if a tag is present. Otherwise, > a new call leg is created, with entries for the To, From and Call-ID > headers. The server returns a response containing the same To value, but > with a unique tag added. The tag MAY be omitted if the request contained > only one Via header field." Actually, I'd prefer to drop this last sentence. I hate special cases like this. I'd much rather write my client not having to consider that a tag might not appear. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 10 19:47:57 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13537 for ; Thu, 10 Feb 2000 19:47:57 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 39ED752B6; Thu, 10 Feb 2000 19:45:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A25A652BB; Thu, 10 Feb 2000 19:45:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 7914952B6 for ; Thu, 10 Feb 2000 19:45:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Feb 10 19:44:04 EST 2000 Received: from repulse.cnchost.com ([207.155.248.4]) by dusty; Thu Feb 10 19:41:46 EST 2000 Received: from vovida.com (w178.z216112071.sjc-ca.dsl.cnc.net [216.112.71.178]) by repulse.cnchost.com id TAA24950; Thu, 10 Feb 2000 19:43:58 -0500 (EST) [ConcentricHost SMTP Relay 1.8] Message-ID: <38A35B4E.E0F1859D@vovida.com> Date: Thu, 10 Feb 2000 16:43:58 -0800 From: Sunitha Kumar Organization: Vovida Networks X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: SIPbell-labs Subject: other-parm un a SIP -URL Content-Type: multipart/alternative; boundary="------------98451DCD1F943F6EBA040569" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --------------98451DCD1F943F6EBA040569 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi: Wanted to clarify that the To field can contain other-parms in its SipUrl. Also, the grammar for other parm is other-parm = (token | token "=" (token | quoted_string))) What do token stand for ? Is this something that the caller , and callee agree prior to starting their transaction? Thanks much! -- Sunitha Kumar Software Engineer Vovida Networks (408) 957 - 6374 --------------98451DCD1F943F6EBA040569 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi:

Wanted to clarify that the To field can contain other-parms in its SipUrl.
Also, the grammar for other parm is

other-parm = (token | token "=" (token | quoted_string)))

What do token stand for ? Is this something that the caller , and callee agree prior to starting their transaction?

Thanks much! 

-- 
Sunitha Kumar
Software Engineer
Vovida Networks
(408) 957 - 6374
  --------------98451DCD1F943F6EBA040569-- From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 10 20:09:55 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13746 for ; Thu, 10 Feb 2000 20:09:55 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 5F36552C4; Thu, 10 Feb 2000 20:07:20 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C6B6652D5; Thu, 10 Feb 2000 20:07:19 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 6D17052C4 for ; Thu, 10 Feb 2000 20:07:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Feb 10 20:06:56 EST 2000 Received: from repulse.cnchost.com ([207.155.248.4]) by dusty; Thu Feb 10 20:04:38 EST 2000 Received: from vovida.com (w178.z216112071.sjc-ca.dsl.cnc.net [216.112.71.178]) by repulse.cnchost.com id UAA00629; Thu, 10 Feb 2000 20:06:43 -0500 (EST) [ConcentricHost SMTP Relay 1.8] Message-ID: <38A360A6.92852E3C@vovida.com> Date: Thu, 10 Feb 2000 17:06:46 -0800 From: Sunitha Kumar Organization: Vovida Networks X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Henning Schulzrinne , archow@hss.hns.com, Marc Petit-Huguenin , IETF SIP Subject: Re: Question about Call comparaison References: <65256848.006D9D53.00@sampark.hss.hns.com> <38588347.9C3F1347@dynamicsoft.com> <3858FB96.EDD557C3@cs.columbia.edu> <3859D17D.64A211F@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi: Was any consensus reached on the URI equality. also, when we say the optional parameters of the URI, what are they? Do they include other-parms? Thanks! sunitha Jonathan Rosenberg wrote: > Henning Schulzrinne wrote: > > > > Jonathan Rosenberg wrote: > > > > > > Yes, I agree that these are the same. When matching the To and From > > > field for call legs, I would say that: > > > > > > 1. the display name is not included in the matching > > > > > 2. the matching includes tags > > > 3. the matching be based on the user, password, host and port components > > > of the URI, in addition to any parameters. The matching is semantic > > > based, so that if a default component is omitted, it still matches. > > > 4. string comparisons are case insensitive > > > 5. an IP address that is the result of a DNS lookup on a hostname does > > > NOT match that hostname. > > > > > > Matching based on URI parameters is debatable. But, we need at least the > > > user param, and rather than special case things, I'd like to make the > > > rule simple and consistent. So, lets include all parameters. > > > > > > > This also agrees with RFC 2616 (http), which says: > > > > 3.2.3 URI Comparison > > > > When comparing two URIs to decide if they match or not, a client > > SHOULD use a case-sensitive octet-by-octet comparison of the entire > > URIs, with these exceptions: > > > > - A port that is empty or not given is equivalent to the default > > port for that URI-reference; > > > > - Comparisons of host names MUST be case-insensitive; > > > > - Comparisons of scheme names MUST be case-insensitive; > > Hmm, so this means that comparisons on the user and password are case > SENSITIVE, and that comparisons on parameters are also case SENSITIVE. > Its a bit yucky with these special cases, but I guess we should be > consistent with http and rfc2396. In that case, I think we should > explicitly say that the username, password, and parameters comparisons > are case sensitive. > > -Jonathan R. > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 11 00:16:19 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18682 for ; Fri, 11 Feb 2000 00:16:12 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 9D31052AB; Fri, 11 Feb 2000 00:11:36 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 15F7D52BB; Fri, 11 Feb 2000 00:11:35 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 318F852AB for ; Fri, 11 Feb 2000 00:11:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Feb 11 00:10:31 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Fri Feb 11 00:08:08 EST 2000 Received: from dynamicsoft.com (1Cust168.tnt1.freehold.nj.da.uu.net [63.17.113.168]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA14112; Fri, 11 Feb 2000 00:10:02 -0500 (EST) Message-ID: <38A39A6D.B27B61DB@dynamicsoft.com> Date: Fri, 11 Feb 2000 00:13:17 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sunitha Kumar Cc: SIPbell-labs Subject: Re: other-parm un a SIP -URL References: <38A35B4E.E0F1859D@vovida.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Its used for extensions. token is a standard construction in BNF. If you see one and you don't know what it is for, ignore it. -Jonathan R. Sunitha Kumar wrote: > > Hi: > > Wanted to clarify that the To field can contain other-parms in its > SipUrl. > Also, the grammar for other parm is > > other-parm = (token | token "=" (token | quoted_string))) > > What do token stand for ? Is this something that the caller , and > callee agree prior to starting their transaction? > > Thanks much! > > -- > Sunitha Kumar > Software Engineer > Vovida Networks > (408) 957 - 6374 > > -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 11 00:23:36 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18725 for ; Fri, 11 Feb 2000 00:23:31 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 7A0B852C4; Fri, 11 Feb 2000 00:18:08 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id AD1F052BB; Fri, 11 Feb 2000 00:18:07 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 2487752C8 for ; Fri, 11 Feb 2000 00:17:12 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Feb 11 00:16:23 EST 2000 Received: from PMESMTP01.wcom.com ([199.249.20.1]) by dusty; Fri Feb 11 00:14:05 EST 2000 Received: from ndcrelay.mcit.com ([166.37.172.49]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FPR0054S2N8AB@firewall.mcit.com> for sip@lists.research.bell-labs.com; Fri, 11 Feb 2000 05:16:20 +0000 (GMT) Received: from omzmta04.mcit.com (omzmta04.mcit.com [166.37.194.122]) by ndcrelay.mcit.com (8.8.7/) with ESMTP id FAA10449; Fri, 11 Feb 2000 05:15:26 +0000 (GMT) Received: from dwillispc8 ([166.44.185.238]) by omzmta04.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000211051418.TJJO22989@dwillispc8>; Fri, 11 Feb 2000 05:14:18 +0000 Date: Thu, 10 Feb 2000 23:13:11 -0600 From: Dean Willis Subject: RE: Question about media desinations In-reply-to: <38A2D1A9.BBB6C889@dynamicsoft.com> To: Jonathan Rosenberg , Jiri Kuthan Cc: Robert.Sparks@wcom.com, "'Billy Biggs'" , "'Andrew Chalupka'" , "'SIP List'" Message-id: <002101bf744e$b0dce180$1af523a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan asked: > I recognize the desire for increased security (especially in light of > the recent attacks > against ebay, yahoo, etc.), but I am wondering if adding this to SDP > really buys you > much. Without this, an attacker must still guess the destination IP > address for media and > the destination port and a time during which a call is active. Adding > the source means it must also guess that. Is it enough extra? Without source-address rules in the firewall, an attacker can simply scan for addresses that don't return an "ICMP administratively denied", then scan each such address for ports that don't return "ICMP port unreachable". If the port isn't one normally used for something else, chances are its a media port and can be spammed with an RTP stream. This is pretty easy. With source-address rules in the firewall, the intruder most know enough to launch a scan with spoofed source addresses from a host likely to be in session with a host behind the firewall, and must be able to contrive to receive return packets to the spoofed address to detect success. This is fairly hard. -- Dean From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 11 01:18:54 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA20152 for ; Fri, 11 Feb 2000 01:18:49 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 17CF852AB; Fri, 11 Feb 2000 01:13:30 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6F5F952C4; Fri, 11 Feb 2000 01:13:29 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id E618A52AB for ; Fri, 11 Feb 2000 01:13:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Feb 11 01:11:08 EST 2000 Received: from PMESMTP02.wcom.com ([199.249.20.2]) by dusty; Fri Feb 11 01:08:50 EST 2000 Received: from ndcrelay2.mcit.com ([166.37.172.6]) by firewall.mcit.com (PMDF V5.2-32 #41713) with ESMTP id <0FPR008EE56I1G@firewall.mcit.com> for sip@lists.research.bell-labs.com; Fri, 11 Feb 2000 06:11:06 +0000 (GMT) Received: from omta3.mcit.com (omta3.mcit.com [166.37.204.5]) by ndcrelay2.mcit.com (8.8.7/) with ESMTP id GAA09905; Fri, 11 Feb 2000 06:11:51 +0000 (GMT) Received: from dwillispc8 ([166.44.186.99]) by omta3.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000211061119.XUGK631@dwillispc8>; Fri, 11 Feb 2000 06:11:19 +0000 Date: Fri, 11 Feb 2000 00:10:08 -0600 From: Dean Willis Subject: RE: When to send 183? In-reply-to: <200002101528.JAA02712@b04a24.exu.ericsson.se> To: "Adam B. Roach" , Srinath Subbarayan Cc: hgs@cs.columbia.edu, jdrosen@dynamicsoft.com, sip@lists.research.bell-labs.com Message-id: <002301bf7456$a5c4a280$1af523a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Adam wrote: > You would use the 183 only if you: > > a) Are able to determine that the audio being generated > is certainly *not* ringing (e.g. "comfort tone" or > "pay tone" as defined in E.18x), or > > b) Are unable to definitively determine that alerting > is occuring. This really should only happen with older > CAS protocols. ISUP and ISDN have sufficient information > to determine what is happening on the far end. > I would argue that a PSTN gateway which is talking to a native UAS (rather than another ss7 gateway) should ALWAYS return 183 upon entering a call-pending state (such as when receiving an ACM from an egress switch). This behavior is required for: 1) Specialized ringing tones, and 2) Network announcements, such as "The number you have reached has been disconnected". The early media session MUST be available BEFORE the announcement is played. You can't wait for audio detection before setting it up, or the announcement would be clipped. In fact, I would go so far as to say that a gateway that does NOT implement this feature is pretty close to useless for IP-PSTN call routing. Such a gateway would only be useful for the PSTN-IP-PSTN role being pursued by alternate-route carriers where SS7 release codes are tunneled back to the originating switch (and I'm frankly not sure it even works then). This needs to be fixed in the SIP-T work if we ever want to talk to REAL internet devices, instead of just tunnelling calls between gateways. I don't believe any real telco would buy an IP-PSTN gateway that doesn't support 183 with early media -- they just wouldn't be useful. One might argue that a UAS which knows it is placing a call thru an IP-PSTN gateway might want to state a requirement for 183 support in its initial INVITE. This approach would allow a gateway to decide whether to 183 based on the initiating INVITE, thereby allowing a gateway to server pstn-ip-pstn and ip-pstn transparently. One might also wonder how a forking proy would deal with 183 messages relating to a call that has been forked. -- Dean From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 11 01:31:46 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21378 for ; Fri, 11 Feb 2000 01:31:46 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 427AA52AB; Fri, 11 Feb 2000 01:29:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id B82FB52C4; Fri, 11 Feb 2000 01:29:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 4DA8E52AB for ; Fri, 11 Feb 2000 01:29:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Feb 11 01:29:00 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Fri Feb 11 01:26:43 EST 2000 Received: from dynamicsoft.com (1Cust168.tnt1.freehold.nj.da.uu.net [63.17.113.168]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA14149; Fri, 11 Feb 2000 01:28:56 -0500 (EST) Message-ID: <38A3ACEA.D5A43BFA@dynamicsoft.com> Date: Fri, 11 Feb 2000 01:32:10 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Gazal, Elly" Cc: "'SIP_ML'" Subject: Re: voicemail packaging References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit "Gazal, Elly" wrote: > > What is Voicemail packaging? > Are SIP+ and SIP-TGCP related to VM packaging? if so, how? I have no idea what voicemail packaging is. Nor do I know what SIP-TGCP is. SIP+ and SIP-T (aka SIP-T-BCP) is a SIP extension plus some interworking guidlines that specify how ISUP messages can be carried in SIP to provide ISUP transparency. It has nothing to do with voicemail so far as I know. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 11 10:16:42 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11281 for ; Fri, 11 Feb 2000 10:16:36 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 7DB3752C4; Fri, 11 Feb 2000 10:13:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id EDA4352C8; Fri, 11 Feb 2000 10:13:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 3847F52C4 for ; Fri, 11 Feb 2000 10:13:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Feb 11 10:12:06 EST 2000 Received: from mailgate.fore.com ([169.144.68.6]) by dusty; Fri Feb 11 10:09:48 EST 2000 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id KAA00017; Fri, 11 Feb 2000 10:12:02 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id KAA03717; Fri, 11 Feb 2000 10:12:04 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id <1WCL78HJ>; Fri, 11 Feb 2000 10:08:38 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF20892C@whq-msgusr-02.fore.com> From: "Rosen, Brian" To: "Gazal, Elly" Cc: "'SIP_ML'" Subject: RE: voicemail packaging Date: Fri, 11 Feb 2000 10:12:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Aaah, perhaps this is a misdirected query. There is an effort to define an MGCP Voicemail package in ISC. If that is what the enquiry is about, join the ISC's MGCP list. Brian > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, February 11, 2000 1:32 AM > To: Gazal, Elly > Cc: 'SIP_ML' > Subject: Re: voicemail packaging > > > > > "Gazal, Elly" wrote: > > > > What is Voicemail packaging? > > Are SIP+ and SIP-TGCP related to VM packaging? if so, how? > > I have no idea what voicemail packaging is. Nor do I know > what SIP-TGCP > is. > > SIP+ and SIP-T (aka SIP-T-BCP) is a SIP extension plus some > interworking > guidlines that specify how ISUP messages can be carried in SIP to > provide ISUP transparency. It has nothing to do with > voicemail so far as > I know. > > -Jonathan R. > > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 11 10:22:49 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11388 for ; Fri, 11 Feb 2000 10:22:43 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 1869452C8; Fri, 11 Feb 2000 10:19:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 751FC52D4; Fri, 11 Feb 2000 10:19:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id A149B52C8 for ; Fri, 11 Feb 2000 10:19:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Feb 11 10:17:55 EST 2000 Received: from gwa.ericsson.com ([198.215.127.2]) by dusty; Fri Feb 11 10:15:38 EST 2000 Received: from mr3.exu.ericsson.se (mr3a.ericsson.com [198.215.127.159]) by gwa.ericsson.com (8.9.3/8.9.3) with ESMTP id JAA00423; Fri, 11 Feb 2000 09:17:34 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id JAA24121; Fri, 11 Feb 2000 09:17:24 -0600 (CST) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA25236; Fri, 11 Feb 2000 09:16:58 -0600 (CST) Received: (from exuadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id JAA05863; Fri, 11 Feb 2000 09:16:57 -0600 (CST) Message-Id: <200002111516.JAA05863@b04a24.exu.ericsson.se> Subject: Re: When to send 183? To: dean.willis@wcom.com (Dean Willis) Date: Fri, 11 Feb 2000 09:16:57 -0600 (CST) Cc: ssubbara@cisco.com (Srinath Subbarayan), hgs@cs.columbia.edu, jdrosen@dynamicsoft.com, sip@lists.research.bell-labs.com In-Reply-To: <002301bf7456$a5c4a280$1af523a6@mcit.com> from "Dean Willis" at Feb 11, 2000 12:10:08 AM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Dean Willis writes: >Adam wrote: >> You would use the 183 only if you: >> >> a) Are able to determine that the audio being generated >> is certainly *not* ringing (e.g. "comfort tone" or >> "pay tone" as defined in E.18x), or >> >> b) Are unable to definitively determine that alerting >> is occuring. This really should only happen with older >> CAS protocols. ISUP and ISDN have sufficient information >> to determine what is happening on the far end. >> > >I would argue that a PSTN gateway which is talking to a native UAS (rather >than another ss7 gateway) should ALWAYS return 183 upon entering a >call-pending state (such as when receiving an ACM from an egress switch). I would argue that this is only appropriate when no other 1xx code will adequately describe the state. >This behavior is required for: > >1) Specialized ringing tones, and If you're providing a specialized ring tone, I would argue that you should send a 180 *with an SDP body* to indicate that you're providing the ringtone yourself. This way, the user hears the ringtone you want him to hear, and the phone (and any other signal-level node) knows that the call is ringing. My hope for 183 is that it does not get used as a generic "ACM -- set up media" type of message that depricates 180-182. It is a suppliment to fill in the gaps that 180-182 leave. >2) Network announcements, such as "The number you have reached has been >disconnected". Wouldn't a "410 The number you have reached has been disconnected" message serve the same purpose for native clients? I sure would prefer to read the text on a display than suffer through the recording. I beleive this is a more appropriate approach if you *know* for a fact that you're terminating on a native client. If you don't know whether you're hitting a PSTN gateway, I'd argue for playing the announcement. This is a fairly trivial task to accomplish by doing a simple mapping of release codes to appropriate SIP codes in the PSTN gateway; e.g.: ISUP SIP 1 410 Number Disconnected 2 404 No route to network 3 404 No route to destination 8 503 Call has been preempted etc. My contributions to the call flows draft will go over this in more detail. -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 11 10:42:22 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11916 for ; Fri, 11 Feb 2000 10:42:14 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id B270852BB; Fri, 11 Feb 2000 10:39:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 2B8FE52D5; Fri, 11 Feb 2000 10:39:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 92DD852BB for ; Fri, 11 Feb 2000 10:39:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Feb 11 10:38:09 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Fri Feb 11 10:35:52 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA14482; Fri, 11 Feb 2000 10:37:48 -0500 (EST) Message-ID: <38A42D91.49442FF8@dynamicsoft.com> Date: Fri, 11 Feb 2000 10:41:05 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sunitha Kumar Cc: Henning Schulzrinne , archow@hss.hns.com, Marc Petit-Huguenin , IETF SIP Subject: Re: Question about Call comparaison References: <65256848.006D9D53.00@sampark.hss.hns.com> <38588347.9C3F1347@dynamicsoft.com> <3858FB96.EDD557C3@cs.columbia.edu> <3859D17D.64A211F@dynamicsoft.com> <38A360A6.92852E3C@vovida.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Yes, consensus was reached. The rules are: 1. matching over domain names are case insensitive, all others are case sensitive. 2. The matching is over all fields: user, password, domain, port AND all parameters, including the optional and extension parameters 3. If a parameter is not present, but it has a default value, the matching is based on the default (i.e., a URL without a port and a URL with port 5060 match) 4. A URL with a domain name does not match a URL with an IP address, where that address is the result of a DNS lookup of the domain name. -Jonathan R. Sunitha Kumar wrote: > > Hi: > > Was any consensus reached on the URI equality. > also, when we say the optional parameters of the URI, what are they? Do they > include other-parms? > > Thanks! > sunitha > > Jonathan Rosenberg wrote: > > > Henning Schulzrinne wrote: > > > > > > Jonathan Rosenberg wrote: > > > > > > > > Yes, I agree that these are the same. When matching the To and From > > > > field for call legs, I would say that: > > > > > > > > 1. the display name is not included in the matching > > > > > > > 2. the matching includes tags > > > > 3. the matching be based on the user, password, host and port components > > > > of the URI, in addition to any parameters. The matching is semantic > > > > based, so that if a default component is omitted, it still matches. > > > > 4. string comparisons are case insensitive > > > > 5. an IP address that is the result of a DNS lookup on a hostname does > > > > NOT match that hostname. > > > > > > > > Matching based on URI parameters is debatable. But, we need at least the > > > > user param, and rather than special case things, I'd like to make the > > > > rule simple and consistent. So, lets include all parameters. > > > > > > > > > > This also agrees with RFC 2616 (http), which says: > > > > > > 3.2.3 URI Comparison > > > > > > When comparing two URIs to decide if they match or not, a client > > > SHOULD use a case-sensitive octet-by-octet comparison of the entire > > > URIs, with these exceptions: > > > > > > - A port that is empty or not given is equivalent to the default > > > port for that URI-reference; > > > > > > - Comparisons of host names MUST be case-insensitive; > > > > > > - Comparisons of scheme names MUST be case-insensitive; > > > > Hmm, so this means that comparisons on the user and password are case > > SENSITIVE, and that comparisons on parameters are also case SENSITIVE. > > Its a bit yucky with these special cases, but I guess we should be > > consistent with http and rfc2396. In that case, I think we should > > explicitly say that the username, password, and parameters comparisons > > are case sensitive. > > > > -Jonathan R. > > -- > > Jonathan D. Rosenberg 200 Executive Drive > > Chief Scientist Suite 120 > > dynamicsoft West Orange, NJ 07052 > > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > > http://www.dynamicsoft.com -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 11 11:38:28 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13676 for ; Fri, 11 Feb 2000 11:38:22 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C222E52D5; Fri, 11 Feb 2000 11:35:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 331F952D6; Fri, 11 Feb 2000 11:35:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 5414552D5 for ; Fri, 11 Feb 2000 11:35:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Feb 11 11:34:21 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Fri Feb 11 11:32:03 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA14633; Fri, 11 Feb 2000 11:34:26 -0500 (EST) Message-ID: <38A43AD6.B436A9F0@dynamicsoft.com> Date: Fri, 11 Feb 2000 11:37:42 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis Cc: Jiri Kuthan , Robert.Sparks@wcom.com, "'Billy Biggs'" , "'Andrew Chalupka'" , "'SIP List'" Subject: Re: Question about media desinations References: <002101bf744e$b0dce180$1af523a6@mcit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Dean Willis wrote: > > Jonathan asked: > > I recognize the desire for increased security (especially in light of > > the recent attacks > > against ebay, yahoo, etc.), but I am wondering if adding this to SDP > > really buys you > > much. Without this, an attacker must still guess the destination IP > > address for media and > > the destination port and a time during which a call is active. Adding > > the source means it must also guess that. Is it enough extra? > > Without source-address rules in the firewall, an attacker can simply scan > for addresses that don't return an "ICMP administratively denied", then scan > each such address for ports that don't return "ICMP port unreachable". If > the port isn't one normally used for something else, chances are its a media > port and can be spammed with an RTP stream. This is pretty easy. This presumes a firewall sends an ICMP error message when it discards the packet. I would think they would blackhole them, which will eliminate the ability to conduct this attack you describe. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 11 11:52:15 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14129 for ; Fri, 11 Feb 2000 11:52:10 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id B1D1852E0; Fri, 11 Feb 2000 11:47:26 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1D61B52E3; Fri, 11 Feb 2000 11:47:26 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 5EE7652E0 for ; Fri, 11 Feb 2000 11:47:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Feb 11 11:46:38 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Fri Feb 11 11:44:20 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA14662; Fri, 11 Feb 2000 11:46:47 -0500 (EST) Message-ID: <38A43DBC.CD2412B9@dynamicsoft.com> Date: Fri, 11 Feb 2000 11:50:04 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: archow@hss.hns.com Cc: sip@lists.research.bell-labs.com Subject: Re: Encryption of From Header References: <65256877.004AA6C1.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit I think it must not be encrypted. This is because (1) call leg identification may need to be done in a proxy, (2) its possible with the call control spec that there are two transactions that have the same To, Call-ID, CSeq but different From, in which case the From is needed for transaction identification. We should therefore remove this tidbit from 13.1.1. Thanks, Jonathan R. archow@hss.hns.com wrote: > > Hi, > Please refer to section 13.1.1 of RFC 2543 > > "The From header field SHOULD > normally remain in the clear, but MAY be encrypted if required, in > which case some proxies MAY return a 401 (Unauthorized) status if > they require a From field." > > The above indicates that its possible for FROM Header to be encrypted if so > desired. > > Now, please refer to Section 6 Table 4 which clearly mentions From (and > others) to have an "n" status in the enc colum implying > they MUST NOT be encrypted. > > So which is the correct statememt ? > > Regds > Arjun > -- > Arjun Roychowdhury @ Hughes Software Systems -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 11 13:35:48 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16847 for ; Fri, 11 Feb 2000 13:35:45 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 8A2F252DA; Fri, 11 Feb 2000 13:23:47 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9BC4F52DC; Fri, 11 Feb 2000 13:23:37 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 85E1F52DB for ; Fri, 11 Feb 2000 13:23:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Feb 11 13:21:45 EST 2000 Received: from atlrel1.hp.com ([156.153.255.210]) by dusty; Fri Feb 11 13:19:28 EST 2000 Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by atlrel1.hp.com (Postfix) with ESMTP id 9B6821A590; Fri, 11 Feb 2000 13:21:40 -0500 (EST) Received: from hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238]) by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id SAA04973; Fri, 11 Feb 2000 18:21:37 GMT Message-ID: <38A45338.3FD08932@hpl.hp.com> Date: Fri, 11 Feb 2000 18:21:44 +0000 From: Anders Kristensen Organization: HP Labs X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Sunitha Kumar , Henning Schulzrinne , archow@hss.hns.com, Marc Petit-Huguenin , IETF SIP Subject: Re: Question about Call comparaison References: <65256848.006D9D53.00@sampark.hss.hns.com> <38588347.9C3F1347@dynamicsoft.com> <3858FB96.EDD557C3@cs.columbia.edu> <3859D17D.64A211F@dynamicsoft.com> <38A360A6.92852E3C@vovida.com> <38A42D91.49442FF8@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Yes, consensus was reached. The rules are: > > 1. matching over domain names are case insensitive, all others are case > sensitive. I believe we agreed that parameter names are CI, also. Otherwise implementations would have to remember not only, say, that a To tag had value "xyz" but also the tag string itself just to get the case right. Not very good. -- Anders Kristensen , http://www-uk.hpl.hp.com/people/ak/ Hewlett-Packard Labs, Bristol, UK From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 11 14:05:24 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17548 for ; Fri, 11 Feb 2000 14:05:20 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 6C2CF52D4; Fri, 11 Feb 2000 14:02:06 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E3E9152DC; Fri, 11 Feb 2000 14:02:05 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from bronx.dnrc.bell-labs.com (bronx [135.180.160.8]) by lists.research.bell-labs.com (Postfix) with ESMTP id A5E4152D4 for ; Fri, 11 Feb 2000 14:01:49 -0500 (EST) Received: from cs.columbia.edu (ume [135.180.240.103]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA08038; Fri, 11 Feb 2000 14:01:47 -0500 (EST) Message-ID: <38A45C9D.81817DA0@cs.columbia.edu> Date: Fri, 11 Feb 2000 14:01:49 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: Jonathan Rosenberg Cc: archow@hss.hns.com, sip@lists.research.bell-labs.com Subject: Re: Encryption of From Header References: <65256877.004AA6C1.00@sampark.hss.hns.com> <38A43DBC.CD2412B9@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > I think it must not be encrypted. This is because (1) call leg > identification may need to be done in a proxy, (2) its possible with the > call control spec that there are two transactions that have the same To, > Call-ID, CSeq but different From, in which case the From is needed for > transaction identification. > > We should therefore remove this tidbit from 13.1.1. The spec has been updated accordingly. From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 11 14:15:58 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17744 for ; Fri, 11 Feb 2000 14:15:55 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id D615A52DC; Fri, 11 Feb 2000 14:13:12 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 457FC52DF; Fri, 11 Feb 2000 14:13:12 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from bronx.dnrc.bell-labs.com (bronx [135.180.160.8]) by lists.research.bell-labs.com (Postfix) with ESMTP id 40EC652DC for ; Fri, 11 Feb 2000 14:12:58 -0500 (EST) Received: from cs.columbia.edu (ume [135.180.240.103]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id OAA08457; Fri, 11 Feb 2000 14:12:48 -0500 (EST) Message-ID: <38A45F32.1FFB6A4E@cs.columbia.edu> Date: Fri, 11 Feb 2000 14:12:50 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: "Adam B. Roach" Cc: Dean Willis , Srinath Subbarayan , sip@lists.research.bell-labs.com Subject: Re: When to send 183? References: <200002111516.JAA05863@b04a24.exu.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit I agree that having a 4xx/5xx immediately is preferable. The only strange thing is that if the announcement is long (including infinite - I don't know how many times the number change or area code change announcement is repeated in the PSTN), the other side hangs up, but can't really send a BYE, since there never was a successful call to begin with. When should the calling gateway stop sending audio? Termination audio seems much closer to a success, from a UA perspective. If there's a human or PSTN gateway at the calling end, it seems like the behavior is closer to success, including hanging up to terminate the announcement, than a failure. Clearly, even for humans, some distinct status code (other than 200) should be provided. From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 11 15:11:40 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18794 for ; Fri, 11 Feb 2000 15:11:34 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 3033552DB; Fri, 11 Feb 2000 15:08:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 95C8E52E1; Fri, 11 Feb 2000 15:08:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from bronx.dnrc.bell-labs.com (bronx [135.180.160.8]) by lists.research.bell-labs.com (Postfix) with ESMTP id 9548C52DB for ; Fri, 11 Feb 2000 15:07:52 -0500 (EST) Received: from cs.columbia.edu (ume [135.180.240.103]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id PAA10751; Fri, 11 Feb 2000 15:07:51 -0500 (EST) Message-ID: <38A46C17.D812144F@cs.columbia.edu> Date: Fri, 11 Feb 2000 15:07:51 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: Anders Kristensen Cc: IETF SIP Subject: Re: Question about Call comparaison References: <65256848.006D9D53.00@sampark.hss.hns.com> <38588347.9C3F1347@dynamicsoft.com> <3858FB96.EDD557C3@cs.columbia.edu> <3859D17D.64A211F@dynamicsoft.com> <38A360A6.92852E3C@vovida.com> <38A42D91.49442FF8@dynamicsoft.com> <38A45338.3FD08932@hpl.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Anders Kristensen wrote: > > Jonathan Rosenberg wrote: > > > > Yes, consensus was reached. The rules are: > > > > 1. matching over domain names are case insensitive, all others are case > > sensitive. > > I believe we agreed that parameter names are CI, also. Otherwise > implementations would have to remember not only, say, that a To tag had > value "xyz" but also the tag string itself just to get the case right. > Not very good. Note that the "tag" is not part of the URL. Thus, call matching = URL matching for From/To + tag matching for To + Call-ID matching. I've added wording on call leg matching in the From header section. From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 11 15:20:14 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18984 for ; Fri, 11 Feb 2000 15:20:11 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 7EE0A52E1; Fri, 11 Feb 2000 15:17:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 0649952E2; Fri, 11 Feb 2000 15:17:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 28A7452E1 for ; Fri, 11 Feb 2000 15:17:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Feb 11 15:16:10 EST 2000 Received: from palrel3.hp.com ([156.153.255.226]) by dusty; Fri Feb 11 15:13:52 EST 2000 Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by palrel3.hp.com (Postfix) with ESMTP id CC016DD3; Fri, 11 Feb 2000 12:16:06 -0800 (PST) Received: from hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238]) by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id UAA10763; Fri, 11 Feb 2000 20:16:05 GMT Message-ID: <38A46E0C.A3B1BD32@hpl.hp.com> Date: Fri, 11 Feb 2000 20:16:12 +0000 From: Anders Kristensen Organization: HP Labs X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: IETF SIP Subject: Re: Question about Call comparaison References: <65256848.006D9D53.00@sampark.hss.hns.com> <38588347.9C3F1347@dynamicsoft.com> <3858FB96.EDD557C3@cs.columbia.edu> <3859D17D.64A211F@dynamicsoft.com> <38A360A6.92852E3C@vovida.com> <38A42D91.49442FF8@dynamicsoft.com> <38A45338.3FD08932@hpl.hp.com> <38A46C17.D812144F@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > Anders Kristensen wrote: > > > > Jonathan Rosenberg wrote: > > > > > > Yes, consensus was reached. The rules are: > > > > > > 1. matching over domain names are case insensitive, all others are case > > > sensitive. > > > > I believe we agreed that parameter names are CI, also. Otherwise > > implementations would have to remember not only, say, that a To tag had > > value "xyz" but also the tag string itself just to get the case right. > > Not very good. > > Note that the "tag" is not part of the URL. Thus, call matching = URL > matching for From/To + tag matching for To + Call-ID matching. Right you are, so substitute "tag" for "transport" and the comment holds. > > I've added wording on call leg matching in the From header section. -- Anders Kristensen , http://www-uk.hpl.hp.com/people/ak/ Hewlett-Packard Labs, Bristol, UK From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 11 16:02:09 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20566 for ; Fri, 11 Feb 2000 16:02:03 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 43C0052DF; Fri, 11 Feb 2000 15:59:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 98B5D52E4; Fri, 11 Feb 2000 15:59:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 92F6852DF for ; Fri, 11 Feb 2000 15:59:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Feb 11 15:58:50 EST 2000 Received: from mail.pingtel.com ([216.91.1.131]) by dusty; Fri Feb 11 15:56:32 EST 2000 Received: from pingtel.com (cdhcp189.pingtel.com [10.1.1.189]) by mail.pingtel.com (8.9.3/8.9.3) with ESMTP id PAA14289; Fri, 11 Feb 2000 15:49:04 -0500 Message-ID: <38A4782E.D068237A@pingtel.com> Date: Fri, 11 Feb 2000 15:59:27 -0500 From: "Daniel G. Petrie" Organization: Pingtel Corp. http://www.pingtel.com X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: "Adam B. Roach" Cc: Dean Willis , Srinath Subbarayan , hgs@cs.columbia.edu, jdrosen@dynamicsoft.com, sip@lists.research.bell-labs.com Subject: Re: When to send 183? References: <200002111516.JAA05863@b04a24.exu.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit You are right on the mark here. Comments below. "Adam B. Roach" wrote: > Dean Willis writes: > >Adam wrote: > >> You would use the 183 only if you: > >> > >> a) Are able to determine that the audio being generated > >> is certainly *not* ringing (e.g. "comfort tone" or > >> "pay tone" as defined in E.18x), or > >> > >> b) Are unable to definitively determine that alerting > >> is occuring. This really should only happen with older > >> CAS protocols. ISUP and ISDN have sufficient information > >> to determine what is happening on the far end. > >> > > > >I would argue that a PSTN gateway which is talking to a native UAS (rather > >than another ss7 gateway) should ALWAYS return 183 upon entering a > >call-pending state (such as when receiving an ACM from an egress switch). > > I would argue that this is only appropriate when no other 1xx code > will adequately describe the state. Yes! > > > >This behavior is required for: > > > >1) Specialized ringing tones, and > > If you're providing a specialized ring tone, I would argue that you > should send a 180 *with an SDP body* to indicate that you're providing > the ringtone yourself. This way, the user hears the ringtone you want > him to hear, and the phone (and any other signal-level node) knows > that the call is ringing. My hope for 183 is that it does not get > used as a generic "ACM -- set up media" type of message that depricates > 180-182. It is a suppliment to fill in the gaps that 180-182 > leave. Absolutely! Using 183 when a more descriptive status is available looses information. That can only serve to limit the knowledge that the UA has and subsequently diminish what it can do to improve the user experience. > > > >2) Network announcements, such as "The number you have reached has been > >disconnected". > > Wouldn't a "410 The number you have reached has been disconnected" > message serve the same purpose for native clients? I sure would > prefer to read the text on a display than suffer through the > recording. I beleive this is a more appropriate approach if > you *know* for a fact that you're terminating on a native client. > If you don't know whether you're hitting a PSTN gateway, I'd > argue for playing the announcement. > > This is a fairly trivial task to accomplish by doing a simple > mapping of release codes to appropriate SIP codes in the > PSTN gateway; e.g.: > > ISUP SIP > 1 410 Number Disconnected > 2 404 No route to network > 3 404 No route to destination > 8 503 Call has been preempted > > etc. > > My contributions to the call flows draft will go over this in > more detail. > > -- > Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 > adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 11 16:18:21 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21237 for ; Fri, 11 Feb 2000 16:18:15 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 3CAE452E4; Fri, 11 Feb 2000 16:15:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A44E552E5; Fri, 11 Feb 2000 16:15:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 8F4AB52E4 for ; Fri, 11 Feb 2000 16:15:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Feb 11 16:14:10 EST 2000 Received: from mail.pingtel.com ([216.91.1.131]) by dusty; Fri Feb 11 16:11:52 EST 2000 Received: from pingtel.com (cdhcp189.pingtel.com [10.1.1.189]) by mail.pingtel.com (8.9.3/8.9.3) with ESMTP id QAA14364; Fri, 11 Feb 2000 16:04:40 -0500 Message-ID: <38A47BD6.235031C9@pingtel.com> Date: Fri, 11 Feb 2000 16:15:02 -0500 From: "Daniel G. Petrie" Organization: Pingtel Corp. http://www.pingtel.com X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis Cc: "Adam B. Roach" , Srinath Subbarayan , hgs@cs.columbia.edu, jdrosen@dynamicsoft.com, sip@lists.research.bell-labs.com Subject: Re: When to send 183? References: <002301bf7456$a5c4a280$1af523a6@mcit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit It seems that your argument is for early media, not necessarily for a 183 status. The point I have been trying to make is that the status 183 is too generic if the outcome is known to be a call setup failure. One should avoid using the status 183 if a more descriptive status can be provided. Early media makes sense with many different status. I think that we need to be very careful in keeping these issues separate. Dean Willis wrote: > Adam wrote: > > You would use the 183 only if you: > > > > a) Are able to determine that the audio being generated > > is certainly *not* ringing (e.g. "comfort tone" or > > "pay tone" as defined in E.18x), or > > > > b) Are unable to definitively determine that alerting > > is occuring. This really should only happen with older > > CAS protocols. ISUP and ISDN have sufficient information > > to determine what is happening on the far end. > > > > I would argue that a PSTN gateway which is talking to a native UAS (rather > than another ss7 gateway) should ALWAYS return 183 upon entering a > call-pending state (such as when receiving an ACM from an egress switch). > This behavior is required for: > > 1) Specialized ringing tones, and > 2) Network announcements, such as "The number you have reached has been > disconnected". > > The early media session MUST be available BEFORE the announcement is played. > You can't wait for audio detection before setting it up, or the announcement > would be clipped. > > In fact, I would go so far as to say that a gateway that does NOT implement > this feature is pretty close to useless for IP-PSTN call routing. Such a > gateway would only be useful for the PSTN-IP-PSTN role being pursued by > alternate-route carriers where SS7 release codes are tunneled back to the > originating switch (and I'm frankly not sure it even works then). This needs > to be fixed in the SIP-T work if we ever want to talk to REAL internet > devices, instead of just tunnelling calls between gateways. I don't believe > any real telco would buy an IP-PSTN gateway that doesn't support 183 with > early media -- they just wouldn't be useful. > > One might argue that a UAS which knows it is placing a call thru an IP-PSTN > gateway might want to state a requirement for 183 support in its initial > INVITE. This approach would allow a gateway to decide whether to 183 based > on the initiating INVITE, thereby allowing a gateway to server pstn-ip-pstn > and ip-pstn transparently. > > One might also wonder how a forking proy would deal with 183 messages > relating to a call that has been forked. > > -- > Dean From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 11 18:18:06 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25777 for ; Fri, 11 Feb 2000 18:18:03 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 5531A52E5; Fri, 11 Feb 2000 18:15:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id BF65E52E7; Fri, 11 Feb 2000 18:15:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 7EAB952E5 for ; Fri, 11 Feb 2000 18:15:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Feb 11 18:14:03 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Fri Feb 11 18:11:46 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA15465; Fri, 11 Feb 2000 18:10:03 -0500 (EST) Message-ID: <38A4978D.50F2D34F@dynamicsoft.com> Date: Fri, 11 Feb 2000 18:13:17 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Anders Kristensen Cc: Sunitha Kumar , Henning Schulzrinne , archow@hss.hns.com, Marc Petit-Huguenin , IETF SIP Subject: Re: Question about Call comparaison References: <65256848.006D9D53.00@sampark.hss.hns.com> <38588347.9C3F1347@dynamicsoft.com> <3858FB96.EDD557C3@cs.columbia.edu> <3859D17D.64A211F@dynamicsoft.com> <38A360A6.92852E3C@vovida.com> <38A42D91.49442FF8@dynamicsoft.com> <38A45338.3FD08932@hpl.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Anders Kristensen wrote: > > > 1. matching over domain names are case insensitive, all others are case > > sensitive. > > I believe we agreed that parameter names are CI, also. Otherwise > implementations would have to remember not only, say, that a To tag had > value "xyz" but also the tag string itself just to get the case right. > Not very good. I'm confused; having it CS is easier. I'll store the tag as a string, and do a normal string comparison on it to "get the case right". Whats the difficulty? -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Sat Feb 12 01:10:08 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06704 for ; Sat, 12 Feb 2000 01:10:08 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 2F24C52E7; Sat, 12 Feb 2000 01:07:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9EBEC52E9; Sat, 12 Feb 2000 01:07:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 65C0A52E7 for ; Sat, 12 Feb 2000 01:07:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Sat Feb 12 01:05:19 EST 2000 Received: from PMESMTP01.wcom.com ([199.249.20.1]) by dusty; Sat Feb 12 01:03:01 EST 2000 Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42256) id <0FPS00C01ZKT57@firewall.mcit.com> for sip@lists.research.bell-labs.com; Sat, 12 Feb 2000 06:05:17 +0000 (GMT) Received: from ndcrelay.mcit.com ([166.37.172.49]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FPS005SEZKTSA@firewall.mcit.com>; Sat, 12 Feb 2000 06:05:17 +0000 (GMT) Received: from omzmta02.mcit.com (omzmta02.mcit.com [166.37.194.120]) by ndcrelay.mcit.com (8.8.7/) with ESMTP id GAA27144; Sat, 12 Feb 2000 06:05:27 +0000 (GMT) Received: from dwillispc8 ([166.44.186.254]) by omzmta02.mcit.com (InterMail v03.02.05 118 120) with SMTP id <20000212060515.IEMM4845@[166.44.186.254]>; Sat, 12 Feb 2000 06:05:15 +0000 Date: Sat, 12 Feb 2000 00:04:19 -0600 From: Dean Willis Subject: RE: When to send 183? In-reply-to: <200002111516.JAA05863@b04a24.exu.ericsson.se> To: "Adam B. Roach" Cc: Srinath Subbarayan , hgs@cs.columbia.edu, jdrosen@dynamicsoft.com, sip@lists.research.bell-labs.com Message-id: <001001bf751f$00325dc0$feba2ca6@dwillispc8> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit > > Wouldn't a "410 The number you have reached has been disconnected" > message serve the same purpose for native clients? I sure would > prefer to read the text on a display than suffer through the > recording. I beleive this is a more appropriate approach if > you *know* for a fact that you're terminating on a native client. > If you don't know whether you're hitting a PSTN gateway, I'd > argue for playing the announcement. As I understand it, the SS7 release code is often quite vague, and certainly doesn't convey the "NEW NUMBER IS . . . " information contained in the voice recording. AS for 180 with ring-SDP -- how does the network gateway anticipate the ring treatment that will be applied by a domestic terminating switch? Can't, can it? I'd suggest that the easiest general solution is to send a 183 with media following the ACM. This gets the RTP stream established in time for network call treatment. I don't think I think 183 is an edge condition -- I think it is far more lilkely to be the norm for PSTN interworking. -- Dean From owner-sip-outgoing@lists.research.bell-labs.com Sat Feb 12 01:19:54 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07388 for ; Sat, 12 Feb 2000 01:19:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 72E3652EA; Sat, 12 Feb 2000 01:17:29 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id ED4A452E9; Sat, 12 Feb 2000 01:17:27 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 36BFD52EA for ; Sat, 12 Feb 2000 01:17:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Sat Feb 12 01:16:43 EST 2000 Received: from PMESMTP02.wcom.com ([199.249.20.2]) by dusty; Sat Feb 12 01:14:26 EST 2000 Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #41713) id <0FPT0040103TKQ@firewall.mcit.com> for sip@lists.research.bell-labs.com; Sat, 12 Feb 2000 06:16:42 +0000 (GMT) Received: from ndcrelay.mcit.com ([166.37.172.49]) by firewall.mcit.com (PMDF V5.2-32 #41713) with ESMTP id <0FPT0037Y03TWB@firewall.mcit.com>; Sat, 12 Feb 2000 06:16:41 +0000 (GMT) Received: from omzmta02.mcit.com (omzmta02.mcit.com [166.37.194.120]) by ndcrelay.mcit.com (8.8.7/) with ESMTP id GAA27733; Sat, 12 Feb 2000 06:16:52 +0000 (GMT) Received: from dwillispc8 ([166.44.186.254]) by omzmta02.mcit.com (InterMail v03.02.05 118 120) with SMTP id <20000212061640.IEUM4845@[166.44.186.254]>; Sat, 12 Feb 2000 06:16:40 +0000 Date: Sat, 12 Feb 2000 00:15:45 -0600 From: Dean Willis Subject: RE: Question about media desinations In-reply-to: <38A43AD6.B436A9F0@dynamicsoft.com> To: Jonathan Rosenberg Cc: "'SIP List'" Message-id: <001e01bf7520$98bba1e0$feba2ca6@dwillispc8> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Try scanning the net at 63.81.221.0/24, for example by telneting to port 122 on 63.81.221.234 -- you'll get back lots of "packet filtered" messages. The default behavior in most systems is to return such a message. Some firewall implementors turn them off. Most don't. -- Dean Jonathan asked: > This presumes a firewall sends an ICMP error message when it discards > the packet. I would > think they would blackhole them, which will eliminate the ability to > conduct this attack > you describe. From owner-sip-outgoing@lists.research.bell-labs.com Sat Feb 12 09:03:59 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22535 for ; Sat, 12 Feb 2000 09:03:58 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 6F24952E9; Sat, 12 Feb 2000 09:01:25 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D695552EB; Sat, 12 Feb 2000 09:01:24 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 384A652E9 for ; Sat, 12 Feb 2000 09:01:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Sat Feb 12 09:00:12 EST 2000 Received: from palrel1.hp.com ([156.153.255.242]) by dusty; Sat Feb 12 08:57:55 EST 2000 Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by palrel1.hp.com (Postfix) with ESMTP id B8EF7CAC; Sat, 12 Feb 2000 06:00:04 -0800 (PST) Received: from hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238]) by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id OAA08644; Sat, 12 Feb 2000 14:00:03 GMT Message-ID: <38A5676A.EAE41A05@hpl.hp.com> Date: Sat, 12 Feb 2000 14:00:10 +0000 From: Anders Kristensen Organization: HP Labs X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Anders Kristensen , Sunitha Kumar , Henning Schulzrinne , archow@hss.hns.com, Marc Petit-Huguenin , IETF SIP Subject: Re: Question about Call comparaison References: <65256848.006D9D53.00@sampark.hss.hns.com> <38588347.9C3F1347@dynamicsoft.com> <3858FB96.EDD557C3@cs.columbia.edu> <3859D17D.64A211F@dynamicsoft.com> <38A360A6.92852E3C@vovida.com> <38A42D91.49442FF8@dynamicsoft.com> <38A45338.3FD08932@hpl.hp.com> <38A4978D.50F2D34F@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Anders Kristensen wrote: > > > > > 1. matching over domain names are case insensitive, all others are case > > > sensitive. > > > > I believe we agreed that parameter names are CI, also. Otherwise > > implementations would have to remember not only, say, that a To tag had > > value "xyz" but also the tag string itself just to get the case right. > > Not very good. > > I'm confused; having it CS is easier. I'll store the tag as a string, > and do a normal > string comparison on it to "get the case right". Right, actually it depends on the implementation. Currently our SipURL class has attributes for RFC 2543 defined SIP URL parameters: user, maddr ttl, transport, and method, whereas other-params are stored in a map. There are advantages and disadvantages to this approach. Amongst the advantages is that it saves us from having to remember the actual attribute name used on the wire for these "well-defined" attributes, and that retrieval is faster than having to lookup in a hashtable or what have you. My posting was predicated on the assumption that people would naturally want to store rfc 2543 SIP URL parameters different from other-params, which I realize now isn't necessarily the case. Anyway, I dont really feel very strongly about it. CS parameter names is fine with me. Anders -- Anders Kristensen , http://www-uk.hpl.hp.com/people/ak/ Hewlett-Packard Labs, Bristol, UK From owner-sip-outgoing@lists.research.bell-labs.com Sat Feb 12 15:38:16 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25816 for ; Sat, 12 Feb 2000 15:38:16 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id CCB5552E2; Sat, 12 Feb 2000 15:35:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3D88952EA; Sat, 12 Feb 2000 15:35:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id DCC2F52E2 for ; Sat, 12 Feb 2000 15:35:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Sat Feb 12 15:34:41 EST 2000 Received: from gwu.ericy.com ([208.196.3.162]) by dusty; Sat Feb 12 15:32:24 EST 2000 Received: from mr4.exu.ericsson.se (mr4u.ericy.com [208.238.116.99]) by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id OAA28443; Sat, 12 Feb 2000 14:34:35 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id OAA26679; Sat, 12 Feb 2000 14:34:35 -0600 (CST) Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA22671; Sat, 12 Feb 2000 14:34:34 -0600 (CST) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id OAA09586; Sat, 12 Feb 2000 14:34:33 -0600 (CST) Date: Sat, 12 Feb 2000 14:34:33 -0600 (CST) Message-Id: <200002122034.OAA09586@b04a45.exu.ericsson.se> To: jdrosen@dynamicsoft.com, ak@hplb.hpl.hp.com Subject: Re: Question about Call comparaison Cc: sip@lists.research.bell-labs.com X-Sun-Charset: US-ASCII Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk > Jonathan Rosenberg wrote: > > > > Anders Kristensen wrote: > > > > > > > 1. matching over domain names are case insensitive, all others are case > > > > sensitive. > > > > > > I believe we agreed that parameter names are CI, also. Otherwise > > > implementations would have to remember not only, say, that a To tag had > > > value "xyz" but also the tag string itself just to get the case right. > > > Not very good. > > > > I'm confused; having it CS is easier. I'll store the tag as a string, > > and do a normal > > string comparison on it to "get the case right". > Is this an argument for CS names or CS values? > Right, actually it depends on the implementation. Currently our SipURL > class has attributes for RFC 2543 defined SIP URL parameters: user, > maddr ttl, transport, and method, whereas other-params are stored in a > map. > We take a very similar approach. > There are advantages and disadvantages to this approach. Amongst the > advantages is that it saves us from having to remember the actual > attribute name used on the wire for these "well-defined" attributes, and > that retrieval is faster than having to lookup in a hashtable or what > have you. > Exactly. > My posting was predicated on the assumption that people would naturally > want to store rfc 2543 SIP URL parameters different from other-params, > which I realize now isn't necessarily the case. > I too think it is a very natural approach, however, some might want just to deal with simple strings. > Anyway, I dont really feel very strongly about it. CS parameter names is > fine with me. > If parameter names are case sensitive, then what is the "correct" case for the standard SIP URL parameters (is it "Transport", "TRANSPORT", "transport", etc?). Or are you saying that a SIP URL with a "transport=tcp" parameter does not match a SIP URL with a "Transport=tcp" parameter (where both cases would be interpreted as a correctly formatted transport parameter)? > Anders > > -- > Anders Kristensen , > http://www-uk.hpl.hp.com/people/ak/ > Hewlett-Packard Labs, Bristol, UK > -- Sean Olson From owner-sip-outgoing@lists.research.bell-labs.com Sun Feb 13 12:12:47 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11937 for ; Sun, 13 Feb 2000 12:12:47 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 6A6ED52C8; Sun, 13 Feb 2000 12:09:34 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C8B5152D4; Sun, 13 Feb 2000 12:09:33 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 4694452C8 for ; Sun, 13 Feb 2000 12:09:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Sun Feb 13 12:07:41 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Sun Feb 13 12:05:23 EST 2000 Received: from dynamicsoft.com (1Cust116.tnt2.freehold.nj.da.uu.net [63.17.114.116]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA15866; Sun, 13 Feb 2000 12:07:49 -0500 (EST) Message-ID: <38A6E5B6.F0C3E412@dynamicsoft.com> Date: Sun, 13 Feb 2000 12:11:18 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis Cc: "'SIP List'" Subject: Re: Question about media desinations References: <001e01bf7520$98bba1e0$feba2ca6@dwillispc8> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit This raises an important point. I don't want to make changes to SDP and its usage within SIP to fix a problem that can be prevented by an administrative change in firewall behavior. If the firewalls did not return these error messages, do you still believe including the source port and address in the SDP is useful? -Jonathan R. Dean Willis wrote: > > Try scanning the net at 63.81.221.0/24, for example by telneting to port 122 > on 63.81.221.234 -- you'll get back lots of "packet filtered" messages. The > default behavior in most systems is to return such a message. Some firewall > implementors turn them off. Most don't. > > -- > Dean > > Jonathan asked: > > This presumes a firewall sends an ICMP error message when it discards > > the packet. I would > > think they would blackhole them, which will eliminate the ability to > > conduct this attack > > you describe. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Sun Feb 13 12:15:34 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11951 for ; Sun, 13 Feb 2000 12:15:34 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 31F8852D5; Sun, 13 Feb 2000 12:09:43 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 589DA52C4; Sun, 13 Feb 2000 12:09:36 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 953BD52C4 for ; Sun, 13 Feb 2000 12:09:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Sun Feb 13 12:08:46 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Sun Feb 13 12:06:29 EST 2000 Received: from dynamicsoft.com (1Cust116.tnt2.freehold.nj.da.uu.net [63.17.114.116]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA15858; Sun, 13 Feb 2000 12:04:45 -0500 (EST) Message-ID: <38A6E4FE.8D87A0C2@dynamicsoft.com> Date: Sun, 13 Feb 2000 12:08:14 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson Cc: ak@hplb.hpl.hp.com, sip@lists.research.bell-labs.com Subject: Re: Question about Call comparaison References: <200002122034.OAA09586@b04a45.exu.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Sean Olson wrote: > > > > I'm confused; having it CS is easier. I'll store the tag as a string, > > > and do a normal > > > string comparison on it to "get the case right". > > > Is this an argument for CS names or CS values? Both are case sensitive. > > > Right, actually it depends on the implementation. Currently our SipURL > > class has attributes for RFC 2543 defined SIP URL parameters: user, > > maddr ttl, transport, and method, whereas other-params are stored in a > > map. > > > > We take a very similar approach. > > > There are advantages and disadvantages to this approach. Amongst the > > advantages is that it saves us from having to remember the actual > > attribute name used on the wire for these "well-defined" attributes, and > > that retrieval is faster than having to lookup in a hashtable or what > > have you. > > > > Exactly. Thats fine, I still don't see why case insensitivity helps you. Consider the tag parameter. The parameter is case sensistive, which means "tag" is the one defined in rfc2543, and "TAG" is an other-param. So, when you need to generate the message, read your tag parameter attribute from the SipURL class, and then spit out "tag=" + myURL.tag(); or whatever. I can understand why you'd prefer case insensitive if "tag" and "TAG" both refer to the same thing, but you needed to remember which was received. > If parameter names are case sensitive, then what is the "correct" case for > the standard SIP URL parameters (is it "Transport", "TRANSPORT", "transport", > etc?). Or are you saying that a SIP URL with a "transport=tcp" parameter > does not match a SIP URL with a "Transport=tcp" parameter (where both cases > would be interpreted as a correctly formatted transport parameter)? Yes, that is what I'm saying. I believe this is what is implied in http 1.1 also. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Sun Feb 13 12:25:46 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11983 for ; Sun, 13 Feb 2000 12:25:45 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 8A3BB52C4; Sun, 13 Feb 2000 12:23:20 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E85D452D4; Sun, 13 Feb 2000 12:23:19 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id DEFFC52C4 for ; Sun, 13 Feb 2000 12:23:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Sun Feb 13 12:21:31 EST 2000 Received: from smtp-out2.bellatlantic.net ([199.45.39.157]) by dusty; Sun Feb 13 12:19:13 EST 2000 Received: from cs.columbia.edu (adsl-151-198-20-48.bellatlantic.net [151.198.20.48]) by smtp-out2.bellatlantic.net (8.9.1/8.9.1) with ESMTP id MAA18174; Sun, 13 Feb 2000 12:21:21 -0500 (EST) Message-ID: <38A6E84B.B9FFEEC7@cs.columbia.edu> Date: Sun, 13 Feb 2000 12:22:19 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Dean Willis , "'SIP List'" Subject: Re: Question about media desinations References: <001e01bf7520$98bba1e0$feba2ca6@dwillispc8> <38A6E5B6.F0C3E412@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Generally speaking, unless there's a strong reason not to, CS comparison is far preferable, since with UTF-8, doing CI comparison is non-trivial. In full fledged OS environments, somebody probably has already taken care of all the hassle of deciding what the upper case equivalents of different characters are, but in an embedded environment, most people are going to deal correctly with ASCII, if we're lucky. Thus, to avoid I18N surprises later, byte-by-byte comparison (i.e, CS) seems generally preferable unless we are forced by convention, e.g., for hostnames (where currently non-ASCII letters are less of an issue) and for header names (where non-ASCII choices for standardized headers are not likely). CS comparison is also somewhat slower. From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 14 13:04:13 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19602 for ; Mon, 14 Feb 2000 13:04:13 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4A60452DA; Mon, 14 Feb 2000 12:59:09 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D57BB52E0; Mon, 14 Feb 2000 12:59:07 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 7E9A552F0 for ; Wed, 9 Feb 2000 17:03:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 9 17:01:44 EST 2000 Received: from NOD.RESTON.MCI.NET ([166.45.6.38]) by dusty; Wed Feb 9 16:59:29 EST 2000 Received: from SKOLEM2 ([166.45.3.11]) by shoe.reston.mci.net (PMDF V5.2-32 #33823) with ESMTP id <01JLPLX7VI9W94E4Y4@shoe.reston.mci.net> for sip@lists.research.bell-labs.com; Wed, 9 Feb 2000 17:01:41 EST Date: Wed, 09 Feb 2000 14:01:39 -0800 From: Paul Krumviede Subject: Re: using RADIUS authentication for SIP requests In-reply-to: <86256880.005CE532.00@mwgate02.mw.3com.com> To: Jerry Mahler , sip@lists.research.bell-labs.com Message-id: <917127124.950104899@SKOLEM2> MIME-version: 1.0 X-Mailer: Mulberry/2.0.0b8 (Win32) Content-type: text/plain; format=flowed; charset=us-ascii Content-disposition: inline Content-transfer-encoding: 7BIT Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7BIT --On Wednesday, 09 February, 2000 10:51 -0600 Jerry Mahler wrote: > Does anyone know of a way to authenticate SIP requests using a RADIUS > server? > > Using a RADIUS server (which uses CHAP) to authenticate SIP requests > that use BASIC authentication is not difficult. The SIP Server (user > agent or proxy) can simply spoof a CHAP challenge and response based on > the username and password contained in the SIP request's Authorization > (or Proxy-Authorization) header and submit it to the RADIUS server. > However, BASIC authentication is quite weak and therefore many > implementations may not support it. > > Using a RADIUS server to authenticate SIP requests that use DIGEST > authentication is impossible. This is because the method of producing > the DIGEST response is very different from the method of producing the > CHAP response. Therefore, a SIP Server (user agent or proxy) which > receives a DIGEST challenge and response cannot spoof a CHAP challenge > and response to a RADIUS server. > > Does anyone have a solution to this problem? Perhaps a new > authentication mechanism (such as CHAP, in addition to BASIC and DIGEST) > is in order? Note that in the case of CHAP, a RADIUS server has no way of authenticating the requestor (other than by source IP address, which isn't very strong). Running such an authentication protocol over something that did provide such authentication might be useful. An alternative would be to look at ways of specifying a way to carry digest authentication in RADIUS; a motivation for doing so might be the desire to use the HMAC construction in HTTP digest rather than the construction in CHAP. -paul From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 14 13:11:12 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19833 for ; Mon, 14 Feb 2000 13:11:11 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 5AE0152DB; Mon, 14 Feb 2000 13:08:13 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9273552E4; Mon, 14 Feb 2000 13:08:12 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 3EB7E52DB for ; Mon, 14 Feb 2000 13:07:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Feb 14 13:05:13 EST 2000 Received: from exchange.santera.com ([38.197.52.6]) by dusty; Mon Feb 14 13:02:52 EST 2000 Received: from rbadriw.santera.com (rbadrip.santera.com [38.197.52.72]) by exchange.santera.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id DZCGF6PD; Mon, 14 Feb 2000 12:08:46 -0600 Message-ID: <013901bf7715$d1583260$4834c526@rbadriw.santera.com> From: "Raja Badri" To: "sip ML" Subject: SIP BCP-T question Date: Mon, 14 Feb 2000 12:03:36 -0600 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0136_01BF76E3.860520C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0136_01BF76E3.860520C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have one question regarding the SIP BCP-T. INFO message outlines the Mid-Call ISUP messages. What is the reason behind not including the ISUP maintenance=20 messages like Block, Unblock and Reset ? Thanks, Raja Badri Santera Systems Inc. ------=_NextPart_000_0136_01BF76E3.860520C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I have one question regarding the = SIP=20 BCP-T.
INFO message = outlines the=20 Mid-Call ISUP messages.
What is the reason behind not = including the ISUP=20 maintenance
messages like Block, Unblock and = Reset=20 ?
 
Thanks,
Raja Badri
Santera Systems Inc.
 
------=_NextPart_000_0136_01BF76E3.860520C0-- From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 14 13:25:57 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20195 for ; Mon, 14 Feb 2000 13:25:55 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id AA0AF52BB; Mon, 14 Feb 2000 13:23:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 2E03A52DC; Mon, 14 Feb 2000 13:23:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id AA63D52BB for ; Mon, 14 Feb 2000 13:23:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 14 13:21:53 EST 2000 Received: from l3mail02.level3.com ([209.244.1.161]) by dusty; Mon Feb 14 13:19:33 EST 2000 Received: by level3.com with Internet Mail Service (5.5.2448.0) id <149SQQ60>; Mon, 14 Feb 2000 11:20:01 -0700 Message-ID: <6DD3824BDF75D211930E0008C71EC920057B50E3@l3lsvlmail02.l3.com> From: Aparna.Vemuri@Level3.com To: raja.badri@santera.com, sip@lists.research.bell-labs.com Subject: RE: SIP BCP-T question Date: Mon, 14 Feb 2000 11:20:26 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Raja, Blocking/ resetting of circuits and circuit-groups is not necessary between MGCs, circuits here are 'paths' over IP. Thanks, Aparna Aparna V. Level (3) Communications. -----Original Message----- From: Raja Badri [ mailto:raja.badri@santera.com ] Sent: Monday, February 14, 2000 11:04 AM To: sip ML Subject: SIP BCP-T question Hi, I have one question regarding the SIP BCP-T. INFO message outlines the Mid-Call ISUP messages. What is the reason behind not including the ISUP maintenance messages like Block, Unblock and Reset ? Thanks, Raja Badri Santera Systems Inc. From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 14 15:04:02 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22650 for ; Mon, 14 Feb 2000 15:04:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 6249852DC; Mon, 14 Feb 2000 15:01:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C739852E0; Mon, 14 Feb 2000 15:01:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 4ADB052DC for ; Mon, 14 Feb 2000 15:01:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 14 14:59:30 EST 2000 Received: from atlrel1.hp.com ([156.153.255.210]) by dusty; Mon Feb 14 14:57:10 EST 2000 Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by atlrel1.hp.com (Postfix) with ESMTP id 435231559 for ; Mon, 14 Feb 2000 14:59:27 -0500 (EST) Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238]) by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id TAA05978; Mon, 14 Feb 2000 19:59:23 GMT Message-ID: <38A85EA3.6DB9A152@hplb.hpl.hp.com> Date: Mon, 14 Feb 2000 19:59:31 +0000 From: Anders Kristensen Organization: HP Labs X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: SIP Subject: Extension negotiation draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit I have a couple of suggestions wrt. the serverfeatures draft: 1. Define Supported in the base spec. 2. Do *not* let presence of the Supported header implicitly signal support for the extension negotiation mechanism. 3. Drop the reversed domain name extension naming convention. 4. Rename the negotiation extension. 5. Define "all-extensions-listed" tag to be used in Supported header. I'll go through these in turns. 1. Define Supported in the base spec. The draft can be seen as having two parts: the definition of the Supported header and a proposal for a feature negotiation mechanism. I think the two should be separated. It makes perfectly good sense for a server to signal supported features in an OPTIONs response without having to implement the negotiation mechanism, and likewise, clients should be allowed to indicate that they support, say, reliable 1xx's without having to implement the negotiation mechanism. So assuming the two should be split, the Supported header must be defined elsewhere. I think it belongs in the base spec because it's the direct equivalent to Unsupported which is in the base spec, it's universally useful, and it's really simple enough to go in there. 2. Do *not* let presence of the Supported header implicitly signal support for the extension negotiation mechanism. This is a corollory of the previous argument. If UAs can list supported features independent of the negotiation mechanism then presence of the Supported header cannot be taken to implicitly indicate support for the latter. 3. Drop the reversed domain name feature naming convention. It makes messages longer and is unnecessary. The (primary) justifiction for the extension negotiation mechanism is that servers need to know what features are supported by clients. It seems to me that the simplest way to meet this requirement is for clients to always tell servers what features they support (and BTW this is another argument for defining Supported in the base spec). Now, the reason why this answer is not enough must be the potentially large overhead of listing all these extensions all the time. Hence SIZE MATTERS! Anything we can do to minimize the size overhead of signaling supported features makes it more practical for us to use the simpler and more efficient mechanism of just listing all supported features always. The use of the short header form and the proposed implicit serverfeature support is further testament to the need to keep messages short. There may be times where it really isn't practical to list all supported extensions, and for these cases we still need the negotiation. For this reason, and *because it's unnecessary*, I propose we drop the convention of using reversed domain name prefixes as namespace identifiers for extension tags. First, as I've mused on a previous occasion, the vast majority (if not all) extensions to come into widespread, regular use will belong to the org.ietf.sip namespace anyway, making this prefix redundant, and secondly, I don't even think we need these namespaces anyway. We don't have namespaces for header names or status codes, and MIME has gotten along just fine for years without namespaces for its media types (of which there will probably always be many more than there will be SIP extensions). We could use the "x-" prefix for experimental or proprietary extensions or continue to use the domain namespaces for this purpose. 4. Rename the negotiation extension. Follows from 1. and 4. Maybe just call the extension "negotiate". 5. Define "all-extensions-listed" tag to be used in Supported header. In order to avoid unnecessary round-trips it would be good if clients can indicate that they have listed *all* supported extensions in the Supported header. This can be done by defining a new token with that meaning. I'd propose using "." since the semantics are kind of like that of "."s use in natural written language (and tokens doesn't come much shorter). So, for example Supported: negotiate, 100rel, . would indicate that the sender supports the 100rel and negotiate extensions and *no* other extension. Hence there is no point for the server to ask whether extension "foo" is supported - it isn't. This tag can be seen as just identifying an extension of its own, and could be defined in its own document, or it could go into the base spec. I'd prefer the latter, since it seems like a generally very useful feature. Of course the same mechanism can be used by servers. So to summarize: the serverfeatures draft is a fine piece of work, but it just makes sense to try and minimize the need for extra "multiple-roundtrip" negotiation. Hence - UAs should be allowed to signal what features are supported without supporting negotiation - feature tags should be kept shortish - UAs should be able to say *all* features have been listed My 2 pence worths. Anders -- Anders Kristensen , http://www-uk.hpl.hp.com/people/ak/ Hewlett-Packard Labs, Bristol, UK From tal@lists.research.bell-labs.com Mon Feb 14 16:25:47 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24190 for ; Mon, 14 Feb 2000 16:25:47 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix, from userid 21643) id 6B21052EC; Mon, 14 Feb 2000 16:25:18 -0500 (EST) To: sip-archive@ietf.org Subject: subscription check (sip@lists.research.bell-labs.com: sip-archive@lists.ietf.org) From: listcheck@lists.research.bell-labs.com Reply-To: listcheck@lists.research.bell-labs.com Message-Id: <20000214212518.6B21052EC@lists.research.bell-labs.com> Date: Mon, 14 Feb 2000 16:25:18 -0500 (EST) Sender: tal@lists.research.bell-labs.com This is a subscription check. Automatically generated by ListCheck. DO NOT REPLY UNLESS SOME OF THE INFORMATION BELOW IS INCORRECT. On the mailing list called: sip@lists.research.bell-labs.com You are subscribed by the name: sip-archive@lists.ietf.org [ Note to Ascend/Nortel/BayNetworks employees and companies involved in recent mergers: Is your email address going to change? This message tells you how to update your subscription to this mailing list! Save it for reference! ] DO YOU WANT TO BE REMOVED FROM THIS MAILING LIST? If this is so, please send email to majordomo@lists.research.bell-labs.com with the words unsubscribe sip sip-archive@lists.ietf.org on the first line of the message. A program will read this and remove you from the list. It isn't a smart program, so you have to type exactly what is above. The program also doesn't read the "Subject:" header, so put anything there, or nothing at all. If this does not work, please send email to tal@lists.research.bell-labs.com and he will manually process the request. He can not read your mind so please give him explicit instructions like: "Please remove sip-archive@lists.ietf.org from sip@lists.research.bell-labs.com" You can make it even easier if you forward this message to him with the words "please remove me" at the top of the message. IF YOUR EMAIL ADDRESS IS WRONG: If you are receiving this message, the address is in some ways correct or is forwarded to you. Maybe mail to an old account is being forwarded or your company name has changed and the old address is working temporarily. We would prefer to have your new address. TO CORRECT/CHANGE YOUR EMAIL ADDRESS: Please send email to majordomo@lists.research.bell-labs.com with these two lines of text: unsubscribe sip sip-archive@lists.ietf.org subscribe sip YOURNEWADDRESS@HOST (replace YOURNEWADDRESS@HOST with your new email address) A program will read this and remove you from the list. It isn't a smart program, so you have to type exactly what is above. The program also doesn't read the "Subject:" header, so put anything there, or nothing at all. If the above confuses you, please send email to tal@lists.research.bell-labs.com and request that the change be made. He is not psychic, so please give him explicit instructions like: "I am on sip@lists.research.bell-labs.com as sip-archive@lists.ietf.org but I would rather be on as so_and_so@where.com" LOCAL RE-FORWARDING TO MULTIPLE PEOPLE: You may get this message because someone forwards it to you (and maybe a couple friends) automatically. If this is so, you should talk to them if you want to discontinue your subscription or change your address. IF YOU GET EVERY MESSAGE TWICE: Please send email to tal@lists.research.bell-labs.com ...we'd love to fix the problem. It will be most helpful if you forward the COMPLETE headers from both copies. (Including all those "Received:" headers!) IF YOU ARE GOING ON AN EXTENDED VACATION: If you would like to be removed for a month or more and then be re-added automatically, send the "start and stop" dates and name of the list to tal@lists.research.bell-labs.com and he will do his best to accommodate you. (Students: Please remember this in the spring!) Otherwise, you do not need to reply. On the other hand, PLEASE save save this message for future reference. You will receive this message once for each mailing list that you are on via this server. We will be sending this message about three times a year. Thank you, ListCheck From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 15 09:50:10 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05668 for ; Tue, 15 Feb 2000 09:50:07 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A511652BB; Tue, 15 Feb 2000 09:47:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 2BBDB52C8; Tue, 15 Feb 2000 09:47:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id A08EF52BB for ; Tue, 15 Feb 2000 09:47:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Feb 15 09:46:16 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Tue Feb 15 09:43:56 EST 2000 Received: from cs.columbia.edu (deccanqueen.cs.columbia.edu [128.59.19.199]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id JAA25581; Tue, 15 Feb 2000 09:46:14 -0500 (EST) Message-ID: <38A9668A.C29E00E9@cs.columbia.edu> Date: Tue, 15 Feb 2000 09:45:30 -0500 From: Gautam Nair Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Cc: Henning Schulzrinne Subject: [Fwd: I-D ACTION:draft-nair-sip-dhcp-01.txt] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit A new version of the Internet-Draft - DHCP Option for SIP Servers - is available. The significant changes over the previous draft are: The number of sub-options have been reduced to 2. The DNS A record sub-option has been removed since it was redundant. The DNS SRV record has been effectively duplicated in the IP address list sub-option. Feedback and comments are appreciated. Gautam Nair. -------- Original Message -------- Subject: I-D ACTION:draft-nair-sip-dhcp-01.txt Date: Tue, 15 Feb 2000 08:36:20 -0500 From: Internet-Drafts@ietf.org (by way of Ralph Droms ) Reply-To: Internet-Drafts@ietf.org To: DHCPv4 discussion list A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DHCP Option for SIP Servers Author(s) : G. Nair, H. Schulzrinne Filename : draft-nair-sip-dhcp-01.txt Pages : 8 Date : 14-Feb-00 This document defines a DHCP option that contains one or more pointers to one or more SIP servers . This enables a SIP client to obtain the addresses of the SIP servers during bootup. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nair-sip-dhcp-01.txt 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-nair-sip-dhcp-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-nair-sip-dhcp-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. Content-Type: text/plain Content-ID: <20000214115153.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nair-sip-dhcp-01.txt From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 15 12:06:08 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13935 for ; Tue, 15 Feb 2000 12:06:07 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 19CCB52C8; Tue, 15 Feb 2000 12:03:25 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8727052D4; Tue, 15 Feb 2000 12:03:24 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C65C752C8 for ; Tue, 15 Feb 2000 12:03:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 15 12:02:04 EST 2000 Received: from gwu.ericy.com ([208.196.3.162]) by dusty; Tue Feb 15 11:59:44 EST 2000 Received: from mr3.exu.ericsson.se (mr3u.ericy.com [208.238.116.100]) by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id LAA04939; Tue, 15 Feb 2000 11:02:01 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr3.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id LAA09167; Tue, 15 Feb 2000 11:02:01 -0600 (CST) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id LAA28744; Tue, 15 Feb 2000 11:02:00 -0600 (CST) Received: (from exuadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id LAA11063; Tue, 15 Feb 2000 11:01:58 -0600 (CST) Message-Id: <200002151701.LAA11063@b04a24.exu.ericsson.se> Subject: Re: When to send 183? To: dean.willis@wcom.com (Dean Willis) Date: Tue, 15 Feb 2000 11:01:57 -0600 (CST) Cc: ssubbara@cisco.com (Srinath Subbarayan), hgs@cs.columbia.edu, jdrosen@dynamicsoft.com, sip@lists.research.bell-labs.com In-Reply-To: <001001bf751f$00325dc0$feba2ca6@dwillispc8> from "Dean Willis" at Feb 12, 2000 12:04:19 AM From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit >> Wouldn't a "410 The number you have reached has been disconnected" >> message serve the same purpose for native clients? I sure would >> prefer to read the text on a display than suffer through the >> recording. I beleive this is a more appropriate approach if >> you *know* for a fact that you're terminating on a native client. >> If you don't know whether you're hitting a PSTN gateway, I'd >> argue for playing the announcement. > >As I understand it, the SS7 release code is often quite vague, and certainly >doesn't convey the "NEW NUMBER IS . . . " information contained in the voice >recording. Grab Q.850. On page Page 5, cause code 22 -- what is the information conveyed in the diagnostic field? Regardless of how often this is used, my argument is that, if it is present, it would be appropriate to return it as a 410 message to the client instead of reading the announcement. In the cases that the release code is too vague to determine this information, you are absolutely correct: a 1xx early media message is the only available method for conveying the error information to the user (unless you want to set up a full call, which may have billing implications, depending on your network architecture). >AS for 180 with ring-SDP -- how does the network gateway anticipate the ring >treatment that will be applied by a domestic terminating switch? Can't, can >it? > >I'd suggest that the easiest general solution is to send a 183 with media >following the ACM. This gets the RTP stream established in time for network >call treatment. You're right. My mistake (for some reason, I was thinking that ACM had event code as an optional parameter). I'd argue that this situation would be best handled by the 183 for early media, followed by an SDP-less 180 when and if a CPG arrives with an event code of 1 (alerting) present. It's far less elegant than I was hoping, but it works. -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 15 14:28:25 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19589 for ; Tue, 15 Feb 2000 14:28:22 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 94F5F52C4; Tue, 15 Feb 2000 14:25:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E8A0D52C8; Tue, 15 Feb 2000 14:25:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id B6E7352C4 for ; Tue, 15 Feb 2000 14:25:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 15 14:23:34 EST 2000 Received: from mercury.Sun.COM ([192.9.25.1]) by dusty; Tue Feb 15 14:21:10 EST 2000 Received: from engmail2.Eng.Sun.COM ([129.146.1.25]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA00785 for ; Tue, 15 Feb 2000 11:20:52 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail2.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA12588 for ; Tue, 15 Feb 2000 11:20:51 -0800 (PST) Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id LAA11743; Tue, 15 Feb 2000 11:20:49 -0800 (PST) Message-Id: <200002151920.LAA11743@nasnfs.eng.sun.com> Date: Tue, 15 Feb 2000 11:21:59 -0800 (PST) From: James Kempf Reply-To: James Kempf Subject: Discovering SIP Servers To: sip@lists.research.bell-labs.com Cc: James.Kempf@Eng.Sun.COM MIME-Version: 1.0 Content-Type: MULTIPART/mixed; BOUNDARY=Gang_of_Elks_029_000 X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --Gang_of_Elks_029_000 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: DWBAX7+ur2ChDNGm198lDw== Attached is an individual submission on how to find SIP servers using SLP, including a service template for SIP. The service template defines the SLP attributes advertised by a SIP server for discovery. The draft may be of interest to members of the group, which is why I've posted it. As an aside, there has been some concern expressed on other lists about the size of an SLP implementation, which might impact the usability of SLP in small devices, such as phones. We have done a client side implementation of the minimal SLP UA specified by RFC 2608 in 5K of uncompressed Java bytecodes. Please send any comments, questions, and criticisms jak --Gang_of_Elks_029_000 Content-Type: TEXT/plain; name="draft-kempf-sip-findsrv-00.txt"; charset=us-ascii; x-unix-mode=0664 Content-Description: draft-kempf-sip-findsrv-00.txt Content-MD5: bY0i5RFY5veq23a4FruzCA== Session Initiation Protocol James Kempf INTERNET DRAFT Sun Microsystems Feburary 8, 2000 Jonathan Rosenberg dynamicsoft Finding a SIP Server With SLP draft-kempf-sip-findsrv-00.txt Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are work- ing documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also dis- tribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as refer- ence material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract The Session Initiation Protocol (SIP) allows a user to communicate with a local SIP proxy and registrar, primarily for registration services and the execution of certain features. Currently, SIP allows for discovery of these servers through multicast or through static configuration. In many cases, it may be more useful for a SIP client to discover local SIP servers based on features supported by those servers. In this document, an alternate technique is specified based on Service Location Protocol (SLP). The document contains a short description of how to use SLP for service discovery, and a SIP service type template. The service type template defines the attributes and service URL for a SIP server advertisement, suitable for SIP clients to discover. 1. Introduction Kempf, Rosenberg expires August 2000 [Page 1] INTERNET DRAFT Feburary 2000 The Session Initiation Protocol (SIP) [1] allows a user to communicate with a local SIP proxy and registrar. The server provides registration services and the execution of certain features. SIP allows for the discovery of servers through multicast and static configuration. The multicast mechanism allows a SIP client, or UAC, to send a REGISTER message to a well-known SIP multicast address. A registrar that is wil- ling to serve the user can then answer the request. Similarly, a UAC can send an INVITE message via multicast in order to determine its local outbound proxy. This approach is limiting, however, if many SIP servers are distributed throughout the domain. Different servers may have differing capabili- ties. Some technique is required whereby a UAC can find a server that supports the particular characteristics it needs. In this document, we describe how to use Service Location Protocol (SLP)[2] for configuring a UAC with a SIP proxy or registrar server. SLP is a new protocol for dynamically discovering contact information for a service. SLP is specifically designed for co-operatively managed networks, and not for the Internet, so the techniques described in RFC 2543 would still apply if the SIP client is required to directly connect with a server on the Internet. Since SLP supports querying for services based on attributes, using SLP allows a SIP client to find a locally available SIP server meeting its requirements with regard to transport protocol and other characteristics. Querying by characteristic reduces the amount of network traffic involved in discovering a server, and the amount of computation the client is required to perform before starting the SIP session. Section 8 contains a service type template [3] describing the attributes advertised by a SIP server and the format of the service URL returned as a result of an SLP query. 2. Notation Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [5]. 3. Terminology We reproduce here some SLP terminology from RFC 2608 for readers unfamilar with SLP. User Agent (SLP UA)- A process working on the user's behalf to establish contact with some service. The SLP UA retrieves service information from the Service Agents, using multicast, or Kempf, Rosenberg expires August 2000 [Page 2] INTERNET DRAFT Feburary 2000 Directory Agents, using unicast. Service Agent(SA)- A process working on behalf of one or more services to advertise the services and their capabilites. The SA listens for multicast SLP UA requests, and registers its advertisements with DAs if any DAs are available. Directory Agent(DA)- A process which collects service advertisements. A DA acts as a cache to consolidate service advertisements so a SLP UA can use unicast instead of multicast to obtain service advertisements. Scope - A set of services, typically making up a logical administrative group. Service Advertisement - A URL, attributes, and a lifetime (indicating how long the advertisement is valid), providing service access information and capabilities description for a particular service. 4. Using SLP for SIP Server Discovery SLP provides the framework in which a SIP client finds an appropri- ate local registrar or proxy/redirect server. Here is a description of how an SIP client finds its server using SLP: 1. The SIP server implements an SLP SA while the UAC implements an SLP UA. 2. The SIP SA constructs a service advertisment consisting of a service URL, attributes and a lifetime. The URL has an appropriate service type, either "service:sip:proxy" if the server is a proxy/redirect server or "service:sip:registrar" if the server is a registrar server, and attributes defined according to the template in Section 8. 3. When the SIP client requires contact information for a SIP server, the SLP UA either contacts the DA using unicast or the SA using multicast. The SLP UA includes a query based on the attributes to indicate the characteristics of the server it requires. 4. Once the SLP UA has the contact information for the SIP server, the UAC can either send a registration (if the UAC is seeking a registrar server) or an INVITE (if the UAC is seeking a local outbound proxy/redirect server). The service URL returned from the SLP query includes the IP address or host name, and, optionally, the port number of the SIP server. If the port number is not included, the SIP client uses the IANA-assigned Kempf, Rosenberg expires August 2000 [Page 3] INTERNET DRAFT Feburary 2000 SIP port, 5060. This procedure is exactly the same for any client/server pair imple- menting SLP and is not specific to SIP. SLP provides a number of advantages over SIP-specific multicast and static configuration. The major advantage of SLP is that clients can specify the attributes describing the desired server. The UAC can find a server that supports exactly the features it needs without requiring every server to support all SIP features. With SLP, an enterprise can support a heterogeneous mix of servers and UACs can find those that best suit their needs. Additionally, SLP contains a number of scaling mechanisms (DAs, scopes), that facilitate deployment in large enterprise networks, as well as in smaller networks. 5. Scalability SLP contains a mechanism, called scopes, for grouping service advertisements. For example, a network administrator could arrange for all users in the Marketing Department to share access to a col- lection of service advertisements by putting their SLP UAs, SAs, and DAs into the same scope. Unless another deparment is in the same scope, their SLP UAs, SAs and DAs would not have access to service advertisements. Scopes don't control access to the services themselves, however, just to the advertisements. Scope configuration is not required, because SLP specifies a default scope that is used if no other scope is available. Scopes are one important scalability mechanism included in the SLP design. The other scaling mechanism is DAs. In small/home office networks, SLP UAs use multicast to contact SLP SAs. In larger, enterprise networks, the network can be configured with DAs to cache advertisements and reduce the amount of multicast traffic on the network. Again, DAs are not a required part of SLP but can be configured if necessary. Scope and DA information can be preconfigured for SLP agents by including them in the DHCP option record for SLP [4]. This allows the SLP agents to be configured without any local information. DHCP con- figuration is not necessary, however. SLP UAs can determine their scope and DA information dynamically, and DAs and SAs use the default scope if no other scope is configured. 6. Finding the Right Proxy for an Incoming Call Without SLP, SIP servers are typically organized into a hierarchy according to the hierarchy of DNS domain names. For example, Acme, Inc. has one top level domain and three second level domains, corresponding Kempf, Rosenberg expires August 2000 [Page 4] INTERNET DRAFT Feburary 2000 to the Sales, Marketing, and Engineering departments. The domain names are: acme.com - Top level domain sales.acme.com - Sales department mkt.acme.com - Marketing department eng.acme.com - Engineering department In a statically configured SIP system, each domain has one or several proxy servers per domain. The names of these servers are available from DNS, either through resolving a name directly or through using the DNS SRV record. If multiple proxies are configured to support a single domain (using DNS load balancing techniques), all of those servers contain the registration for a user. This is accomplished through some back end replication protocol, or through SIP multicast registrations. A call coming through the proxy server for the top level domain is resolved by determining in which domain the called party is located. The request is proxied to any proxy server in the called party's domain. In our previous example, if a call comes in for Joe User in the Engineering department, the Acme top level proxy can easily determine which which proxy to use by looking up the user in some corporate directory, as in the following figure: | | joe.user@acme.com | | v +----------------+ +------------------+ | | | | | acme.com proxy | <----> | Backend Database | | | | | +----------------+ +------------------+ ^ | v +--------------+ +--------------+ +----------------+ | | | | | | | mkt.acme.com | | eng.acme.com | | sales.acme.com | | registrar | | registrar | | registrar | | | | | | | +--------------+ | joe.user | +----------------+ +--------------+ Kempf, Rosenberg expires August 2000 [Page 5] INTERNET DRAFT Feburary 2000 If SLP is in use, a SIP system can be configured so that different registrar servers in the same domain support different capabilities. Thus, from the example, the Engineering domain might contain one registrar server that supports CPL [6] processing and another that supports CGI processing. A UAC can use SLP to discover a SIP registrar server supporting a particular set of capabilities that it needs. For example, suppose that Joe User wants to upload a CPL program to his SIP registrar. Joe can specify that his UAC use SLP to find a registrar that supports CPL [7] and register with it. As a consequence, the registration will not be available to other registrars/proxies. From the previous figure, the proxy server for acme.com can't simply use a static back end database to determine the next hop proxy, because a dynamically chosen one has a registration for the user: | | joe.user@acme.com | | v +----------------+ | | | acme.com proxy | | | +----------------+ ????? +------------------+ +------------------+ | | | | | cgi.eng.acme.com | | cpl.eng.acme.com | | registrar | | registrar | | | | | +------------------+ | joe.user | +------------------+ There are two ways this problem can be handled: 1. The top level proxy server can use SIP "forking" to try more than one next hop proxy server at once. Whichever proxy has a registration for the user will redirect or proxy there, and all others will return a 404 Not Found. This approach has the drawback of requiring the Kempf, Rosenberg expires August 2000 [Page 6] INTERNET DRAFT Feburary 2000 top level proxy to have a list of all possible proxies the user may have registered at. It could discover these using SLP (see Section 7 on non-SIP-UAs as SLP UAs), or be configured with them. 2. The top level proxy server multicasts the invitation to the SIP multicast address. The registrar with the registration will proxy the call to the user. All others will not respond. This approach has the advantage of requiring less configuration. 7. SIP Servers as SLP UAs Although SLP is primarily of interest by UACs for finding servers having particular characteristics, it may also be used by SIP servers for finding other SIP servers. As an example, in the previous section, the top level acme.com SIP proxy server could use SLP to locate the registrar servers in the eng domain. Although this does not help in finding which registrar server has the registration, it does allow the network of SIP servers to autoconfigure, in the event a server goes down or a new one is added, without requiring DNS updates or changing static configurations. In general, a SIP server locating other SIP servers does not include particular attributes in its query, other than the "transport" attribute that is required in every query. And, since SLP is only of use on cooperatively managed networks, a SIP proxy server in one top level domain can't use SLP over the Internet to locate the proxy in another. But a server MAY include a query if it requires that the contacted servers support particular characteristics. An example here is IP-level security. 8. The SIP Service Type Template SIP defines two different kinds of servers: registrars and proxy/ redirect servers. The features of both are different enough that separate service type templates are required. We define an abstract service type [3], with a concrete service type for the two different kinds of servers. 8.1 SIP Abstract Service Type Name of submitters: James Kempf Jonathan Rosenberg Language of service template: en Security Considerations: Kempf, Rosenberg expires August 2000 [Page 7] INTERNET DRAFT Feburary 2000 SIP clients can use Service Location Protocol to find SIP servers having particular security characteristics. If secure access to such information is required, SLP security should be used. Template text: ----------------------template begins here ------------------------ template-type = sip template-version = 0.0 template-description= The abstract service:sip type provides advertisements for clients seeing Session Initiation Protocol (SIP) service. Concrete types specialize the service:sip type for proxy/redirect and registrar servers. template-url-syntax= transport-attr-list transport-attr-list = ';transport=udp' / ';transport=tcp' / ';transport=udp,tcp' ;The SIP service URL includes the transport protocol or ;protocols that the server supports. While the client must include ;the protocol type in the query and therefore does not need this ;information, the transport protocol attribute is included in ;the URL in case the client passes the URL along to a third ;party, for example, by way of a SIP Request-URI. ;An example SIP service URL (for a proxy server) is: ; service:sip:proxy://telsrv:2021;transport=udp. ; transport = STRING X L M udp #Transport protocol used to contact the server. Servers can support #UDP, TCP, or both. This attribute is REQUIRED in every query. udp,tcp domain = STRING M L O #The name of the domain represented by the server. ip-security-mechanisms = STRING M L O #IP-level security mechanisms supported by the server. #Allowed values are: # # ipsec - The server supports IP level security (IPSEC). # tls - The server supports transport level security (TLS). # ipsec,tls Kempf, Rosenberg expires August 2000 [Page 8] INTERNET DRAFT Feburary 2000 sip-security-mechanisms = STRING M L O #SIP-level security mechanisms supported by the server. #Allowed values are: # # basic - The server supports basic authentication. # digest - The server supports digest authentication. # pgp - The server supports PGP authentication. # basic,digest,pgp options = STRING M L O #A collection of SIP option tags supported by the server. The tags #are appropriate for inclusion in the REQUIRE or OPTIONS #SIP request. extensions = STRING M L O #A list of extensions supported by the server. UACs use #this attribute to identify whether a server supports #a particular extension. ----------------------template ends here -------------------------- 8.2 SIP Proxy/Redirect Concrete Service Type Name of submitters: James Kempf Jonathan Rosenberg Language of service template: en Security Considerations: SIP clients can use Service Location Protocol to find SIP proxy/redirect servers having particular security characteristics. If secure access to such information is required, SLP security should be used. Template text: ----------------------template begins here ------------------------ template-type = sip:proxy template-version = 0.0 template-description= The service:sip:proxy type provides advertisements for clients seeking Session Initiation Protocol (SIP) proxy/redirect servers. template-url-syntax = ;inherited from abstract type. features = STRING M L O #A list of features supported by the server. Allowed values are: Kempf, Rosenberg expires August 2000 [Page 9] INTERNET DRAFT Feburary 2000 # # recursion - The server can recursively try addresses returned to # it in a redirect request. # forking - The proxy may fork off multiple requests in response to # a client request. # stateful - The proxy remembers incoming request that generated # outgoing requests and the corresponding outgoing # requests. # recursion,forking,stateful caller-preferences = BOOLEAN O #True if the server supports caller preferences. handles-e.164-addresses = BOOLEAN O #True if the server handles E.164 (telephone number) #addresses. An example is: # tel:5551234 ----------------------template ends here -------------------------- 8.3 SIP Registrar Concrete Service Type Name of submitters: James Kempf Jonathan Rosenberg Language of service template: en Security Considerations: SIP clients can use Service Location Protocol to find SIP registrar servers having particular security characteristics. If secure access to such information is required, SLP security should be used. Template text: ----------------------template begins here ------------------------ template-type = sip:registrar template-version = 0.0 template-description= The service:sip:registrar type provides advertisements for clients seeking Session Initiation Protocol (SIP) registrar servers. template-url-syntax = ;inherited from abstract type. app-services = STRING M L O #Application services supported by the server. Allowed values are: # Kempf, Rosenberg expires August 2000 [Page 10] INTERNET DRAFT Feburary 2000 # cpl - The server supports Call Processing Language (CPL) upload. # cgi - The server supports CGI upload. # cpl,cgi non-sip-urls = BOOLEAN O #True if the server supports nonSIP URLs in Contacts. ----------------------template ends here -------------------------- 9. An Example SLP Query From the example in Section 8, suppose Joe User's UAC is looking for a registrar server that supports CPL. The following SLP query can be used by the UAC to find a registrar server that supports CPL: (&(transport=udp)(app-services=cpl)) The transport type is required in all queries (indicated by the 'X' flag in the template). In this case, the UAC requires UDP. 10. Security Considerations Service type templates provide information that is used to inter- pret information obtained by clients through SLP. If the SIP tem- plate is modified or if a false template is distributed, SIP servers may not correctly register themselves, and SIP clients may not be able to interpret service information. SLP provides an authentication mechanism for SLP UAs to assure that ser- vice advertisments only come from trusted SAs [2]. If trust is an issue, particularly with respect to the information sought by the client about security mechanisms, then SLP authentication should be enabled in the network. 11. Summary This document describes how to use SLP to discover a SIP server. SLP allows the SIP client to specify characteristics of the SIP server that it requires, such as transport protocol type, SIP services sup- plied, application services supplied, etc. A service type template is defined that contains the attributes advertised by SIP servers. 12. Full Copyright Statement Copyright (C) The Internet Society (1997). All Rights Reserved. Kempf, Rosenberg expires August 2000 [Page 11] INTERNET DRAFT Feburary 2000 This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of devel- oping Internet standards in which case the procedures for copy- rights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 13. References [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg."SIP: Session Initiation Protocol".RFC 2543, March, 1999. [2] E. Guttman, C. Perkins, J. Veizades, and M. Day. "Service Loca- tion Protocol". RFC 2608, July, 1999. [3] E. Guttman, C. Perkins and J. Kempf. "Service Templates and ser- vice: Schemes", RFC 2609, July, 1999. [4] C. Perkins and E. Guttman. "DHCP Options for Service Location Protocol". RFC 2610, July, 1999. [5] S. Bradner. "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997. [6] J. Lennox and H. Schulzrinne. "Call Processing Language Framework and Requirements". draft-ietf-iptel-cpl-framework-01.txt. A work in progress. 14. Author's Addresses James Kempf Jonathan Rosenberg Sun Microsystems dynamicsoft Kempf, Rosenberg expires August 2000 [Page 12] INTERNET DRAFT Feburary 2000 901 San Antonio Rd. 200 Executive Drive UMPK15-214 Suite 120 Palo Alto, CA, 94040 West Orange, NJ, 07052 USA USA +1 650 786 5890 +1 732 741 7244 +1 650 786 6445(fax) +1 732 741 4778(fax) james.kempf@sun.com jdrosen@dynamicsoft.com Kempf, Rosenberg expires August 2000 [Page 13] --Gang_of_Elks_029_000-- From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 15 15:27:57 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21429 for ; Tue, 15 Feb 2000 15:27:56 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C313052BB; Tue, 15 Feb 2000 15:25:20 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3ED1B52C4; Tue, 15 Feb 2000 15:25:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 7C70F52BB for ; Tue, 15 Feb 2000 15:25:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 15 15:23:42 EST 2000 Received: from ns.fmmo.ca ([207.253.160.156]) by dusty; Tue Feb 15 15:21:22 EST 2000 Received: from localhost (fm-listproc@localhost) by ns.fmmo.ca (8.9.3/8.9.3) with ESMTP id PAA15061; Tue, 15 Feb 2000 15:16:50 -0500 Date: Tue, 15 Feb 2000 15:16:49 -0500 (EST) From: Francois Menard List Account To: James Kempf Cc: sip@lists.research.bell-labs.com, etremblay@mediatrix.com Subject: Re: Discovering SIP Servers In-Reply-To: <200002151920.LAA11743@nasnfs.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Excellent! I welcome this initiative. Will Sun release the source code of the minimal UA implementation ? -=Francois=- On Tue, 15 Feb 2000, James Kempf wrote: > Attached is an individual submission on how to find SIP servers using > SLP, including a service template for SIP. The service template defines > the SLP attributes advertised by a SIP server for discovery. The > draft may be of interest to members of the group, which is why > I've posted it. > > As an aside, there has been some concern expressed on other lists about > the size of an SLP implementation, which might impact the usability > of SLP in small devices, such as phones. We have done a client side > implementation of the minimal SLP UA specified by RFC 2608 in 5K of uncompressed > Java bytecodes. > > Please send any comments, questions, and criticisms > > > jak > From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 15 15:37:57 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21807 for ; Tue, 15 Feb 2000 15:37:55 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 13D2752C4; Tue, 15 Feb 2000 15:35:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 80FF352D4; Tue, 15 Feb 2000 15:35:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 8BD2C52C4 for ; Tue, 15 Feb 2000 15:35:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Feb 15 15:34:20 EST 2000 Received: from mercury.Sun.COM ([192.9.25.1]) by dusty; Tue Feb 15 15:32:00 EST 2000 Received: from engmail1.Eng.Sun.COM ([129.146.1.13]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA10114; Tue, 15 Feb 2000 12:34:02 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail1.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id MAA29942; Tue, 15 Feb 2000 12:34:00 -0800 (PST) Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id MAA13777; Tue, 15 Feb 2000 12:33:59 -0800 (PST) Message-Id: <200002152033.MAA13777@nasnfs.eng.sun.com> Date: Tue, 15 Feb 2000 12:35:09 -0800 (PST) From: James Kempf Reply-To: James Kempf Subject: Re: Discovering SIP Servers To: James.Kempf@eng.sun.com, fm-listproc@fmmo.ca Cc: sip@lists.research.bell-labs.com, etremblay@mediatrix.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 6sFNgag/kDaLlzU6Gp224Q== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk We're working on it. jak >Date: Tue, 15 Feb 2000 15:16:49 -0500 (EST) >From: Francois Menard List Account >To: James Kempf >cc: sip@lists.research.bell-labs.com, etremblay@mediatrix.com >Subject: Re: Discovering SIP Servers >MIME-Version: 1.0 > > >Excellent! > >I welcome this initiative. > >Will Sun release the source code of the minimal UA implementation ? > >-=Francois=- > >On Tue, 15 Feb 2000, James Kempf wrote: > >> Attached is an individual submission on how to find SIP servers using >> SLP, including a service template for SIP. The service template defines >> the SLP attributes advertised by a SIP server for discovery. The >> draft may be of interest to members of the group, which is why >> I've posted it. >> >> As an aside, there has been some concern expressed on other lists about >> the size of an SLP implementation, which might impact the usability >> of SLP in small devices, such as phones. We have done a client side >> implementation of the minimal SLP UA specified by RFC 2608 in 5K of uncompressed >> Java bytecodes. >> >> Please send any comments, questions, and criticisms >> >> >> jak >> > From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 15 17:56:23 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26665 for ; Tue, 15 Feb 2000 17:56:19 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 7FB6B52C4; Tue, 15 Feb 2000 17:53:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 51A4752C8; Tue, 15 Feb 2000 17:53:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 6E3E452C4 for ; Tue, 15 Feb 2000 17:53:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 15 17:52:33 EST 2000 Received: from howler.tri.sbc.com ([205.173.58.4]) by dusty; Tue Feb 15 17:50:13 EST 2000 Received: from sbctri.tri.sbc.com (sbctri [144.60.1.10]) by howler.tri.sbc.com (8.9.3/8.9.3) with ESMTP id QAA06866 for ; Tue, 15 Feb 2000 16:53:52 -0600 (CST) Received: from trimail2.tri.sbc.com (trimail2 [144.60.55.227]) by sbctri.tri.sbc.com (8.9.3/8.9.3) with ESMTP id QAA05222 for ; Tue, 15 Feb 2000 16:51:59 -0600 (CST) Received: by trimail2.tri.sbc.com with Internet Mail Service (5.5.2448.0) id <14H006NB>; Tue, 15 Feb 2000 16:51:58 -0600 Message-ID: <4D45BA2A58A7D3119E050008C7E69E29079084@trimail2.tri.sbc.com> From: "Schroeder, Tim" To: "'sip@lists.research.bell-labs.com'" Subject: RE: When to send 183? Date: Tue, 15 Feb 2000 16:51:48 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk From: Dean Willis [mailto:dean.willis@wcom.com] >> As I understand it, the SS7 release code is often quite vague, and certainly doesn't convey the "NEW NUMBER IS . . . " information contained in the voice recording. << It looks to me like the ACM message gets cause code 22, and the diagnostic field may *optionally* contain the new number. Also, it is not required that cause code 22 be supported, in which case cause code 1 is used instead. So, it could work well, but almost certainly wouldn't consistently work well. Tim Schroeder From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 15 19:52:07 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29288 for ; Tue, 15 Feb 2000 19:52:05 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id DC76A52C8; Tue, 15 Feb 2000 19:49:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 5085A52D4; Tue, 15 Feb 2000 19:49:24 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 51C3E52C8 for ; Tue, 15 Feb 2000 19:49:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 15 19:48:45 EST 2000 Received: from PMESMTP01.wcom.com ([199.249.20.1]) by dusty; Tue Feb 15 19:46:25 EST 2000 Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42256) id <0FPZ00501ZL1DK@firewall.mcit.com> for sip@lists.research.bell-labs.com; Wed, 16 Feb 2000 00:48:37 +0000 (GMT) Received: from ndcrelay.mcit.com ([166.37.172.49]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FPZ0043ZZL0TT@firewall.mcit.com>; Wed, 16 Feb 2000 00:48:37 +0000 (GMT) Received: from omzmta02.mcit.com (omzmta02.mcit.com [166.37.194.120]) by ndcrelay.mcit.com (8.8.7/) with ESMTP id AAA06346; Wed, 16 Feb 2000 00:48:46 +0000 (GMT) Received: from dwillispc8 ([166.35.148.173]) by omzmta02.mcit.com (InterMail v03.02.05 118 120) with SMTP id <20000216004835.MUQK10346@[166.35.148.173]>; Wed, 16 Feb 2000 00:48:35 +0000 Date: Tue, 15 Feb 2000 18:47:40 -0600 From: Dean Willis Subject: RE: When to send 183? In-reply-to: <38A47BD6.235031C9@pingtel.com> To: "Daniel G. Petrie" Cc: "Adam B. Roach" , Srinath Subbarayan , hgs@cs.columbia.edu, jdrosen@dynamicsoft.com, sip@lists.research.bell-labs.com Message-id: <002d01bf7817$6d222b40$ad9423a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit My argument is that you MUST send a 18x with early media immediately after receiving an ACM in order to have a media path established JUST IN CASE there is an unsignaled in-band call treatment. Every time, all the time, in a PSTN gateway. I believe this should be a 183 rather than a 180 due to the semantic difference -- a 180 means that something is being alerted, whereas a 183 just means that something is happening. This distinction allows UACes and proxies to be a little smarter about how the use the 18x message. Where some sort of release code can be determined, I firmly concur that the call should be appropriately finalized. -- Dean > -----Original Message----- > From: Daniel G. Petrie [mailto:dpetrie@pingtel.com] > Sent: Friday, February 11, 2000 3:15 PM > To: Dean Willis > Cc: Adam B. Roach; Srinath Subbarayan; hgs@cs.columbia.edu; > jdrosen@dynamicsoft.com; sip@lists.research.bell-labs.com > Subject: Re: When to send 183? > > > It seems that your argument is for early media, not necessarily > for a 183 status. The point I have been trying to make is > that the status 183 is too generic if the outcome is known > to be a call setup failure. One should avoid using the status > 183 if a more descriptive status can be provided. > > Early media makes sense with many different status. I think > that we need to be very careful in keeping these issues > separate. > From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 15 19:56:36 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29395 for ; Tue, 15 Feb 2000 19:56:35 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A2D9152D5; Tue, 15 Feb 2000 19:53:41 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 10B6F52D4; Tue, 15 Feb 2000 19:53:40 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 1655252D5 for ; Tue, 15 Feb 2000 19:53:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 15 19:52:17 EST 2000 Received: from PMESMTP02.wcom.com ([199.249.20.2]) by dusty; Tue Feb 15 19:49:57 EST 2000 Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #41713) id <0FPZ00H01ZR2L3@firewall.mcit.com> for sip@lists.research.bell-labs.com; Wed, 16 Feb 2000 00:52:14 +0000 (GMT) Received: from ndcrelay2.mcit.com ([166.37.172.6]) by firewall.mcit.com (PMDF V5.2-32 #41713) with ESMTP id <0FPZ00G6UZR2Z7@firewall.mcit.com>; Wed, 16 Feb 2000 00:52:14 +0000 (GMT) Received: from omzmta02.mcit.com (omzmta02.mcit.com [166.37.194.120]) by ndcrelay2.mcit.com (8.8.7/) with ESMTP id AAA10736; Wed, 16 Feb 2000 00:52:57 +0000 (GMT) Received: from dwillispc8 ([166.35.148.173]) by omzmta02.mcit.com (InterMail v03.02.05 118 120) with SMTP id <20000216005213.MUYY10346@[166.35.148.173]>; Wed, 16 Feb 2000 00:52:14 +0000 Date: Tue, 15 Feb 2000 18:51:17 -0600 From: Dean Willis Subject: RE: Question about media desinations In-reply-to: <38A6E5B6.F0C3E412@dynamicsoft.com> To: Jonathan Rosenberg Cc: IETF SIP Message-id: <002f01bf7817$ef092c80$ad9423a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Yes. Having both endpoints allows the firewall to construct a far more effective dynamic ACL. It also allows UAs to selectively bind their RTP streams to a specific partner, rather than waiting open-eared for a download of spam. -- Dean > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Sunday, February 13, 2000 11:11 AM > To: Dean Willis > Cc: 'SIP List' > Subject: Re: Question about media desinations > > > This raises an important point. I don't want to make changes to SDP and > its usage within SIP to fix a problem that can be prevented by an > administrative change in firewall behavior. If the firewalls did not > return these error messages, do you still believe including the source > port and address in the SDP is useful? > > -Jonathan R. > > Dean Willis wrote: > > > > Try scanning the net at 63.81.221.0/24, for example by > telneting to port 122 > > on 63.81.221.234 -- you'll get back lots of "packet filtered" > messages. The > > default behavior in most systems is to return such a message. > Some firewall > > implementors turn them off. Most don't. > > > > -- > > Dean > > > > Jonathan asked: > > > This presumes a firewall sends an ICMP error message when it discards > > > the packet. I would > > > think they would blackhole them, which will eliminate the ability to > > > conduct this attack > > > you describe. > > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 16 06:44:20 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22658 for ; Wed, 16 Feb 2000 06:44:16 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C8F0652BB; Wed, 16 Feb 2000 06:41:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3FA2852C4; Wed, 16 Feb 2000 06:41:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 2F06052BB for ; Wed, 16 Feb 2000 06:41:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 16 06:40:56 EST 2000 Received: from ietf.org ([132.151.1.176]) by dusty; Wed Feb 16 06:38:36 EST 2000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22577; Wed, 16 Feb 2000 06:40:36 -0500 (EST) Message-Id: <200002161140.GAA22577@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.research.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sip-info-method-02.txt Date: Wed, 16 Feb 2000 06:40:34 -0500 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --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 SIP INFO Method Author(s) : S. Donovan Filename : draft-ietf-sip-info-method-02.txt Pages : 10 Date : 15-Feb-00 This document proposes an extension to the Session Initiation Protocol (SIP). This extension adds the INFO method to the SIP protocol. The intent of the INFO method is to allow for the carrying of session related control information that is generated during a session. One example of such session control information is ISUP and ISDN signaling messages used to control telephony call services. This and other example uses of the INFO method may be standardized in the future. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-info-method-02.txt 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-info-method-02.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-info-method-02.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: <20000215140017.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-info-method-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-info-method-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000215140017.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 16 14:26:19 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10850 for ; Wed, 16 Feb 2000 14:26:09 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 66C6E52AB; Wed, 16 Feb 2000 14:23:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id BDDFE52BB; Wed, 16 Feb 2000 14:23:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 54F8252AB for ; Wed, 16 Feb 2000 14:23:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 16 14:22:40 EST 2000 Received: from PMESMTP02.wcom.com ([199.249.20.2]) by dusty; Wed Feb 16 14:20:21 EST 2000 Received: from ndcrelay.mcit.com ([166.37.172.49]) by firewall.mcit.com (PMDF V5.2-32 #41713) with ESMTP id <0FQ100G60F4YWI@firewall.mcit.com> for sip@lists.research.bell-labs.com; Wed, 16 Feb 2000 19:22:10 +0000 (GMT) Received: from omta4.mcit.com (omta4.mcit.com [166.37.204.6]) by ndcrelay.mcit.com (8.8.7/) with ESMTP id TAA04213; Wed, 16 Feb 2000 19:22:10 +0000 (GMT) Received: from sipdev4 ([166.35.146.138]) by omta4.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000216192405.BIAX32241@sipdev4>; Wed, 16 Feb 2000 19:24:05 +0000 Date: Wed, 16 Feb 2000 13:18:07 -0600 From: Robert Sparks Subject: RE: UAC use of tags received in responses In-reply-to: <38A33790.5A052AC6@dynamicsoft.com> To: "'Jonathan Rosenberg'" Cc: "''SIP List' (E-mail)'" , "'Henning Schulzrinne (E-mail)'" Reply-To: Robert.Sparks@wcom.com Message-id: <003201bf78b2$8f59c4c0$8a9223a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Since there have been no other comments, the suggestion now is to add the following to '11.3 Caller Receives Response to Initial Request': A UAC MUST copy the tag from a final response into the ACK of that response. The UAC MUST include that tag into all other subsequent requests if, and only if, the response was in the 200 class. The UAC MUST NOT include that tag in any subsequent requests beyond the ACK if the response was not in the 200 class. and changing the sentence in Section 6.41 To: from All subsequent transactions between two entities MUST include the "tag" parameter, as described in Section 11. to Section 11 details when the "tag" parameter MUST appear in subsequent requests. RjS > -----Original Message----- > From: owner-sip@lists.research.bell-labs.com > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Jonathan > Rosenberg > Sent: Thursday, February 10, 2000 4:11 PM > To: Robert.Sparks@wcom.com > Cc: 'SIP List' (E-mail); Henning Schulzrinne (E-mail) > Subject: Re: UAC use of tags received in responses > > > > > Robert Sparks wrote: > > > > One of the two requirements above must be modified to allow for this > > scenario. Changing the requirement on the proxy, having it > not add tags > > for some or all locally generated responses, leads to > problems determining > > the appropriate destination for the subsequent ACK (pointed > out by Jonathan > > Rosenberg). The better solution then (suggested by both > Jonathan and Alan > > Johnston) is to modify the behavior of the UAC such that: > > > > A UAC only copies a tag into subsequent requests if it > arrives in a > > 200 OK to an INVITE. > > > > I would further clarify this: > > A UAC copies the tag from the response into the ACK, but it MUST > NOT > copy the tag into any subsequent requests unless the response was > a 200 class response to an INVITE. > > Since ACK is a "subsequent" request after all. > > -Jonathan R. > > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 16 15:11:59 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12103 for ; Wed, 16 Feb 2000 15:11:53 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 348C252B6; Wed, 16 Feb 2000 15:09:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9C6B452C4; Wed, 16 Feb 2000 15:09:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id E35C552B6 for ; Wed, 16 Feb 2000 15:09:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 16 15:08:29 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Wed Feb 16 15:06:09 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA19988; Wed, 16 Feb 2000 15:08:27 -0500 (EST) Message-ID: <38AB0319.B3E2AF52@dynamicsoft.com> Date: Wed, 16 Feb 2000 15:05:45 -0500 From: Igor Slepchin Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Robert.Sparks@wcom.com Cc: "'Jonathan Rosenberg'" , "''SIP List' (E-mail)'" , "'Henning Schulzrinne (E-mail)'" Subject: Re: UAC use of tags received in responses References: <003201bf78b2$8f59c4c0$8a9223a6@mcit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Robert Sparks wrote: > > Since there have been no other comments, the suggestion now > is to add the following to '11.3 Caller Receives Response to > Initial Request': > > <...> > The UAC MUST include that tag into all other subsequent > requests if, and only if, the response was in the 200 class. CANCEL is an exception from that rule. People also argued for allowing BYE requests with no tag (though I am not very happy with the idea). --- Igor Slepchin From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 16 18:20:04 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18272 for ; Wed, 16 Feb 2000 18:20:02 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 5F90452BB; Wed, 16 Feb 2000 18:17:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id CA60752C4; Wed, 16 Feb 2000 18:17:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 73FDE52BB for ; Wed, 16 Feb 2000 18:17:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Feb 16 18:15:17 EST 2000 Received: from PMESMTP01.wcom.com ([199.249.20.1]) by dusty; Wed Feb 16 18:12:55 EST 2000 Received: from ndcrelay2.mcit.com ([166.37.172.6]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FQ10078RPW58F@firewall.mcit.com> for sip@lists.research.bell-labs.com; Wed, 16 Feb 2000 23:14:29 +0000 (GMT) Received: from omzmta01.mcit.com (omzmta01.mcit.com [166.37.194.119]) by ndcrelay2.mcit.com (8.8.7/) with ESMTP id XAA00724; Wed, 16 Feb 2000 23:15:09 +0000 (GMT) Received: from dwillispc8 ([166.35.148.173]) by omzmta01.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000216231424.HZOD10975@dwillispc8>; Wed, 16 Feb 2000 23:14:24 +0000 Date: Wed, 16 Feb 2000 17:12:47 -0600 From: Dean Willis Subject: 183 vs 180, When and Where, a Proposal In-reply-to: <4.2.0.58.20000216105725.00a1b5c0@farley.cisco.com> To: IETF SIP Cc: Taichi Fu Message-id: <000001bf78d3$56db2be0$ad9423a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Taichi Fu and I have been having a discussion on 18x provisional messages with media that may be worth sharing. Here's what I think we agreed to. For PSTN interworking, you really have to "listen" to the bearer channel to figure out what's going on (see previous discussion on release codes). Note that this is really quite different from a pure-IP scenario. If we don't have PSTN interworking, then a 180 means that a user is being alerted, and media on a 180 clearly indicates a custom message that can be played to the caller. For example, a French user might want to play back the distinctive French double-ring, and a Trekky might want to play a clip of Lt. Uhuru saying "Captain, there is an incoming call". We might also want to include a text message for the audio-impaired device or user, or present a visual notification such as a corporate logo. On the other hand, many UASes (and proxies) MAY choose to ignore the media on a 180. This can avoid very complex mixing scenarios in a forking environment. Devices MAY also choose to ignore the media on a 183, but this MUST be done very carefully. Media on a 183 for PSTN interworking is far more critical than that on a 180 -- it may provide the only useful information available to the caller for determining the cause of a call failure. Think very carefully before ignoring a 183. We suggest that a straight IP system, especially a UAS, SHOULD send 180 (which MAY have media) when alerting a user. A PSTN gateway SHOULD send a 183 with media when "launching" a call onto the PSTN. Devices MAY decide to ignore the media of a 180. Devices SHOULD present the media of a 183 to an end user, and MUST deal with the results of not doing so. A key point: Some have argued that 183 also has uses outside of PSTN interworking, whenever there is some status information describing a call which needs to be presented "in band", but there has been no actual notification delivered to a destination. For example, consider a proxy (P) that implements a forking search. An INVITE for "Joe" is delivered to P. P might, in parallel: 1) respond with a 183 containing media in two parts. part 1 is an html object with text="Your call is being forwarded by Joe's Finder Service". part 2 is an SDP object describing a media stream with a spoken rendition of the same text 2) send INVITES to all of the contacts Joe has on his contact list. This is probably a BAD usage of 183 -- the status information, while useful and entertaining, is not critical to the successful interworking of the call. Its presence could obfuscate an upstream forking system, and would provide no additional value to that system. This example SHOULD be implemented using a 180, not a 183. -- Dean From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 16 21:59:59 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21387 for ; Wed, 16 Feb 2000 21:59:56 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 6C1B652C4; Wed, 16 Feb 2000 21:57:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E1AA052C8; Wed, 16 Feb 2000 21:57:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 69BAC52C4 for ; Wed, 16 Feb 2000 21:57:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 16 21:56:18 EST 2000 Received: from farley.cisco.com ([171.71.153.30]) by dusty; Wed Feb 16 21:53:55 EST 2000 Received: from tfu-NT1 (dhcp-71-148-186.cisco.com [171.71.148.186]) by farley.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id SAA28733; Wed, 16 Feb 2000 18:56:09 -0800 (PST) Message-Id: <4.2.0.58.20000216174540.00d15450@farley.cisco.com> X-Sender: tfu@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 16 Feb 2000 18:59:33 -0800 To: Dean Willis From: Taichi Fu Subject: Re: 183 vs 180, When and Where, a Proposal Cc: IETF SIP In-Reply-To: <000001bf78d3$56db2be0$ad9423a6@mcit.com> References: <4.2.0.58.20000216105725.00a1b5c0@farley.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Dean, Thanks for the summary. I add a small note below the paragraph 6 from my understanding. Regards, -Taichi At 05:12 PM 2/16/00 -0600, Dean Willis wrote: >Taichi Fu and I have been having a discussion on 18x provisional messages >with media that may be worth sharing. Here's what I think we agreed to. > >For PSTN interworking, you really have to "listen" to the bearer channel to >figure out what's going on (see previous discussion on release codes). Note >that this is really quite different from a pure-IP scenario. > >If we don't have PSTN interworking, then a 180 means that a user is being >alerted, and media on a 180 clearly indicates a custom message that can be >played to the caller. For example, a French user might want to play back the >distinctive French double-ring, and a Trekky might want to >play a clip of Lt. Uhuru saying "Captain, there is an incoming call". We >might also want to include a text message for the audio-impaired device or >user, or present a visual notification such as a corporate logo. > >On the other hand, many UASes (and proxies) MAY choose to ignore the media >on a 180. This can avoid very complex mixing scenarios in a forking >environment. > >Devices MAY also choose to ignore the media on a 183, but this MUST be done >very carefully. Media on a 183 for PSTN interworking is far more critical >than that on a 180 -- it may provide the only useful information available >to the caller for determining the cause of a call failure. Think very >carefully before ignoring a 183. > >We suggest that a straight IP system, especially a UAS, SHOULD send 180 >(which MAY have media) when alerting a user. A PSTN gateway SHOULD send a >183 with media when "launching" a call onto the PSTN. Devices MAY decide to >ignore the media of a 180. Devices SHOULD present the media of a 183 to an >end user, and MUST deal with the results of not doing so. That means, for SIP and PSTN interworking (a PSTN gateway converting between SIP messages and SS7 messages): (1) For a call from SIP to PSTN, a PSTN gateway SHOULD respond with 183 , and (2) For a call from PSTN to SIP, a PSTN gateway SHOULD expect to receive 180. An asymmetry. >A key point: > >Some have argued that 183 also has uses outside of PSTN interworking, >whenever there is some status information describing a call which needs to >be presented "in band", but there has been no actual notification delivered >to a destination. > >For example, consider a proxy (P) that implements a forking search. An >INVITE for "Joe" is delivered to P. P might, in parallel: > 1) respond with a 183 containing media in two parts. > part 1 is an html object with > text="Your call is being forwarded by Joe's Finder Service". > part 2 is an SDP object describing a media stream with a > spoken > rendition of the same text > 2) send INVITES to all of the contacts Joe has on his contact list. > >This is probably a BAD usage of 183 -- the status information, while useful >and entertaining, is not critical to the successful interworking of the >call. Its presence could obfuscate an upstream forking system, and would >provide no additional value to that system. This example SHOULD be >implemented using a 180, not a 183. > >-- >Dean > From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 17 01:48:02 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27517 for ; Thu, 17 Feb 2000 01:48:02 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 06FFD52C8; Thu, 17 Feb 2000 01:45:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6E7AA52D4; Thu, 17 Feb 2000 01:45:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C5E3852C8 for ; Thu, 17 Feb 2000 01:45:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 17 01:44:12 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Thu Feb 17 01:41:49 EST 2000 Received: from dynamicsoft.com (1Cust188.tnt1.freehold.nj.da.uu.net [63.17.113.188]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA20513; Thu, 17 Feb 2000 01:44:19 -0500 (EST) Message-ID: <38AB99A8.D33E74FB@dynamicsoft.com> Date: Thu, 17 Feb 2000 01:48:08 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Igor Slepchin Cc: Robert.Sparks@wcom.com, "''SIP List' (E-mail)'" , "'Henning Schulzrinne (E-mail)'" Subject: Re: UAC use of tags received in responses References: <003201bf78b2$8f59c4c0$8a9223a6@mcit.com> <38AB0319.B3E2AF52@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Igor Slepchin wrote: > > Robert Sparks wrote: > > > > Since there have been no other comments, the suggestion now > > is to add the following to '11.3 Caller Receives Response to > > Initial Request': > > > > <...> > > The UAC MUST include that tag into all other subsequent > > requests if, and only if, the response was in the 200 class. > > CANCEL is an exception from that rule. In theory, yes. However, the copy-the-tag-into-subsequent-requests rule applies only after a 200 OK to INVITE has come. At that point, sending a CANCEL is guaranteed to do nothing. So, there is no point in sending one. If you did, you are right it should not contain a tag. > People also argued for allowing > BYE requests with no tag (though I am not very happy with the idea). The same thing is true here with BYE. The issue is that people will be sending BYE before the 200 OK (and thus the tag) has been established. Igor has a good point, though, that we should clarify that obviously tags cannot be inserted into requests sent before the 200 OK to INVITE comes. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 17 01:59:51 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28385 for ; Thu, 17 Feb 2000 01:59:50 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 2979352D4; Thu, 17 Feb 2000 01:57:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8CD2552D5; Thu, 17 Feb 2000 01:57:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 4D9F152D4 for ; Thu, 17 Feb 2000 01:57:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Feb 17 01:55:10 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Thu Feb 17 01:52:47 EST 2000 Received: from dynamicsoft.com (1Cust188.tnt1.freehold.nj.da.uu.net [63.17.113.188]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA20522; Thu, 17 Feb 2000 01:55:17 -0500 (EST) Message-ID: <38AB9C3A.442D3AC7@dynamicsoft.com> Date: Thu, 17 Feb 2000 01:59:06 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis Cc: IETF SIP , Taichi Fu Subject: Re: 183 vs 180, When and Where, a Proposal References: <000001bf78d3$56db2be0$ad9423a6@mcit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit I'm not sure I like making this kind of distinction. Why not simply say that a UAC always pay attention to media it is asked to receive via a provisional response, and that pure IP UASs are advised not to send SDP in provisional responses, but rather encode the data in the response itself, via reason phrases or content. -Jonathan R. Dean Willis wrote: > > Taichi Fu and I have been having a discussion on 18x provisional messages > with media that may be worth sharing. Here's what I think we agreed to. > > For PSTN interworking, you really have to "listen" to the bearer channel to > figure out what's going on (see previous discussion on release codes). Note > that this is really quite different from a pure-IP scenario. > > If we don't have PSTN interworking, then a 180 means that a user is being > alerted, and media on a 180 clearly indicates a custom message that can be > played to the caller. For example, a French user might want to play back the > distinctive French double-ring, and a Trekky might want to > play a clip of Lt. Uhuru saying "Captain, there is an incoming call". We > might also want to include a text message for the audio-impaired device or > user, or present a visual notification such as a corporate logo. > > On the other hand, many UASes (and proxies) MAY choose to ignore the media > on a 180. This can avoid very complex mixing scenarios in a forking > environment. > > Devices MAY also choose to ignore the media on a 183, but this MUST be done > very carefully. Media on a 183 for PSTN interworking is far more critical > than that on a 180 -- it may provide the only useful information available > to the caller for determining the cause of a call failure. Think very > carefully before ignoring a 183. > > We suggest that a straight IP system, especially a UAS, SHOULD send 180 > (which MAY have media) when alerting a user. A PSTN gateway SHOULD send a > 183 with media when "launching" a call onto the PSTN. Devices MAY decide to > ignore the media of a 180. Devices SHOULD present the media of a 183 to an > end user, and MUST deal with the results of not doing so. > > A key point: > > Some have argued that 183 also has uses outside of PSTN interworking, > whenever there is some status information describing a call which needs to > be presented "in band", but there has been no actual notification delivered > to a destination. > > For example, consider a proxy (P) that implements a forking search. An > INVITE for "Joe" is delivered to P. P might, in parallel: > 1) respond with a 183 containing media in two parts. > part 1 is an html object with > text="Your call is being forwarded by Joe's Finder Service". > part 2 is an SDP object describing a media stream with a spoken > rendition of the same text > 2) send INVITES to all of the contacts Joe has on his contact list. > > This is probably a BAD usage of 183 -- the status information, while useful > and entertaining, is not critical to the successful interworking of the > call. Its presence could obfuscate an upstream forking system, and would > provide no additional value to that system. This example SHOULD be > implemented using a 180, not a 183. > > -- > Dean -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 17 06:22:30 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08942 for ; Thu, 17 Feb 2000 06:22:30 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id AFC0652D6; Thu, 17 Feb 2000 06:11:48 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 48CF452DA; Thu, 17 Feb 2000 06:11:46 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id BFCE152D6 for ; Thu, 17 Feb 2000 06:11:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 17 06:09:39 EST 2000 Received: from mars.mediagate.co.il ([194.90.192.20]) by dusty; Thu Feb 17 06:07:16 EST 2000 Received: from jacob ([194.90.192.122]) by mars.mediagate.co.il (Eureka! Silver(tm) v2.4) id AA-2000Feb17.131011.S5000.30871; Thu, 17 Feb 2000 13:10:12 +0200 From: "Jacob Avraham" To: "VPIM list" , "SS7-INTEREST list" , "Sip list" , "SIGTRAN list" Subject: FW: Attention !!! Warm virus found ! Date: Thu, 17 Feb 2000 13:12:11 +0200 Message-ID: <028601bf7937$d68efb00$7ac05ac2@mediagate> 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 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 X-MailServer: Eureka! Silver Internet Server (v2.4 Build 1033) Organization: mediagate Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit >> subject: "Check this" >> body: "Have fun with these links. Bye." >> attachment: "LINKS.VBS" >> >> Do not open the attachment! Delete it immediatly and DO NOT open it! It >> contains a visual basic script that sends all your friends (at your >address >> book) the same email for them to open. It might also install a virus on >your >> computer. >> >> > > > From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 17 10:37:58 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16067 for ; Thu, 17 Feb 2000 10:37:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id BDB3652DA; Thu, 17 Feb 2000 10:35:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 370AA52DB; Thu, 17 Feb 2000 10:35:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id E1BE852DA for ; Thu, 17 Feb 2000 10:35:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 17 10:34:09 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Thu Feb 17 10:31:46 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id KAA11104; Thu, 17 Feb 2000 10:33:58 -0500 (EST) Message-ID: <38AC14E5.9FEC3C48@cs.columbia.edu> Date: Thu, 17 Feb 2000 10:33:57 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Dean Willis , IETF SIP , Taichi Fu Subject: Re: 183 vs 180, When and Where, a Proposal References: <000001bf78d3$56db2be0$ad9423a6@mcit.com> <38AB9C3A.442D3AC7@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > I'm not sure I like making this kind of distinction. Why not simply say > that a UAC always pay attention to media it is asked to receive via a > provisional response, and that pure IP UASs are advised not to send SDP > in provisional responses, but rather encode the data in the response > itself, via reason phrases or content. Beyond this, I still have two major concerns/requirements: - The caller needs to be able to express that it doesn't want audio. Yes, it can ignore it, but the traffic may interfere with other on-going communications. - If this is an error condition, i.e., no call can ensue, when is the UAS going to send a 4xx or 5xx? There is no right time, since it either prematurely shuts off the explanation or it delays sequential searches in proxies for very long time periods. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 17 11:44:05 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17825 for ; Thu, 17 Feb 2000 11:44:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 17CBD52DB; Thu, 17 Feb 2000 11:41:27 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6234052DD; Thu, 17 Feb 2000 11:41:26 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id CAA8D52DB for ; Thu, 17 Feb 2000 11:41:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 17 11:40:38 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Thu Feb 17 11:38:16 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA21050; Thu, 17 Feb 2000 11:40:47 -0500 (EST) Message-ID: <38AC2576.5D4D199E@dynamicsoft.com> Date: Thu, 17 Feb 2000 11:44:38 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: Dean Willis , IETF SIP , Taichi Fu Subject: Re: 183 vs 180, When and Where, a Proposal References: <000001bf78d3$56db2be0$ad9423a6@mcit.com> <38AB9C3A.442D3AC7@dynamicsoft.com> <38AC14E5.9FEC3C48@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > Jonathan Rosenberg wrote: > > > > I'm not sure I like making this kind of distinction. Why not simply say > > that a UAC always pay attention to media it is asked to receive via a > > provisional response, and that pure IP UASs are advised not to send SDP > > in provisional responses, but rather encode the data in the response > > itself, via reason phrases or content. > > Beyond this, I still have two major concerns/requirements: > > - The caller needs to be able to express that it doesn't want audio. > Yes, it can ignore it, but the traffic may interfere with other on-going > communications. I'm not sure this is a NEED so much as something that might be a nice feature. Actually this seems something appropriate for caller preferences. > > - If this is an error condition, i.e., no call can ensue, when is the > UAS going to send a 4xx or 5xx? There is no right time, since it either > prematurely shuts off the explanation or it delays sequential searches > in proxies for very long time periods. My guess is that in practice, there will seldom be forking with gateways involved. As such, reasonable behavior might be to send the audio, potentially delaying the unlikely sequential search. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 17 11:50:01 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18081 for ; Thu, 17 Feb 2000 11:50:00 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 82FB652DD; Thu, 17 Feb 2000 11:47:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id DC9D652DF; Thu, 17 Feb 2000 11:47:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 8B2E452DD for ; Thu, 17 Feb 2000 11:47:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 17 11:45:38 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Thu Feb 17 11:43:16 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id LAA17121; Thu, 17 Feb 2000 11:44:50 -0500 (EST) Message-ID: <38AC2581.C87C7B4D@cs.columbia.edu> Date: Thu, 17 Feb 2000 11:44:49 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Dean Willis , IETF SIP , Taichi Fu Subject: Re: 183 vs 180, When and Where, a Proposal References: <000001bf78d3$56db2be0$ad9423a6@mcit.com> <38AB9C3A.442D3AC7@dynamicsoft.com> <38AC14E5.9FEC3C48@cs.columbia.edu> <38AC2576.5D4D199E@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Henning Schulzrinne wrote: > > > > Jonathan Rosenberg wrote: > > > > > > I'm not sure I like making this kind of distinction. Why not simply say > > > that a UAC always pay attention to media it is asked to receive via a > > > provisional response, and that pure IP UASs are advised not to send SDP > > > in provisional responses, but rather encode the data in the response > > > itself, via reason phrases or content. > > > > Beyond this, I still have two major concerns/requirements: > > > > - The caller needs to be able to express that it doesn't want audio. > > Yes, it can ignore it, but the traffic may interfere with other on-going > > communications. > > I'm not sure this is a NEED so much as something that might be a nice > feature. Actually > this seems something appropriate for caller preferences. Agreed, or one can argue that it is a feature, described via Supported, since not all end systems will even be able to accept voice ahead of 200 (e.g., they may only start the media tools after the 200 has been received). > > > > > - If this is an error condition, i.e., no call can ensue, when is the > > UAS going to send a 4xx or 5xx? There is no right time, since it either > > prematurely shuts off the explanation or it delays sequential searches > > in proxies for very long time periods. > > My guess is that in practice, there will seldom be forking with gateways > involved. As such, reasonable behavior might be to send the audio, > potentially delaying the unlikely sequential search. I'm not sure that's true. I get the voice announcement if a cell phone (Sprint PCS) is not answering. If I route to both a home phone and cell number, I don't want the announcement to delay ringing the other phone. > -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 17 12:19:52 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19222 for ; Thu, 17 Feb 2000 12:19:50 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 866E652DF; Thu, 17 Feb 2000 12:17:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E877352E0; Thu, 17 Feb 2000 12:17:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C97A652DF for ; Thu, 17 Feb 2000 12:17:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 17 12:16:33 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Thu Feb 17 12:14:10 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA21179; Thu, 17 Feb 2000 12:16:42 -0500 (EST) Message-ID: <38AC2DE1.4E5B10B0@dynamicsoft.com> Date: Thu, 17 Feb 2000 12:20:33 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Igor Slepchin , sip@lists.research.bell-labs.com Subject: Re: UAC use of tags received in responses References: <003201bf78b2$8f59c4c0$8a9223a6@mcit.com> <38AB0319.B3E2AF52@dynamicsoft.com> <38AB99A8.D33E74FB@dynamicsoft.com> <38AB9F58.6889F1B7@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Igor Slepchin wrote: > > > > CANCEL is an exception from that rule. > > > > In theory, yes. However, the copy-the-tag-into-subsequent-requests rule > > applies only after a 200 OK to INVITE has come. At that point, sending a > > CANCEL is guaranteed to do nothing. So, there is no point in sending > > one. If you did, you are right it should not contain a tag. > > One could theoretically CANCEL any request. A more practical example is > a re-INVITE. Besides, UAC might want to send a CANCEL even after it got > a 200 OK to cancel the search on forked branches that might still be > outstanding. Fair enough. However, I think that in the case of cancelling a re-INVITE, you do actually want the tag in the To field. I believe the CANCEL needs to match the request its cancelling, in terms of the To, From, Call-ID and CSeq, including tags. In the case of multiple call legs, if a re-INVITE were sent on each call leg, and then cancelled on each call leg, you might not be able to distinguish the CANCELs except for the tag in the To field. So, if this is OK, the proposed addition is: "The exception to this is CANCEL. The CANCEL always contains exactly the same value of the To field as the request it is cancelling." -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 17 14:10:04 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22231 for ; Thu, 17 Feb 2000 14:10:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 8C9D352E0; Thu, 17 Feb 2000 14:07:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 00F6E52E1; Thu, 17 Feb 2000 14:07:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 6D47952E0 for ; Thu, 17 Feb 2000 14:07:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 17 14:05:51 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Thu Feb 17 14:03:28 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA21402; Thu, 17 Feb 2000 14:05:55 -0500 (EST) Message-ID: <38AC4779.B4765442@dynamicsoft.com> Date: Thu, 17 Feb 2000 14:09:45 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis Cc: IETF SIP Subject: Re: Question about media desinations References: <002f01bf7817$ef092c80$ad9423a6@mcit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hmmm. Actually, placing the source address in the SDP solves another problem. When multiple 200 OK (or 183 or whatever) arrive with SDP, the caller is going to receive audio all on the same port, with no way to figure out which RTP stream corresponds to which call leg. By adding the source address, the UAC will be able to correlate them. I guess the next step is to write up the SDP extension as a small draft and submit it to mmusic, as its really an mmusic issue and not a sip one. -Jonathan R. Dean Willis wrote: > > Yes. Having both endpoints allows the firewall to construct a far more > effective dynamic ACL. It also allows UAs to selectively bind their RTP > streams to a specific partner, rather than waiting open-eared for a download > of spam. > > -- > Dean > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Sunday, February 13, 2000 11:11 AM > > To: Dean Willis > > Cc: 'SIP List' > > Subject: Re: Question about media desinations > > > > > > This raises an important point. I don't want to make changes to SDP and > > its usage within SIP to fix a problem that can be prevented by an > > administrative change in firewall behavior. If the firewalls did not > > return these error messages, do you still believe including the source > > port and address in the SDP is useful? > > > > -Jonathan R. > > > > Dean Willis wrote: > > > > > > Try scanning the net at 63.81.221.0/24, for example by > > telneting to port 122 > > > on 63.81.221.234 -- you'll get back lots of "packet filtered" > > messages. The > > > default behavior in most systems is to return such a message. > > Some firewall > > > implementors turn them off. Most don't. > > > > > > -- > > > Dean > > > > > > Jonathan asked: > > > > This presumes a firewall sends an ICMP error message when it discards > > > > the packet. I would > > > > think they would blackhole them, which will eliminate the ability to > > > > conduct this attack > > > > you describe. > > > > -- > > Jonathan D. Rosenberg 200 Executive Drive > > Chief Scientist Suite 120 > > dynamicsoft West Orange, NJ 07052 > > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > > http://www.dynamicsoft.com > > -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 17 14:13:23 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22286 for ; Thu, 17 Feb 2000 14:13:20 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id E31EB52E1; Thu, 17 Feb 2000 14:09:43 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C6DD452E2; Thu, 17 Feb 2000 14:09:42 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 2D42752E1 for ; Thu, 17 Feb 2000 14:09:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 17 14:08:42 EST 2000 Received: from repulse.cnchost.com ([207.155.248.4]) by dusty; Thu Feb 17 14:06:20 EST 2000 Received: from vovida.com (w178.z216112071.sjc-ca.dsl.cnc.net [216.112.71.178]) by repulse.cnchost.com id OAA25466; Thu, 17 Feb 2000 14:08:39 -0500 (EST) [ConcentricHost SMTP Relay 1.8] Message-ID: <38AC4739.B34A05C0@vovida.com> Date: Thu, 17 Feb 2000 11:08:41 -0800 From: Sunitha Kumar Organization: Vovida Networks X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: SIPbell-labs Subject: SIP security mailing list Content-Type: multipart/alternative; boundary="------------7017333F4C4B969150960DF3" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --------------7017333F4C4B969150960DF3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi: I had sent this request on Feb 8th. But, unfortunately got no reply back. So, i am resending it. The question was; where can i find any information in SIP security mailing list or discussions going on in this group. Thanks much! -- Sunitha Kumar Software Engineer Vovida Networks (408) 957 - 6374 --------------7017333F4C4B969150960DF3 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi:

I had sent this request on Feb 8th. But, unfortunately got no reply back.
So, i am resending it.

The question was;

where can i find any information in SIP security mailing list or discussions going on in this group.

Thanks much! 

-- 
Sunitha Kumar
Software Engineer
Vovida Networks
(408) 957 - 6374
  --------------7017333F4C4B969150960DF3-- From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 17 14:44:47 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22876 for ; Thu, 17 Feb 2000 14:44:45 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id ACD7952DC; Thu, 17 Feb 2000 14:41:36 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1803F52E4; Thu, 17 Feb 2000 14:41:35 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 91CBA52DC for ; Thu, 17 Feb 2000 14:41:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 17 14:40:58 EST 2000 Received: from PMESMTP01.wcom.com ([199.249.20.1]) by dusty; Thu Feb 17 14:38:36 EST 2000 Received: from ndcrelay2.mcit.com ([166.37.172.6]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FQ3000NTAO3NG@firewall.mcit.com> for sip@lists.research.bell-labs.com; Thu, 17 Feb 2000 19:40:52 +0000 (GMT) Received: from omzmta02.mcit.com (omzmta02.mcit.com [166.37.194.120]) by ndcrelay2.mcit.com (8.8.7/) with ESMTP id TAA29959; Thu, 17 Feb 2000 19:40:51 +0000 (GMT) Received: from dwillispc8 ([166.35.225.166]) by omzmta02.mcit.com (InterMail v03.02.05 118 120) with SMTP id <20000217194009.GVZQ105@[166.35.225.166]>; Thu, 17 Feb 2000 19:40:09 +0000 Date: Thu, 17 Feb 2000 13:39:14 -0600 From: Dean Willis Subject: RE: 183 vs 180, When and Where, a Proposal In-reply-to: <38AB9C3A.442D3AC7@dynamicsoft.com> To: Jonathan Rosenberg Cc: IETF SIP , Taichi Fu Message-id: <001d01bf797e$abfd2f00$a6e123a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Well, some marketing folks I know got all gooey over custom ringback, which I see implemented as 180 with SDP pointing to a streaming audio source. I suppose one could provide this with a back-to-back UA and a transfer operation, but the signaling semantics would be much more annoying if the UAC proved to be a gateway. -- dean > -----Original Message----- > From: owner-sip@lists.research.bell-labs.com > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Jonathan > Rosenberg > Sent: Thursday, February 17, 2000 12:59 AM > To: Dean Willis > Cc: IETF SIP; Taichi Fu > Subject: Re: 183 vs 180, When and Where, a Proposal > > > I'm not sure I like making this kind of distinction. Why not simply say > that a UAC always pay attention to media it is asked to receive via a > provisional response, and that pure IP UASs are advised not to send SDP > in provisional responses, but rather encode the data in the response > itself, via reason phrases or content. > > -Jonathan R. > > Dean Willis wrote: > > > > Taichi Fu and I have been having a discussion on 18x > provisional messages > > with media that may be worth sharing. Here's what I think we agreed to. > > > > For PSTN interworking, you really have to "listen" to the > bearer channel to > > figure out what's going on (see previous discussion on release > codes). Note > > that this is really quite different from a pure-IP scenario. > > > > If we don't have PSTN interworking, then a 180 means that a > user is being > > alerted, and media on a 180 clearly indicates a custom message > that can be > > played to the caller. For example, a French user might want to > play back the > > distinctive French double-ring, and a Trekky might want to > > play a clip of Lt. Uhuru saying "Captain, there is an incoming > call". We > > might also want to include a text message for the > audio-impaired device or > > user, or present a visual notification such as a corporate logo. > > > > On the other hand, many UASes (and proxies) MAY choose to > ignore the media > > on a 180. This can avoid very complex mixing scenarios in a forking > > environment. > > > > Devices MAY also choose to ignore the media on a 183, but this > MUST be done > > very carefully. Media on a 183 for PSTN interworking is far > more critical > > than that on a 180 -- it may provide the only useful > information available > > to the caller for determining the cause of a call failure. Think very > > carefully before ignoring a 183. > > > > We suggest that a straight IP system, especially a UAS, SHOULD send 180 > > (which MAY have media) when alerting a user. A PSTN gateway > SHOULD send a > > 183 with media when "launching" a call onto the PSTN. Devices > MAY decide to > > ignore the media of a 180. Devices SHOULD present the media of > a 183 to an > > end user, and MUST deal with the results of not doing so. > > > > A key point: > > > > Some have argued that 183 also has uses outside of PSTN interworking, > > whenever there is some status information describing a call > which needs to > > be presented "in band", but there has been no actual > notification delivered > > to a destination. > > > > For example, consider a proxy (P) that implements a forking search. An > > INVITE for "Joe" is delivered to P. P might, in parallel: > > 1) respond with a 183 containing media in two parts. > > part 1 is an html object with > > text="Your call is being forwarded by Joe's > Finder Service". > > part 2 is an SDP object describing a media > stream with a spoken > > rendition of the same text > > 2) send INVITES to all of the contacts Joe has on his > contact list. > > > > This is probably a BAD usage of 183 -- the status information, > while useful > > and entertaining, is not critical to the successful interworking of the > > call. Its presence could obfuscate an upstream forking system, and would > > provide no additional value to that system. This example SHOULD be > > implemented using a 180, not a 183. > > > > -- > > Dean > > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 17 14:47:18 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22909 for ; Thu, 17 Feb 2000 14:47:15 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 9FAFA52E5; Thu, 17 Feb 2000 14:41:45 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A675352E3; Thu, 17 Feb 2000 14:41:41 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 44EEF52E3 for ; Thu, 17 Feb 2000 14:41:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 17 14:40:48 EST 2000 Received: from PMESMTP02.wcom.com ([199.249.20.2]) by dusty; Thu Feb 17 14:38:26 EST 2000 Received: from ndcrelay.mcit.com ([166.37.172.49]) by firewall.mcit.com (PMDF V5.2-32 #41713) with ESMTP id <0FQ300CGPANSHN@firewall.mcit.com> for sip@lists.research.bell-labs.com; Thu, 17 Feb 2000 19:40:40 +0000 (GMT) Received: from omzmta02.mcit.com (omzmta02.mcit.com [166.37.194.120]) by ndcrelay.mcit.com (8.8.7/) with ESMTP id TAA02287; Thu, 17 Feb 2000 19:40:23 +0000 (GMT) Received: from dwillispc8 ([166.35.225.166]) by omzmta02.mcit.com (InterMail v03.02.05 118 120) with SMTP id <20000217194011.GVZX105@[166.35.225.166]>; Thu, 17 Feb 2000 19:40:11 +0000 Date: Thu, 17 Feb 2000 13:39:16 -0600 From: Dean Willis Subject: RE: 183 vs 180, When and Where, a Proposal In-reply-to: <4.2.0.58.20000216174540.00d15450@farley.cisco.com> To: Taichi Fu Cc: IETF SIP Message-id: <001e01bf797e$ad43b8c0$a6e123a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Thanks for the clarification. That's what I meant. -- Dean Taichi Fu said: > -----Original Message----- > From: owner-sip@lists.research.bell-labs.com > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Taichi Fu > Sent: Wednesday, February 16, 2000 9:00 PM > To: Dean Willis > Cc: IETF SIP > Subject: Re: 183 vs 180, When and Where, a Proposal > > > Dean, > > Thanks for the summary. I add a small note below the paragraph 6 > from my understanding. > > Regards, > -Taichi > > At 05:12 PM 2/16/00 -0600, Dean Willis wrote: > > >Taichi Fu and I have been having a discussion on 18x provisional messages > >with media that may be worth sharing. Here's what I think we agreed to. > > > >For PSTN interworking, you really have to "listen" to the bearer > channel to > >figure out what's going on (see previous discussion on release > codes). Note > >that this is really quite different from a pure-IP scenario. > > > >If we don't have PSTN interworking, then a 180 means that a user is being > >alerted, and media on a 180 clearly indicates a custom message > that can be > >played to the caller. For example, a French user might want to > play back the > >distinctive French double-ring, and a Trekky might want to > >play a clip of Lt. Uhuru saying "Captain, there is an incoming call". We > >might also want to include a text message for the audio-impaired > device or > >user, or present a visual notification such as a corporate logo. > > > >On the other hand, many UASes (and proxies) MAY choose to ignore > the media > >on a 180. This can avoid very complex mixing scenarios in a forking > >environment. > > > >Devices MAY also choose to ignore the media on a 183, but this > MUST be done > >very carefully. Media on a 183 for PSTN interworking is far more critical > >than that on a 180 -- it may provide the only useful information > available > >to the caller for determining the cause of a call failure. Think very > >carefully before ignoring a 183. > > > >We suggest that a straight IP system, especially a UAS, SHOULD send 180 > >(which MAY have media) when alerting a user. A PSTN gateway SHOULD send a > >183 with media when "launching" a call onto the PSTN. Devices > MAY decide to > >ignore the media of a 180. Devices SHOULD present the media of a > 183 to an > >end user, and MUST deal with the results of not doing so. > > That means, for SIP and PSTN interworking (a PSTN gateway converting > between SIP messages and SS7 messages): > > (1) For a call from SIP to PSTN, a PSTN gateway SHOULD respond > with 183 , and > (2) For a call from PSTN to SIP, a PSTN gateway SHOULD expect to > receive 180. > > An asymmetry. > > >A key point: > > > >Some have argued that 183 also has uses outside of PSTN interworking, > >whenever there is some status information describing a call > which needs to > >be presented "in band", but there has been no actual > notification delivered > >to a destination. > > > >For example, consider a proxy (P) that implements a forking search. An > >INVITE for "Joe" is delivered to P. P might, in parallel: > > 1) respond with a 183 containing media in two parts. > > part 1 is an html object with > > text="Your call is being forwarded by Joe's > Finder Service". > > part 2 is an SDP object describing a media > stream with a > > spoken > > rendition of the same text > > 2) send INVITES to all of the contacts Joe has on his > contact list. > > > >This is probably a BAD usage of 183 -- the status information, > while useful > >and entertaining, is not critical to the successful interworking of the > >call. Its presence could obfuscate an upstream forking system, and would > >provide no additional value to that system. This example SHOULD be > >implemented using a 180, not a 183. > > > >-- > >Dean > > > > From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 17 14:53:55 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22979 for ; Thu, 17 Feb 2000 14:53:50 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id E34AC52E3; Thu, 17 Feb 2000 14:51:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 5F4B952E4; Thu, 17 Feb 2000 14:51:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 5CE5C52E3 for ; Thu, 17 Feb 2000 14:51:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 17 14:51:02 EST 2000 Received: from PMESMTP01.wcom.com ([199.249.20.1]) by dusty; Thu Feb 17 14:48:40 EST 2000 Received: from ndcrelay2.mcit.com ([166.37.172.6]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FQ30078VB4ZLY@firewall.mcit.com> for sip@lists.research.bell-labs.com; Thu, 17 Feb 2000 19:50:59 +0000 (GMT) Received: from omzmta02.mcit.com (omzmta02.mcit.com [166.37.194.120]) by ndcrelay2.mcit.com (8.8.7/) with ESMTP id TAA06630; Thu, 17 Feb 2000 19:51:19 +0000 (GMT) Received: from dwillispc8 ([166.35.225.166]) by omzmta02.mcit.com (InterMail v03.02.05 118 120) with SMTP id <20000217195016.GYUG105@[166.35.225.166]>; Thu, 17 Feb 2000 19:50:16 +0000 Date: Thu, 17 Feb 2000 13:49:21 -0600 From: Dean Willis Subject: RE: 183 vs 180, When and Where, a Proposal In-reply-to: <38AC2581.C87C7B4D@cs.columbia.edu> To: Henning Schulzrinne , Jonathan Rosenberg Cc: IETF SIP , Taichi Fu Message-id: <001f01bf7980$15ce9c60$a6e123a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Henning wrote: > Agreed, or one can argue that it is a feature, described via Supported, > since not all end systems will even be able to accept voice ahead of 200 > (e.g., they may only start the media tools after the 200 has been > received). Then they're going to have a hard time making calls to the PSTN, where "early media" is a fact of life. > > > - If this is an error condition, i.e., no call can ensue, when is the > > > UAS going to send a 4xx or 5xx? There is no right time, since > it either > > > prematurely shuts off the explanation or it delays sequential searches > > > in proxies for very long time periods. > > > > My guess is that in practice, there will seldom be forking with gateways > > involved. As such, reasonable behavior might be to send the audio, > > potentially delaying the unlikely sequential search. The UAS sends a 4xx on teardown-with-cause from the PSTN side. This is AFTER the message has been played. Can't do it sooner and still work. > I'm not sure that's true. I get the voice announcement if a cell phone > (Sprint PCS) is not answering. If I route to both a home phone and cell > number, I don't want the announcement to delay ringing the other phone. It may be necessary to consider things like a "forking proxy" that can fork, absorb the 183(s), record the media attached to it(them), notify the caller, then play the media back on demand. This lets a user do things like "Hmm, that call failed, I wonder why. Oh, my message light is blinking, there must be a telco message from that call." I call this "thinking carefully about ignoring the provisional media". Save this, it's "prior art". -- Dean From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 17 15:38:14 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23963 for ; Thu, 17 Feb 2000 15:38:13 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C196652E9; Thu, 17 Feb 2000 15:35:36 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 0397C52E8; Thu, 17 Feb 2000 15:35:35 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 29A2652E4 for ; Thu, 17 Feb 2000 15:35:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Feb 17 15:34:45 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Thu Feb 17 15:32:22 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id PAA12596; Thu, 17 Feb 2000 15:32:45 -0500 (EST) Message-ID: <38AC5AED.6BB32780@cs.columbia.edu> Date: Thu, 17 Feb 2000 15:32:45 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis Cc: IETF SIP Subject: Re: 183 vs 180, When and Where, a Proposal References: <001f01bf7980$15ce9c60$a6e123a6@mcit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Dean Willis wrote: > > Henning wrote: > > Agreed, or one can argue that it is a feature, described via Supported, > > since not all end systems will even be able to accept voice ahead of 200 > > (e.g., they may only start the media tools after the 200 has been > > received). > > Then they're going to have a hard time making calls to the PSTN, where > "early media" is a fact of life. Not for devices like autodialers. They want to get off the line as quickly as possible, however useful the phonelady spiel. > > The UAS sends a 4xx on teardown-with-cause from the PSTN side. This is AFTER > the message has been played. Can't do it sooner and still work. The problem is that AFTER is ill-defined. As far as I know, the "The number you have dialed has been changed. The new number is ..." repeats indefinitely or at least a very long time. > > > I'm not sure that's true. I get the voice announcement if a cell phone > > (Sprint PCS) is not answering. If I route to both a home phone and cell > > number, I don't want the announcement to delay ringing the other phone. > > It may be necessary to consider things like a "forking proxy" that can fork, > absorb the 183(s), record the media attached to it(them), notify the caller, > then play the media back on demand. This lets a user do things like "Hmm, > that call failed, I wonder why. Oh, my message light is blinking, there must > be a telco message from that call." I call this "thinking carefully about > ignoring the provisional media". Save this, it's "prior art". > > -- > Dean -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 17 15:51:55 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24260 for ; Thu, 17 Feb 2000 15:51:55 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 583F652E2; Thu, 17 Feb 2000 15:49:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C600F52E7; Thu, 17 Feb 2000 15:49:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 0543552E2 for ; Thu, 17 Feb 2000 15:49:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 17 15:48:51 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Thu Feb 17 15:46:29 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id PAA14076; Thu, 17 Feb 2000 15:48:42 -0500 (EST) Message-ID: <38AC5EA9.AFC3FD93@cs.columbia.edu> Date: Thu, 17 Feb 2000 15:48:41 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: IETF SIP Subject: Re: Question about media desinations References: <002f01bf7817$ef092c80$ad9423a6@mcit.com> <38AC4779.B4765442@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Hmmm. Actually, placing the source address in the SDP solves another > problem. When multiple 200 OK (or 183 or whatever) arrive with SDP, the > caller is going to receive audio all on the same port, with no way to > figure out which RTP stream corresponds to which call leg. By adding the > source address, the UAC will be able to correlate them. While this is helpful, it is not foolproof, since RTP translators will mess up the IP address. I think RTCP-based means are preferable. Also, for multi-homed hosts, it's not always easy to know at the application layer, which source address is going to be used, since that can depend on routing. While this is probably infrequent, relying on it may be suboptimal. Maybe RTCP SDES should contain the appropriate identifier, including tag. > -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 17 16:44:02 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25336 for ; Thu, 17 Feb 2000 16:44:00 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id F128652E4; Thu, 17 Feb 2000 16:41:25 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6043E52E8; Thu, 17 Feb 2000 16:41:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 3DC2652E4 for ; Thu, 17 Feb 2000 16:41:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Feb 17 16:39:53 EST 2000 Received: from PMESMTP02.wcom.com ([199.249.20.2]) by dusty; Thu Feb 17 16:37:31 EST 2000 Received: from ndcrelay.mcit.com ([166.37.172.49]) by firewall.mcit.com (PMDF V5.2-32 #41713) with ESMTP id <0FQ30081FG6CWI@firewall.mcit.com> for sip@lists.research.bell-labs.com; Thu, 17 Feb 2000 21:39:48 +0000 (GMT) Received: from omta1.mcit.com (omta1.mcit.com [166.37.204.2]) by ndcrelay.mcit.com (8.8.7/) with ESMTP id VAA30615; Thu, 17 Feb 2000 21:39:09 +0000 (GMT) Received: from sipdev4 ([166.35.146.138]) by omta1.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000217213817.LOGE18747@sipdev4>; Thu, 17 Feb 2000 15:38:17 -0600 Date: Thu, 17 Feb 2000 15:35:04 -0600 From: Robert Sparks Subject: RE: Question about media desinations In-reply-to: <38AC5EA9.AFC3FD93@cs.columbia.edu> To: "'Henning Schulzrinne'" , "'Jonathan Rosenberg'" Cc: "'IETF SIP'" Reply-To: Robert.Sparks@wcom.com Message-id: <000501bf798e$db4348c0$8a9223a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit How would an RTP translator get into the media path of a SIP initiated session without one of the SIP participants being aware of it during the setup? Multi-homed SIP entities already have to discover which interfaces are going to participate in a given SIP transaction (for proper construction of Vias, Contacts, Record-Routes, and possibly the receiving address in session description). In the context of an RTCP-based solution and the case that Jonathan describes, what would the client do with RTP packets received before the first associated RTCP packet arrives? RjS Henning Schulzrinne writes: > Jonathan Rosenberg wrote: > > > > Hmmm. Actually, placing the source address in the SDP solves another > > problem. When multiple 200 OK (or 183 or whatever) arrive > with SDP, the > > caller is going to receive audio all on the same port, with > no way to > > figure out which RTP stream corresponds to which call leg. > By adding the > > source address, the UAC will be able to correlate them. > > While this is helpful, it is not foolproof, since RTP translators will > mess up the IP address. I think RTCP-based means are preferable. Also, > for multi-homed hosts, it's not always easy to know at the application > layer, which source address is going to be used, since that can depend > on routing. While this is probably infrequent, relying on it may be > suboptimal. Maybe RTCP SDES should contain the appropriate identifier, > including tag. From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 17 17:15:49 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26039 for ; Thu, 17 Feb 2000 17:15:47 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 2A25652E8; Thu, 17 Feb 2000 17:13:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9A0F752EA; Thu, 17 Feb 2000 17:13:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 07DFA52E8 for ; Thu, 17 Feb 2000 17:13:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Feb 17 17:12:56 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Thu Feb 17 17:10:34 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id RAA23246; Thu, 17 Feb 2000 17:12:31 -0500 (EST) Message-ID: <38AC724F.969A824@cs.columbia.edu> Date: Thu, 17 Feb 2000 17:12:31 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Robert.Sparks@wcom.com Cc: "'Jonathan Rosenberg'" , "'IETF SIP'" Subject: Re: Question about media desinations References: <000501bf798e$db4348c0$8a9223a6@mcit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Robert Sparks wrote: > > How would an RTP translator get into the media path of a > SIP initiated session without one of the SIP participants > being aware of it during the setup? Never mind... > > Multi-homed SIP entities already have to discover which > interfaces are going to participate in a given SIP > transaction (for proper construction of Vias, Contacts, > Record-Routes, and possibly the receiving address in > session description). Not really, since if the receiver binds on INADDR_ANY, it doesn't matter which interface the SIP packet comes in on. > > In the context of an RTCP-based solution and the case that > Jonathan describes, what would the client do with RTP > packets received before the first associated RTCP packet > arrives? Mix it and play it out. Streams can be distinguished based on SSRC, they just can't be identified with some blinking icon which says "Joe is talking right now". -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 17 18:16:09 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27084 for ; Thu, 17 Feb 2000 18:16:09 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 9F4EF52E7; Thu, 17 Feb 2000 18:13:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1B86652EB; Thu, 17 Feb 2000 18:13:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 5F41452E7 for ; Thu, 17 Feb 2000 18:13:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 17 18:12:31 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Thu Feb 17 18:10:08 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA22097; Thu, 17 Feb 2000 18:12:39 -0500 (EST) Message-ID: <38AC814B.A713ABDC@dynamicsoft.com> Date: Thu, 17 Feb 2000 18:16:27 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Matthias.Lang@ericsson.com Cc: sip@lists.research.bell-labs.com Subject: Re: Question about media desinations References: <002f01bf7817$ef092c80$ad9423a6@mcit.com> <38AC4779.B4765442@dynamicsoft.com> <14508.24943.764505.310713@gargle.gargle.HOWL> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Matthias.Lang@ericsson.com wrote: > > Jonathan Rosenberg writes: > > Hmmm. Actually, placing the source address in the SDP solves another > > problem. When multiple 200 OK (or 183 or whatever) arrive with SDP, the > > caller is going to receive audio all on the same port, with no way to > > figure out which RTP stream corresponds to which call leg. By adding the > > source address, the UAC will be able to correlate them. > > The easy way to figure out which RTP stream corresponds to which SIP > call is to use different destination port numbers. I don't think > you can always distinguish calls based on source address, I don't > think there's anything in the RTP spec which says I can't send two > different RTP streams from the same port. Clearly thats the preferred solution, but it doesn't work for multiple 200 OK - thats my point. The INVITE contains the port I expect to receive media on. If two gateways receive that, and each send a 183 and then send media, they will end up sending media to that same port. Thus, I cannot use the port to differentiate. Of course, I will realize there are two separate streams. These two streams will generally have different SSRC, so I can separate them. However, there is no way to correlate a particular stream (identified by its SSRC) with the SIP call leg. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 17 19:05:54 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27874 for ; Thu, 17 Feb 2000 19:05:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id DA2FF52EA; Thu, 17 Feb 2000 19:03:20 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 5FABB52EC; Thu, 17 Feb 2000 19:03:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 4DCC252EA for ; Thu, 17 Feb 2000 19:03:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Feb 17 19:01:06 EST 2000 Received: from mail.pingtel.com ([216.91.1.131]) by dusty; Thu Feb 17 18:58:44 EST 2000 Received: from pingtel.com (cdhcp189.pingtel.com [10.1.1.189]) by mail.pingtel.com (8.9.3/8.9.3) with ESMTP id SAA09880; Thu, 17 Feb 2000 18:51:29 -0500 Message-ID: <38AC8C44.85E4A854@pingtel.com> Date: Thu, 17 Feb 2000 19:03:17 -0500 From: "Daniel G. Petrie" Organization: Pingtel Corp. http://www.pingtel.com X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Igor Slepchin , sip@lists.research.bell-labs.com Subject: Re: UAC use of tags received in responses References: <003201bf78b2$8f59c4c0$8a9223a6@mcit.com> <38AB0319.B3E2AF52@dynamicsoft.com> <38AB99A8.D33E74FB@dynamicsoft.com> <38AB9F58.6889F1B7@dynamicsoft.com> <38AC2DE1.4E5B10B0@dynamicsoft.com> Content-Type: multipart/mixed; boundary="------------3DF37DACAB8893DB62DD6A79" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk This is a multi-part message in MIME format. --------------3DF37DACAB8893DB62DD6A79 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sorry I could not resist these two questions. What would one expect to happen when sending a CANCEL to a ReINVITE: Cancel the transaction, leave the call up at the previously negotiated capabilities. or Cancel the transaction, drop the call. Why would someone want to do this? Cheers, Dan Jonathan Rosenberg wrote: > > > Fair enough. However, I think that in the case of cancelling a > re-INVITE, > you do actually want the tag in the To field. I believe the CANCEL needs > to > match the request its cancelling, in terms of the To, From, Call-ID and > CSeq, > including tags. In the case of multiple call legs, if a re-INVITE were > sent on > each call leg, and then cancelled on each call leg, you might not be > able to distinguish > the CANCELs except for the tag in the To field. > > So, if this is OK, the proposed addition is: > > "The exception to this is CANCEL. The CANCEL always contains exactly the > same value of the To field as the request it is cancelling." > > -Jonathan R. > > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com --------------3DF37DACAB8893DB62DD6A79 Content-Type: text/x-vcard; charset=us-ascii; name="dpetrie.vcf" Content-Description: Card for Daniel G. Petrie Content-Disposition: attachment; filename="dpetrie.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Petrie;Daniel tel;fax:+1 781 938 9650 tel;work:+1 781 938 5306 x111 x-mozilla-html:FALSE url:www.pingtel.com org:Pingtel Corp. version:2.1 email;internet:dpetrie@pingtel.com title:Software Systems Architect adr;quoted-printable:;;Suite 2200=0D=0A400 Cummings Park;Woburn;MA;01801;USA x-mozilla-cpt:;14032 fn:Daniel Petrie end:vcard --------------3DF37DACAB8893DB62DD6A79-- From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 17 20:49:52 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28968 for ; Thu, 17 Feb 2000 20:49:52 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 5243B52EE; Thu, 17 Feb 2000 20:47:25 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id BF9D152EC; Thu, 17 Feb 2000 20:47:24 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C2CFF52EE for ; Thu, 17 Feb 2000 20:47:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 17 20:46:26 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Thu Feb 17 20:44:04 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id UAA22172; Thu, 17 Feb 2000 20:46:35 -0500 (EST) Message-ID: <38ACA3CC.78FD2652@dynamicsoft.com> Date: Thu, 17 Feb 2000 20:43:40 -0500 From: Igor Slepchin Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: "Daniel G. Petrie" Cc: Jonathan Rosenberg , sip@lists.research.bell-labs.com Subject: Re: UAC use of tags received in responses References: <003201bf78b2$8f59c4c0$8a9223a6@mcit.com> <38AB0319.B3E2AF52@dynamicsoft.com> <38AB99A8.D33E74FB@dynamicsoft.com> <38AB9F58.6889F1B7@dynamicsoft.com> <38AC2DE1.4E5B10B0@dynamicsoft.com> <38AC8C44.85E4A854@pingtel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit "Daniel G. Petrie" wrote: > > What would one expect to happen when sending > a CANCEL to a ReINVITE: > Cancel the transaction, leave the call up at the previously negotiated > capabilities. > or > Cancel the transaction, drop the call. The former. > Why would someone want to do this? Media renegotiation might involve some user interaction and the caller may want to give up on the re-INVITE if it does not complete within certain time. For example, a re-INVITE may be sent when one of the call participants wants to start video exchange. If the other side is capable of supporting it, the user there might be prompted to see if he/she agrees to activate video. --- Igor Slepchin From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 18 09:30:07 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23867 for ; Fri, 18 Feb 2000 09:30:06 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 83C8E52B6; Fri, 18 Feb 2000 09:27:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id F0B3B52BB; Fri, 18 Feb 2000 09:27:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 8765A52B6 for ; Fri, 18 Feb 2000 09:27:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Feb 18 09:25:11 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Fri Feb 18 09:22:49 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA22487 for ; Fri, 18 Feb 2000 09:25:15 -0500 (EST) Message-ID: <38AD5739.C579520D@dynamicsoft.com> Date: Fri, 18 Feb 2000 09:29:13 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Subject: DHCP option tags for SIP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Folks, Many of you may have seen the recent draft presenting DHCP option codes for SIP: http://search.ietf.org/internet-drafts/draft-nair-sip-dhcp-01.txt The consensus among the authors and wg chairs is that this is a clearly useful item, and we would like to move it forward. In the interests of speed, we are proposing a "fast track" approach for this document. Basically, this message will serve as announcement of our intention to adopt this as a work item. If no one objects to this procedure, in one weeks time, we will issue an extended working group last call on it, and that call will last 3 weeks. Comments will be collected, and then we will send the document to IESG for proposed. I believe its critical that we do whatever we can to speed up the process of delivering documents to the community. This is especially the case for small, largely uncontroversial documents such as this. Rather than languish for months, getting this from concept to submission to IESG in a matter of a single month seems more desirable. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 18 09:43:21 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24190 for ; Fri, 18 Feb 2000 09:43:20 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 6D7E252AB; Fri, 18 Feb 2000 09:40:50 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D58B452C4; Fri, 18 Feb 2000 09:40:49 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from daimanta.ascend.com (unknown [152.148.40.20]) by lists.research.bell-labs.com (Postfix) with ESMTP id D5D7D52AB for ; Fri, 18 Feb 2000 09:40:32 -0500 (EST) Received: from reddog.casc.com (reddog.ascend.com [152.148.100.22]) by daimanta.ascend.com (8.9.3/8.9.3) with ESMTP id JAA08794 for ; Fri, 18 Feb 2000 09:40:28 -0500 (EST) Received: from lucent.com ([152.148.210.59]) by reddog.casc.com (8.8.8+Sun/8.8.8) with ESMTP id JAA03323 for ; Fri, 18 Feb 2000 09:21:47 -0500 (EST) Message-ID: <38AD5A45.BEF69D7C@lucent.com> Date: Fri, 18 Feb 2000 09:42:13 -0500 From: Kim Liu Organization: Lucent Technologies X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Subject: Question about UDP, Via: header, and received= attribute. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit This is a question regarding UDP connections and the received tag in Via header fields (6.40.2 of the draft I believe.) I did not see this answered off hand in the clarifications or elsewhere. Section 6.40.2 states that a proxy should check that the address in the last Via: header matches the address that the request was actually received from. If the addresses do not match, the proxy must add the received tag with the address that the request was actually received from. My problem is with what happens if the address/hostname in the Via header matches several IP addresses, including the one actually used to send it, but not all of the addresses are routable, preferred, or public. That is, suppose a server receives a Via header like: Via: SIP/2.0/UDP aka.generic.com:5060 in a UDP packet with an originating address of 10.100.100.100. The server looks up the IP addresses for aka.generic.com to see whether or not 10.100.100.100 is one of its addresses. The returned addresses for aka.generic.com are: 192.168.128.1, 192.168.128.2, 192.168.128.3, 192.168.128.3, and 10.100.100.100. So, since the 10.100.100.100 address is present, no received tag is added to the Via field. Now, when the response comes back through the proxy, and the proxy tries to forward it back along the Via lines, which IP address should the proxy choose to send the UDP message to? (Of course, the 192.* addresses might be public interfaces, and the 10.100.100.100 address is on a private network to keep call information private, etc.) Could a recieved= tag be added to the Via: header anyways to be used to tell the proxy exactly which IP address the response should be sent to? (Hmmm. This almost but does not quite feel like a security issue. If a target server has an IP address of 10.10.10.10, an attacker sets up a DNS entry for bogus.someplace.com that has IP addresses 10.10.10.10 and 20.20.20.20, then sends a packet from 20.20.20.20 with a Via line specifying bogus.someplace.com as the return hop.) Also, I think I may have seen this question earlier, but I cannot find it now (is there a mailing list archive somewhere?) -- how does the Via:/received affect loop detection? The example given in the draft indicates that one use of the received tag was for when a SIP request is passing through NAT. When checking for loops and a received tag is present, should only the address in the received tag be checked? (For instance, one organization is using the 10.* network behind NAT, and a SIP request is sent across the public network to a second organization which also uses the 10.* network behind NAT. The SIP servers in the second organization see a Via header: Via: SIP/2.0/UDP 10.10.10.10:5060; received=200.200.200.200 If the second organization using the 10.* network also has a SIP server at 10.10.10.10, will this show up as an accidental loop detection? Thanks, Kim Liu From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 18 09:46:55 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24247 for ; Fri, 18 Feb 2000 09:46:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id AA75D52C8; Fri, 18 Feb 2000 09:43:38 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A505152C4; Fri, 18 Feb 2000 09:43:36 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id A1DCD52C4 for ; Fri, 18 Feb 2000 09:43:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Feb 18 09:41:15 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Fri Feb 18 09:38:53 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA22531; Fri, 18 Feb 2000 09:41:18 -0500 (EST) Message-ID: <38AD5AFC.7AFBD768@dynamicsoft.com> Date: Fri, 18 Feb 2000 09:45:16 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Igor Slepchin Cc: "Daniel G. Petrie" , sip@lists.research.bell-labs.com Subject: Re: UAC use of tags received in responses References: <003201bf78b2$8f59c4c0$8a9223a6@mcit.com> <38AB0319.B3E2AF52@dynamicsoft.com> <38AB99A8.D33E74FB@dynamicsoft.com> <38AB9F58.6889F1B7@dynamicsoft.com> <38AC2DE1.4E5B10B0@dynamicsoft.com> <38AC8C44.85E4A854@pingtel.com> <38ACA3CC.78FD2652@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Igor Slepchin wrote: > > "Daniel G. Petrie" wrote: > > > > What would one expect to happen when sending > > a CANCEL to a ReINVITE: > > Cancel the transaction, leave the call up at the previously negotiated > > capabilities. > > or > > Cancel the transaction, drop the call. > > The former. > > > Why would someone want to do this? > > Media renegotiation might involve some user interaction and the caller > may want to give up on the re-INVITE if it does not complete within > certain time. For example, a re-INVITE may be sent when one of the call > participants wants to start video exchange. If the other side is capable > of supporting it, the user there might be prompted to see if he/she > agrees to activate video. I'd also like to add to this that whilst CANCEL is most useful for INVITE, it is a generic mechanism that can be applied to any request (excepting CANCEL itself and ACK). In general, if you get a CANCEL for a request for which you haven't sent a response, you should send a 487 response to the original request, 200 OK to the CANCEL, and then behave as if the original request were never received. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 18 09:55:51 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24418 for ; Fri, 18 Feb 2000 09:55:50 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 7080A52C4; Fri, 18 Feb 2000 09:53:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id DABFA52D4; Fri, 18 Feb 2000 09:53:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 4B82352C4 for ; Fri, 18 Feb 2000 09:53:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Feb 18 09:52:56 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Fri Feb 18 09:50:34 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA22556; Fri, 18 Feb 2000 09:53:00 -0500 (EST) Message-ID: <38AD5DBA.483CD19D@dynamicsoft.com> Date: Fri, 18 Feb 2000 09:56:58 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: Robert.Sparks@wcom.com, "'IETF SIP'" Subject: Re: Question about media desinations References: <000501bf798e$db4348c0$8a9223a6@mcit.com> <38AC724F.969A824@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > > In the context of an RTCP-based solution and the case that > > Jonathan describes, what would the client do with RTP > > packets received before the first associated RTCP packet > > arrives? > > Mix it and play it out. Streams can be distinguished based on SSRC, they > just can't be identified with some blinking icon which says "Joe is > talking right now". The bigger problem is firewalls. If we presume that the firewall won't let things through unless it has the source address at least (source port as well I guess would be desirable), the RTCP will never get through in the first place. I'm not 100% convinced of putting the source address/port in the SDP yet - still trying to understand the pros and cons. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 18 10:05:56 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24659 for ; Fri, 18 Feb 2000 10:05:51 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id CCC8B52D4; Fri, 18 Feb 2000 10:03:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 48A6652D5; Fri, 18 Feb 2000 10:03:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 3DB3552D4 for ; Fri, 18 Feb 2000 10:03:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Feb 18 10:01:16 EST 2000 Received: from PMESMTP01.wcom.com ([199.249.20.1]) by dusty; Fri Feb 18 09:58:53 EST 2000 Received: from ndcrelay2.mcit.com ([166.37.172.6]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FQ400HF9SDQ4J@firewall.mcit.com> for sip@lists.research.bell-labs.com; Fri, 18 Feb 2000 15:01:03 +0000 (GMT) Received: from omzmta04.mcit.com (omzmta04.mcit.com [166.37.194.122]) by ndcrelay2.mcit.com (8.8.7/) with ESMTP id PAA00742; Fri, 18 Feb 2000 15:01:40 +0000 (GMT) Received: from sipdev4 ([166.35.146.138]) by omzmta04.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000218150058.CGAC13039@sipdev4>; Fri, 18 Feb 2000 15:00:58 +0000 Date: Fri, 18 Feb 2000 08:57:03 -0600 From: Robert Sparks Subject: RE: Question about media desinations In-reply-to: <38AC724F.969A824@cs.columbia.edu> To: "'Henning Schulzrinne'" Cc: "'Jonathan Rosenberg'" , "'IETF SIP'" Reply-To: Robert.Sparks@wcom.com Message-id: <001801bf7a20$6b18e900$8a9223a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > > > Multi-homed SIP entities already have to discover which > > interfaces are going to participate in a given SIP > > transaction (for proper construction of Vias, Contacts, > > Record-Routes, and possibly the receiving address in > > session description). > > Not really, since if the receiver binds on INADDR_ANY, it > doesn't matter > which interface the SIP packet comes in on. If the interfaces are to discrete networks, there could be no valid response path to a request with a Via indicating the wrong interface. RjS From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 18 10:14:18 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24812 for ; Fri, 18 Feb 2000 10:14:16 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 94D7E52D5; Fri, 18 Feb 2000 10:11:51 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 167FC52D6; Fri, 18 Feb 2000 10:11:51 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from bronx.dnrc.bell-labs.com (bronx [135.180.160.8]) by lists.research.bell-labs.com (Postfix) with ESMTP id F08E952D5 for ; Fri, 18 Feb 2000 10:11:18 -0500 (EST) Received: from cs.columbia.edu (ume [135.180.240.103]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA15211; Fri, 18 Feb 2000 10:11:16 -0500 (EST) Message-ID: <38AD6116.E16080BD@cs.columbia.edu> Date: Fri, 18 Feb 2000 10:11:18 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Robert.Sparks@wcom.com, "'IETF SIP'" Subject: Re: Question about media desinations References: <000501bf798e$db4348c0$8a9223a6@mcit.com> <38AC724F.969A824@cs.columbia.edu> <38AD5DBA.483CD19D@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit > The bigger problem is firewalls. If we presume that the firewall won't > let things through unless it has the source address at least (source > port as well I guess would be desirable), the RTCP will never get > through in the first place. > > I'm not 100% convinced of putting the source address/port in the SDP yet > - still trying to understand the pros and cons. I wonder how firewalls handle current RealAudio streams. I gather that most do allow Real UDP packets through, although I haven't checked this. From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 18 10:34:10 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25170 for ; Fri, 18 Feb 2000 10:34:09 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 866B152D6; Fri, 18 Feb 2000 10:31:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id F28D452DA; Fri, 18 Feb 2000 10:31:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id A516752D6 for ; Fri, 18 Feb 2000 10:31:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Feb 18 10:29:09 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Fri Feb 18 10:26:46 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA22701; Fri, 18 Feb 2000 10:29:16 -0500 (EST) Message-ID: <38AD6639.A8E3F718@dynamicsoft.com> Date: Fri, 18 Feb 2000 10:33:13 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis Cc: IETF SIP , Taichi Fu Subject: Re: 183 vs 180, When and Where, a Proposal References: <001d01bf797e$abfd2f00$a6e123a6@mcit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Thats fine. My suggestion was that if possible, to encode reasons in responses rather than use provisional media. But, that UACs still pay attention to it if provisional media is sent, for something like distinctive ringing. -Jonathan R. Dean Willis wrote: > > Well, some marketing folks I know got all gooey over custom ringback, which > I see implemented as 180 with SDP pointing to a streaming audio source. I > suppose one could provide this with a back-to-back UA and a transfer > operation, but the signaling semantics would be much more annoying if the > UAC proved to be a gateway. > > -- > dean > > > -----Original Message----- > > From: owner-sip@lists.research.bell-labs.com > > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Jonathan > > Rosenberg > > Sent: Thursday, February 17, 2000 12:59 AM > > To: Dean Willis > > Cc: IETF SIP; Taichi Fu > > Subject: Re: 183 vs 180, When and Where, a Proposal > > > > > > I'm not sure I like making this kind of distinction. Why not simply say > > that a UAC always pay attention to media it is asked to receive via a > > provisional response, and that pure IP UASs are advised not to send SDP > > in provisional responses, but rather encode the data in the response > > itself, via reason phrases or content. > > > > -Jonathan R. > > > > Dean Willis wrote: > > > > > > Taichi Fu and I have been having a discussion on 18x > > provisional messages > > > with media that may be worth sharing. Here's what I think we agreed to. > > > > > > For PSTN interworking, you really have to "listen" to the > > bearer channel to > > > figure out what's going on (see previous discussion on release > > codes). Note > > > that this is really quite different from a pure-IP scenario. > > > > > > If we don't have PSTN interworking, then a 180 means that a > > user is being > > > alerted, and media on a 180 clearly indicates a custom message > > that can be > > > played to the caller. For example, a French user might want to > > play back the > > > distinctive French double-ring, and a Trekky might want to > > > play a clip of Lt. Uhuru saying "Captain, there is an incoming > > call". We > > > might also want to include a text message for the > > audio-impaired device or > > > user, or present a visual notification such as a corporate logo. > > > > > > On the other hand, many UASes (and proxies) MAY choose to > > ignore the media > > > on a 180. This can avoid very complex mixing scenarios in a forking > > > environment. > > > > > > Devices MAY also choose to ignore the media on a 183, but this > > MUST be done > > > very carefully. Media on a 183 for PSTN interworking is far > > more critical > > > than that on a 180 -- it may provide the only useful > > information available > > > to the caller for determining the cause of a call failure. Think very > > > carefully before ignoring a 183. > > > > > > We suggest that a straight IP system, especially a UAS, SHOULD send 180 > > > (which MAY have media) when alerting a user. A PSTN gateway > > SHOULD send a > > > 183 with media when "launching" a call onto the PSTN. Devices > > MAY decide to > > > ignore the media of a 180. Devices SHOULD present the media of > > a 183 to an > > > end user, and MUST deal with the results of not doing so. > > > > > > A key point: > > > > > > Some have argued that 183 also has uses outside of PSTN interworking, > > > whenever there is some status information describing a call > > which needs to > > > be presented "in band", but there has been no actual > > notification delivered > > > to a destination. > > > > > > For example, consider a proxy (P) that implements a forking search. An > > > INVITE for "Joe" is delivered to P. P might, in parallel: > > > 1) respond with a 183 containing media in two parts. > > > part 1 is an html object with > > > text="Your call is being forwarded by Joe's > > Finder Service". > > > part 2 is an SDP object describing a media > > stream with a spoken > > > rendition of the same text > > > 2) send INVITES to all of the contacts Joe has on his > > contact list. > > > > > > This is probably a BAD usage of 183 -- the status information, > > while useful > > > and entertaining, is not critical to the successful interworking of the > > > call. Its presence could obfuscate an upstream forking system, and would > > > provide no additional value to that system. This example SHOULD be > > > implemented using a 180, not a 183. > > > > > > -- > > > Dean > > > > -- > > Jonathan D. Rosenberg 200 Executive Drive > > Chief Scientist Suite 120 > > dynamicsoft West Orange, NJ 07052 > > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > > http://www.dynamicsoft.com > > -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 18 10:37:53 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25227 for ; Fri, 18 Feb 2000 10:37:52 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 089B952DA; Fri, 18 Feb 2000 10:35:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 59D2852DB; Fri, 18 Feb 2000 10:35:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 08D8752DA for ; Fri, 18 Feb 2000 10:35:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Feb 18 10:33:11 EST 2000 Received: from PMESMTP01.wcom.com ([199.249.20.1]) by dusty; Fri Feb 18 10:30:49 EST 2000 Received: from ndcrelay2.mcit.com ([166.37.172.6]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FQ400MFITV256@firewall.mcit.com> for sip@lists.research.bell-labs.com; Fri, 18 Feb 2000 15:33:02 +0000 (GMT) Received: from omzmta04.mcit.com (omzmta04.mcit.com [166.37.194.122]) by ndcrelay2.mcit.com (8.8.7/) with ESMTP id PAA28915; Fri, 18 Feb 2000 15:33:38 +0000 (GMT) Received: from sipdev4 ([166.35.146.138]) by omzmta04.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000218153257.CPZZ13039@sipdev4>; Fri, 18 Feb 2000 15:32:57 +0000 Date: Fri, 18 Feb 2000 09:29:01 -0600 From: Robert Sparks Subject: Cancelled, Decllined, or Failed ReINVITES (was RE: UAC use of tags received in responses) In-reply-to: <38ACA3CC.78FD2652@dynamicsoft.com> To: "'Igor Slepchin'" , "'Daniel G. Petrie'" Cc: "'Jonathan Rosenberg'" , sip@lists.research.bell-labs.com Reply-To: Robert.Sparks@wcom.com Message-id: <001901bf7a24$e2a2e1c0$8a9223a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2615.200 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit This is like the case when the reINVITE ultimately receives a non-200 final response (not including 401, 407 or responses that induce Retry-Afters leading in the end to a reINVITE receiving a 200). I think that case has been discussed here (I know it has been discussed at the bake-offs). Returning (if possible) to the previous call state is the right approach. UA implementations must be careful, however, with how they get back to that state. A failed HOLD, for example, better not leave the user thinking the call is on hold while media is still being sent to the other end. RjS ps. More at the edge, if you have a reINVITE/200/ACK sequence where the 200 contains "bad" SDP, yet another reINVITE will have to be issued to restore the call to the previous state (which should have a high probability of success since the UAs agreed to get that call into that state once before). > -----Original Message----- > From: owner-sip@lists.research.bell-labs.com > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Igor > Slepchin > Sent: Thursday, February 17, 2000 7:44 PM > To: Daniel G. Petrie > Cc: Jonathan Rosenberg; sip@lists.research.bell-labs.com > Subject: Re: UAC use of tags received in responses > > > "Daniel G. Petrie" wrote: > > > > What would one expect to happen when sending > > a CANCEL to a ReINVITE: > > Cancel the transaction, leave the call up at the > previously negotiated > > capabilities. > > or > > Cancel the transaction, drop the call. > > The former. > > > Why would someone want to do this? > > Media renegotiation might involve some user interaction and the caller > may want to give up on the re-INVITE if it does not complete within > certain time. For example, a re-INVITE may be sent when one > of the call > participants wants to start video exchange. If the other side > is capable > of supporting it, the user there might be prompted to see if he/she > agrees to activate video. > > --- > Igor Slepchin > From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 18 10:41:42 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25295 for ; Fri, 18 Feb 2000 10:41:41 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id ABB6E52BB; Fri, 18 Feb 2000 10:39:29 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1CAC952DC; Fri, 18 Feb 2000 10:39:29 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 9182E52BB for ; Fri, 18 Feb 2000 10:39:13 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Feb 18 10:37:54 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Fri Feb 18 10:35:32 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA22709; Fri, 18 Feb 2000 10:30:20 -0500 (EST) Message-ID: <38AD667A.53ED3098@dynamicsoft.com> Date: Fri, 18 Feb 2000 10:34:18 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis Cc: Henning Schulzrinne , IETF SIP , Taichi Fu Subject: Re: 183 vs 180, When and Where, a Proposal References: <001f01bf7980$15ce9c60$a6e123a6@mcit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Dean Willis wrote: > > > I'm not sure that's true. I get the voice announcement if a cell phone > > (Sprint PCS) is not answering. If I route to both a home phone and cell > > number, I don't want the announcement to delay ringing the other phone. > > It may be necessary to consider things like a "forking proxy" that can fork, > absorb the 183(s), record the media attached to it(them), notify the caller, > then play the media back on demand. This lets a user do things like "Hmm, > that call failed, I wonder why. Oh, my message light is blinking, there must > be a telco message from that call." I call this "thinking carefully about > ignoring the provisional media". Save this, it's "prior art". You can certainly do this, but I definitely don't want to mandate this kind of behavior in a normal proxy. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 18 12:40:39 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27866 for ; Fri, 18 Feb 2000 12:40:36 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 5597552DC; Fri, 18 Feb 2000 12:37:28 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id BCFAC52E2; Fri, 18 Feb 2000 12:37:27 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id EEA2752DC for ; Fri, 18 Feb 2000 12:37:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Feb 18 12:36:37 EST 2000 Received: from penguin.wise.edt.ericsson.se ([194.237.142.110]) by dusty; Fri Feb 18 12:34:15 EST 2000 Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id SAA27489 for ; Fri, 18 Feb 2000 18:36:35 +0100 (MET) Received: from greymse1.lmf.ericsson.se (greymse1.lmf.ericsson.se [131.160.1.6]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id TAA16723 for ; Fri, 18 Feb 2000 19:36:34 +0200 (EET) Received: from lmf.ericsson.se (E005004B52C74-udp241380.lmf.ericsson.se [131.160.75.231]) by greymse1.lmf.ericsson.se (8.8.6 (PHNE_17135)/8.8.6) with ESMTP id TAA09199 for ; Fri, 18 Feb 2000 19:36:33 +0200 (EET) Message-ID: <38AD831E.C5421431@lmf.ericsson.se> Date: Fri, 18 Feb 2000 19:36:30 +0200 From: Christer Holmberg X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Subject: Display name References: <38AD5A45.BEF69D7C@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I have a question about the syntax of the display-name. According to the draft, the syntax is: display-name = *token | quoted-string My question concerns the case when we do NOT use quotes. Then, we should only be allowed to use token characters, which don't allow space characters, but in many of the examples I've seen we have, for example, a name, a space(!), and a family name - and this without quotes. eg. To: T.Watson ... Regards, Christer Holmberg Ericsson Finland From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 18 12:45:53 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27957 for ; Fri, 18 Feb 2000 12:45:52 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 6D67752DD; Fri, 18 Feb 2000 12:43:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id DA57B52DF; Fri, 18 Feb 2000 12:43:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id D525952DD for ; Fri, 18 Feb 2000 12:43:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Feb 18 12:41:45 EST 2000 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by dusty; Fri Feb 18 12:39:22 EST 2000 Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA13457; Fri, 18 Feb 2000 09:42:28 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA27619; Fri, 18 Feb 2000 09:41:42 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14509.33878.524020.317488@thomasm-u1.cisco.com> Date: Fri, 18 Feb 2000 09:41:42 -0800 (PST) To: Jonathan Rosenberg Cc: sip@lists.research.bell-labs.com Subject: DHCP option tags for SIP In-Reply-To: <38AD5739.C579520D@dynamicsoft.com> References: <38AD5739.C579520D@dynamicsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit I'd like to throw out one wet blanket: getting the name of a first hop proxy is all well and good, but it hardly solves the larger provisioning problem, especially for "simple" phones and other devices which don't have an easy way to be configured by a user, or want/need to be centrally managed. Trying to cram bootstrap provisioning for N different kinds of protocols/devices into one MTU sized packet seems like a losing situation and symptomatic that DHCP is being used for way more than it can deliver in the long run. It seems to me that it would be far better to create some sort of indirection method within DHCP which says "here's the URL if you want to get SIP related parameters" (ad naseum). But all that's being asked for is "just" the address of the first hop proxy... sigh. Mike Jonathan Rosenberg writes: > Folks, > > Many of you may have seen the recent draft presenting DHCP option codes > for SIP: > > http://search.ietf.org/internet-drafts/draft-nair-sip-dhcp-01.txt > > The consensus among the authors and wg chairs is that this is a clearly > useful item, and we would like to move it forward. In the interests of > speed, we are proposing a "fast track" approach for this document. > Basically, this message will serve as announcement of our intention to > adopt this as a work item. If no one objects to this procedure, in one > weeks time, we will issue an extended working group last call on it, and > that call will last 3 weeks. Comments will be collected, and then we > will send the document to IESG for proposed. > > I believe its critical that we do whatever we can to speed up the > process of delivering documents to the community. This is especially the > case for small, largely uncontroversial documents such as this. Rather > than languish for months, getting this from concept to submission to > IESG in a matter of a single month seems more desirable. > > -Jonathan R. > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > > From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 18 12:56:47 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28168 for ; Fri, 18 Feb 2000 12:56:47 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A34DE52DF; Fri, 18 Feb 2000 12:51:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 0C74B52E0; Fri, 18 Feb 2000 12:51:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id C06FC52DF for ; Fri, 18 Feb 2000 12:51:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Feb 18 12:49:55 EST 2000 Received: from mercury.Sun.COM ([192.9.25.1]) by dusty; Fri Feb 18 12:47:33 EST 2000 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA27473; Fri, 18 Feb 2000 09:49:43 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id JAA04232; Fri, 18 Feb 2000 09:49:36 -0800 (PST) Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id JAA18154; Fri, 18 Feb 2000 09:49:36 -0800 (PST) Message-Id: <200002181749.JAA18154@nasnfs.eng.sun.com> Date: Fri, 18 Feb 2000 09:50:48 -0800 (PST) From: James Kempf Reply-To: James Kempf Subject: Re: DHCP option tags for SIP To: jdrosen@dynamicsoft.com, mat@cisco.com Cc: sip@lists.research.bell-labs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: CDm4+VO7w3ywFtm5mjMlCg== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Well, at the risk of prolonging a controversy, SLP was designed to fix exactly the problems you outline with DHCP. jak >Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com >Delivered-To: sip-local@paperless.dnrc.bell-labs.com >From: Michael Thomas >MIME-Version: 1.0 >Content-Transfer-Encoding: 7bit >Date: Fri, 18 Feb 2000 09:41:42 -0800 (PST) >To: Jonathan Rosenberg >Cc: sip@lists.research.bell-labs.com >Subject: DHCP option tags for SIP >X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! > > >I'd like to throw out one wet blanket: getting the >name of a first hop proxy is all well and good, >but it hardly solves the larger provisioning >problem, especially for "simple" phones and other >devices which don't have an easy way to be >configured by a user, or want/need to be centrally >managed. Trying to cram bootstrap provisioning for >N different kinds of protocols/devices into one >MTU sized packet seems like a losing situation and >symptomatic that DHCP is being used for way more >than it can deliver in the long run. > >It seems to me that it would be far better to >create some sort of indirection method within DHCP >which says "here's the URL if you want to get SIP >related parameters" (ad naseum). > >But all that's being asked for is "just" the >address of the first hop proxy... sigh. > > Mike > > >Jonathan Rosenberg writes: > > Folks, > > > > Many of you may have seen the recent draft presenting DHCP option codes > > for SIP: > > > > http://search.ietf.org/internet-drafts/draft-nair-sip-dhcp-01.txt > > > > The consensus among the authors and wg chairs is that this is a clearly > > useful item, and we would like to move it forward. In the interests of > > speed, we are proposing a "fast track" approach for this document. > > Basically, this message will serve as announcement of our intention to > > adopt this as a work item. If no one objects to this procedure, in one > > weeks time, we will issue an extended working group last call on it, and > > that call will last 3 weeks. Comments will be collected, and then we > > will send the document to IESG for proposed. > > > > I believe its critical that we do whatever we can to speed up the > > process of delivering documents to the community. This is especially the > > case for small, largely uncontroversial documents such as this. Rather > > than languish for months, getting this from concept to submission to > > IESG in a matter of a single month seems more desirable. > > > > -Jonathan R. > > -- > > Jonathan D. Rosenberg 200 Executive Drive > > Chief Scientist Suite 120 > > dynamicsoft West Orange, NJ 07052 > > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > > http://www.dynamicsoft.com > > > > > > > From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 18 13:08:05 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28426 for ; Fri, 18 Feb 2000 13:08:05 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 1DF9C52E0; Fri, 18 Feb 2000 13:05:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 83FC152E1; Fri, 18 Feb 2000 13:05:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id F07B752E0 for ; Fri, 18 Feb 2000 13:05:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Feb 18 13:04:40 EST 2000 Received: from palrel3.hp.com ([156.153.255.226]) by dusty; Fri Feb 18 13:02:17 EST 2000 Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by palrel3.hp.com (Postfix) with ESMTP id B27511E9 for ; Fri, 18 Feb 2000 10:04:28 -0800 (PST) Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238]) by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id SAA14183; Fri, 18 Feb 2000 18:04:26 GMT Message-ID: <38AD89AF.30ED95DF@hplb.hpl.hp.com> Date: Fri, 18 Feb 2000 18:04:31 +0000 From: Anders Kristensen Organization: HP Labs X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Christer Holmberg Cc: sip@lists.research.bell-labs.com Subject: Re: Display name References: <38AD5A45.BEF69D7C@lucent.com> <38AD831E.C5421431@lmf.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Christer Holmberg wrote: > > Hi, > > I have a question about the syntax of the display-name. > > According to the draft, the syntax is: > > display-name = *token | quoted-string > > My question concerns the case when we do NOT use quotes. Then, we should > only be allowed to use token characters, which don't allow space > characters, but in many of the examples I've seen we have, for example, > a name, a space(!), and a family name - and this without quotes. *token matches zero or more tokens. The grammar allows whitespace between these tokens - see the comments on implied LWS in appendix C of rfc 2543. Anders -- Anders Kristensen , http://www-uk.hpl.hp.com/people/ak/ Hewlett-Packard Labs, Bristol, UK From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 18 13:25:57 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28649 for ; Fri, 18 Feb 2000 13:25:56 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 308D852E1; Fri, 18 Feb 2000 13:23:27 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A2E6752E2; Fri, 18 Feb 2000 13:23:26 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from bronx.dnrc.bell-labs.com (bronx [135.180.160.8]) by lists.research.bell-labs.com (Postfix) with ESMTP id A663452E1 for ; Fri, 18 Feb 2000 13:23:09 -0500 (EST) Received: from cs.columbia.edu (ume [135.180.240.103]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA24673; Fri, 18 Feb 2000 13:23:07 -0500 (EST) Message-ID: <38AD8E0D.3F21294D@cs.columbia.edu> Date: Fri, 18 Feb 2000 13:23:09 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.05 [en] (WinNT; U) MIME-Version: 1.0 To: Michael Thomas Cc: sip@lists.research.bell-labs.com Subject: Re: DHCP option tags for SIP References: <38AD5739.C579520D@dynamicsoft.com> <14509.33878.524020.317488@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > I'd like to throw out one wet blanket: getting the > name of a first hop proxy is all well and good, > but it hardly solves the larger provisioning > problem, especially for "simple" phones and other > devices which don't have an easy way to be > configured by a user, or want/need to be centrally > managed. Trying to cram bootstrap provisioning for > N different kinds of protocols/devices into one > MTU sized packet seems like a losing situation and > symptomatic that DHCP is being used for way more > than it can deliver in the long run. As far as I can tell from our implementation experience, this is pretty much (*) the last piece of information needed to configure a phone. At the DHCP level, we currently use for a basic phone: - IP address, DNS server address, default gateway (standard DHCP fare) - time server address - outbound SIP proxy server - normal boot image information for phones with downloadable code We have to implement DHCP in any event, so the incremental cost of providing this is close to zero. There are other SIP-level configurations that are inappropriate, in my view, for DHCP, things like speed dial configurations or other UI assignments, any end system CPL, etc. > > It seems to me that it would be far better to > create some sort of indirection method within DHCP > which says "here's the URL if you want to get SIP > related parameters" (ad naseum). > > But all that's being asked for is "just" the > address of the first hop proxy... sigh. As I said, this is necessary and sufficient to get working phones, from what I can tell. > > Mike From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 18 14:44:42 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29966 for ; Fri, 18 Feb 2000 14:44:41 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id D20B452E2; Fri, 18 Feb 2000 14:41:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E24BC52E3; Fri, 18 Feb 2000 14:41:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C69D452E2 for ; Fri, 18 Feb 2000 14:41:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Feb 18 14:39:06 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Fri Feb 18 14:36:44 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA23343; Fri, 18 Feb 2000 14:39:05 -0500 (EST) Message-ID: <38ADA0C5.DB80C08B@dynamicsoft.com> Date: Fri, 18 Feb 2000 14:43:01 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: James Kempf Cc: mat@cisco.com, sip@lists.research.bell-labs.com Subject: Re: DHCP option tags for SIP References: <200002181749.JAA18154@nasnfs.eng.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit There is definitely room for both. DHCP is appropriate where a simple "gimme the closest proxy" will do. SLP is better when the selection process is more complicated, and depends on attributes of the proxy. -Jonathan R. James Kempf wrote: > > Well, at the risk of prolonging a controversy, SLP was designed to > fix exactly the problems you outline with DHCP. > > jak > -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 18 17:24:02 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03095 for ; Fri, 18 Feb 2000 17:24:00 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id D10B952E3; Fri, 18 Feb 2000 17:21:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 49D7552E4; Fri, 18 Feb 2000 17:21:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id B177652E3 for ; Fri, 18 Feb 2000 17:21:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Feb 18 17:20:38 EST 2000 Received: from repulse.cnchost.com ([207.155.248.4]) by dusty; Fri Feb 18 17:18:16 EST 2000 Received: from vovida.com (w178.z216112071.sjc-ca.dsl.cnc.net [216.112.71.178]) by repulse.cnchost.com id RAA06656; Fri, 18 Feb 2000 17:20:36 -0500 (EST) [ConcentricHost SMTP Relay 1.8] Message-ID: <38ADC5B6.CADA0C6@vovida.com> Date: Fri, 18 Feb 2000 14:20:38 -0800 From: Sunitha Kumar Organization: Vovida Networks X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: SIPbell-labs Subject: Proxy tagging the fields Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi: Can the proxy tag the From or the To fields. Thanks! Sunitha Kumar From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 18 18:33:55 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03873 for ; Fri, 18 Feb 2000 18:33:55 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id B181452DB; Fri, 18 Feb 2000 18:31:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 2098552E5; Fri, 18 Feb 2000 18:31:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 6FB3652DB for ; Fri, 18 Feb 2000 18:31:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Feb 18 18:30:36 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Fri Feb 18 18:28:13 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA23739; Fri, 18 Feb 2000 18:30:42 -0500 (EST) Message-ID: <38ADD575.B77D19DC@dynamicsoft.com> Date: Fri, 18 Feb 2000 18:27:49 -0500 From: Igor Slepchin Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Sunitha Kumar Cc: SIPbell-labs Subject: Re: Proxy tagging the fields References: <38ADC5B6.CADA0C6@vovida.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Sunitha Kumar wrote: > > Hi: > > Can the proxy tag the From or the To fields. Proxy should never touch the From field. A proxy should put a tag in the To field of final responses it generates for the requests with no tag in the To. --- Igor Slepchin From owner-sip-outgoing@lists.research.bell-labs.com Sat Feb 19 09:27:40 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24695 for ; Sat, 19 Feb 2000 09:27:34 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 1C41F52E4; Sat, 19 Feb 2000 09:17:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 7C3FE52E7; Sat, 19 Feb 2000 09:17:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id B200252E4 for ; Sat, 19 Feb 2000 09:17:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Sat Feb 19 09:16:46 EST 2000 Received: from dirty.research.bell-labs.com ([204.178.16.6]) by dusty; Sat Feb 19 09:14:24 EST 2000 Received: from ns.fmmo.ca ([207.253.160.156]) by dirty; Sat Feb 19 08:45:53 EST 2000 Received: from localhost (fm-listproc@localhost) by ns.fmmo.ca (8.9.3/8.9.3) with ESMTP id IAA26560; Sat, 19 Feb 2000 08:40:36 -0500 Date: Sat, 19 Feb 2000 08:40:36 -0500 (EST) From: Francois Menard List Account To: Michael Thomas Cc: Jonathan Rosenberg , sip@lists.research.bell-labs.com Subject: Re: DHCP option tags for SIP In-Reply-To: <14509.33878.524020.317488@thomasm-u1.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk The option is SLP I think .... DHCP as a bootstrap protocol doesn't ring too well with me. -=Francois=- On Fri, 18 Feb 2000, Michael Thomas wrote: > > I'd like to throw out one wet blanket: getting the > name of a first hop proxy is all well and good, > but it hardly solves the larger provisioning > problem, especially for "simple" phones and other > devices which don't have an easy way to be > configured by a user, or want/need to be centrally > managed. Trying to cram bootstrap provisioning for > N different kinds of protocols/devices into one > MTU sized packet seems like a losing situation and > symptomatic that DHCP is being used for way more > than it can deliver in the long run. > > It seems to me that it would be far better to > create some sort of indirection method within DHCP > which says "here's the URL if you want to get SIP > related parameters" (ad naseum). > > But all that's being asked for is "just" the > address of the first hop proxy... sigh. > > Mike > > > Jonathan Rosenberg writes: > > Folks, > > > > Many of you may have seen the recent draft presenting DHCP option codes > > for SIP: > > > > http://search.ietf.org/internet-drafts/draft-nair-sip-dhcp-01.txt > > > > The consensus among the authors and wg chairs is that this is a clearly > > useful item, and we would like to move it forward. In the interests of > > speed, we are proposing a "fast track" approach for this document. > > Basically, this message will serve as announcement of our intention to > > adopt this as a work item. If no one objects to this procedure, in one > > weeks time, we will issue an extended working group last call on it, and > > that call will last 3 weeks. Comments will be collected, and then we > > will send the document to IESG for proposed. > > > > I believe its critical that we do whatever we can to speed up the > > process of delivering documents to the community. This is especially the > > case for small, largely uncontroversial documents such as this. Rather > > than languish for months, getting this from concept to submission to > > IESG in a matter of a single month seems more desirable. > > > > -Jonathan R. > > -- > > Jonathan D. Rosenberg 200 Executive Drive > > Chief Scientist Suite 120 > > dynamicsoft West Orange, NJ 07052 > > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > > http://www.dynamicsoft.com > > > > > > > From owner-sip-outgoing@lists.research.bell-labs.com Sat Feb 19 12:14:01 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26246 for ; Sat, 19 Feb 2000 12:14:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 5D30F52E5; Sat, 19 Feb 2000 12:11:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id B9D8F52E8; Sat, 19 Feb 2000 12:11:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 7707152E5 for ; Sat, 19 Feb 2000 12:11:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Sat Feb 19 12:10:58 EST 2000 Received: from sj-msg-core-1.cisco.com ([171.71.163.11]) by dusty; Sat Feb 19 12:08:36 EST 2000 Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA27785; Sat, 19 Feb 2000 09:11:41 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA27949; Sat, 19 Feb 2000 09:10:55 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14510.52895.229482.812706@thomasm-u1.cisco.com> Date: Sat, 19 Feb 2000 09:10:55 -0800 (PST) To: Francois Menard List Account Cc: Michael Thomas , Jonathan Rosenberg , sip@lists.research.bell-labs.com Subject: Re: DHCP option tags for SIP In-Reply-To: References: <14509.33878.524020.317488@thomasm-u1.cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit So, let me poke at this a bit: 1) if I have a residential gateway, say, which runs SIP on its two POTS lines, with SLP can I find the (different) first hop proxies for each port? 2) Suppose I have some IP phones at home which are gateway'd through my home SIP proxy which allow me to set up local dial plans. Would SLP be adequate to configure the 1) phones 2) my home proxy for learning their next hope proxy? I'm not trying to diss the idea, but SLP seems to have been written with enterprises in mind -- which is fine -- but the more complicated situations will probably need to be considered where we start splitting up the monolithicly administered network into various administrative domains, and differently administered services. Mike Francois Menard List Account writes: > > > The option is SLP I think .... DHCP as a bootstrap protocol doesn't ring > too well with me. > > -=Francois=- > > On Fri, 18 Feb 2000, Michael Thomas wrote: > > > > > I'd like to throw out one wet blanket: getting the > > name of a first hop proxy is all well and good, > > but it hardly solves the larger provisioning > > problem, especially for "simple" phones and other > > devices which don't have an easy way to be > > configured by a user, or want/need to be centrally > > managed. Trying to cram bootstrap provisioning for > > N different kinds of protocols/devices into one > > MTU sized packet seems like a losing situation and > > symptomatic that DHCP is being used for way more > > than it can deliver in the long run. > > > > It seems to me that it would be far better to > > create some sort of indirection method within DHCP > > which says "here's the URL if you want to get SIP > > related parameters" (ad naseum). > > > > But all that's being asked for is "just" the > > address of the first hop proxy... sigh. > > > > Mike > > > > > > Jonathan Rosenberg writes: > > > Folks, > > > > > > Many of you may have seen the recent draft presenting DHCP option codes > > > for SIP: > > > > > > http://search.ietf.org/internet-drafts/draft-nair-sip-dhcp-01.txt > > > > > > The consensus among the authors and wg chairs is that this is a clearly > > > useful item, and we would like to move it forward. In the interests of > > > speed, we are proposing a "fast track" approach for this document. > > > Basically, this message will serve as announcement of our intention to > > > adopt this as a work item. If no one objects to this procedure, in one > > > weeks time, we will issue an extended working group last call on it, and > > > that call will last 3 weeks. Comments will be collected, and then we > > > will send the document to IESG for proposed. > > > > > > I believe its critical that we do whatever we can to speed up the > > > process of delivering documents to the community. This is especially the > > > case for small, largely uncontroversial documents such as this. Rather > > > than languish for months, getting this from concept to submission to > > > IESG in a matter of a single month seems more desirable. > > > > > > -Jonathan R. > > > -- > > > Jonathan D. Rosenberg 200 Executive Drive > > > Chief Scientist Suite 120 > > > dynamicsoft West Orange, NJ 07052 > > > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > > > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > > > http://www.dynamicsoft.com > > > > > > > > > > > > > > > From owner-sip-outgoing@lists.research.bell-labs.com Sat Feb 19 12:45:47 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26454 for ; Sat, 19 Feb 2000 12:45:46 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 7F5C452E7; Sat, 19 Feb 2000 12:43:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id F1BA652E9; Sat, 19 Feb 2000 12:43:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 1404152E7 for ; Sat, 19 Feb 2000 12:43:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Sat Feb 19 12:42:01 EST 2000 Received: from sj-msg-core-2.cisco.com ([171.69.43.88]) by dusty; Sat Feb 19 12:39:39 EST 2000 Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA20169; Sat, 19 Feb 2000 09:42:26 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id JAA27956; Sat, 19 Feb 2000 09:41:58 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14510.54758.210526.176628@thomasm-u1.cisco.com> Date: Sat, 19 Feb 2000 09:41:58 -0800 (PST) To: Henning Schulzrinne Cc: Michael Thomas , sip@lists.research.bell-labs.com Subject: Re: DHCP option tags for SIP In-Reply-To: <38AD8E0D.3F21294D@cs.columbia.edu> References: <38AD5739.C579520D@dynamicsoft.com> <14509.33878.524020.317488@thomasm-u1.cisco.com> <38AD8E0D.3F21294D@cs.columbia.edu> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Henning Schulzrinne writes: > As far as I can tell from our implementation experience, this is pretty > much (*) the last piece of information needed to configure a phone. At > the DHCP level, we currently use for a basic phone: > > - IP address, DNS server address, default gateway (standard DHCP fare) > - time server address > - outbound SIP proxy server > - normal boot image information for phones with downloadable code Dumb question: would a phone need its E.164 address(es) when registering, etc? > We have to implement DHCP in any event, so the incremental cost of > providing this is close to zero. Sure, but that wasn't my point of course. > There are other SIP-level configurations that are inappropriate, in my > view, for DHCP, things like speed dial configurations or other UI > assignments, any end system CPL, etc. This, however, was my point. If you believe in directories for configless widgets, it would make a lot more sense to dump all of this information there and have a pointer to the directory in DHCP. If the sum total of configuration that a configurationless device is greater than just the address of the first hop proxy, then all this new option is doing is solving a small part of a previously unsolved problem. Mike From owner-sip-outgoing@lists.research.bell-labs.com Sat Feb 19 13:11:50 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26648 for ; Sat, 19 Feb 2000 13:11:50 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id B204652E9; Sat, 19 Feb 2000 13:09:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 2D84152EA; Sat, 19 Feb 2000 13:09:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 3B47E52E9 for ; Sat, 19 Feb 2000 13:09:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Sat Feb 19 13:07:08 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Sat Feb 19 13:04:46 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id NAA12785; Sat, 19 Feb 2000 13:07:04 -0500 (EST) Message-ID: <38AEDBC8.E3D77507@cs.columbia.edu> Date: Sat, 19 Feb 2000 13:07:04 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Michael Thomas Cc: sip@lists.research.bell-labs.com Subject: Re: DHCP option tags for SIP References: <38AD5739.C579520D@dynamicsoft.com> <14509.33878.524020.317488@thomasm-u1.cisco.com> <38AD8E0D.3F21294D@cs.columbia.edu> <14510.54758.210526.176628@thomasm-u1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Michael Thomas wrote: > > Henning Schulzrinne writes: > > As far as I can tell from our implementation experience, this is pretty > > much (*) the last piece of information needed to configure a phone. At > > the DHCP level, we currently use for a basic phone: > > > > - IP address, DNS server address, default gateway (standard DHCP fare) > > - time server address > > - outbound SIP proxy server > > - normal boot image information for phones with downloadable code > > Dumb question: would a phone need its E.164 address(es) > when registering, etc? Actually, an interesting question. A phone would need the identity with which it should register. From what I can tell, PBX will probably have two identities for their phones, one "legacy" (E.164) identity and one or more SIP identities (email address). It could be more than one if two people share a phone, as our grad students do. It might even have a third identity reflecting the phone's location, e.g., "Room2F524@somewhere.com". The first two types of identities would change if a person moved into a different office (assuming that she leaves her phone behind), while the latter would stay constant. Conversely, if people take their phones with them, only the last identity would change. Since these identities don't generally change all that often, this could be hard-coded. (Fancier mechanisms, such as identities conveyed by PalmPilots, have been discussed elsewhere.) Alternatively, a few of us have discussed that there might well be a need for an additional configuration parameter, namely a list of "identities" that the phone should register with. Pretty straightforward to define, but I kind of wanted to get the server issue out of the way first. > > > There are other SIP-level configurations that are inappropriate, in my > > view, for DHCP, things like speed dial configurations or other UI > > assignments, any end system CPL, etc. > > This, however, was my point. If you believe in directories > for configless widgets, it would make a lot more sense to > dump all of this information there and have a pointer to > the directory in DHCP. If the sum total of configuration > that a configurationless device is greater than just the > address of the first hop proxy, then all this new > option is doing is solving a small part of a previously > unsolved problem. Our current intent is to put some of this into the REGISTER response, using an appropriate MIME type, since it avoids having to define yet another directory protocol, more servers, etc. (Putting LDAP into an embedded system strikes me as challenging, to put it mildly.) However, the outbound proxy can be different from my registration server. Indeed, in order to find my non-multicast registration server, I need to know my identity (see discussion above). Thus, overall, I see DHCP used for things that are needed to bootstrap into the SIP infrastructure with minimum cost and without creating seventeen new directory servers. Almost all SOHO-style integrated devices support DHCP, for obvious reasons, while installing and configuring LDAP, say, seems like a stretch for this type of application. (You don't mention a specific directory service, so pardon me if I'm misinterpreting your remarks.) Overall, the larger the number of servers, the higher the probability that one of the alphabet soup servers is down, misconfigured. In my view, it would be nice if I can install a basic Internet PBX with two servers, a DHCP server and a SIP server. These seem to be required, adding anything else as a basic requirement to make phones ring seems like it needs a fair amount of justification for the complexity. This does not mean that more complicated scenarios can't make good use of SLP or LDAP. (We use LDAP in our SIP server and PC client, for example.) > > Mike -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Sun Feb 20 20:06:15 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14172 for ; Sun, 20 Feb 2000 20:06:14 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 7B4F152AB; Sun, 20 Feb 2000 20:03:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E6C3552BB; Sun, 20 Feb 2000 20:03:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 3060152AB for ; Sun, 20 Feb 2000 20:03:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Sun Feb 20 20:01:47 EST 2000 Received: from mercury.Sun.COM ([192.9.25.1]) by dusty; Sun Feb 20 19:59:26 EST 2000 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA09125; Sun, 20 Feb 2000 17:01:44 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id RAA23858; Sun, 20 Feb 2000 17:01:43 -0800 (PST) Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id RAA13500; Sun, 20 Feb 2000 17:01:42 -0800 (PST) Message-Id: <200002210101.RAA13500@nasnfs.eng.sun.com> Date: Sun, 20 Feb 2000 17:02:58 -0800 (PST) From: James Kempf Reply-To: James Kempf Subject: Re: DHCP option tags for SIP To: mat@cisco.com Cc: sip@lists.research.bell-labs.com, James.Kempf@Eng.Sun.COM MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: +epPXwzuYdMf4JW6S5wpTQ== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk >1) if I have a residential gateway, say, which runs > SIP on its two POTS lines, with SLP can I find > the (different) first hop proxies for each port? I'm not quite sure I understand the scenerio (I'm new to SIP, sorry). What is looking for the first hop proxy, the residental gateway? My feeling is that the answer to this must be "no" because if the gateway is sitting on a POTS line, then the protocol on the POTS line must be something other than IP. Or do you mean having a phone in the house find the first hop proxy which would be the residential gateway? If that's the case, then because the scenerio states that there are different first hop proxies, there must be two residential gateways, or? If that's the case, then the phone could select a gateway using SLP, if the service advertisements for the gateways distinguished them in some way. >2) Suppose I have some IP phones at home which are > gateway'd through my home SIP proxy which allow > me to set up local dial plans. Would SLP be adequate > to configure the 1) phones 2) my home proxy for learning > their next hope proxy? > Let me speculate about the intent of this question (please correct me if I'm wrong). Is the intent of this question to see whether SLP can configure a home phone with a custom dial plan? If so, then I would say that that is probably not the right use for SLP. I would venture to guess that would involve some kind of negotiation with the telephone company's subscriber database. I would presume a AAA protocol would get involved somehow, to authenticate your phone for access to the dial plan. As for 1), this depends on what you want to configure the phones with. You can't configure them with an IP address, because you need an IP address to use SLP. You could configure them with basic stuff like outbound proxy address. Similarly for 2), you could have the proxy find the next hop proxy using SLP if you wanted. >I'm not trying to diss the idea, but SLP seems to >have been written with enterprises in mind -- >which is fine -- but the more complicated >situations will probably need to be considered >where we start splitting up the monolithicly >administered network into various administrative >domains, and differently administered services. > There is nothing specific to the enterprise in SLP's design, though it is not designed to be used on the Internet (large "I" here). SLP has some features for home-style networks, like using multicast in the simplest case. As Jonathan points out, it is primarily of value when the client has choices for a server. If you take a look at the SLP template draft we submitted the other day, you can get an idea of the kinds of attributes we are proposing for distinguishing servers. jak From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 21 07:51:55 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05079 for ; Mon, 21 Feb 2000 07:51:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 5171052C4; Mon, 21 Feb 2000 07:49:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id CBDF952C8; Mon, 21 Feb 2000 07:49:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 6180652C4 for ; Mon, 21 Feb 2000 07:49:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 21 07:48:28 EST 2000 From: rpreethy@hss.hns.com To: sip@lists.research.bell-labs.com Date: Mon, 21 Feb 2000 07:46:07 -0500 Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Mon Feb 21 07:46:07 EST 2000 Message-Id: <20000221124907.6180652C4@lists.research.bell-labs.com> Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 21 07:55:45 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05188 for ; Mon, 21 Feb 2000 07:55:44 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4EDB552C8; Mon, 21 Feb 2000 07:51:36 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A708B52D4; Mon, 21 Feb 2000 07:51:35 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 7621A52C8 for ; Mon, 21 Feb 2000 07:51:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 21 07:50:02 EST 2000 Received: from dirty.research.bell-labs.com ([204.178.16.6]) by dusty; Mon Feb 21 07:47:40 EST 2000 Received: from tapti.hss.hns.com ([139.85.242.19]) by dirty; Mon Feb 21 07:49:00 EST 2000 Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id SAA00523 for ; Mon, 21 Feb 2000 18:36:57 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 6525688C.0045A286 ; Mon, 21 Feb 2000 18:10:35 +0530 X-Lotus-FromDomain: HSSBLR From: rpreethy@hss.hns.com To: sip@lists.research.bell-labs.com Message-ID: <6525688C.0045A19B.00@sampark.hss.hns.com> Date: Mon, 21 Feb 2000 18:10:32 +0530 Subject: Accept-Contact Header Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk hi All, The document SIP Caller Preferences and Callee Capabilities - draft-ietf-sipcallerprefs-00.txt gives the grammer for Accept-Contact Header as Accept-Contact = "Accept-Contact" ":" 1# rule rule = ( name-addr | addr-spec ) [ *( ";" (cp-params | extension-param | q-param) ) ] q-param = "q" "=" qvalue extension-param = extension-name "=" extension-value extension-name = token extension-value = token | quoted-string and the example given is Accept-Contact: sip:sales@acme.com ;q=0, ;media="!video" ;q=0.1, ;mobility="fixed" ;q=0.6, ;mobility="!fixed" ;q=0.4 According to my understanding, in this example each of the comma separated values is a separate Accept Contact rule, And the parameters of a paticular accept contact rule are separated by ";" semicolon. Here each of the q-params are followed by a comma and then a semi-colon . I cannot understand whether to consider this as 1) a single accept contact rule with all the entries following sip:sales@acme.com as parameters in which case I dont see a need for a comma and semi-colon as separaters between parameters. 2) 4 rules where-in the 2nd 3rd and 4th do not have a nameaddr|addrspec entry which is also an error, becos the rule mandates the presence of nameaddr|addr-spec. Can someone explain this to me. Regards, Preethy From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 21 08:19:49 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05840 for ; Mon, 21 Feb 2000 08:19:49 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 2288352D4; Mon, 21 Feb 2000 08:17:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D90F052D5; Mon, 21 Feb 2000 08:17:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 4F43B52D4 for ; Mon, 21 Feb 2000 08:17:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Feb 21 08:15:05 EST 2000 Received: from ns.fmmo.ca ([207.253.160.156]) by dusty; Mon Feb 21 08:12:44 EST 2000 Received: from localhost (fm-listproc@localhost) by ns.fmmo.ca (8.9.3/8.9.3) with ESMTP id IAA31583; Mon, 21 Feb 2000 08:29:38 -0500 Date: Mon, 21 Feb 2000 08:29:37 -0500 (EST) From: Francois Menard List Account To: James Kempf Cc: mat@cisco.com, sip@lists.research.bell-labs.com, etremblay@mediatrix.com Subject: Re: DHCP option tags for SIP In-Reply-To: <200002210101.RAA13500@nasnfs.eng.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk The question has to do with generic means for capabilities exchange between two devices, using a common set of semantics. I can easily see how an XML DTD for a specific industry (i.e. in some cases Internet Telephony for SIP), could be used to agree on capabilities parameters of other UA's, Proxy Servers, PSTN Gateways & RTP Mixers. In this sense, and to answer some private concerns of others, I feel that SLP is a better end-to-end protocol than DHCP in order to perform these tasks. I dont like the approach, of "if all you want to do is pass on the IP address of the first Proxy Server, then DHCP is fine". To me this violates the notion of end-to-end capabilities exchange (and gives all the power to a mighty-god Proxy server). To this end, my proposal for an SLP DTD for SIP appliances could resembles the Call Processing Language. Maybe the XML DTD for CPL (with some tweaks) could be used for caps exchange using SLP. For example, Mediatrix has a device which is very unique, i.e. a VoIP gateway with more RTP mixing capabilties than end-points, 3 fxs ports and one fxs/fxo port. Being able to advertise this functionality through SLP is a very unique situation. Hence my warm welcome of SLP to the SIP scene. Its simply better than all those nasty broadcast packets on LANs using DHCP. -=Francois=- On Sun, 20 Feb 2000, James Kempf wrote: > > >1) if I have a residential gateway, say, which runs > > SIP on its two POTS lines, with SLP can I find > > the (different) first hop proxies for each port? > > I'm not quite sure I understand the scenerio (I'm new to SIP, sorry). > What is looking for the first hop proxy, the residental gateway? > My feeling is that the answer to this must be "no" because > if the gateway is sitting on a POTS line, then the protocol on > the POTS line must be something other than IP. Or do you mean > having a phone in the house find the first hop proxy which would > be the residential gateway? If that's the case, then because > the scenerio states that there are different first hop proxies, > there must be two residential gateways, or? If that's the case, > then the phone could select a gateway using SLP, if the service > advertisements for the gateways distinguished them in some way. > > >2) Suppose I have some IP phones at home which are > > gateway'd through my home SIP proxy which allow > > me to set up local dial plans. Would SLP be adequate > > to configure the 1) phones 2) my home proxy for learning > > their next hope proxy? > > > > Let me speculate about the intent of this question (please correct > me if I'm wrong). Is the intent of this question to see whether > SLP can configure a home phone with a custom dial plan? If so, > then I would say that that is probably not the right use for > SLP. I would venture to guess that would involve some kind of > negotiation with the telephone company's subscriber database. > I would presume a AAA protocol would get involved somehow, to > authenticate your phone for access to the dial plan. > As for 1), this depends on what you want to configure the phones > with. You can't configure them with an IP address, because you > need an IP address to use SLP. You could configure them with > basic stuff like outbound proxy address. Similarly for 2), you could > have the proxy find the next hop proxy using SLP if you wanted. > > >I'm not trying to diss the idea, but SLP seems to > >have been written with enterprises in mind -- > >which is fine -- but the more complicated > >situations will probably need to be considered > >where we start splitting up the monolithicly > >administered network into various administrative > >domains, and differently administered services. > > > > There is nothing specific to the enterprise in SLP's design, though > it is not designed to be used on the Internet (large "I" here). > SLP has some features for home-style networks, like using multicast > in the simplest case. As Jonathan points out, it is primarily of > value when the client has choices for a server. If you take a look > at the SLP template draft we submitted the other day, you can get > an idea of the kinds of attributes we are proposing for distinguishing > servers. > > jak > > From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 21 10:40:28 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09611 for ; Mon, 21 Feb 2000 10:40:27 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id EDF7852C4; Mon, 21 Feb 2000 10:37:29 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id DB98552D6; Mon, 21 Feb 2000 10:37:27 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 9D9B352C4 for ; Mon, 21 Feb 2000 10:37:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 21 10:35:47 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Mon Feb 21 10:33:26 EST 2000 Received: from dynamicsoft.com (1Cust228.tnt1.freehold.nj.da.uu.net [63.17.113.228]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA24879; Mon, 21 Feb 2000 10:31:53 -0500 (EST) Message-ID: <38B15B68.B350009A@dynamicsoft.com> Date: Mon, 21 Feb 2000 10:36:08 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Francois Menard List Account Cc: James Kempf , mat@cisco.com, sip@lists.research.bell-labs.com, etremblay@mediatrix.com Subject: Re: DHCP option tags for SIP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit I'd like to try and keep this discussion focused in order to quickly answer the following question: Should we "fast track" a DHCP options for finding a SIP server document? Neither DHCP nor SLP are capable of providing complicated application layer configuration parameters, such as dialing plans or addresses. Neither are good for capabilities exchange, which is something different altogether IMHO. With DHCP, you can at least find the server to register to, and that may provide much of this information in registration responses. Certainly, it doesn't preclude using DHCP to point to a specialized configuration server down the road either. Both DHCP and SLP will do the same thing - get you the adress of a server. With SLP, you can be picky about which server you want, based on its capabilities (like ability to support CPL). I see roles for both. -Jonathan R. Francois Menard List Account wrote: > > The question has to do with generic means for capabilities exchange > between two devices, using a common set of semantics. > > I can easily see how an XML DTD for a specific industry (i.e. in some > cases Internet Telephony for SIP), could be used to agree on capabilities > parameters of other UA's, Proxy Servers, PSTN Gateways & RTP Mixers. > > In this sense, and to answer some private concerns of others, I feel that > SLP is a better end-to-end protocol than DHCP in order to perform these > tasks. I dont like the approach, of "if all you want to do is pass on the > IP address of the first Proxy Server, then DHCP is fine". To me this > violates the notion of end-to-end capabilities exchange (and gives all the > power to a mighty-god Proxy server). > > To this end, my proposal for an SLP DTD for SIP appliances could > resembles the Call Processing Language. Maybe the XML DTD > for CPL (with some tweaks) could be used for caps exchange using SLP. > > For example, Mediatrix has a device which is very unique, i.e. a VoIP > gateway with more RTP mixing capabilties than end-points, 3 fxs ports and > one fxs/fxo port. Being able to advertise this functionality through SLP > is a very unique situation. > > Hence my warm welcome of SLP to the SIP scene. Its simply better than all > those nasty broadcast packets on LANs using DHCP. > > -=Francois=- > > On Sun, 20 Feb 2000, James Kempf wrote: > > > > > >1) if I have a residential gateway, say, which runs > > > SIP on its two POTS lines, with SLP can I find > > > the (different) first hop proxies for each port? > > > > I'm not quite sure I understand the scenerio (I'm new to SIP, sorry). > > What is looking for the first hop proxy, the residental gateway? > > My feeling is that the answer to this must be "no" because > > if the gateway is sitting on a POTS line, then the protocol on > > the POTS line must be something other than IP. Or do you mean > > having a phone in the house find the first hop proxy which would > > be the residential gateway? If that's the case, then because > > the scenerio states that there are different first hop proxies, > > there must be two residential gateways, or? If that's the case, > > then the phone could select a gateway using SLP, if the service > > advertisements for the gateways distinguished them in some way. > > > > >2) Suppose I have some IP phones at home which are > > > gateway'd through my home SIP proxy which allow > > > me to set up local dial plans. Would SLP be adequate > > > to configure the 1) phones 2) my home proxy for learning > > > their next hope proxy? > > > > > > > Let me speculate about the intent of this question (please correct > > me if I'm wrong). Is the intent of this question to see whether > > SLP can configure a home phone with a custom dial plan? If so, > > then I would say that that is probably not the right use for > > SLP. I would venture to guess that would involve some kind of > > negotiation with the telephone company's subscriber database. > > I would presume a AAA protocol would get involved somehow, to > > authenticate your phone for access to the dial plan. > > As for 1), this depends on what you want to configure the phones > > with. You can't configure them with an IP address, because you > > need an IP address to use SLP. You could configure them with > > basic stuff like outbound proxy address. Similarly for 2), you could > > have the proxy find the next hop proxy using SLP if you wanted. > > > > >I'm not trying to diss the idea, but SLP seems to > > >have been written with enterprises in mind -- > > >which is fine -- but the more complicated > > >situations will probably need to be considered > > >where we start splitting up the monolithicly > > >administered network into various administrative > > >domains, and differently administered services. > > > > > > > There is nothing specific to the enterprise in SLP's design, though > > it is not designed to be used on the Internet (large "I" here). > > SLP has some features for home-style networks, like using multicast > > in the simplest case. As Jonathan points out, it is primarily of > > value when the client has choices for a server. If you take a look > > at the SLP template draft we submitted the other day, you can get > > an idea of the kinds of attributes we are proposing for distinguishing > > servers. > > > > jak > > > > -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 21 11:00:02 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10148 for ; Mon, 21 Feb 2000 11:00:02 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 377AD52C8; Mon, 21 Feb 2000 10:57:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A1BA352D4; Mon, 21 Feb 2000 10:57:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C8E5B52C8 for ; Mon, 21 Feb 2000 10:57:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 21 10:56:46 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Mon Feb 21 10:54:24 EST 2000 Received: from dynamicsoft.com (1Cust228.tnt1.freehold.nj.da.uu.net [63.17.113.228]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA24920; Mon, 21 Feb 2000 10:56:37 -0500 (EST) Message-ID: <38B16134.824A5194@dynamicsoft.com> Date: Mon, 21 Feb 2000 11:00:52 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: rpreethy@hss.hns.com Cc: sip@lists.research.bell-labs.com Subject: Re: Accept-Contact Header References: <6525688C.0045A19B.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Thanks for pointing this out. The bnf appears to be wrong, as it mandates a valid name-addr or addr-spec. The document clearly discusses the capability of not specifying one. I will fix in the next version (due out before the draft deadline). The BNF should be: Accept-Contact = "Accept-Contact" ":" 1#rule rule = (name-addr | addr-spec | "*") .... So, we'll use the * for anything, aligning with current Contact usage. -Jonathan R. rpreethy@hss.hns.com wrote: > > hi All, > > The document SIP Caller Preferences and Callee Capabilities - > draft-ietf-sipcallerprefs-00.txt > gives the grammer for Accept-Contact Header as > > Accept-Contact = "Accept-Contact" ":" 1# rule > rule = ( name-addr | addr-spec ) > [ *( ";" (cp-params | extension-param | q-param) ) ] > q-param = "q" "=" qvalue > extension-param = extension-name "=" extension-value > extension-name = token > extension-value = token | quoted-string > > and the example given is > > Accept-Contact: sip:sales@acme.com ;q=0, > ;media="!video" ;q=0.1, > ;mobility="fixed" ;q=0.6, > ;mobility="!fixed" ;q=0.4 > > According to my understanding, in this example each of the comma separated > values is a separate Accept Contact rule, > And the parameters of a paticular accept contact rule are separated by ";" > semicolon. > Here each of the q-params are followed by a comma and then a semi-colon . > > I cannot understand whether to consider this as > 1) a single accept contact rule with all the entries following > sip:sales@acme.com as parameters in which case I dont see a need for a > comma and semi-colon as separaters between parameters. > > 2) 4 rules where-in the 2nd 3rd and 4th do not have a nameaddr|addrspec > entry which is also an error, becos the rule mandates the presence of > nameaddr|addr-spec. > > Can someone explain this to me. > > Regards, > Preethy -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 21 11:22:02 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10652 for ; Mon, 21 Feb 2000 11:22:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 5A59E52D4; Mon, 21 Feb 2000 11:19:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A97F952D6; Mon, 21 Feb 2000 11:19:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 9D50352D4 for ; Mon, 21 Feb 2000 11:19:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 21 11:17:49 EST 2000 Received: from qhars001.nortel.com ([192.100.101.18]) by dusty; Mon Feb 21 11:15:27 EST 2000 Received: from smtprch1.nortel.com (actually erchg0j) by qhars001.nortel.com; Mon, 21 Feb 2000 16:16:30 +0000 Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Mon, 21 Feb 2000 10:16:11 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 21 Feb 2000 10:16:02 -0600 Message-ID: From: "Glenn Morrow" To: "'Jonathan Rosenberg'" , Francois Menard List Account Cc: James Kempf , mat@cisco.com, sip@lists.research.bell-labs.com, etremblay@mediatrix.com Subject: RE: DHCP option tags for SIP Date: Mon, 21 Feb 2000 10:15:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7C86.F24FEF50" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk 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_01BF7C86.F24FEF50 Content-Type: text/plain; charset="ISO-8859-1" Why can't the downloaded UAS, by bootp or other means, simply have the configured proxy address? The configuration can be changed later with SIP signaling without reboot for the in-service cases. This approach requires no changes to DHCP or SIP and appears to meet the requirements. If we do go forward with these changes, what do think SG-16 will want to do in another month? - another damp blanket. > -----Original Message----- > From: Jonathan Rosenberg [SMTP:jdrosen@dynamicsoft.com] > Sent: Monday, February 21, 2000 9:36 AM > To: Francois Menard List Account > Cc: James Kempf; mat@cisco.com; sip@lists.research.bell-labs.com; > etremblay@mediatrix.com > Subject: Re: DHCP option tags for SIP > > I'd like to try and keep this discussion focused in order to quickly > answer the following question: > > Should we "fast track" a DHCP options for finding a SIP server > document? > > Neither DHCP nor SLP are capable of providing complicated application > layer configuration parameters, such as dialing plans or addresses. > Neither are good for capabilities exchange, which is something different > altogether IMHO. With DHCP, you can at least find the server to register > to, and that may provide much of this information in registration > responses. Certainly, it doesn't preclude using DHCP to point to a > specialized configuration server down the road either. > > Both DHCP and SLP will do the same thing - get you the adress of a > server. With SLP, you can be picky about which server you want, based on > its capabilities (like ability to support CPL). I see roles for both. > > -Jonathan R. > > Francois Menard List Account wrote: > > > > The question has to do with generic means for capabilities exchange > > between two devices, using a common set of semantics. > > > > I can easily see how an XML DTD for a specific industry (i.e. in some > > cases Internet Telephony for SIP), could be used to agree on > capabilities > > parameters of other UA's, Proxy Servers, PSTN Gateways & RTP Mixers. > > > > In this sense, and to answer some private concerns of others, I feel > that > > SLP is a better end-to-end protocol than DHCP in order to perform these > > tasks. I dont like the approach, of "if all you want to do is pass on > the > > IP address of the first Proxy Server, then DHCP is fine". To me this > > violates the notion of end-to-end capabilities exchange (and gives all > the > > power to a mighty-god Proxy server). > > > > To this end, my proposal for an SLP DTD for SIP appliances could > > resembles the Call Processing Language. Maybe the XML DTD > > for CPL (with some tweaks) could be used for caps exchange using SLP. > > > > For example, Mediatrix has a device which is very unique, i.e. a VoIP > > gateway with more RTP mixing capabilties than end-points, 3 fxs ports > and > > one fxs/fxo port. Being able to advertise this functionality through > SLP > > is a very unique situation. > > > > Hence my warm welcome of SLP to the SIP scene. Its simply better than > all > > those nasty broadcast packets on LANs using DHCP. > > > > -=Francois=- > > > > On Sun, 20 Feb 2000, James Kempf wrote: > > > > > > > > >1) if I have a residential gateway, say, which runs > > > > SIP on its two POTS lines, with SLP can I find > > > > the (different) first hop proxies for each port? > > > > > > I'm not quite sure I understand the scenerio (I'm new to SIP, sorry). > > > What is looking for the first hop proxy, the residental gateway? > > > My feeling is that the answer to this must be "no" because > > > if the gateway is sitting on a POTS line, then the protocol on > > > the POTS line must be something other than IP. Or do you mean > > > having a phone in the house find the first hop proxy which would > > > be the residential gateway? If that's the case, then because > > > the scenerio states that there are different first hop proxies, > > > there must be two residential gateways, or? If that's the case, > > > then the phone could select a gateway using SLP, if the service > > > advertisements for the gateways distinguished them in some way. > > > > > > >2) Suppose I have some IP phones at home which are > > > > gateway'd through my home SIP proxy which allow > > > > me to set up local dial plans. Would SLP be adequate > > > > to configure the 1) phones 2) my home proxy for learning > > > > their next hope proxy? > > > > > > > > > > Let me speculate about the intent of this question (please correct > > > me if I'm wrong). Is the intent of this question to see whether > > > SLP can configure a home phone with a custom dial plan? If so, > > > then I would say that that is probably not the right use for > > > SLP. I would venture to guess that would involve some kind of > > > negotiation with the telephone company's subscriber database. > > > I would presume a AAA protocol would get involved somehow, to > > > authenticate your phone for access to the dial plan. > > > As for 1), this depends on what you want to configure the phones > > > with. You can't configure them with an IP address, because you > > > need an IP address to use SLP. You could configure them with > > > basic stuff like outbound proxy address. Similarly for 2), you could > > > have the proxy find the next hop proxy using SLP if you wanted. > > > > > > >I'm not trying to diss the idea, but SLP seems to > > > >have been written with enterprises in mind -- > > > >which is fine -- but the more complicated > > > >situations will probably need to be considered > > > >where we start splitting up the monolithicly > > > >administered network into various administrative > > > >domains, and differently administered services. > > > > > > > > > > There is nothing specific to the enterprise in SLP's design, though > > > it is not designed to be used on the Internet (large "I" here). > > > SLP has some features for home-style networks, like using multicast > > > in the simplest case. As Jonathan points out, it is primarily of > > > value when the client has choices for a server. If you take a look > > > at the SLP template draft we submitted the other day, you can get > > > an idea of the kinds of attributes we are proposing for distinguishing > > > servers. > > > > > > jak > > > > > > > > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > ------_=_NextPart_001_01BF7C86.F24FEF50 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: DHCP option tags for SIP

Why can't the = downloaded UAS, by bootp or other means, simply have the configured = proxy address? The configuration can be changed later with SIP = signaling without reboot for the in-service cases.

This approach = requires no changes to DHCP or SIP and appears to meet the = requirements.

If we do go forward = with these changes, what do think SG-16 will want to do in another = month?

- another damp = blanket.


    -----Original Message-----
    From:   Jonathan Rosenberg = [SMTP:jdrosen@dynamicsoft.com]
    Sent:   Monday, February 21, 2000 9:36 AM
    To:     Francois Menard List Account
    Cc:     James Kempf; mat@cisco.com; = sip@lists.research.bell-labs.com; etremblay@mediatrix.com
    Subject:       = Re: DHCP option tags for SIP

    I'd like to try and keep this = discussion focused in order to quickly
    answer the following question:

      Should we "fast = track" a DHCP options for finding a SIP server
    document?

    Neither DHCP nor SLP are capable of = providing complicated application
    layer configuration parameters, such = as dialing plans or addresses.
    Neither are good for capabilities = exchange, which is something different
    altogether IMHO. With DHCP, you can = at least find the server to register
    to, and that may provide much of this = information in registration
    responses. Certainly, it doesn't = preclude using DHCP to point to a
    specialized configuration server down = the road either.

    Both DHCP and SLP will do the same = thing - get you the adress of a
    server. With SLP, you can be picky = about which server you want, based on
    its capabilities (like ability to = support CPL). I see roles for both.

    -Jonathan R.

    Francois Menard List Account = wrote:
    >
    > The question has to do with = generic means for capabilities exchange
    > between two devices, using a = common set of semantics.
    >
    > I can easily see how an XML DTD = for a specific industry (i.e. in some
    > cases Internet Telephony for = SIP), could be used to agree on capabilities
    > parameters of other UA's, Proxy = Servers, PSTN Gateways & RTP Mixers.
    >
    > In this sense, and to answer = some private concerns of others, I feel that
    > SLP is a better end-to-end = protocol than DHCP in order to perform these
    > tasks.  I dont like the = approach, of "if all you want to do is pass on the
    > IP address of the first Proxy = Server, then DHCP is fine". To me this
    > violates the notion of = end-to-end capabilities exchange (and gives all the
    > power to a mighty-god Proxy = server).
    >
    > To this end, my proposal for an = SLP DTD for SIP appliances could
    > resembles the Call Processing = Language.  Maybe the XML DTD
    > for CPL (with some tweaks) could = be used for caps exchange using SLP.
    >
    > For example, Mediatrix has a = device which is very unique, i.e. a VoIP
    > gateway with more RTP mixing = capabilties than end-points, 3 fxs ports and
    > one fxs/fxo port.  Being = able to advertise this functionality through SLP
    > is a very unique = situation.
    >
    > Hence my warm welcome of SLP to = the SIP scene.  Its simply better than all
    > those nasty broadcast packets on = LANs using DHCP.
    >
    > -=3DFrancois=3D-
    >
    > On Sun, 20 Feb 2000, James Kempf = wrote:
    >
    > >
    > > >1) if I have a = residential gateway, say, which runs
    > > >   SIP on its = two POTS lines, with SLP can I find
    > > >   the = (different) first hop proxies for each port?
    > >
    > > I'm not quite sure I = understand the scenerio (I'm new to SIP, sorry).
    > > What is looking for the = first hop proxy, the residental gateway?
    > > My feeling is that the = answer to this must be "no" because
    > > if the gateway is sitting = on a POTS line, then the protocol on
    > > the POTS line must be = something other than IP. Or do you mean
    > > having a phone in the house = find the first hop proxy which would
    > > be the residential gateway? = If that's the case, then because
    > > the scenerio states that = there are different first hop proxies,
    > > there must be two = residential gateways, or? If that's the case,
    > > then the phone could select = a gateway using SLP, if the service
    > > advertisements for the = gateways distinguished them in some way.
    > >
    > > >2) Suppose I have some = IP phones at home which are
    > > >   gateway'd = through my home SIP proxy which allow
    > > >   me to set = up local dial plans. Would SLP be adequate
    > > >   to = configure the 1) phones 2) my home proxy for learning
    > > >   their next = hope proxy?
    > > >
    > >
    > > Let me speculate about the = intent of this question (please correct
    > > me if I'm wrong). Is the = intent of this question to see whether
    > > SLP can configure a home = phone with a custom dial plan? If so,
    > > then I would say that that = is probably not the right use for
    > > SLP. I would venture to = guess that would involve some kind of
    > > negotiation with the = telephone company's subscriber database.
    > > I would presume a AAA = protocol would get involved somehow, to
    > > authenticate your phone for = access to the dial plan.
    > > As for 1), this depends on = what you want to configure the phones
    > > with. You can't configure = them with an IP address, because you
    > > need an IP address to use = SLP. You could configure them with
    > > basic stuff like outbound = proxy address. Similarly for 2), you could
    > > have the proxy find the = next hop proxy using SLP if you wanted.
    > >
    > > >I'm not trying to diss = the idea, but SLP seems to
    > > >have been written with = enterprises in mind --
    > > >which is fine -- but = the more complicated
    > > >situations will = probably need to be considered
    > > >where we start = splitting up the monolithicly
    > > >administered network = into various administrative
    > > >domains, and = differently administered services.
    > > >
    > >
    > > There is nothing specific = to the enterprise in SLP's design, though
    > > it is not designed to be = used on the Internet (large "I" here).
    > > SLP has some features for = home-style networks, like using multicast
    > > in the simplest case. As = Jonathan points out, it is primarily of
    > > value when the client has = choices for a server. If you take a look
    > > at the SLP template draft = we submitted the other day, you can get
    > > an idea of the kinds of = attributes we are proposing for distinguishing
    > > servers.
    > >
    > = >           &n= bsp;   jak
    > >
    > >

    --
    Jonathan D. = Rosenberg          &nb= sp;            = 200 Executive Drive
    Chief = Scientist          &nb= sp;           &nb= sp;      Suite 120
    dynamicsoft       &nbs= p;           &nbs= p;           &nbs= p; West Orange, NJ 07052
    jdrosen@dynamicsoft.com     &nbs= p;           &nbs= p;   FAX:   (732) 741-4778
    http://www.cs.columbia.edu/~jdrosen         PHONE: = (732) 741-7244
    http://www.dynamicsoft.com

------_=_NextPart_001_01BF7C86.F24FEF50-- From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 21 11:44:50 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11675 for ; Mon, 21 Feb 2000 11:44:47 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 6302F52DB; Mon, 21 Feb 2000 11:41:42 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8781352D5; Mon, 21 Feb 2000 11:41:36 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 406F452D5 for ; Mon, 21 Feb 2000 11:41:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 21 11:40:16 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Mon Feb 21 11:37:54 EST 2000 Received: from dynamicsoft.com (1Cust228.tnt1.freehold.nj.da.uu.net [63.17.113.228]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA25114; Mon, 21 Feb 2000 11:39:53 -0500 (EST) Message-ID: <38B16B57.28271CB2@dynamicsoft.com> Date: Mon, 21 Feb 2000 11:44:07 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Glenn Morrow Cc: Francois Menard List Account , James Kempf , mat@cisco.com, sip@lists.research.bell-labs.com, etremblay@mediatrix.com Subject: Re: DHCP option tags for SIP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit > Glenn Morrow wrote: > > Why can't the downloaded UAS, by bootp or other means, simply have the > configured proxy address? The configuration can be changed later with > SIP signaling without reboot for the in-service cases. The place I download my client from is generally unrelated to my service provider (I downloaded Netscape from Netscapes site... has nothing to do with my ISP). Even presuming you did this, how does one change this later with SIP signaling? Changing this is exactly what DHCP or SLP is desired for... > If we do go forward with these changes, what do think SG-16 will want > to do in another month? I'm not sure I understand this... is SG16 planning some kind of activity in this area (SIP configuration)? -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 21 11:47:36 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11832 for ; Mon, 21 Feb 2000 11:47:33 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 8A20252DA; Mon, 21 Feb 2000 11:41:35 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 0AED652DD; Mon, 21 Feb 2000 11:41:34 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id E245F52DA for ; Mon, 21 Feb 2000 11:41:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 21 11:39:25 EST 2000 Received: from atlrel1.hp.com ([156.153.255.210]) by dusty; Mon Feb 21 11:37:03 EST 2000 Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by atlrel1.hp.com (Postfix) with ESMTP id 95C1F1828; Mon, 21 Feb 2000 11:39:21 -0500 (EST) Received: from hplb.hpl.hp.com (fleming-r-2.hpl.hp.com [15.144.25.59]) by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id QAA28031; Mon, 21 Feb 2000 16:39:20 GMT Message-ID: <38B16A38.CE3F5187@hplb.hpl.hp.com> Date: Mon, 21 Feb 2000 16:39:20 +0000 From: Anders Byttner X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg , rpreethy@hss.hns.com Cc: IETF-SIP Subject: Re: Accept-Contact Header References: <6525688C.0045A19B.00@sampark.hss.hns.com> <38B16134.824A5194@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Just wanted to point out another error in this draft: The proposed matching algorithm is not correct. Consider for example if we have a contact entry that is language="en,ge" and the rule is language="en,nl". Certainly we want this to be a match, since both parties speak one common language. But the rule is clearly not a subset of the entry . In the draft there is an example, which is not accurate following the above algorithm: ;duplex="full,half" matches the contact entry ;duplex="full" As we see the rule set is clearly not a subset of the entry set (rather a superset) and according to the proposed algorithm there should not be a match. But we want it to be a match (as stated in the example, and in the text above). The algorithm may instead be changed to the following: - The parameter name is first checked. If it is not defined in the contact entry, the parameter is ignored. - Parameter values are treated as sets, so the intersection of the rule set and the entry set for this parameter is checked. - If the intersection is non-empty and the rule set is not negated we have a match. - If the intersection is empty and the rule set is negated we also have a match. regards //Anders Jonathan Rosenberg wrote: > > Thanks for pointing this out. The bnf appears to be wrong, as it > mandates a valid name-addr or addr-spec. The document clearly discusses > the capability of not specifying one. I will fix in the next version > (due out before the draft deadline). The BNF should be: > > Accept-Contact = "Accept-Contact" ":" 1#rule > rule = (name-addr | addr-spec | "*") > .... > > So, we'll use the * for anything, aligning with current Contact usage. > > -Jonathan R. > > rpreethy@hss.hns.com wrote: > > > > hi All, > > > > The document SIP Caller Preferences and Callee Capabilities - > > draft-ietf-sipcallerprefs-00.txt > > gives the grammer for Accept-Contact Header as > > > > Accept-Contact = "Accept-Contact" ":" 1# rule > > rule = ( name-addr | addr-spec ) > > [ *( ";" (cp-params | extension-param | q-param) ) ] > > q-param = "q" "=" qvalue > > extension-param = extension-name "=" extension-value > > extension-name = token > > extension-value = token | quoted-string > > > > and the example given is > > > > Accept-Contact: sip:sales@acme.com ;q=0, > > ;media="!video" ;q=0.1, > > ;mobility="fixed" ;q=0.6, > > ;mobility="!fixed" ;q=0.4 > > > > According to my understanding, in this example each of the comma separated > > values is a separate Accept Contact rule, > > And the parameters of a paticular accept contact rule are separated by ";" > > semicolon. > > Here each of the q-params are followed by a comma and then a semi-colon . > > > > I cannot understand whether to consider this as > > 1) a single accept contact rule with all the entries following > > sip:sales@acme.com as parameters in which case I dont see a need for a > > comma and semi-colon as separaters between parameters. > > > > 2) 4 rules where-in the 2nd 3rd and 4th do not have a nameaddr|addrspec > > entry which is also an error, becos the rule mandates the presence of > > nameaddr|addr-spec. > > > > Can someone explain this to me. > > > > Regards, > > Preethy > > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com -- -------------------------------------------------------------------------- Anders Byttner Email: Hewlett-Packard Laboratories Cellular: +44-(0)7901-805 479 Internet Communication Work: +44-(0)117-312 96 03 Filton Road, Stoke Grifford Bristol BS34 8QZ United Kingdom From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 21 12:05:58 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12476 for ; Mon, 21 Feb 2000 12:05:56 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C3F5852DC; Mon, 21 Feb 2000 12:03:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3CBAC52DD; Mon, 21 Feb 2000 12:03:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id EB53C52DC for ; Mon, 21 Feb 2000 12:03:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Feb 21 12:03:02 EST 2000 Received: from gwu.ericy.com ([208.196.3.162]) by dusty; Mon Feb 21 12:00:40 EST 2000 Received: from mr4.exu.ericsson.se (mr4u.ericy.com [208.238.116.99]) by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id KAA09151; Mon, 21 Feb 2000 10:57:09 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id KAA09504; Mon, 21 Feb 2000 10:57:08 -0600 (CST) Received: from b04a45.exu.ericsson.se (b04a45 [138.85.60.145]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA13357; Mon, 21 Feb 2000 10:57:07 -0600 (CST) From: Sean Olson Received: (from eussean@localhost) by b04a45.exu.ericsson.se (8.9.1/8.9.1) id KAA15279; Mon, 21 Feb 2000 10:57:04 -0600 (CST) Date: Mon, 21 Feb 2000 10:57:04 -0600 (CST) Message-Id: <200002211657.KAA15279@b04a45.exu.ericsson.se> To: gmorrow@nortelnetworks.com, jdrosen@dynamicsoft.com Subject: Re: DHCP option tags for SIP Cc: fm-listproc@fmmo.ca, James.Kempf@Eng.Sun.COM, mat@cisco.com, sip@lists.research.bell-labs.com, etremblay@mediatrix.com X-Sun-Charset: US-ASCII Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk > > Glenn Morrow wrote: > > > > Why can't the downloaded UAS, by bootp or other means, simply have the > > configured proxy address? The configuration can be changed later with > > SIP signaling without reboot for the in-service cases. > Hey, we could even use a multicast/broadcast SIP OPTIONS request to query local SIP servers and part of the response could be the parameters people have been discussing like first SIP proxy hop. There are a lot of possibilities here. I haven't seen a good argument against simply including the SIP proxy as a DHCP option yet. If you are allowing for BOOTP, it's a short step to go to DHCP and if you allow DHCP then why not exploit its capabilities? I see the advantage of SLP over DHCP, but its clearly overkill for a simple SIP phone especially if you need to implement DHCP anyways. my two cents sean -- Sean Olson Ericsson Inc. tel:972-583-5472 From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 21 13:03:57 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13789 for ; Mon, 21 Feb 2000 13:03:56 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 0B64652D6; Mon, 21 Feb 2000 13:01:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 740BE52DF; Mon, 21 Feb 2000 13:01:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 532FF52D6 for ; Mon, 21 Feb 2000 13:01:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 21 12:59:50 EST 2000 Received: from dnsmx2pya.telcordia.com ([128.96.20.32]) by dusty; Mon Feb 21 12:57:28 EST 2000 Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx2pya.telcordia.com (8.9.3/8.9.2) with SMTP id MAA10075; Mon, 21 Feb 2000 12:58:27 -0500 (EST) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 8525688C.0062B812 ; Mon, 21 Feb 2000 12:58:16 -0500 X-Lotus-FromDomain: TELCORDIA From: "Ashutosh Dutta" To: Sean Olson Cc: gmorrow@nortelnetworks.com, jdrosen@dynamicsoft.com, fm-listproc@fmmo.ca, James.Kempf@Eng.Sun.COM, mat@cisco.com, sip@lists.research.bell-labs.com, etremblay@mediatrix.com Message-ID: <8525688C.0062B6B7.00@notes949.cc.telcordia.com> Date: Mon, 21 Feb 2000 12:57:50 -0500 Subject: Re: DHCP option tags for SIP Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk For a wireless roaming user (e.g. moving between cells, subnets, and domains) where fast handoff is an issue during an ongoing call, DHCP option tag for finding out the nearest SIP proxy would be also very useful. Thanks Ashutosh From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 21 13:54:13 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14543 for ; Mon, 21 Feb 2000 13:54:12 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id D221552E3; Mon, 21 Feb 2000 13:51:32 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6619352E2; Mon, 21 Feb 2000 13:51:30 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id CA3D752E2 for ; Mon, 21 Feb 2000 13:51:03 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Feb 21 13:49:51 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Mon Feb 21 13:47:29 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id NAA05175; Mon, 21 Feb 2000 13:49:37 -0500 (EST) Message-ID: <38B188C0.FC3347DE@cs.columbia.edu> Date: Mon, 21 Feb 2000 13:49:36 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson Cc: sip@lists.research.bell-labs.com Subject: Re: DHCP option tags for SIP References: <200002211657.KAA15279@b04a45.exu.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Sean Olson wrote: > > > > Glenn Morrow wrote: > > > > > > Why can't the downloaded UAS, by bootp or other means, simply have the > > > configured proxy address? The configuration can be changed later with > > > SIP signaling without reboot for the in-service cases. > > > > Hey, we could even use a multicast/broadcast SIP OPTIONS request to query > local SIP servers and part of the response could be the parameters people > have been discussing like first SIP proxy hop. There are a lot of > possibilities here. I haven't seen a good argument against simply including > the SIP proxy as a DHCP option yet. If you are allowing for BOOTP, it's a > short step to go to DHCP and if you allow DHCP then why not exploit its > capabilities? I see the advantage of SLP over DHCP, but its clearly overkill > for a simple SIP phone especially if you need to implement DHCP anyways. While I agree that multicast is a nice mechanism for some autoconfig/discovery, the problem is that in many cases the outbound proxy server may not be part of the local network. I don't think, for example, that you'd want to have all 20,000 phones at Columbia send out multicast requests, with all other phones having to listen to them, particularly if they happen to reboot at roughly the same time, as after a power outage. Otherwise, we seem to be in agreement... -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 21 14:05:57 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14831 for ; Mon, 21 Feb 2000 14:05:56 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4633652DD; Mon, 21 Feb 2000 14:03:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id BB53352E0; Mon, 21 Feb 2000 14:03:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C0EC952DD for ; Mon, 21 Feb 2000 14:03:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 21 14:02:24 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Mon Feb 21 14:00:00 EST 2000 Received: from dynamicsoft.com (1Cust228.tnt1.freehold.nj.da.uu.net [63.17.113.228]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA25379; Mon, 21 Feb 2000 13:58:22 -0500 (EST) Message-ID: <38B18BCC.C9028997@dynamicsoft.com> Date: Mon, 21 Feb 2000 14:02:36 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Anders Kristensen Cc: SIP Subject: Re: Extension negotiation draft References: <38A85EA3.6DB9A152@hplb.hpl.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Anders Kristensen wrote: > > I'll go through these in turns. > > 1. Define Supported in the base spec. > > The draft can be seen as having two parts: the definition of the > Supported header and a proposal for a feature negotiation mechanism. I > think the two should be separated. It makes perfectly good sense for a > server to signal supported features in an OPTIONs response without > having to implement the negotiation mechanism, and likewise, clients > should be allowed to indicate that they support, say, reliable 1xx's > without having to implement the negotiation mechanism. I agree that Supported has uses outside of the negotiation mechanism. In fact, rfc2543bis has a definition of Supported. However, you cannot separate the header from the protocol semantics and exchanges it is used in. To date, there are two applications: 1. Returned in response to OPTIONS to indicate capabilities (this is what is described in rfc2543bis) 2. the negotiation mechanism in the draft So, I would argue that (1) is something which might well be included in the next version of the base spec - its completely backwards compatible and easy, and well in line with OPTIONS operation now. The other use, (2), is new and different. So, where does the SYNTAX itself of Supported get defined? Doesn't really matter... may very well be both. > 2. Do *not* let presence of the Supported header implicitly > signal support for the extension negotiation mechanism. > > This is a corollory of the previous argument. If UAs can list supported > features independent of the negotiation mechanism then presence of the > Supported header cannot be taken to implicitly indicate support for the > latter. Again, you can't separate the header from the protocol behavior. I would agree that adding Supported to an OPTIONS response does not imply understanding of the negotiation mechanism. However, placement of Supported in a request is strongly coupled with the negotiation mechanism, and I would be reluctant to allow it without the full thing. So, in the interests of short fields (which you argue for below), I would prefer to allow the presence of Supported alone in a request be used to indicate this. > > 3. Drop the reversed domain name feature naming convention. > > It makes messages longer and is unnecessary. > > The (primary) justifiction for the extension negotiation mechanism is > that servers need to know what features are supported by clients. It > seems to me that the simplest way to meet this requirement is for > clients to always tell servers what features they support (and BTW this > is another argument for defining Supported in the base spec). > > Now, the reason why this answer is not enough must be the potentially > large overhead of listing all these extensions all the time. Hence SIZE > MATTERS! Anything we can do to minimize the size overhead of signaling > supported features makes it more practical for us to use the simpler and > more efficient mechanism of just listing all supported features always. > The use of the short header form and the proposed implicit serverfeature > support is further testament to the need to keep messages short. There > may be times where it really isn't practical to list all supported > extensions, and for these cases we still need the negotiation. > > For this reason, and *because it's unnecessary*, I propose we drop the > convention of using reversed domain name prefixes as namespace > identifiers for extension tags. First, as I've mused on a previous > occasion, the vast majority (if not all) extensions to come into > widespread, regular use will belong to the org.ietf.sip namespace > anyway, making this prefix redundant, and secondly, I don't even think > we need these namespaces anyway. We don't have namespaces for header > names or status codes, and MIME has gotten along just fine for years > without namespaces for its media types (of which there will probably > always be many more than there will be SIP extensions). We could use the > "x-" prefix for experimental or proprietary extensions or continue to > use the domain namespaces for this purpose. OK.... I'll buy on this one. However, I'd still like the base spec to define usage of the domain-based namespaces for unregistered extensions. > > 4. Rename the negotiation extension. > > Follows from 1. and 4. Maybe just call the extension "negotiate". Rename the draft? The feature tag? > > 5. Define "all-extensions-listed" tag to be used in Supported > header. > > In order to avoid unnecessary round-trips it would be good if clients > can indicate that they have listed *all* supported extensions in the > Supported header. This can be done by defining a new token with that > meaning. I'd propose using "." since the semantics are kind of like that > of "."s use in natural written language (and tokens doesn't come much > shorter). So, for example > > Supported: negotiate, 100rel, . > > would indicate that the sender supports the 100rel and negotiate > extensions and *no* other extension. Hence there is no point for the > server to ask whether extension "foo" is supported - it isn't. This tag > can be seen as just identifying an extension of its own, and could be > defined in its own document, or it could go into the base spec. I'd > prefer the latter, since it seems like a generally very useful feature. Very good idea. I like this a lot. The period is nice too since its got that email connotation of "thats all". We must make sure implementations are prepared to not receive it last, though, since ordering is not important among feature tags. > My 2 pence worths. > I thank you for your insightful comments. I apologize for the delay in responding... I'd like to get this whole thing closed soon so we can move on to other things. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 21 14:29:52 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15129 for ; Mon, 21 Feb 2000 14:29:50 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 67E7E52E0; Mon, 21 Feb 2000 14:27:19 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D4B3652E2; Mon, 21 Feb 2000 14:27:18 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 316F752E0 for ; Mon, 21 Feb 2000 14:27:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 21 14:26:08 EST 2000 Received: from qhars001.nortel.com ([192.100.101.18]) by dusty; Mon Feb 21 14:23:43 EST 2000 Received: from smtprch1.nortel.com (actually erchg0j) by qhars001.nortel.com; Mon, 21 Feb 2000 19:23:18 +0000 Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Mon, 21 Feb 2000 13:22:51 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 21 Feb 2000 13:22:44 -0600 Message-ID: From: "Glenn Morrow" To: "'Henning Schulzrinne'" , Sean Olson Cc: sip@lists.research.bell-labs.com Subject: RE: DHCP option tags for SIP Date: Mon, 21 Feb 2000 13:22:34 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7CA1.0709CD48" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk 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_01BF7CA1.0709CD48 Content-Type: text/plain While much of the free router code and some early commercial implementations only allow for local interfaces for multicast addresses, many new commercial implementations offer more route type options for these addresses. The local route concern is not an issue for commercial implementations and there are also ways to scale in an n to n fashion using any type of address (multicast, anycast or even unicast). These methods are needed to account for maintenance and other service disruptions, as well. Thank You Glenn > -----Original Message----- > From: Henning Schulzrinne [SMTP:schulzrinne@cs.columbia.edu] > Sent: Monday, February 21, 2000 12:50 PM > To: Sean Olson > Cc: sip@lists.research.bell-labs.com > Subject: Re: DHCP option tags for SIP > > Sean Olson wrote: > > > > > > Glenn Morrow wrote: > > > > > > > > Why can't the downloaded UAS, by bootp or other means, simply have > the > > > > configured proxy address? The configuration can be changed later > with > > > > SIP signaling without reboot for the in-service cases. > > > > > > > Hey, we could even use a multicast/broadcast SIP OPTIONS request to > query > > local SIP servers and part of the response could be the parameters > people > > have been discussing like first SIP proxy hop. There are a lot of > > possibilities here. I haven't seen a good argument against simply > including > > the SIP proxy as a DHCP option yet. If you are allowing for BOOTP, it's > a > > short step to go to DHCP and if you allow DHCP then why not exploit its > > capabilities? I see the advantage of SLP over DHCP, but its clearly > overkill > > for a simple SIP phone especially if you need to implement DHCP anyways. > > While I agree that multicast is a nice mechanism for some > autoconfig/discovery, the problem is that in many cases the outbound > proxy server may not be part of the local network. I don't think, for > example, that you'd want to have all 20,000 phones at Columbia send out > multicast requests, with all other phones having to listen to them, > particularly if they happen to reboot at roughly the same time, as after > a power outage. > > Otherwise, we seem to be in agreement... > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > ------_=_NextPart_001_01BF7CA1.0709CD48 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: DHCP option tags for SIP

While much of the = free router code and some early commercial implementations only allow = for local interfaces for multicast addresses, many new commercial = implementations offer more route type options for these addresses. =

The local route = concern is not an issue for commercial implementations and there are = also ways to scale in an n to n fashion using any type of address = (multicast, anycast or even unicast).

These methods are = needed to account for maintenance and other service disruptions, as = well.


Thank You

Glenn

    -----Original Message-----
    From:   Henning Schulzrinne = [SMTP:schulzrinne@cs.columbia.edu]
    Sent:   Monday, February 21, 2000 12:50 PM
    To:     Sean Olson
    Cc:     sip@lists.research.bell-labs.com
    Subject:       = Re: DHCP option tags for SIP

    Sean Olson wrote:
    >
    > > > Glenn Morrow = wrote:
    > > >
    > > > Why can't the = downloaded UAS, by bootp or other means, simply have the
    > > > configured proxy = address? The configuration can be changed later with
    > > > SIP signaling without = reboot for the in-service cases.
    > >
    >
    > Hey, we could even use a = multicast/broadcast SIP OPTIONS request to query
    > local SIP servers and part of = the response could be the parameters people
    > have been discussing like first = SIP proxy hop. There are a lot of
    > possibilities here. I haven't = seen a good argument against simply including
    > the SIP proxy as a DHCP option = yet. If you are allowing for BOOTP, it's a
    > short step to go to DHCP and if = you allow DHCP then why not exploit its
    > capabilities? I see the = advantage of SLP over DHCP, but its clearly overkill
    > for a simple SIP phone = especially if you need to implement DHCP anyways.

    While I agree that multicast is a nice = mechanism for some
    autoconfig/discovery, the problem is = that in many cases the outbound
    proxy server may not be part of the = local network. I don't think, for
    example, that you'd want to have all = 20,000 phones at Columbia send out
    multicast requests, with all other = phones having to listen to them,
    particularly if they happen to reboot = at roughly the same time, as after
    a power outage.

    Otherwise, we seem to be in = agreement...

    --
    Henning Schulzrinne   = http://www.cs.columbia.edu/~hgs

------_=_NextPart_001_01BF7CA1.0709CD48-- From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 21 14:48:43 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15485 for ; Mon, 21 Feb 2000 14:48:43 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id E483552DF; Mon, 21 Feb 2000 14:45:37 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 17E6552E5; Mon, 21 Feb 2000 14:45:36 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 842E252DF for ; Mon, 21 Feb 2000 14:45:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 21 14:44:31 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Mon Feb 21 14:42:07 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id OAA14836; Mon, 21 Feb 2000 14:44:20 -0500 (EST) Message-ID: <38B19593.B0C7B065@cs.columbia.edu> Date: Mon, 21 Feb 2000 14:44:19 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Glenn Morrow Cc: Sean Olson , sip@lists.research.bell-labs.com Subject: Re: DHCP option tags for SIP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit > Glenn Morrow wrote: > > While much of the free router code and some early commercial > implementations only allow for local interfaces for multicast > addresses, many new commercial implementations offer more route type > options for these addresses. I'm not concerned about availability of multicast, but its scalability in the current setup. Inherently, the SIP multicast model implies that every device has to listen to all multicast packets, which just doesn't scale beyond a fairly small region. In my view, outbound proxy server often cover a larger region. > > The local route concern is not an issue for commercial implementations > and there are also ways to scale in an n to n fashion using any type > of address (multicast, anycast or even unicast). I'm afraid I lost you somewhere in this sentence. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 21 14:50:58 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15519 for ; Mon, 21 Feb 2000 14:50:58 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 9C34252E6; Mon, 21 Feb 2000 14:45:42 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id B71D352E4; Mon, 21 Feb 2000 14:45:36 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 0EB6C52E4 for ; Mon, 21 Feb 2000 14:45:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 21 14:44:56 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Mon Feb 21 14:42:31 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id OAA14603; Mon, 21 Feb 2000 14:41:19 -0500 (EST) Message-ID: <38B194DE.183CA9DF@cs.columbia.edu> Date: Mon, 21 Feb 2000 14:41:18 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Anders Kristensen , SIP Subject: Re: Extension negotiation draft References: <38A85EA3.6DB9A152@hplb.hpl.hp.com> <38B18BCC.C9028997@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > However, you cannot separate the header from the protocol semantics and > exchanges it is used in. To date, there are two applications: > > 1. Returned in response to OPTIONS to indicate capabilities (this is > what is described in rfc2543bis) I see the ability to declare capabilities in *all* requests as an alternative model that is also backwards-compatible, as long as we define it before the first capability extension is standardized. (All we would need to say is that an implementation that supports "foo" also has to support the "Supported" header, which seems trivial enough.) There are two models, it seems: - Reveal all, one round-trip: The client lists all capabilities that it wants the server to use. Asking again is not going to elicit additional capabilities. +: lot simpler, still backward compatible with existing systems +: uniform call setup delay -: longer headers (but see below) - Selective disclosure: Be coy and wait to be asked for particular features. The trade-off is pretty much the opposite as above. The draft mainly deals with the shy persons. Maybe giving SIP implementations some powdermilk biscuits might help (don't ask). In terms of efficiency, it depends on how often a second round-trip is required. If it is even 10% of the time, I would guess that declaring all capabilities ahead of time is a good move, both in terms of time and space (since you need a lot of options to compensate for the 500 bytes of repeated request, even ignoring the crucial issue of call setup delay). Given that, I'm somewhat tempted to explore a different, simpler avenue initially: assume that the client declares all beyond-RFC2543 capabilities, possibly allow short-hand feature names (as Anders is suggesting) and wait until we have a better idea as to whether we'll have 10 or 100 extensions. Clients that have 100 extensions, can offer the btw-I-know-more-than-this-please-ask-again extension in Supported (with a somewhat shorter name, like "shy"), which is the current model. If 100 turns out to be closer to the mark, it might well be that there will be agreed-upon groups of capabilities, similar to "Host Requirements" (see the TIA work), shrinking that number to a smaller number of aliases again. > 2. the negotiation mechanism in the draft > > So, I would argue that (1) is something which might well be included in > the next version of the base spec - its completely backwards compatible > and easy, and well in line with OPTIONS operation now. The other use, > (2), is new and different. So, where does the SYNTAX itself of Supported > get defined? Doesn't really matter... may very well be both. I'd rather have one place. If timing dictates this, we can have a Proposed Standard for the Supported header syntax and use (nothing else) pushed out in a matter of weeks, which would then be labeled as "obsoleted by" RFC2543bis whenever it reaches Draft. > > OK.... I'll buy on this one. However, I'd still like the base spec to > define usage of the domain-based namespaces for unregistered extensions. I would turn the "we don't do 'com.hp.header: foo' argument around and say that if you see a header that looks unfamiliar (and it's important, i.e., you can't just ignore it), it should show up in the Supported header, giving others a much smaller number of places to ask and look around for where this new unfamiliar header might be defined. Thus, header names are not so much to avoid collisions (those haven't really been a major problem in HTTP or email - these usually get discovered early and can be fixed before major damage occurs), but rather the ability to see who's responsible for a particular feature. The x- mechanism, by the way, is not very helpful. It tends to stick around forever (even if the header gets widely used), since nobody wants to change all those implementations that caused it to be widely use. Thus, my overall modified agreement with Anders: org.ietf.sip is implied (but can be spelled out?) and proprietary extensions need the reverse path. If the length penalty encourages people to write informational or standards-track RFCs to describe the feature, I wouldn't mind. > > Very good idea. I like this a lot. The period is nice too since its got > that > email connotation of "thats all". We must make sure implementations are > prepared > to not receive it last, though, since ordering is not important among > feature tags. I would argue that the "I have declared everything unless I put in some special token" as being a better option, until we have a better idea what's happening and whether we need a relatively complicated mechanism to solve what turns out to be a non-problem. At the rate that we are pushing out extensions, we're a long way of having to worry about listing them all. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 21 14:58:51 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15581 for ; Mon, 21 Feb 2000 14:58:51 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 9054552E5; Mon, 21 Feb 2000 14:55:51 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id F2E5952E4; Mon, 21 Feb 2000 14:55:49 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 375D352E5 for ; Mon, 21 Feb 2000 14:55:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 21 14:53:29 EST 2000 Received: from crash.netspeak.com ([208.143.140.6]) by dusty; Mon Feb 21 14:51:05 EST 2000 Received: by crash with Internet Mail Service (5.5.2448.0) id ; Mon, 21 Feb 2000 14:53:23 -0500 Message-ID: From: Linden deCarmo To: sip@lists.research.bell-labs.com Subject: Aurthorization & Proxy-Authorization URIs Date: Mon, 21 Feb 2000 14:53:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk The BNF for digest-uri defined by "HTTP Authentication: Basic and Digest Access Authentication" for use in Aurthorization & Proxy-Authorization headers is: digest-uri = "uri" "=" digest-uri-value digest-uri-value = request-uri ; As specified by HTTP/1.1 RFC2543, updates this definition to be: 2. The BNF for digest-uri-value is: digest-uri-value = Request-URI ; a defined in Section 4.3 Yet, all the sample call flows for the uri parameters for the Aurthorization & Proxy-Authorization headers that I've seen (i.e. SIP Telephony Service Examples With Call Flows) enclose the uri parameter in quotes (i.e. a quoted string) just like the HTTP docs: uri="sip:xxx.yyyy.com" Syntacically, I can't see how this is possible. Am I wrong? If so, could someone point out the relevant section that explains how this is possible? Thank you. Linden deCarmo Netspeak Corporation 902 Clint Moore Road Suite 104 Boca Raton, FL 33487 From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 21 15:02:13 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15692 for ; Mon, 21 Feb 2000 15:02:13 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 8F12452E7; Mon, 21 Feb 2000 14:57:40 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id D5CDA52E8; Mon, 21 Feb 2000 14:57:39 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 342CD52DC for ; Mon, 14 Feb 2000 13:27:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 14 13:25:41 EST 2000 Received: from shasta.gate.net ([216.219.246.6]) by dusty; Mon Feb 14 13:23:21 EST 2000 Received: from boca-isbu-nt04.boca.unisphere.com ([207.36.128.20]) by shasta.gate.net (AIX4.3/8.9.3/8.9.3) with ESMTP id NAA76786; Mon, 14 Feb 2000 13:25:28 -0500 Received: by boca-isbu-nt04.boca.unisphere.com with Internet Mail Service (5.5.2650.21) id <1YB3D6CP>; Mon, 14 Feb 2000 13:25:28 -0500 Message-ID: <153BDA136259D311859900A0C99B5263027750@boca-isbu-nt04.boca.unisphere.com> From: "Carr, Steve" To: "'Raja Badri'" , sip ML Subject: RE: SIP BCP-T question Date: Mon, 14 Feb 2000 13:25:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk The ISUP maintenance messages relate to the physical trunk circuit, which when not being used on a call, is still physically present and in an IDLE (or blocked) state. SIP BCT-T sets up calls over an RTP "logical" connection, which is not a physical circuit. After the end of the call, the RTP connection ceases to exist. Therefore is does not make sense to block it, unblock it, reset it etc...... Steve Carr Unisphere Solutions Inc. Boca Raton scarr@unispheresolutions.com Office (561) 955-8288 Fax (561) 955-6477 www.unispheresolutions.com -----Original Message----- From: Raja Badri [mailto:raja.badri@santera.com] Sent: Monday, February 14, 2000 1:04 PM To: sip ML Subject: SIP BCP-T question Hi, I have one question regarding the SIP BCP-T. INFO message outlines the Mid-Call ISUP messages. What is the reason behind not including the ISUP maintenance messages like Block, Unblock and Reset ? Thanks, Raja Badri Santera Systems Inc. From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 21 15:16:28 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15839 for ; Mon, 21 Feb 2000 15:16:27 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 434F552E9; Mon, 21 Feb 2000 15:09:00 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id B2D5652EB; Mon, 21 Feb 2000 15:08:59 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 248E052E7 for ; Thu, 17 Feb 2000 16:01:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 17 16:00:35 EST 2000 Received: from penguin.wise.edt.ericsson.se ([194.237.142.110]) by dusty; Thu Feb 17 15:58:12 EST 2000 Received: from super.du.uab.ericsson.se (mml@super.du.uab.ericsson.se [134.138.176.16]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id WAA13050; Thu, 17 Feb 2000 22:00:32 +0100 (MET) Received: (from mml@localhost) by super.du.uab.ericsson.se (8.10.0.Beta12/8.10.0.Beta12/erix-1.7) id e1HL0VA16591; Thu, 17 Feb 2000 22:00:32 +0100 (MET) Message-ID: <14508.24943.764505.310713@gargle.gargle.HOWL> Date: Thu, 17 Feb 2000 22:00:31 +0100 (MET) From: Matthias.Lang@ericsson.com To: Jonathan Rosenberg Cc: sip@lists.research.bell-labs.com Subject: Re: Question about media desinations In-Reply-To: <38AC4779.B4765442@dynamicsoft.com> References: <002f01bf7817$ef092c80$ad9423a6@mcit.com> <38AC4779.B4765442@dynamicsoft.com> X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid Mime-Version: 1.0 (generated by tm-edit 1.5) Content-Type: text/plain; charset=US-ASCII Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Jonathan Rosenberg writes: > Hmmm. Actually, placing the source address in the SDP solves another > problem. When multiple 200 OK (or 183 or whatever) arrive with SDP, the > caller is going to receive audio all on the same port, with no way to > figure out which RTP stream corresponds to which call leg. By adding the > source address, the UAC will be able to correlate them. The easy way to figure out which RTP stream corresponds to which SIP call is to use different destination port numbers. I don't think you can always distinguish calls based on source address, I don't think there's anything in the RTP spec which says I can't send two different RTP streams from the same port. It seems like we have a few choices: 1. Distinguish streams based on destination port #. This might make life harder for firewalls and firewall administrators; it's easiest to just open port 5004 for RTP. 2. Distinguish streams based on SSRC. This is a bad idea; you can't be sure that a client won't change SSRC from packet to packet. You also can't be sure that two clients talkign to a gateway won't choose the same SSRC, however unlikely that may be in theory. 3. Distinguish streams based on source address and port. (as above) The first option seems qutie clearly the least of three evils. Matthias From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 21 15:25:53 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15904 for ; Mon, 21 Feb 2000 15:25:53 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id EBE9652E8; Mon, 21 Feb 2000 15:23:25 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 58DEA52EA; Mon, 21 Feb 2000 15:23:24 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id CBE6C52E8 for ; Mon, 21 Feb 2000 15:23:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 21 15:22:47 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Mon Feb 21 15:20:22 EST 2000 Received: from dynamicsoft.com (1Cust228.tnt1.freehold.nj.da.uu.net [63.17.113.228]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA25634; Mon, 21 Feb 2000 15:19:06 -0500 (EST) Message-ID: <38B19EB8.68CC1B10@dynamicsoft.com> Date: Mon, 21 Feb 2000 15:23:20 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: Anders Kristensen , SIP Subject: Re: Extension negotiation draft References: <38A85EA3.6DB9A152@hplb.hpl.hp.com> <38B18BCC.C9028997@dynamicsoft.com> <38B194DE.183CA9DF@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Henning Schulzrinne wrote: > > Jonathan Rosenberg wrote: > > > > > > > However, you cannot separate the header from the protocol semantics and > > exchanges it is used in. To date, there are two applications: > > > > 1. Returned in response to OPTIONS to indicate capabilities (this is > > what is described in rfc2543bis) > > Given that, I'm somewhat tempted to explore a different, simpler avenue > initially: assume that the client declares all beyond-RFC2543 > capabilities, possibly allow short-hand feature names (as Anders is > suggesting) and wait until we have a better idea as to whether we'll > have 10 or 100 extensions. Clients that have 100 extensions, can offer > the > > btw-I-know-more-than-this-please-ask-again > > extension in Supported (with a somewhat shorter name, like "shy"), which > is the current model. That certainly would simplify things. Its all a matter of engineering goals - the negotiation mechanism is quite powerful and flexible, and will grow to handle a large extension space, whilst what you are proposing is far simpler and handles a smaller case. Which is our goal? Well, I'm inclined to agree with you that KISS probably wins over a yet-to-be-fully demonstrated need. We can wait on the more extensive negotiation stuff, so long as there is a way to add it later ("shy", as you suggest). > > So, I would argue that (1) is something which might well be included in > > the next version of the base spec - its completely backwards compatible > > and easy, and well in line with OPTIONS operation now. The other use, > > (2), is new and different. So, where does the SYNTAX itself of Supported > > get defined? Doesn't really matter... may very well be both. > > I'd rather have one place. If timing dictates this, we can have a > Proposed Standard for the Supported header syntax and use (nothing else) > pushed out in a matter of weeks, which would then be labeled as > "obsoleted by" RFC2543bis whenever it reaches Draft. Thats fine. Basically the server features draft does this now, except I don't know if we were going to fold it into draft when the time came. So, the current proposal is to write a draft that: 1. Defines the Supported header syntax 2. specifies its usage in OPTIONS responses 3. specifies its usage in requests - basically, it lists all features with short names 4. supports no negotiation This draft will be obsoleted by rfc2543bis when it goes to rfc, but no way we can wait that long for this. How do people feel about this? If we get consensus, I'll do another rev on the document and we can push it out the door. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 21 15:35:54 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16123 for ; Mon, 21 Feb 2000 15:35:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 2C62552EA; Mon, 21 Feb 2000 15:33:20 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8137C52EB; Mon, 21 Feb 2000 15:33:19 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 9C3D152EA for ; Mon, 21 Feb 2000 15:33:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Feb 21 15:33:01 EST 2000 Received: from qhars002.nortel.com ([192.100.101.19]) by dusty; Mon Feb 21 15:30:36 EST 2000 Received: from smtprich.nortel.com (actually zrchs148) by qhars002.nortel.com; Mon, 21 Feb 2000 20:32:45 +0000 Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprich.nortel.com; Mon, 21 Feb 2000 14:33:14 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2650.21) id ; Mon, 21 Feb 2000 14:32:25 -0600 Message-ID: From: "Glenn Morrow" To: "'Jonathan Rosenberg'" Cc: Francois Menard List Account , James Kempf , mat@cisco.com, sip@lists.research.bell-labs.com, etremblay@mediatrix.com Subject: RE: DHCP option tags for SIP Date: Mon, 21 Feb 2000 14:32:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7CAA.C2F0DB74" X-Orig: Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk 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_01BF7CAA.C2F0DB74 Content-Type: text/plain Below > -----Original Message----- > From: Jonathan Rosenberg [SMTP:jdrosen@dynamicsoft.com] > Sent: Monday, February 21, 2000 10:44 AM > To: Morrow, Glenn [RICH2:C301:EXCH] > Cc: Francois Menard List Account; James Kempf; mat@cisco.com; > sip@lists.research.bell-labs.com; etremblay@mediatrix.com > Subject: Re: DHCP option tags for SIP > > > > > Glenn Morrow wrote: > > > > Why can't the downloaded UAS, by bootp or other means, simply have the > > configured proxy address? The configuration can be changed later with > > SIP signaling without reboot for the in-service cases. > > The place I download my client from is generally unrelated to my service > provider (I downloaded Netscape from Netscapes site... has nothing to do > with my ISP). > TRUE but ISPs can download software too using the same method while the UAS is being used (inservice). DHCP usually get invoked at boot-up. Some ISPs use DHCP right to the customers devices, others do not. > Even presuming you did this, how does one change this later with SIP > signaling? Changing this is exactly what DHCP or SLP is desired for... Are you trying to convince people that SIP can't do this? I believe there are many methods that could be used to facilitate this. INVITE/BYE/CANCEL CONTACT header, Registration, Options, etc.. > > If we do go forward with these changes, what do think SG-16 will want > > to do in another month? > > I'm not sure I understand this... is SG16 planning some kind of activity > in this area (SIP configuration)? That would be something. What I mean is: " Perhaps one might also wish to include H.323 Gatekeeper address discovery extensions for DHCP, too". Would you support this? What would be your reasoning for not supporting this? I think you might find yourself repeating the arguments above and others of the chain. If not, you might as well go ahead and change the draft to include H.323 gatekeeper discovery as well. Don't get me wrong. I'm just trying to offer some constructive criticism. There is no hidden agenda on changing DHCP. There are simply other ways to accomplish the function desired without it. > -Jonathan R. > > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > ------_=_NextPart_001_01BF7CAA.C2F0DB74 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: DHCP option tags for SIP

Below

    -----Original Message-----
    From:   Jonathan Rosenberg = [SMTP:jdrosen@dynamicsoft.com]
    Sent:   Monday, February 21, 2000 10:44 AM
    To:     Morrow, Glenn [RICH2:C301:EXCH]
    Cc:     Francois Menard List Account; James Kempf; = mat@cisco.com; sip@lists.research.bell-labs.com; = etremblay@mediatrix.com

    Subject:       = Re: DHCP option tags for SIP



    > Glenn Morrow wrote:
    >
    > Why can't the downloaded UAS, by = bootp or other means, simply have the
    > configured proxy address? The = configuration can be changed later with
    > SIP signaling without reboot for = the in-service cases.

    The place I download my client from is = generally unrelated to my service
    provider (I downloaded Netscape from = Netscapes site... has nothing to do
    with my ISP).

    TRUE but ISPs = can download software too using the same method while the UAS is being = used (inservice). DHCP usually get invoked at boot-up. Some ISPs use = DHCP right to the customers devices, others do = not.

    Even presuming you did this, how does = one change this later with SIP
    signaling? Changing this is exactly = what DHCP or SLP is desired for...
    Are you = trying to convince people that SIP can't do this? I believe there are = many methods that could be used to facilitate this. INVITE/BYE/CANCEL = CONTACT header, Registration, Options, etc..

    > If we do go forward with these = changes, what do think SG-16 will want
    > to do in another month?

    I'm not sure I understand this... is = SG16 planning some kind of activity
    in this area (SIP = configuration)?
    That would be = something.

    What I mean = is: " Perhaps one  might also wish to include H.323 = Gatekeeper address discovery extensions for DHCP, too". =

    Would you = support this?

    What would be = your reasoning for not supporting this?

    I think you = might find yourself repeating the arguments above and others of the = chain.

    If not, you = might as well go ahead and change the draft to include H.323 gatekeeper = discovery as well.


    Don't get me = wrong. I'm just trying to offer some constructive criticism. =

    There is no = hidden agenda on changing DHCP. There are simply other ways to = accomplish the function desired without it.


    -Jonathan R.

    --
    Jonathan D. = Rosenberg          &nb= sp;            = 200 Executive Drive
    Chief = Scientist          &nb= sp;           &nb= sp;      Suite 120
    dynamicsoft       &nbs= p;           &nbs= p;           &nbs= p; West Orange, NJ 07052
    jdrosen@dynamicsoft.com     &nbs= p;           &nbs= p;   FAX:   (732) 741-4778
    http://www.cs.columbia.edu/~jdrosen         PHONE: = (732) 741-7244
    http://www.dynamicsoft.com

------_=_NextPart_001_01BF7CAA.C2F0DB74-- From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 21 15:38:45 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16161 for ; Mon, 21 Feb 2000 15:38:44 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 0944352EB; Mon, 21 Feb 2000 15:35:50 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 81E2552EC; Mon, 21 Feb 2000 15:35:48 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 623F852EB for ; Mon, 21 Feb 2000 15:35:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Feb 21 15:33:56 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Mon Feb 21 15:31:27 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id PAA18733; Mon, 21 Feb 2000 15:30:13 -0500 (EST) Message-ID: <38B1A054.73DF31AE@cs.columbia.edu> Date: Mon, 21 Feb 2000 15:30:12 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Anders Kristensen , SIP Subject: Re: Extension negotiation draft References: <38A85EA3.6DB9A152@hplb.hpl.hp.com> <38B18BCC.C9028997@dynamicsoft.com> <38B194DE.183CA9DF@cs.columbia.edu> <38B19EB8.68CC1B10@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > That certainly would simplify things. Its all a matter of engineering > goals - the negotiation mechanism is quite powerful and flexible, and > will grow to handle a large extension space, whilst what you are > proposing is far simpler and handles a smaller case. Which is our goal? > Well, I'm inclined to agree with you that KISS probably wins over a > yet-to-be-fully demonstrated need. We can wait on the more extensive > negotiation stuff, so long as there is a way to add it later ("shy", as > you suggest). I'd rather get the KISS draft out in a week and then worry about it again when/if the need arises. At that time, we'll also have a better idea, for example, if we need parameterized extensions, as has been mentioned somewhere along the way. > So, the current proposal is to write a draft that: > > 1. Defines the Supported header syntax > 2. specifies its usage in OPTIONS responses > 3. specifies its usage in requests - basically, it lists all features > with short names > 4. supports no negotiation > > This draft will be obsoleted by rfc2543bis when it goes to rfc, but no > way we can wait that long for this. Agreed. I've already included the changes in today's version of rfc2543bis. It might be useful to have the wording in the draft and rfc2543bis agree, to simplify the merging later. (Obviously, rfc2543bis spreads things around a bit more, e.g., the redefinition of the option-tag and the table indicating allowable use.) -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 21 15:57:48 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16423 for ; Mon, 21 Feb 2000 15:57:47 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 0CD0B52E2; Mon, 21 Feb 2000 15:55:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 7469952EC; Mon, 21 Feb 2000 15:55:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 92E4452E2 for ; Mon, 21 Feb 2000 15:55:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Feb 21 15:53:26 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Mon Feb 21 15:51:01 EST 2000 Received: from dynamicsoft.com (1Cust228.tnt1.freehold.nj.da.uu.net [63.17.113.228]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA25712; Mon, 21 Feb 2000 15:52:35 -0500 (EST) Message-ID: <38B1A690.1C6AEFB3@dynamicsoft.com> Date: Mon, 21 Feb 2000 15:56:48 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Glenn Morrow Cc: Francois Menard List Account , James Kempf , mat@cisco.com, sip@lists.research.bell-labs.com, etremblay@mediatrix.com Subject: Re: DHCP option tags for SIP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit > Glenn Morrow wrote: > \ > The place I download my client from is generally unrelated to my > service > provider (I downloaded Netscape from Netscapes site... has > nothing to do > with my ISP). > > TRUE but ISPs can download software too using the same method > while the UAS is being used (inservice). DHCP usually get invoked > at boot-up. Some ISPs use DHCP right to the customers devices, > others do not. I don't follow what you are trying to say here. > > Even presuming you did this, how does one change this later with > SIP > signaling? Changing this is exactly what DHCP or SLP is desired > for... > Are you trying to convince people that SIP can't do this? I > believe there are many methods that could be used to facilitate > this. INVITE/BYE/CANCEL CONTACT header, Registration, Options, > etc.. All of these things assume you have a server to talk to in the first place. Thats the problem we are trying to solve. > > > If we do go forward with these changes, what do think SG-16 > will want > > to do in another month? > What I mean is: " Perhaps one might also wish to include H.323 > Gatekeeper address discovery extensions for DHCP, too". > > Would you support this? Its not for me to support or not support. The SIP wg doesn't work on H.323, ITU SG16 does. If they want to register DHCP options for gatekeepers, fine with me. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 21 23:58:04 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23823 for ; Mon, 21 Feb 2000 23:58:03 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id D159752DE; Mon, 21 Feb 2000 23:55:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 483F052E1; Mon, 21 Feb 2000 23:55:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 4AF0F52DE for ; Mon, 21 Feb 2000 23:55:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 21 23:54:02 EST 2000 Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Mon Feb 21 23:51:30 EST 2000 Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id KAA09379; Tue, 22 Feb 2000 10:50:46 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 6525688D.001AC10A ; Tue, 22 Feb 2000 10:22:13 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Jonathan Rosenberg Cc: rpreethy@hss.hns.com, sip@lists.research.bell-labs.com Message-ID: <6525688D.001A2A69.00@sampark.hss.hns.com> Date: Tue, 22 Feb 2000 10:15:47 +0530 Subject: Re: Accept-Contact Header Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Hi, So if my interpretation is correct, what you are saying is put a "*" when you dont want to specify a uri, else put a uri. So in each Accept-Contact hdr, either a "*" or (name-addr |addr-spec) is mandatory. Is the example in Page 13 also correct then ? Accept-Contact: sip:sales@acme.com ;q=0, ;media="!video" ;q=0.1, ;mobility="fixed" ;q=0.6, ;mobility="!fixed" ;q=0.4 Im still confused with the use of commas - if they are indeed sep. Acc-Contact hdrs, shouldnt the example be Accept-Contact: sip:sales@acme.com ;q=0, * ;media="!video" ;q=0.1, *;mobility="fixed" ;q=0.6, *;mobility="!fixed" ;q=0.4 And I guess the same holds for reject contact too ? i.e. Reject-Contact = "Reject-Contact" ":" 1# ( ( name-addr | addr-spec | "*" ) [ *( ";" new-params ) ] ) Regds Arjun Arjun Roychowdhyry @ Hughes Software Systems Jonathan Rosenberg on 02/21/2000 09:30:52 PM To: Preethy Rangarajan/HSSBLR cc: sip@lists.research.bell-labs.com Subject: Re: Accept-Contact Header Thanks for pointing this out. The bnf appears to be wrong, as it mandates a valid name-addr or addr-spec. The document clearly discusses the capability of not specifying one. I will fix in the next version (due out before the draft deadline). The BNF should be: Accept-Contact = "Accept-Contact" ":" 1#rule rule = (name-addr | addr-spec | "*") .... So, we'll use the * for anything, aligning with current Contact usage. -Jonathan R. rpreethy@hss.hns.com wrote: > > hi All, > > The document SIP Caller Preferences and Callee Capabilities - > draft-ietf-sipcallerprefs-00.txt > gives the grammer for Accept-Contact Header as > > Accept-Contact = "Accept-Contact" ":" 1# rule > rule = ( name-addr | addr-spec ) > [ *( ";" (cp-params | extension-param | q-param) ) ] > q-param = "q" "=" qvalue > extension-param = extension-name "=" extension-value > extension-name = token > extension-value = token | quoted-string > > and the example given is > > Accept-Contact: sip:sales@acme.com ;q=0, > ;media="!video" ;q=0.1, > ;mobility="fixed" ;q=0.6, > ;mobility="!fixed" ;q=0.4 > > According to my understanding, in this example each of the comma separated > values is a separate Accept Contact rule, > And the parameters of a paticular accept contact rule are separated by ";" > semicolon. > Here each of the q-params are followed by a comma and then a semi-colon . > > I cannot understand whether to consider this as > 1) a single accept contact rule with all the entries following > sip:sales@acme.com as parameters in which case I dont see a need for a > comma and semi-colon as separaters between parameters. > > 2) 4 rules where-in the 2nd 3rd and 4th do not have a nameaddr|addrspec > entry which is also an error, becos the rule mandates the presence of > nameaddr|addr-spec. > > Can someone explain this to me. > > Regards, > Preethy -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 22 01:29:51 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26177 for ; Tue, 22 Feb 2000 01:29:50 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 8413652B6; Tue, 22 Feb 2000 01:27:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id DD1AF52C4; Tue, 22 Feb 2000 01:27:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id DD0FF52B6 for ; Tue, 22 Feb 2000 01:27:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Feb 22 01:26:21 EST 2000 Received: from ns.fmmo.ca ([207.253.160.156]) by dusty; Tue Feb 22 01:23:57 EST 2000 Received: from localhost (fm-listproc@localhost) by ns.fmmo.ca (8.9.3/8.9.3) with ESMTP id BAA01399; Tue, 22 Feb 2000 01:41:16 -0500 Date: Tue, 22 Feb 2000 01:41:15 -0500 (EST) From: Francois Menard List Account To: Jonathan Rosenberg Cc: James Kempf , mat@cisco.com, sip@lists.research.bell-labs.com, etremblay@mediatrix.com Subject: Re: DHCP option tags for SIP In-Reply-To: <38B15B68.B350009A@dynamicsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk I also think that it ought to be possible to do it with DHCP. I agree with Jonathan here. -=Francois=- On Mon, 21 Feb 2000, Jonathan Rosenberg wrote: > I'd like to try and keep this discussion focused in order to quickly > answer the following question: > > Should we "fast track" a DHCP options for finding a SIP server > document? > > Neither DHCP nor SLP are capable of providing complicated application > layer configuration parameters, such as dialing plans or addresses. > Neither are good for capabilities exchange, which is something different James, do you have a rebuttal for this ? -=Francois=- From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 22 06:46:05 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08755 for ; Tue, 22 Feb 2000 06:46:04 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 24D5652C4; Tue, 22 Feb 2000 06:43:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8C65152ED; Tue, 22 Feb 2000 06:43:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 5E94252C4 for ; Tue, 22 Feb 2000 06:43:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 22 06:42:00 EST 2000 Received: from palrel3.hp.com ([156.153.255.226]) by dusty; Tue Feb 22 06:39:36 EST 2000 Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by palrel3.hp.com (Postfix) with ESMTP id 17BB4841; Tue, 22 Feb 2000 03:41:53 -0800 (PST) Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238]) by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id LAA03861; Tue, 22 Feb 2000 11:41:52 GMT Message-ID: <38B27608.8F23789B@hplb.hpl.hp.com> Date: Tue, 22 Feb 2000 11:42:00 +0000 From: Anders Kristensen Organization: HP Labs X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Henning Schulzrinne , SIP Subject: Re: Extension negotiation draft References: <38A85EA3.6DB9A152@hplb.hpl.hp.com> <38B18BCC.C9028997@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Cool beans. I think we're all in agreement now. Comments below anyway. Jonathan Rosenberg wrote: > > Anders Kristensen wrote: > > > > I'll go through these in turns. > > > > 1. Define Supported in the base spec. > > > > The draft can be seen as having two parts: the definition of the > > Supported header and a proposal for a feature negotiation mechanism. I > > think the two should be separated. It makes perfectly good sense for a > > server to signal supported features in an OPTIONs response without > > having to implement the negotiation mechanism, and likewise, clients > > should be allowed to indicate that they support, say, reliable 1xx's > > without having to implement the negotiation mechanism. > > I agree that Supported has uses outside of the negotiation mechanism. In > fact, > rfc2543bis has a definition of Supported. > > However, you cannot separate the header from the protocol semantics and > exchanges it is used in. To date, there are two applications: > > 1. Returned in response to OPTIONS to indicate capabilities (this is > what is described in rfc2543bis) > 2. the negotiation mechanism in the draft There is a third which is the one I'm concerned about here, which is to allow clients to tell the server which features it supports without having to implement the negotiation mechanism. Like Henning, I believe that many clients can get away with not implementing the negotiation mechanism simply by listing all known features. > > So, I would argue that (1) is something which might well be included in > the next version of the base spec - its completely backwards compatible > and easy, and well in line with OPTIONS operation now. The other use, > (2), is new and different. So, where does the SYNTAX itself of Supported > get defined? Doesn't really matter... may very well be both. > > > 2. Do *not* let presence of the Supported header implicitly > > signal support for the extension negotiation mechanism. > > > > This is a corollory of the previous argument. If UAs can list supported > > features independent of the negotiation mechanism then presence of the > > Supported header cannot be taken to implicitly indicate support for the > > latter. > > Again, you can't separate the header from the protocol behavior. I would > agree that adding Supported to an OPTIONS response does not imply > understanding of the negotiation mechanism. However, placement of > Supported in a request is strongly coupled with the negotiation > mechanism, and I would be reluctant to allow it without the full thing. Well, this is really what I argued against. A great part of the value of letting clients list features known to them is that it becomes a mechanism for not having to implement the negotiation. I think this advantage weighs much more heavily than saving listing the extra tag when negotiation *is* supported. If I understand your 4-step plan correctly this is what it is saying also with the "shy" tag. Basically the Supported header can be used in requests without it signaling support for negotiation, which is instead signalled explicitly with the inclusion of the "shy" tag. > So, in the interests of short fields (which you argue for below), I > would prefer to allow the presence of Supported alone in a request be > used to indicate this. > > > > > 3. Drop the reversed domain name feature naming convention. > > > > It makes messages longer and is unnecessary. > > > > [...] > > "x-" prefix for experimental or proprietary extensions or continue to > > use the domain namespaces for this purpose. > > OK.... I'll buy on this one. However, I'd still like the base spec to > define usage of the domain-based namespaces for unregistered extensions. Agreed. I must say I really don't like the idea of making it optional whether or not to include the "org.ietf.sip" prefix. It complicates matters for no extra gain. -- Anders Kristensen , http://www-uk.hpl.hp.com/people/ak/ Hewlett-Packard Labs, Bristol, UK From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 22 07:57:56 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09511 for ; Tue, 22 Feb 2000 07:57:55 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id D980A52EC; Tue, 22 Feb 2000 07:55:20 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 586CA52EE; Tue, 22 Feb 2000 07:55:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 8D75652EC for ; Tue, 22 Feb 2000 07:55:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 22 07:53:38 EST 2000 Received: from mail.huawei.com.cn ([202.96.135.132]) by dusty; Tue Feb 22 07:51:14 EST 2000 Received: from y13638 ([10.108.22.162]) by mail.huawei.com.cn (Netscape Mail Server v2.02) with SMTP id AAA28148 for ; Tue, 22 Feb 2000 20:53:36 +0800 Message-ID: <00df01bf7d33$92cee560$a2166c0a@y13638.huawei.com.cn> Reply-To: "yinshaohua" From: "yinshaohua" To: Subject: About Timer Date: Tue, 22 Feb 2000 20:51:42 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi: When reading RFC 2543, I have a question regarding path of ACK and BYE. In section 4.2.4, there writes "If the INVITE request contained a contact header, the callee should send a BYE request to that address rather than the from address ". And in section 10.5.1, there has " If the response contained a Contact header field, the ACK may be sent to the address listed in that Contact header field." So I can draw a following call flow chart : user A Proxy User B INVITE -----------> INVITE ---------> 200 <--------- 200 <---------- ACK -----------------------------> The call is established BYE <---------------------------- In the example ,when do I release the call resource in the Proxy Server ? Thanks ! Shaohua Yin From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 22 09:24:11 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10987 for ; Tue, 22 Feb 2000 09:24:08 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id ECA1352E1; Tue, 22 Feb 2000 09:21:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 59ECF52EF; Tue, 22 Feb 2000 09:21:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 5CDAA52E1 for ; Tue, 22 Feb 2000 09:21:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 22 09:20:56 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Tue Feb 22 09:18:32 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA26462; Tue, 22 Feb 2000 09:20:11 -0500 (EST) Message-ID: <38B29C1F.B05FFCEF@dynamicsoft.com> Date: Tue, 22 Feb 2000 09:24:31 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: yinshaohua Cc: sip@lists.research.bell-labs.com Subject: Re: About Timer References: <00df01bf7d33$92cee560$a2166c0a@y13638.huawei.com.cn> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit yinshaohua wrote: > > Hi: > > When reading RFC 2543, I have a question regarding path of ACK and BYE. > In section 4.2.4, there writes "If the INVITE request contained a > contact header, the callee should send a BYE request to that address rather > than the from address ". > And in section 10.5.1, there has " If the response contained a Contact > header field, the ACK may be sent to the address listed in that Contact > header field." So I can draw a following call flow chart : > > user A Proxy User B > INVITE > -----------> INVITE > ---------> > 200 > <--------- > 200 > <---------- > ACK > -----------------------------> > The call is established > BYE > <---------------------------- Correct. > In the example ,when do I release the call resource in the Proxy Server ? > Thanks ! What call resource? If the proxy doesn't record-route, it can't maintain call state, and thus there is no call resource to release. The proxy will probably maintain transaction state in this case (what we call stateful). That state is released after some short period of time after the 200 OK has been forwarded; 32 seconds is reasonable based on the timers defined in the spec. In the case of a stateless proxy, there is no state at all to maintain or release. If the proxy record-routes, it will see the ACK and the BYE. If its maintaining call state, it can release that state upon the BYE. Also, the usage of the session timer (http://www.ietf.org/internet-drafts/draft-ietf-sip-session-timer-00.txt) is recommended in case the BYE never gets sent or is lost. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 22 10:02:02 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11673 for ; Tue, 22 Feb 2000 10:02:02 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 39B7C52EE; Tue, 22 Feb 2000 09:59:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9C39E52F0; Tue, 22 Feb 2000 09:59:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id D551452EE for ; Tue, 22 Feb 2000 09:59:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 22 09:58:31 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Tue Feb 22 09:56:06 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA26552; Tue, 22 Feb 2000 09:58:39 -0500 (EST) Message-ID: <38B2A523.9103EBE7@dynamicsoft.com> Date: Tue, 22 Feb 2000 10:02:59 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: archow@hss.hns.com Cc: rpreethy@hss.hns.com, sip@lists.research.bell-labs.com Subject: Re: Accept-Contact Header References: <6525688D.001A2A69.00@sampark.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit archow@hss.hns.com wrote: > > Hi, > So if my interpretation is correct, what you are saying is put a "*" when > you dont want to specify a uri, else put a uri. > So in each Accept-Contact hdr, either a "*" or (name-addr |addr-spec) is > mandatory. > > Is the example in Page 13 also correct then ? No; there must be a star there. > > Accept-Contact: sip:sales@acme.com ;q=0, > ;media="!video" ;q=0.1, > ;mobility="fixed" ;q=0.6, > ;mobility="!fixed" ;q=0.4 > > Im still confused with the use of commas - if they are indeed sep. > Acc-Contact hdrs, shouldnt the example be > > Accept-Contact: sip:sales@acme.com ;q=0, > * ;media="!video" ;q=0.1, > *;mobility="fixed" ;q=0.6, > *;mobility="!fixed" ;q=0.4 Yes. This is correct. > > And I guess the same holds for reject contact too ? > > i.e. > > Reject-Contact = "Reject-Contact" ":" 1# ( ( name-addr | addr-spec | > "*" ) [ *( ";" new-params ) ] ) Yes. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 22 11:14:08 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13864 for ; Tue, 22 Feb 2000 11:14:04 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id BC81252DA; Tue, 22 Feb 2000 11:11:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 2FE4A52DB; Tue, 22 Feb 2000 11:11:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 36A9252DA for ; Tue, 22 Feb 2000 11:11:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Feb 22 11:11:02 EST 2000 Received: from gwu.ericy.com ([208.196.3.162]) by dusty; Tue Feb 22 11:08:37 EST 2000 Received: from mr4.exu.ericsson.se (mr4u.ericy.com [208.238.116.99]) by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id KAA17841; Tue, 22 Feb 2000 10:10:55 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id KAA06219; Tue, 22 Feb 2000 10:10:54 -0600 (CST) Received: from b04a24.exu.ericsson.se (b04a24 [138.85.60.124]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA05132; Tue, 22 Feb 2000 10:10:54 -0600 (CST) Received: (from exuadam@localhost) by b04a24.exu.ericsson.se (8.9.1/8.9.1) id KAA02284; Tue, 22 Feb 2000 10:10:52 -0600 (CST) Message-Id: <200002221610.KAA02284@b04a24.exu.ericsson.se> Subject: Cross-domain QoS setup To: jdrosen@dynamicsoft.com, hgs@cs.columbia.edu, Steven.R.Donovan@wcom.com Date: Tue, 22 Feb 2000 10:10:52 -0600 (CST) Cc: sip@lists.research.bell-labs.com From: "Adam B. Roach" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Since draft-ietf-mmusic-sdp-qos-00.txt expired in December, and is functionality we still need to standardize, it will (presumably) be reissued soon. Speaking on behalf of the PacketCable group, we have some suggestions of enhancements to the upcoming release of this document which would allow it to support a more robust network architecture. The current draft makes an assumption that end-to-end network resource reservation is controlled by a single entity. For calls being placed across adminstrative domains, however, this will not be the case. Under such circumstances, the reservation of resources needs a greater degree of coordination than is currently provided in the draft. In particular, the calling user agent needs the ability to communicate to the called user agent that it has reserved the necessary resources on its end, and that alerting may begin as soon as the called user agent has done the same. Our proposed method of doing so is as follows: 1) As in the current draft, the INVITE message contains a=qos:... lines to indicate the calling party's preferences for which streams have mandatory or optional reservation couplings associated with them. 2) Similary, the 18x response contains a subset of the INVITE preconditions. 3) The PRACK confirming the 18x will echo back the finally agreed-on preconditions. This will serve as a "go ahead" message to the called party to begin its actual resource reservation. 4) After the calling side has procured reservations for the required resources, it sends an INFO message to the called party. This INFO message contains an SDP with a confirmation that the required streams have been reserved. For the purposes of this message, we add two values to the "strength" field in the current draft: "reserved" and "resvfail". The presence of the "resvfail" token allows the called party to terminate the call with an error code (for mandatory streams) or to remove its local reservation (for optional streams). 5) The 200 response to the INFO message similarly contains SDP indicating, on a per-stream basis, the status of its local reservations (allowing the calling party to remove reservations for optional streams which were not reserved on the terminating side). An example callflow follows (with unnecessary but present details, like tags and call-ids, removed). To prevent abiguity, I have inserted a "Session" header for all cases where SDP is present in a way that is not defined in the base specification and cannot be determined from context (e.g. the response to a QoS INFO message). -------------------- UAC->UAS INVITE sip:adam.roach@ericsson.com SIP/2.0 To: Adam Roach From: John Q. Public CSeq: 1 INVITE Content-Type: application/sdp v=0 m=audio 48327 RTP/AVP 0 a=qos:mandatory sendrecv m=video 10275 RTP/AVP 31 a=qos:mandatory sendrecv -------------------- UAS->UAC SIP/2.0 183 Preconditions To: Adam Roach From: John Q. Public CSeq: 1 INVITE Session: QoS Content-Type: application/sdp v=0 m=audio 48327 RTP/AVP 0 a=qos:mandatory sendrecv m=video 10275 RTP/AVP 31 a=qos:optional sendrecv -------------------- UAC->UAS PRACK sip:adam.roach@ericsson.com SIP/2.0 To: Adam Roach From: John Q. Public CSeq: 2 PRACK Session: QoS Content-Type: application/sdp v=0 m=audio 48327 RTP/AVP 0 a=qos:mandatory sendrecv m=video 10275 RTP/AVP 31 a=qos:optional sendrecv -------------------- UAS->UAC SIP/2.0 200 OK To: Adam Roach From: John Q. Public CSeq: 2 PRACK Content-Length: 0 -------------------- Both parties perform resource reservation -------------------- UAC->UAS INFO sip:adam.roach@ericsson.com SIP/2.0 To: Adam Roach From: John Q. Public CSeq: 3 INFO Session: QoS Content-Type: application/sdp v=0 m=audio 48327 RTP/AVP 0 a=qos:reserved sendrecv m=video 10275 RTP/AVP 31 a=qos:resvfail sendrecv -------------------- UAS->UAC SIP/2.0 200 OK To: Adam Roach From: John Q. Public CSeq: 3 INFO Content-Type: application/sdp v=0 m=audio 48327 RTP/AVP 0 a=qos:reserved sendrecv m=video 10275 RTP/AVP 31 a=qos:resvfail sendrecv -------------------- The called party cancels the videostream reservation and begins alerting the called party. -------------------- UAS->UAC SIP/2.0 180 Ringing To: Adam Roach From: John Q. Public CSeq: 1 INVITE Content-Length: 0 -------------------- -- Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 22 12:00:01 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15171 for ; Tue, 22 Feb 2000 11:59:56 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id D962952AB; Tue, 22 Feb 2000 11:57:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 5526952B6; Tue, 22 Feb 2000 11:57:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 3CC5552AB for ; Tue, 22 Feb 2000 11:57:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Feb 22 11:56:37 EST 2000 Received: from tapti.hss.hns.com ([139.85.242.19]) by dusty; Tue Feb 22 11:54:12 EST 2000 Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.22]) by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id WAA11205; Tue, 22 Feb 2000 22:53:50 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 6525688D.005D34F5 ; Tue, 22 Feb 2000 22:28:04 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: "yinshaohua" Cc: sip@lists.research.bell-labs.com Message-ID: <6525688D.005D32FD.00@sampark.hss.hns.com> Date: Tue, 22 Feb 2000 22:27:58 +0530 Subject: Re: About Timer Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Hi, if you are talking about a stateful proxy, then it must have inserted Record-Route header. If it did, ACK and BYE will pass through it. Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems "yinshaohua" on 02/22/2000 06:21:42 PM Please respond to "yinshaohua" To: sip@lists.research.bell-labs.com cc: Subject: About Timer Hi: When reading RFC 2543, I have a question regarding path of ACK and BYE. In section 4.2.4, there writes "If the INVITE request contained a contact header, the callee should send a BYE request to that address rather than the from address ". And in section 10.5.1, there has " If the response contained a Contact header field, the ACK may be sent to the address listed in that Contact header field." So I can draw a following call flow chart : user A Proxy User B INVITE -----------> INVITE ---------> 200 <--------- 200 <---------- ACK -----------------------------> The call is established BYE <---------------------------- In the example ,when do I release the call resource in the Proxy Server ? Thanks ! Shaohua Yin From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 22 14:16:13 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19402 for ; Tue, 22 Feb 2000 14:16:04 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 2713852B6; Tue, 22 Feb 2000 14:13:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 841A852C8; Tue, 22 Feb 2000 14:13:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 45C1752B6 for ; Tue, 22 Feb 2000 14:13:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Feb 22 14:11:48 EST 2000 Received: from diablo.cisco.com ([171.68.224.210]) by dusty; Tue Feb 22 14:09:23 EST 2000 Received: from jmpolk-8k (sj-dial-4-41.cisco.com [171.68.181.170]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id LAA19028; Tue, 22 Feb 2000 11:10:50 -0800 (PST) Message-Id: <4.1.20000222130104.00c8e380@diablo.cisco.com> X-Sender: jmpolk@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Tue, 22 Feb 2000 13:09:36 -0600 To: "Adam B. Roach" , jdrosen@dynamicsoft.com, hgs@cs.columbia.edu, Steven.R.Donovan@wcom.com From: "James M. Polk" Subject: Re: Cross-domain QoS setup Cc: sip@lists.research.bell-labs.com, rohan@cisco.com In-Reply-To: <200002221610.KAA02284@b04a24.exu.ericsson.se> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_2567198==_.ALT" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --=====================_2567198==_.ALT Content-Type: text/plain; charset="us-ascii" Adam I think I see a flaw in this suggestion, but I'm not sure: What happens if you have, for example, Level 3's pure IP network between the Calling agent's Domain and the Called agents Domain? Expanding on this, say I'm within my domain calling from my SIP IP Phone, Cisco.com, who has a direct IP connection into Level 3's IP Backbone (I don't think we do -- but work within me here), but you are on a Cable Modem in the AT&T Broadband Network in Dallas with VoIP enabled to your home; your example seems to only allow for interaction between the calling and called domains, does it matter than there will likely (more so in the future than now) be a additional IP domain in the middle that could very well muck things up quite a bit? Further, if it does matter, what indication will both sides get if this middle domain is the only one not to comply with the requested QoS settings? At 10:10 AM 2/22/2000 -0600, Adam B. Roach wrote: >Since draft-ietf-mmusic-sdp-qos-00.txt expired in December, and is >functionality we still need to standardize, it will (presumably) be >reissued soon. Speaking on behalf of the PacketCable group, we have >some suggestions of enhancements to the upcoming release of this >document which would allow it to support a more robust network >architecture. > >The current draft makes an assumption that end-to-end network >resource reservation is controlled by a single entity. For calls >being placed across adminstrative domains, however, this will >not be the case. Under such circumstances, the reservation of >resources needs a greater degree of coordination than is >currently provided in the draft. > >In particular, the calling user agent needs the ability to >communicate to the called user agent that it has reserved >the necessary resources on its end, and that alerting may >begin as soon as the called user agent has done the same. > >Our proposed method of doing so is as follows: > >1) As in the current draft, the INVITE message contains > a=qos:... lines to indicate the calling party's preferences > for which streams have mandatory or optional reservation > couplings associated with them. > >2) Similary, the 18x response contains a subset of the INVITE > preconditions. > >3) The PRACK confirming the 18x will echo back the finally > agreed-on preconditions. This will serve as a "go ahead" > message to the called party to begin its actual resource > reservation. > >4) After the calling side has procured reservations for the > required resources, it sends an INFO message to the called > party. This INFO message contains an SDP with a confirmation > that the required streams have been reserved. For the purposes > of this message, we add two values to the "strength" field > in the current draft: "reserved" and "resvfail". The presence > of the "resvfail" token allows the called party to terminate > the call with an error code (for mandatory streams) or to > remove its local reservation (for optional streams). > >5) The 200 response to the INFO message similarly contains > SDP indicating, on a per-stream basis, the status of > its local reservations (allowing the calling party to > remove reservations for optional streams which were not > reserved on the terminating side). > >An example callflow follows (with unnecessary but present details, >like tags and call-ids, removed). To prevent abiguity, I have inserted >a "Session" header for all cases where SDP is present in a way that is >not defined in the base specification and cannot be determined from >context (e.g. the response to a QoS INFO message). > >-------------------- >UAC->UAS > >INVITE sip:adam.roach@ericsson.com SIP/2.0 >To: Adam Roach >From: John Q. Public >CSeq: 1 INVITE >Content-Type: application/sdp > >v=0 >m=audio 48327 RTP/AVP 0 >a=qos:mandatory sendrecv >m=video 10275 RTP/AVP 31 >a=qos:mandatory sendrecv >-------------------- >UAS->UAC > >SIP/2.0 183 Preconditions >To: Adam Roach >From: John Q. Public >CSeq: 1 INVITE >Session: QoS >Content-Type: application/sdp > >v=0 >m=audio 48327 RTP/AVP 0 >a=qos:mandatory sendrecv >m=video 10275 RTP/AVP 31 >a=qos:optional sendrecv >-------------------- >UAC->UAS > >PRACK sip:adam.roach@ericsson.com SIP/2.0 >To: Adam Roach >From: John Q. Public >CSeq: 2 PRACK >Session: QoS >Content-Type: application/sdp > >v=0 >m=audio 48327 RTP/AVP 0 >a=qos:mandatory sendrecv >m=video 10275 RTP/AVP 31 >a=qos:optional sendrecv >-------------------- >UAS->UAC > >SIP/2.0 200 OK >To: Adam Roach >From: John Q. Public >CSeq: 2 PRACK >Content-Length: 0 >-------------------- >Both parties perform resource reservation >-------------------- >UAC->UAS > >INFO sip:adam.roach@ericsson.com SIP/2.0 >To: Adam Roach >From: John Q. Public >CSeq: 3 INFO >Session: QoS >Content-Type: application/sdp > >v=0 >m=audio 48327 RTP/AVP 0 >a=qos:reserved sendrecv >m=video 10275 RTP/AVP 31 >a=qos:resvfail sendrecv >-------------------- >UAS->UAC > >SIP/2.0 200 OK >To: Adam Roach >From: John Q. Public >CSeq: 3 INFO >Content-Type: application/sdp > >v=0 >m=audio 48327 RTP/AVP 0 >a=qos:reserved sendrecv >m=video 10275 RTP/AVP 31 >a=qos:resvfail sendrecv >-------------------- >The called party cancels the videostream reservation >and begins alerting the called party. >-------------------- >UAS->UAC > >SIP/2.0 180 Ringing >To: Adam Roach >From: John Q. Public >CSeq: 1 INVITE >Content-Length: 0 >-------------------- > >-- >Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 >adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA > > ************************************* "At the end of the day... the most committed win!" James M. Polk Sr. Product Manager, Multiservice Architecture and Standards Enterprise Voice Business Unit Cisco Systems Dallas, Texas w) 972.813.5208 f) 972.813.5280 www.cisco.com --=====================_2567198==_.ALT Content-Type: text/html; charset="us-ascii"
Adam

I think I see a flaw in this suggestion, but I'm not sure:

What happens if you have, for example, Level 3's pure IP network between  the Calling agent's Domain and the Called agents Domain?

Expanding on this, say I'm within my domain calling from my SIP IP Phone, Cisco.com,  who has a direct IP connection into Level 3's IP Backbone (I don't think we do -- but work within me here), but you are on a Cable Modem in the AT&T Broadband Network in Dallas with VoIP enabled to your home; your example seems to only allow for interaction between the calling and called domains, does it matter than there will likely (more so in the future than now) be a additional IP domain in the middle that could very well muck things up quite a bit?

Further, if it does matter, what indication will both sides get if this middle domain is the only one not to comply with the requested QoS settings?

At 10:10 AM 2/22/2000 -0600, Adam B. Roach wrote:
>Since draft-ietf-mmusic-sdp-qos-00.txt expired in December, and is
>functionality we still need to standardize, it will (presumably) be
>reissued soon. Speaking on behalf of the PacketCable group, we have
>some suggestions of enhancements to the upcoming release of this
>document which would allow it to support a more robust network
>architecture.
>
>The current draft makes an assumption that end-to-end network
>resource reservation is controlled by a single entity. For calls
>being placed across adminstrative domains, however, this will
>not be the case. Under such circumstances, the reservation of
>resources needs a greater degree of coordination than is
>currently provided in the draft.
>
>In particular, the calling user agent needs the ability to
>communicate to the called user agent that it has reserved
>the necessary resources on its end, and that alerting may
>begin as soon as the called user agent has done the same.
>
>Our proposed method of doing so is as follows:
>
>1) As in the current draft, the INVITE message contains
>   a=qos:... lines to indicate the calling party's preferences
>   for which streams have mandatory or optional reservation
>   couplings associated with them.
>
>2) Similary, the 18x response contains a subset of the INVITE
>   preconditions.
>
>3) The PRACK confirming the 18x will echo back the finally
>   agreed-on preconditions. This will serve as a "go ahead"
>   message to the called party to begin its actual resource
>   reservation.
>
>4) After the calling side has procured reservations for the
>   required resources, it sends an INFO message to the called
>   party. This INFO message contains an SDP with a confirmation
>   that the required streams have been reserved. For the purposes
>   of this message, we add two values to the "strength" field
>   in the current draft: "reserved" and "resvfail". The presence
>   of the "resvfail" token allows the called party to terminate
>   the call with an error code (for mandatory streams) or to
>   remove its local reservation (for optional streams).
>
>5) The 200 response to the INFO message similarly contains
>   SDP indicating, on a per-stream basis, the status of
>   its local reservations (allowing the calling party to
>   remove reservations for optional streams which were not
>   reserved on the terminating side).
>
>An example callflow follows (with unnecessary but present details,
>like tags and call-ids, removed). To prevent abiguity, I have inserted
>a "Session" header for all cases where SDP is present in a way that is
>not defined in the base specification and cannot be determined from
>context (e.g. the response to a QoS INFO message).
>
>--------------------
>UAC->UAS
>
>INVITE sip:adam.roach@ericsson.com SIP/2.0
>To: Adam Roach <adam.roach@ericsson.com>
>From: John Q. Public <jpublic@ietf.org>
>CSeq: 1 INVITE
>Content-Type: application/sdp
>
>v=0
>m=audio 48327 RTP/AVP 0
>a=qos:mandatory sendrecv
>m=video 10275 RTP/AVP 31
>a=qos:mandatory sendrecv
>--------------------
>UAS->UAC
>
>SIP/2.0 183 Preconditions
>To: Adam Roach <adam.roach@ericsson.com>
>From: John Q. Public <jpublic@ietf.org>
>CSeq: 1 INVITE
>Session: QoS
>Content-Type: application/sdp
>
>v=0
>m=audio 48327 RTP/AVP 0
>a=qos:mandatory sendrecv
>m=video 10275 RTP/AVP 31
>a=qos:optional sendrecv
>--------------------
>UAC->UAS
>
>PRACK sip:adam.roach@ericsson.com SIP/2.0
>To: Adam Roach <adam.roach@ericsson.com>
>From: John Q. Public <jpublic@ietf.org>
>CSeq: 2 PRACK
>Session: QoS
>Content-Type: application/sdp
>
>v=0
>m=audio 48327 RTP/AVP 0
>a=qos:mandatory sendrecv
>m=video 10275 RTP/AVP 31
>a=qos:optional sendrecv
>--------------------
>UAS->UAC
>
>SIP/2.0 200 OK
>To: Adam Roach <adam.roach@ericsson.com>
>From: John Q. Public <jpublic@ietf.org>
>CSeq: 2 PRACK
>Content-Length: 0
>--------------------
>Both parties perform resource reservation
>--------------------
>UAC->UAS
>
>INFO sip:adam.roach@ericsson.com SIP/2.0
>To: Adam Roach <adam.roach@ericsson.com>
>From: John Q. Public <jpublic@ietf.org>
>CSeq: 3 INFO
>Session: QoS
>Content-Type: application/sdp
>
>v=0
>m=audio 48327 RTP/AVP 0
>a=qos:reserved sendrecv
>m=video 10275 RTP/AVP 31
>a=qos:resvfail sendrecv
>--------------------
>UAS->UAC
>
>SIP/2.0 200 OK
>To: Adam Roach <adam.roach@ericsson.com>
>From: John Q. Public <jpublic@ietf.org>
>CSeq: 3 INFO
>Content-Type: application/sdp
>
>v=0
>m=audio 48327 RTP/AVP 0
>a=qos:reserved sendrecv
>m=video 10275 RTP/AVP 31
>a=qos:resvfail sendrecv
>--------------------
>The called party cancels the videostream reservation
>and begins alerting the called party.
>--------------------
>UAS->UAC
>
>SIP/2.0 180 Ringing
>To: Adam Roach <adam.roach@ericsson.com>
>From: John Q. Public <jpublic@ietf.org>
>CSeq: 1 INVITE
>Content-Length: 0
>--------------------
>
>--
>Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
>adam.roach@ericsson.com   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA
>
>

*************************************
"At the end of the day... the most committed win!"

James M. Polk
Sr. Product Manager, Multiservice Architecture and Standards
Enterprise Voice Business Unit
Cisco Systems
Dallas, Texas
w) 972.813.5208
f)  972.813.5280
www.cisco.com --=====================_2567198==_.ALT-- From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 22 14:45:58 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20349 for ; Tue, 22 Feb 2000 14:45:55 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id B370D52C4; Tue, 22 Feb 2000 14:43:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 2992852D4; Tue, 22 Feb 2000 14:43:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id E2E4F52C4 for ; Tue, 22 Feb 2000 14:43:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Feb 22 14:42:28 EST 2000 Received: from mercury.Sun.COM ([192.9.25.1]) by dusty; Tue Feb 22 14:40:04 EST 2000 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA06435; Tue, 22 Feb 2000 11:37:58 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA08058; Tue, 22 Feb 2000 11:37:54 -0800 (PST) Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id LAA25988; Tue, 22 Feb 2000 11:37:54 -0800 (PST) Message-Id: <200002221937.LAA25988@nasnfs.eng.sun.com> Date: Tue, 22 Feb 2000 11:39:11 -0800 (PST) From: James Kempf Reply-To: James Kempf Subject: Re: DHCP option tags for SIP To: eussean@exu.ericsson.se, adutta@telcordia.com Cc: gmorrow@nortelnetworks.com, jdrosen@dynamicsoft.com, fm-listproc@fmmo.ca, James.Kempf@eng.sun.com, mat@cisco.com, sip@lists.research.bell-labs.com, etremblay@mediatrix.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: yFWzQpArijoY+9XEEFcE3w== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk >For a wireless roaming user (e.g. moving between cells, subnets, and domains) >where fast handoff is an issue during an ongoing call, DHCP option tag for >finding out the nearest SIP proxy would be also very useful. > It is not yet clear whether DHCP will be used during wireless roaming. It is a proposed option, but there are a few others. jak From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 22 18:02:09 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26813 for ; Tue, 22 Feb 2000 18:02:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 45C5252C8; Tue, 22 Feb 2000 17:59:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A7DCB52D6; Tue, 22 Feb 2000 17:59:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 0FFF652C8 for ; Tue, 22 Feb 2000 17:59:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 22 17:57:10 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Tue Feb 22 17:54:44 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA28181; Tue, 22 Feb 2000 17:56:52 -0500 (EST) Message-ID: <38B31536.71A6A8DD@dynamicsoft.com> Date: Tue, 22 Feb 2000 18:01:10 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Adam B. Roach" Cc: hgs@cs.columbia.edu, Steven.R.Donovan@wcom.com, sip@lists.research.bell-labs.com Subject: Re: Cross-domain QoS setup References: <200002221610.KAA02284@b04a24.exu.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit "Adam B. Roach" wrote: > The current draft makes an assumption that end-to-end network > resource reservation is controlled by a single entity. For calls > being placed across adminstrative domains, however, this will > not be the case. Under such circumstances, the reservation of > resources needs a greater degree of coordination than is > currently provided in the draft. Not really. Resource reservation is under the "control" of all the network elements along the path that perform some kind of admission control and resource allocation. These elements will often belong to different administrative domains. The draft makes no assumptions about the number of providers along the reservation path, or anything like that. It only ties resource reservation and signaling together at the endpoints, dicatating a particular temporal sequence. > > In particular, the calling user agent needs the ability to > communicate to the called user agent that it has reserved > the necessary resources on its end, and that alerting may > begin as soon as the called user agent has done the same. This is something different from what you are discussing above. It is, in fact, covered in the draft. If A calls B, the RSVP RESV message from A to B confirms resources are reserved from A to B, and the RESVCONF from A to B confirms resource reservation from B to A. This allows B to know whether resources are reserved in both directions. A mirror case exists for A. The difficulty arises only with the segmented DQoS model in DCS, which does not provide a way to confirm resource reservation (I think), whereas RSVP does. So, the question is this. We know we need a way for both parties to know when resources are reserved in both directions. Is this a function that belongs somewhere in SIP (through INFO, as you propose, or some other means), or in a reservation protocol. The mechanism exists already now in RSVP, but not in DQoS (DCS folks, please correct me if I am mistaken). So, do we add it to SIP, in which case its not needed for RSVP, or should it be added to DQoS, in which case the SIP operation is independent of the underlying reservation mechanism? I have argued that confirmation of resource reservation is rightly a job for a resource reservation protocol. One of the things I like about SIP is its separation from session level control and network layer issues, such as resource reservation. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 22 21:03:58 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29180 for ; Tue, 22 Feb 2000 21:03:55 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id EF5A852C4; Tue, 22 Feb 2000 21:01:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 61B3452D4; Tue, 22 Feb 2000 21:01:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 205F452C4 for ; Tue, 22 Feb 2000 21:01:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Feb 22 20:59:03 EST 2000 Received: from PMESMTP01.wcom.com ([199.249.20.1]) by dusty; Tue Feb 22 20:56:38 EST 2000 Received: from ndcrelay.mcit.com ([166.37.172.49]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FQD001EO1I7B0@firewall.mcit.com> for sip@lists.research.bell-labs.com; Wed, 23 Feb 2000 01:58:55 +0000 (GMT) Received: from omzmta01.mcit.com (omzmta01.mcit.com [166.37.194.119]) by ndcrelay.mcit.com (8.8.7/) with ESMTP id BAA10768; Wed, 23 Feb 2000 01:59:03 +0000 (GMT) Received: from C25766A ([166.44.56.121]) by omzmta01.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000223015852.ZSQO14922@C25766A>; Wed, 23 Feb 2000 01:58:52 +0000 Date: Tue, 22 Feb 2000 19:58:51 -0600 From: Henry Sinnreich Subject: RE: Cross-domain QoS setup In-reply-to: <38B31536.71A6A8DD@dynamicsoft.com> To: Jonathan Rosenberg , "Adam B. Roach" Cc: hgs@cs.columbia.edu, Steven.R.Donovan@wcom.com, sip@lists.research.bell-labs.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Detailed call flows addressing this issue are in http://search.ietf.org/internet-drafts/draft-sinnreich-interdoma in-sip-qos-osp-00.txt in general agreement with Jonathan's position. We hope to have a new version in time for the 47th IETF. Henry >-----Original Message----- >From: owner-sip@lists.research.bell-labs.com >[mailto:owner-sip@lists.research.bell-labs.com]On >Behalf Of Jonathan >Rosenberg >Sent: Tuesday, February 22, 2000 5:01 PM >To: Adam B. Roach >Cc: hgs@cs.columbia.edu; Steven.R.Donovan@wcom.com; >sip@lists.research.bell-labs.com >Subject: Re: Cross-domain QoS setup > > > > >"Adam B. Roach" wrote: >> The current draft makes an assumption that >end-to-end network >> resource reservation is controlled by a single >entity. For calls >> being placed across adminstrative domains, however, this will >> not be the case. Under such circumstances, the reservation of >> resources needs a greater degree of coordination than is >> currently provided in the draft. > >Not really. Resource reservation is under the >"control" of all the >network elements along the path that perform some kind >of admission >control and resource allocation. These elements will >often belong to >different administrative domains. The draft makes no >assumptions about >the number of providers along the reservation path, or >anything like >that. It only ties resource reservation and signaling >together at the >endpoints, dicatating a particular temporal sequence. > >> >> In particular, the calling user agent needs the ability to >> communicate to the called user agent that it has reserved >> the necessary resources on its end, and that alerting may >> begin as soon as the called user agent has done the same. > >This is something different from what you are >discussing above. It is, >in fact, covered in the draft. If A calls B, the RSVP >RESV message from >A to B confirms resources are reserved from A to B, >and the RESVCONF >from A to B confirms resource reservation from B to A. >This allows B to >know whether resources are reserved in both >directions. A mirror case >exists for A. > >The difficulty arises only with the segmented DQoS >model in DCS, which >does not provide a way to confirm resource reservation >(I think), >whereas RSVP does. > >So, the question is this. We know we need a way for >both parties to know >when resources are reserved in both directions. Is >this a function that >belongs somewhere in SIP (through INFO, as you >propose, or some other >means), or in a reservation protocol. The mechanism >exists already now >in RSVP, but not in DQoS (DCS folks, please correct me if I am >mistaken). So, do we add it to SIP, in which case its >not needed for >RSVP, or should it be added to DQoS, in which case the >SIP operation is >independent of the underlying reservation mechanism? > >I have argued that confirmation of resource >reservation is rightly a job >for a resource reservation protocol. One of the things >I like about SIP >is its separation from session level control and >network layer issues, >such as resource reservation. > >-Jonathan R. > >-- >Jonathan D. Rosenberg 200 Executive Drive >Chief Scientist Suite 120 >dynamicsoft West >Orange, NJ 07052 >jdrosen@dynamicsoft.com FAX: >(732) 741-4778 >http://www.cs.columbia.edu/~jdrosen PHONE: >(732) 741-7244 >http://www.dynamicsoft.com > From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 23 00:31:23 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03044 for ; Wed, 23 Feb 2000 00:31:23 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id BB10C52AB; Wed, 23 Feb 2000 00:26:08 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 85DD152C4; Wed, 23 Feb 2000 00:26:07 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 2F88752AB for ; Wed, 23 Feb 2000 00:25:09 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 23 00:23:56 EST 2000 Received: from mail-green.research.att.com ([135.207.30.103]) by dusty; Wed Feb 23 00:21:31 EST 2000 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 2832A1E017 for ; Wed, 23 Feb 2000 00:23:53 -0500 (EST) Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id AAA23705 for ; Wed, 23 Feb 2000 00:23:52 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id AAA84989 for sip@lists.research.bell-labs.com; Wed, 23 Feb 2000 00:23:52 -0500 (EST) Date: Wed, 23 Feb 2000 00:23:52 -0500 (EST) Message-Id: <200002230523.AAA84989@fish-ha.research.att.com> Subject: Re: Cross-domain QoS setup To: sip@lists.research.bell-labs.com Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk James M. Polk wrote: > does it matter than there will likely (more so in the future than now) be a > additional IP domain in the middle that could very well muck things up quite a > bit? This is exactly the point. In general there will be three (or more) service providers involved in establishing the QoS, and their service level agreements may be (and in some cases definitely are) different. The router at the edge of each service provider's network needs to convert the resource reservation request into something that the next service provider is willing to handle; in general this may not always be RSVP. Depending on end-to-end RSVP for a successful SIP connection would be an unfortunate dependency. Bill Marshall wtm@research.att.com -----original message----- > > > Adam > > I think I see a flaw in this suggestion, but I'm not sure: > > What happens if you have, for example, Level 3's pure IP network between the > Calling agent's Domain and the Called agents Domain? > > Expanding on this, say I'm within my domain calling from my SIP IP Phone, > Cisco.com, who has a direct IP connection into Level 3's IP Backbone (I don't > think we do -- but work within me here), but you are on a Cable Modem in the > AT&T Broadband Network in Dallas with VoIP enabled to your home; your example > seems to only allow for interaction between the calling and called domains, > does it matter than there will likely (more so in the future than now) be a > additional IP domain in the middle that could very well muck things up quite a > bit? > > Further, if it does matter, what indication will both sides get if this middle > domain is the only one not to comply with the requested QoS settings? > > At 10:10 AM 2/22/2000 -0600, Adam B. Roach wrote: > >Since draft-ietf-mmusic-sdp-qos-00.txt expired in December, and is > >functionality we still need to standardize, it will (presumably) be > >reissued soon. Speaking on behalf of the PacketCable group, we have > >some suggestions of enhancements to the upcoming release of this > >document which would allow it to support a more robust network > >architecture. > > > >The current draft makes an assumption that end-to-end network > >resource reservation is controlled by a single entity. For calls > >being placed across adminstrative domains, however, this will > >not be the case. Under such circumstances, the reservation of > >resources needs a greater degree of coordination than is > >currently provided in the draft. > > > >In particular, the calling user agent needs the ability to > >communicate to the called user agent that it has reserved > >the necessary resources on its end, and that alerting may > >begin as soon as the called user agent has done the same. > > > >Our proposed method of doing so is as follows: > > > >1) As in the current draft, the INVITE message contains > > a=qos:... lines to indicate the calling party's preferences > > for which streams have mandatory or optional reservation > > couplings associated with them. > > > >2) Similary, the 18x response contains a subset of the INVITE > > preconditions. > > > >3) The PRACK confirming the 18x will echo back the finally > > agreed-on preconditions. This will serve as a "go ahead" > > message to the called party to begin its actual resource > > reservation. > > > >4) After the calling side has procured reservations for the > > required resources, it sends an INFO message to the called > > party. This INFO message contains an SDP with a confirmation > > that the required streams have been reserved. For the purposes > > of this message, we add two values to the "strength" field > > in the current draft: "reserved" and "resvfail". The presence > > of the "resvfail" token allows the called party to terminate > > the call with an error code (for mandatory streams) or to > > remove its local reservation (for optional streams). > > > >5) The 200 response to the INFO message similarly contains > > SDP indicating, on a per-stream basis, the status of > > its local reservations (allowing the calling party to > > remove reservations for optional streams which were not > > reserved on the terminating side). > > > >An example callflow follows (with unnecessary but present details, > >like tags and call-ids, removed). To prevent abiguity, I have inserted > >a "Session" header for all cases where SDP is present in a way that is > >not defined in the base specification and cannot be determined from > >context (e.g. the response to a QoS INFO message). > > > >-------------------- > >UAC->UAS > > > >INVITE sip:adam.roach@ericsson.com SIP/2.0 > >To: Adam Roach > >From: John Q. Public > >CSeq: 1 INVITE > >Content-Type: application/sdp > > > >v=0 > >m=audio 48327 RTP/AVP 0 > >a=qos:mandatory sendrecv > >m=video 10275 RTP/AVP 31 > >a=qos:mandatory sendrecv > >-------------------- > >UAS->UAC > > > >SIP/2.0 183 Preconditions > >To: Adam Roach > >From: John Q. Public > >CSeq: 1 INVITE > >Session: QoS > >Content-Type: application/sdp > > > >v=0 > >m=audio 48327 RTP/AVP 0 > >a=qos:mandatory sendrecv > >m=video 10275 RTP/AVP 31 > >a=qos:optional sendrecv > >-------------------- > >UAC->UAS > > > >PRACK sip:adam.roach@ericsson.com SIP/2.0 > >To: Adam Roach > >From: John Q. Public > >CSeq: 2 PRACK > >Session: QoS > >Content-Type: application/sdp > > > >v=0 > >m=audio 48327 RTP/AVP 0 > >a=qos:mandatory sendrecv > >m=video 10275 RTP/AVP 31 > >a=qos:optional sendrecv > >-------------------- > >UAS->UAC > > > >SIP/2.0 200 OK > >To: Adam Roach > >From: John Q. Public > >CSeq: 2 PRACK > >Content-Length: 0 > >-------------------- > >Both parties perform resource reservation > >-------------------- > >UAC->UAS > > > >INFO sip:adam.roach@ericsson.com SIP/2.0 > >To: Adam Roach > >From: John Q. Public > >CSeq: 3 INFO > >Session: QoS > >Content-Type: application/sdp > > > >v=0 > >m=audio 48327 RTP/AVP 0 > >a=qos:reserved sendrecv > >m=video 10275 RTP/AVP 31 > >a=qos:resvfail sendrecv > >-------------------- > >UAS->UAC > > > >SIP/2.0 200 OK > >To: Adam Roach > >From: John Q. Public > >CSeq: 3 INFO > >Content-Type: application/sdp > > > >v=0 > >m=audio 48327 RTP/AVP 0 > >a=qos:reserved sendrecv > >m=video 10275 RTP/AVP 31 > >a=qos:resvfail sendrecv > >-------------------- > >The called party cancels the videostream reservation > >and begins alerting the called party. > >-------------------- > >UAS->UAC > > > >SIP/2.0 180 Ringing > >To: Adam Roach > >From: John Q. Public > >CSeq: 1 INVITE > >Content-Length: 0 > >-------------------- > > > >-- > >Adam Roach, Ericsson Inc. | Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04 > >adam.roach@ericsson.com | Fax: +1 972 669 0154 | Richardson, TX 75081 USA > > > > > > ************************************* > "At the end of the day... the most committed win!" > > James M. Polk > Sr. Product Manager, Multiservice Architecture and Standards > Enterprise Voice Business Unit > Cisco Systems > Dallas, Texas > w) 972.813.5208 > f) 972.813.5280 > www.cisco.com > --=====================_2567198==_.ALT > Content-Type: text/html; charset="us-ascii" > >
Adam
>
>
I think I see a flaw in this suggestion, but I'm not sure:
>
>
What happens if you have, for example, Level 3's pure IP network > between  the Calling agent's Domain and the Called agents Domain? >
>
>
Expanding on this, say I'm within my domain calling from my SIP IP > Phone, Cisco.com,  who has a direct IP connection into Level 3's IP > Backbone (I don't think we do -- but work within me here), but you are on > a Cable Modem in the AT&T Broadband Network in Dallas with VoIP > enabled to your home; your example seems to only allow for interaction > between the calling and called domains, does it matter than there will > likely (more so in the future than now) be a additional IP domain in the > middle that could very well muck things up quite a bit?
>
>
Further, if it does matter, what indication will both sides get if > this middle domain is the only one not to comply with the requested QoS > settings?
>
>
At 10:10 AM 2/22/2000 -0600, Adam B. Roach wrote:
>
>Since draft-ietf-mmusic-sdp-qos-00.txt expired in December, and > is
>
>functionality we still need to standardize, it will (presumably) > be
>
>reissued soon. Speaking on behalf of the PacketCable group, we > have
>
>some suggestions of enhancements to the upcoming release of > this
>
>document which would allow it to support a more robust network >
>
>architecture.
>
>
>
>The current draft makes an assumption that end-to-end network >
>
>resource reservation is controlled by a single entity. For > calls
>
>being placed across adminstrative domains, however, this > will
>
>not be the case. Under such circumstances, the reservation > of
>
>resources needs a greater degree of coordination than is >
>
>currently provided in the draft.
>
>
>
>In particular, the calling user agent needs the ability > to
>
>communicate to the called user agent that it has reserved >
>
>the necessary resources on its end, and that alerting > may
>
>begin as soon as the called user agent has done the > same.
>
>
>
>Our proposed method of doing so is as follows:
>
>
>
>1) As in the current draft, the INVITE message contains
>
>   a=qos:... lines to indicate the calling party's > preferences
>
>   for which streams have mandatory or optional > reservation
>
>   couplings associated with them.
>
>
>
>2) Similary, the 18x response contains a subset of the > INVITE
>
>   preconditions.
>
>
>
>3) The PRACK confirming the 18x will echo back the > finally
>
>   agreed-on preconditions. This will serve as a > "go ahead"
>
>   message to the called party to begin its actual > resource
>
>   reservation.
>
>
>
>4) After the calling side has procured reservations for > the
>
>   required resources, it sends an INFO message to the > called
>
>   party. This INFO message contains an SDP with a > confirmation
>
>   that the required streams have been reserved. For > the purposes
>
>   of this message, we add two values to the > "strength" field
>
>   in the current draft: "reserved" and > "resvfail". The presence
>
>   of the "resvfail" token allows the called > party to terminate
>
>   the call with an error code (for mandatory streams) > or to
>
>   remove its local reservation (for optional > streams).
>
>
>
>5) The 200 response to the INFO message similarly > contains
>
>   SDP indicating, on a per-stream basis, the status > of
>
>   its local reservations (allowing the calling party > to
>
>   remove reservations for optional streams which were > not
>
>   reserved on the terminating side).
>
>
>
>An example callflow follows (with unnecessary but present > details,
>
>like tags and call-ids, removed). To prevent abiguity, I have > inserted
>
>a "Session" header for all cases where SDP is present > in a way that is
>
>not defined in the base specification and cannot be determined > from
>
>context (e.g. the response to a QoS INFO message).
>
>
>
>--------------------
>
>UAC->UAS
>
>
>
>INVITE sip:adam.roach@ericsson.com SIP/2.0
>
>To: Adam Roach <adam.roach@ericsson.com>
>
>From: John Q. Public <jpublic@ietf.org>
>
>CSeq: 1 INVITE
>
>Content-Type: application/sdp
>
>
>
>v=0
>
>m=audio 48327 RTP/AVP 0
>
>a=qos:mandatory sendrecv
>
>m=video 10275 RTP/AVP 31
>
>a=qos:mandatory sendrecv
>
>--------------------
>
>UAS->UAC
>
>
>
>SIP/2.0 183 Preconditions
>
>To: Adam Roach <adam.roach@ericsson.com>
>
>From: John Q. Public <jpublic@ietf.org>
>
>CSeq: 1 INVITE
>
>Session: QoS
>
>Content-Type: application/sdp
>
>
>
>v=0
>
>m=audio 48327 RTP/AVP 0
>
>a=qos:mandatory sendrecv
>
>m=video 10275 RTP/AVP 31
>
>a=qos:optional sendrecv
>
>--------------------
>
>UAC->UAS
>
>
>
>PRACK sip:adam.roach@ericsson.com SIP/2.0
>
>To: Adam Roach <adam.roach@ericsson.com>
>
>From: John Q. Public <jpublic@ietf.org>
>
>CSeq: 2 PRACK
>
>Session: QoS
>
>Content-Type: application/sdp
>
>
>
>v=0
>
>m=audio 48327 RTP/AVP 0
>
>a=qos:mandatory sendrecv
>
>m=video 10275 RTP/AVP 31
>
>a=qos:optional sendrecv
>
>--------------------
>
>UAS->UAC
>
>
>
>SIP/2.0 200 OK
>
>To: Adam Roach <adam.roach@ericsson.com>
>
>From: John Q. Public <jpublic@ietf.org>
>
>CSeq: 2 PRACK
>
>Content-Length: 0
>
>--------------------
>
>Both parties perform resource reservation
>
>--------------------
>
>UAC->UAS
>
>
>
>INFO sip:adam.roach@ericsson.com SIP/2.0
>
>To: Adam Roach <adam.roach@ericsson.com>
>
>From: John Q. Public <jpublic@ietf.org>
>
>CSeq: 3 INFO
>
>Session: QoS
>
>Content-Type: application/sdp
>
>
>
>v=0
>
>m=audio 48327 RTP/AVP 0
>
>a=qos:reserved sendrecv
>
>m=video 10275 RTP/AVP 31
>
>a=qos:resvfail sendrecv
>
>--------------------
>
>UAS->UAC
>
>
>
>SIP/2.0 200 OK
>
>To: Adam Roach <adam.roach@ericsson.com>
>
>From: John Q. Public <jpublic@ietf.org>
>
>CSeq: 3 INFO
>
>Content-Type: application/sdp
>
>
>
>v=0
>
>m=audio 48327 RTP/AVP 0
>
>a=qos:reserved sendrecv
>
>m=video 10275 RTP/AVP 31
>
>a=qos:resvfail sendrecv
>
>--------------------
>
>The called party cancels the videostream reservation
>
>and begins alerting the called party.
>
>--------------------
>
>UAS->UAC
>
>
>
>SIP/2.0 180 Ringing
>
>To: Adam Roach <adam.roach@ericsson.com>
>
>From: John Q. Public <jpublic@ietf.org>
>
>CSeq: 1 INVITE
>
>Content-Length: 0
>
>--------------------
>
>
>
>--
>
>Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. > Arapaho, MS L-04
>
>adam.roach@ericsson.com   | Fax: +1 972 669 0154 | > Richardson, TX 75081 USA
>
>
>
>
>
> >
> *************************************
> "At the end of the day... the most committed win!"
>
>
> James M. Polk
> Sr. Product Manager, Multiservice Architecture and Standards
> Enterprise Voice Business Unit
> Cisco Systems
> Dallas, Texas
> w) 972.813.5208
> f)  972.813.5280
> www.cisco.com > > --=====================_2567198==_.ALT-- > > From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 23 00:49:57 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03115 for ; Wed, 23 Feb 2000 00:49:56 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 74ED052B6; Wed, 23 Feb 2000 00:47:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E792252C8; Wed, 23 Feb 2000 00:47:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 46B4B52B6 for ; Wed, 23 Feb 2000 00:47:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 23 00:45:14 EST 2000 Received: from mail-green.research.att.com ([135.207.30.103]) by dusty; Wed Feb 23 00:42:50 EST 2000 Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id A14501E00D for ; Wed, 23 Feb 2000 00:45:07 -0500 (EST) Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id AAA24148 for ; Wed, 23 Feb 2000 00:45:07 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id AAA86788 for sip@lists.research.bell-labs.com; Wed, 23 Feb 2000 00:45:06 -0500 (EST) Date: Wed, 23 Feb 2000 00:45:06 -0500 (EST) Message-Id: <200002230545.AAA86788@fish-ha.research.att.com> To: sip@lists.research.bell-labs.com Subject: Re: Cross-domain QoS setup Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Jonathan Rosenberg wrote: > The difficulty arises only with the segmented DQoS model in DCS, which > does not provide a way to confirm resource reservation (I think), > whereas RSVP does. ... ..... ... The mechanism exists already now > in RSVP, but not in DQoS (DCS folks, please correct me if I am > mistaken). RSVP only provides this if (1) both endpoints support RSVP, and (2) the backbone transports RSVP. Neither is a valid assumption in DQoS or DCS. Further, please remember the address privacy requirements. Whatever the confirmation message looks like, the anonymizer must be able to parse and rewrite it (just like it does for SIP messages) to update all the addresses. A single mechanism is much preferred. Bill Marshall wtm@research.att.com ----- original message ----- > > > "Adam B. Roach" wrote: > > The current draft makes an assumption that end-to-end network > > resource reservation is controlled by a single entity. For calls > > being placed across adminstrative domains, however, this will > > not be the case. Under such circumstances, the reservation of > > resources needs a greater degree of coordination than is > > currently provided in the draft. > > Not really. Resource reservation is under the "control" of all the > network elements along the path that perform some kind of admission > control and resource allocation. These elements will often belong to > different administrative domains. The draft makes no assumptions about > the number of providers along the reservation path, or anything like > that. It only ties resource reservation and signaling together at the > endpoints, dicatating a particular temporal sequence. > > > > > In particular, the calling user agent needs the ability to > > communicate to the called user agent that it has reserved > > the necessary resources on its end, and that alerting may > > begin as soon as the called user agent has done the same. > > This is something different from what you are discussing above. It is, > in fact, covered in the draft. If A calls B, the RSVP RESV message from > A to B confirms resources are reserved from A to B, and the RESVCONF > from A to B confirms resource reservation from B to A. This allows B to > know whether resources are reserved in both directions. A mirror case > exists for A. > > The difficulty arises only with the segmented DQoS model in DCS, which > does not provide a way to confirm resource reservation (I think), > whereas RSVP does. > > So, the question is this. We know we need a way for both parties to know > when resources are reserved in both directions. Is this a function that > belongs somewhere in SIP (through INFO, as you propose, or some other > means), or in a reservation protocol. The mechanism exists already now > in RSVP, but not in DQoS (DCS folks, please correct me if I am > mistaken). So, do we add it to SIP, in which case its not needed for > RSVP, or should it be added to DQoS, in which case the SIP operation is > independent of the underlying reservation mechanism? > > I have argued that confirmation of resource reservation is rightly a job > for a resource reservation protocol. One of the things I like about SIP > is its separation from session level control and network layer issues, > such as resource reservation. > > -Jonathan R. > > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 23 01:01:54 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03226 for ; Wed, 23 Feb 2000 01:01:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id D983852C8; Wed, 23 Feb 2000 00:59:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 4A47052D4; Wed, 23 Feb 2000 00:59:24 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id DB94052C8 for ; Wed, 23 Feb 2000 00:59:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 23 00:57:46 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Wed Feb 23 00:55:21 EST 2000 Received: from dynamicsoft.com (1Cust25.tnt1.freehold.nj.da.uu.net [63.17.113.25]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA28624; Wed, 23 Feb 2000 00:53:52 -0500 (EST) Message-ID: <38B376F7.3ADFA9F4@dynamicsoft.com> Date: Wed, 23 Feb 2000 00:58:15 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Anders Byttner Cc: rpreethy@hss.hns.com, IETF-SIP Subject: Re: Accept-Contact Header References: <6525688C.0045A19B.00@sampark.hss.hns.com> <38B16134.824A5194@dynamicsoft.com> <38B16A38.CE3F5187@hplb.hpl.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Thanks for catching this. Its been fixed. -Jonathan R. Anders Byttner wrote: > > Just wanted to point out another error in this draft: > > The proposed matching algorithm is not correct. Consider for example if > we have a contact entry that is language="en,ge" and the rule is > language="en,nl". Certainly we want this to be a match, since both > parties speak one common language. But the rule is clearly not a subset > of the entry . In the draft there is an example, which is not accurate > following the above algorithm: > > ;duplex="full,half" > matches the contact entry > ;duplex="full" > > As we see the rule set is clearly not a subset of the entry set (rather > a superset) and according to the proposed algorithm there should not be > a match. But we want it to be a match (as stated in the example, and in > the text above). The algorithm may instead be changed to the following: > > - The parameter name is first checked. If it is not defined in the > contact entry, the parameter is ignored. > - Parameter values are treated as sets, so the intersection of the rule > set and the entry set for this parameter is checked. > - If the intersection is non-empty and the rule set is not negated we > have a match. > - If the intersection is empty and the rule set is negated we also have > a match. > > regards > //Anders > > Jonathan Rosenberg wrote: > > > > Thanks for pointing this out. The bnf appears to be wrong, as it > > mandates a valid name-addr or addr-spec. The document clearly discusses > > the capability of not specifying one. I will fix in the next version > > (due out before the draft deadline). The BNF should be: > > > > Accept-Contact = "Accept-Contact" ":" 1#rule > > rule = (name-addr | addr-spec | "*") > > .... > > > > So, we'll use the * for anything, aligning with current Contact usage. > > > > -Jonathan R. > > > > rpreethy@hss.hns.com wrote: > > > > > > hi All, > > > > > > The document SIP Caller Preferences and Callee Capabilities - > > > draft-ietf-sipcallerprefs-00.txt > > > gives the grammer for Accept-Contact Header as > > > > > > Accept-Contact = "Accept-Contact" ":" 1# rule > > > rule = ( name-addr | addr-spec ) > > > [ *( ";" (cp-params | extension-param | q-param) ) ] > > > q-param = "q" "=" qvalue > > > extension-param = extension-name "=" extension-value > > > extension-name = token > > > extension-value = token | quoted-string > > > > > > and the example given is > > > > > > Accept-Contact: sip:sales@acme.com ;q=0, > > > ;media="!video" ;q=0.1, > > > ;mobility="fixed" ;q=0.6, > > > ;mobility="!fixed" ;q=0.4 > > > > > > According to my understanding, in this example each of the comma separated > > > values is a separate Accept Contact rule, > > > And the parameters of a paticular accept contact rule are separated by ";" > > > semicolon. > > > Here each of the q-params are followed by a comma and then a semi-colon . > > > > > > I cannot understand whether to consider this as > > > 1) a single accept contact rule with all the entries following > > > sip:sales@acme.com as parameters in which case I dont see a need for a > > > comma and semi-colon as separaters between parameters. > > > > > > 2) 4 rules where-in the 2nd 3rd and 4th do not have a nameaddr|addrspec > > > entry which is also an error, becos the rule mandates the presence of > > > nameaddr|addr-spec. > > > > > > Can someone explain this to me. > > > > > > Regards, > > > Preethy > > > > -- > > Jonathan D. Rosenberg 200 Executive Drive > > Chief Scientist Suite 120 > > dynamicsoft West Orange, NJ 07052 > > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > > http://www.dynamicsoft.com > > -- > -------------------------------------------------------------------------- > Anders Byttner Email: > Hewlett-Packard Laboratories Cellular: +44-(0)7901-805 479 > Internet Communication Work: +44-(0)117-312 96 03 > > Filton Road, Stoke Grifford > Bristol > BS34 8QZ > United Kingdom -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 23 02:21:55 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15408 for ; Wed, 23 Feb 2000 02:21:55 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 363C752AB; Wed, 23 Feb 2000 02:19:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A64F552B6; Wed, 23 Feb 2000 02:19:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 4A25A52AB for ; Wed, 23 Feb 2000 02:19:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 23 02:17:07 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Wed Feb 23 02:14:43 EST 2000 Received: from dynamicsoft.com (1Cust25.tnt1.freehold.nj.da.uu.net [63.17.113.25]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA28659 for ; Wed, 23 Feb 2000 02:17:16 -0500 (EST) Message-ID: <38B38A82.E9D934CD@dynamicsoft.com> Date: Wed, 23 Feb 2000 02:21:38 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Subject: firewall and NAT I-D available Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Folks, Some colleagues and I have written and Internet Draft on getting SIP through firewalls and NATs. It discusess the various configurations and problems, and describes in detail the processing required to get things working. The draft should appear in the archives shortly. Until it does, you can pick up a copy at: http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-sip-firewalls-00.txt Thanks, Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 23 02:33:51 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA16122 for ; Wed, 23 Feb 2000 02:33:51 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 9276052B6; Wed, 23 Feb 2000 02:31:25 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 0E34E52C4; Wed, 23 Feb 2000 02:31:24 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 48AAF52B6 for ; Wed, 23 Feb 2000 02:31:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 23 02:30:35 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Wed Feb 23 02:28:11 EST 2000 Received: from dynamicsoft.com (1Cust25.tnt1.freehold.nj.da.uu.net [63.17.113.25]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA28663; Wed, 23 Feb 2000 02:30:42 -0500 (EST) Message-ID: <38B38DA8.7FECBACB@dynamicsoft.com> Date: Wed, 23 Feb 2000 02:35:04 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kim Liu Cc: sip@lists.research.bell-labs.com Subject: Re: Question about UDP, Via: header, and received= attribute. References: <38AD5A45.BEF69D7C@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Kim Liu wrote: > > Section 6.40.2 states that a proxy should check that the address in > the last Via: header matches the address that the request was actually > received from. If the addresses do not match, the proxy must add the > received tag with the address that the request was actually received > from. > > My problem is with what happens if the address/hostname in the Via > header matches several IP addresses, including the one actually used > to send it, but not all of the addresses are routable, preferred, or > public. > > That is, suppose a server receives a Via header like: > > Via: SIP/2.0/UDP aka.generic.com:5060 > > in a UDP packet with an originating address of 10.100.100.100. > The server looks up the IP addresses for aka.generic.com to see > whether or not 10.100.100.100 is one of its addresses. The > returned addresses for aka.generic.com are: > > 192.168.128.1, 192.168.128.2, 192.168.128.3, 192.168.128.3, and > 10.100.100.100. > > So, since the 10.100.100.100 address is present, no received tag is > added to the Via field. Now, when the response comes back through > the proxy, and the proxy tries to forward it back along the Via > lines, which IP address should the proxy choose to send the UDP > message to? (Of course, the 192.* addresses might be public > interfaces, and the 10.100.100.100 address is on a private network > to keep call information private, etc.) Could a recieved= tag > be added to the Via: header anyways to be used to tell the proxy > exactly which IP address the response should be sent to? I would not recommend that. The reason for having a hostname in the Via field as an option is to add a layer of indirection. This would allow a set of proxy servers to be used for load balancing purposes through DNS round robining. In many cases, its not actually important for the response to even go back to the same server the request came from (not important at all for stateless proxies). Thus, my recommendation would be: If the Via contains a hostname, and the IP address the request came from is one of the addresses returned from DNS query for that hostname, no received tag is added. If your proxy is such that responses should always be sent to just that proxy, well, then don't put multiple addresses for it in DNS, or don't put a hostname in the Via header. Also, in your example above, DNS queries from outside the network the server sits in are never going to return a net 10 address. Thus, if a request has passed through a NAT, and the source IP address is a net 10 address, and the Via header contained a hostname, you can be sure the received tag will be inserted. This is also what you want. > > Also, I think I may have seen this question earlier, but I cannot > find it now (is there a mailing list archive somewhere?) Yes. Its linked from the sip page at IETF. Its: http://www.bell-labs.com/mailing-lists/sip > -- how does > the Via:/received affect loop detection? It doesn't. > The example given in > the draft indicates that one use of the received tag was for when > a SIP request is passing through NAT. When checking for loops > and a received tag is present, should only the address in the > received tag be checked? The received tag is not used for loop detection. A proxy looks for Via fields that contain its own address that it inserted into the sent-by field. Some recent posts to the list discuss additional checks that must be made to avoid false classification of loops when calls are forwarded to other users on the same network. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 23 04:11:56 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17124 for ; Wed, 23 Feb 2000 04:11:55 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 11D5752B6; Wed, 23 Feb 2000 04:09:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 847EE52C4; Wed, 23 Feb 2000 04:09:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id B0D4752B6 for ; Wed, 23 Feb 2000 04:09:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 23 04:08:56 EST 2000 Received: from bounty.cisco.com ([161.44.2.72]) by dusty; Wed Feb 23 04:06:32 EST 2000 Received: (from shbhatna@localhost) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) id EAA24969 for sip@lists.research.bell-labs.com; Wed, 23 Feb 2000 04:08:53 -0500 (EST) From: Shail Bhatnagar Message-Id: <200002230908.EAA24969@bounty.cisco.com> Subject: Proxy questions To: sip@lists.research.bell-labs.com Date: Wed, 23 Feb 2000 04:08:53 -0500 (EST) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit These questions have probably been discussed in the past - I will ask one more time. 1) Does To header have any role in call routing ( from a proxy's standpoint) - I mean in determining the next hop. 2) A stateful proxy receives a retransmitted request for which it **proxied** a 200 OK recently. Should it re-proxy the 200 OK ? Thanks, Shail From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 23 09:12:01 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22418 for ; Wed, 23 Feb 2000 09:12:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 6764A52AB; Wed, 23 Feb 2000 09:09:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id DABC152D6; Wed, 23 Feb 2000 09:09:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 4D3B252AB for ; Wed, 23 Feb 2000 09:09:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 23 09:07:58 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Wed Feb 23 09:05:34 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA28797; Wed, 23 Feb 2000 09:08:05 -0500 (EST) Message-ID: <38B3EACF.553FE7CC@dynamicsoft.com> Date: Wed, 23 Feb 2000 09:12:31 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Shail Bhatnagar Cc: sip@lists.research.bell-labs.com Subject: Re: Proxy questions References: <200002230908.EAA24969@bounty.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Shail Bhatnagar wrote: > > These questions have probably been discussed in the past - I will ask one > more time. > > 1) Does To header have any role in call routing ( from a proxy's > standpoint) - I mean in determining the next hop. Normally, no. When using the registration database, it is the request URI that is used as a key. The request URI is the entity being addressed at that particular server, so that is what will generally be used. However, no one can dictate the logic used by a proxy for determining how a call should be handled. Certainly its possible that the To field might be used for some kind of policy decision. > > 2) A stateful proxy receives a retransmitted request for which it > **proxied** a 200 OK recently. Should it re-proxy the 200 OK ? No. Retransmissions of 200 OK to INVITE are handled end to end. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 23 11:02:15 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24662 for ; Wed, 23 Feb 2000 11:02:13 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 609AA52DA; Wed, 23 Feb 2000 10:59:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id CB38A52DD; Wed, 23 Feb 2000 10:59:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id DBE8C52DA for ; Wed, 23 Feb 2000 10:59:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 23 10:58:36 EST 2000 Received: from sj-mailhub-3.cisco.com ([171.68.224.215]) by dusty; Wed Feb 23 10:56:12 EST 2000 Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [171.71.147.106]) by sj-mailhub-3.cisco.com (8.9.1a/8.9.1) with ESMTP id IAA15461; Wed, 23 Feb 2000 08:20:32 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA28759; Wed, 23 Feb 2000 07:57:49 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14516.893.82555.575473@thomasm-u1.cisco.com> Date: Wed, 23 Feb 2000 07:57:49 -0800 (PST) To: William Marshall Cc: sip@lists.research.bell-labs.com Subject: Re: Cross-domain QoS setup In-Reply-To: <200002230523.AAA84989@fish-ha.research.att.com> References: <200002230523.AAA84989@fish-ha.research.att.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit William Marshall writes: > This is exactly the point. In general there will be three (or more) service > providers involved in establishing the QoS, and their service level agreements > may be (and in some cases definitely are) different. The router at the > edge of each service provider's network needs to convert the resource > reservation request into something that the next service provider is willing > to handle; in general this may not always be RSVP. Depending on end-to-end > RSVP for a successful SIP connection would be an unfortunate dependency. I think that this is somewhat speculative at this point because backbone providers up until recently haven't had a business case to provide differential treatment of EF traffic, say, through their network. If there's a business case for RSVP and a solution that will scale to their network, I'm sure there will be providers who offer it. But I'm not even sure that it is the case that the backbone provider even needs to participate in RSVP in the "normal" case (other than carrying the datagram over their network). Suppose we have the following network: UAC->[cloud]->Border<==>Border->[BB cloud]->Border<==>Border->[cloud]->UAC Further, suppose that there is a SLA across the backbone cloud which gives 20% EF traffic guarantees. In this case, the backbone provider's border router (or any for that matter) does not need to participate in RSVP because the border router at the access network will do the flow admission control at its backbone border router. The BB router's job is to traffic shape the SLA, but it needs to do that anyway. The access network's border router needs to make certain that the admission control operation takes into account the SLA with the backbone operator, which it needs to do anyway as well. It's even better with aggregated RSVP since it allows multiple levels of aggregation: between the access router and the border router, flows could be aggregated to relieve the micro flow load at the border router. Since aggregated RSVP "tunnels" the "end to end" RSVP requests to the next aggregation point, we can use the same technique to tunnel the RSVP request across the backbone so that it doesn't matter whether the BB provider does or does not allow/act on RSVP in their network -- it will be transparent to them (and in fact, the RSVP requests should use integrity objects to disallow unauthorized use). I believe this extends to the general case where you have more than one BB provider too: so long as the intermediate providers honor the SLA that the initial BB provider sold to the access provider, all is well. There doesn't need to be any admission control in center because the admission control was done at the choke point. I believe this also extends to non-static SLA's as well if we want to use RSVP in the core: with the use of RSVP and COPS at the access provider's border, large(r) pipes can be created which so long as they can be billed correctly would provide a dynamic SLA capability too which doesn't even exist today that I'm aware of. All in all, RSVP+Policy+Aggregation gives a lot of flexibility. Mike From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 23 12:04:03 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26834 for ; Wed, 23 Feb 2000 12:04:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 5FDC152C8; Wed, 23 Feb 2000 12:01:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id CCC5352DE; Wed, 23 Feb 2000 12:01:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 6A05352C8 for ; Wed, 23 Feb 2000 12:01:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Feb 23 11:59:16 EST 2000 Received: from PMESMTP02.wcom.com ([199.249.20.2]) by dusty; Wed Feb 23 11:56:52 EST 2000 Received: from omzrelay.mcit.com ([166.37.204.49]) by firewall.mcit.com (PMDF V5.2-32 #41713) with ESMTP id <0FQE009D974HYT@firewall.mcit.com> for sip@lists.research.bell-labs.com; Wed, 23 Feb 2000 16:57:54 +0000 (GMT) Received: from omzmta03.mcit.com (omzmta03.mcit.com [166.37.194.121]) by omzrelay.mcit.com (8.8.7/) with ESMTP id QAA07235; Wed, 23 Feb 2000 16:57:56 +0000 (GMT) Received: from dwillispc8 ([166.35.225.166]) by omzmta03.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000223165753.ZZUL12655@dwillispc8>; Wed, 23 Feb 2000 16:57:53 +0000 Date: Wed, 23 Feb 2000 10:57:00 -0600 From: Dean Willis Subject: RE: DHCP option tags for SIP In-reply-to: <38AEDBC8.E3D77507@cs.columbia.edu> To: Henning Schulzrinne , Michael Thomas Cc: sip@lists.research.bell-labs.com Message-id: <003101bf7e1f$007ad880$a6e123a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit In actually doing this stuff, I can say that our experimental deployment model is that the phone registers with an "identity" value which is effectively unique to the phone. This "identity" is associated with users (domain addresses) and phone numbers in a profile schema (directory). We provide a web interface for managing the profile, or one can manipulate it with SIP registrations. This allows users to forward their phones, move them, clone them, sell them and buy new ones, etc. The phone is not the user, nor is it the phone number. It's just a piece of gear that may (or may not) be on the contact list for a given request URI as that request URI evolves from the original request through processing by proxies, etc. -- Dean > -----Original Message----- > From: owner-sip@lists.research.bell-labs.com > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Henning > Schulzrinne > Sent: Saturday, February 19, 2000 12:07 PM > To: Michael Thomas > Cc: sip@lists.research.bell-labs.com > Subject: Re: DHCP option tags for SIP > > > Michael Thomas wrote: > > > > Henning Schulzrinne writes: > > > As far as I can tell from our implementation experience, > this is pretty > > > much (*) the last piece of information needed to configure a > phone. At > > > the DHCP level, we currently use for a basic phone: > > > > > > - IP address, DNS server address, default gateway (standard > DHCP fare) > > > - time server address > > > - outbound SIP proxy server > > > - normal boot image information for phones with downloadable code > > > > Dumb question: would a phone need its E.164 address(es) > > when registering, etc? > > Actually, an interesting question. A phone would need the identity with > which it should register. From what I can tell, PBX will probably have > two identities for their phones, one "legacy" (E.164) identity and one > or more SIP identities (email address). It could be more than one if two > people share a phone, as our grad students do. > > It might even have a third identity reflecting the phone's location, > e.g., "Room2F524@somewhere.com". The first two types of identities would > change if a person moved into a different office (assuming that she > leaves her phone behind), while the latter would stay constant. > Conversely, if people take their phones with them, only the last > identity would change. > > Since these identities don't generally change all that often, this could > be hard-coded. (Fancier mechanisms, such as identities conveyed by > PalmPilots, have been discussed elsewhere.) Alternatively, a few of us > have discussed that there might well be a need for an additional > configuration parameter, namely a list of "identities" that the phone > should register with. Pretty straightforward to define, but I kind of > wanted to get the server issue out of the way first. > > > > > > > There are other SIP-level configurations that are > inappropriate, in my > > > view, for DHCP, things like speed dial configurations or other UI > > > assignments, any end system CPL, etc. > > > > This, however, was my point. If you believe in directories > > for configless widgets, it would make a lot more sense to > > dump all of this information there and have a pointer to > > the directory in DHCP. If the sum total of configuration > > that a configurationless device is greater than just the > > address of the first hop proxy, then all this new > > option is doing is solving a small part of a previously > > unsolved problem. > > Our current intent is to put some of this into the REGISTER response, > using an appropriate MIME type, since it avoids having to define yet > another directory protocol, more servers, etc. (Putting LDAP into an > embedded system strikes me as challenging, to put it mildly.) > > However, the outbound proxy can be different from my registration > server. > > Indeed, in order to find my non-multicast registration server, I need to > know my identity (see discussion above). > > Thus, overall, I see DHCP used for things that are needed to bootstrap > into the SIP infrastructure with minimum cost and without creating > seventeen new directory servers. Almost all SOHO-style integrated > devices support DHCP, for obvious reasons, while installing and > configuring LDAP, say, seems like a stretch for this type of > application. (You don't mention a specific directory service, so pardon > me if I'm misinterpreting your remarks.) > > Overall, the larger the number of servers, the higher the probability > that one of the alphabet soup servers is down, misconfigured. In my > view, it would be nice if I can install a basic Internet PBX with two > servers, a DHCP server and a SIP server. These seem to be required, > adding anything else as a basic requirement to make phones ring seems > like it needs a fair amount of justification for the complexity. This > does not mean that more complicated scenarios can't make good use of SLP > or LDAP. (We use LDAP in our SIP server and PC client, for example.) > > > > > Mike > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 23 12:14:19 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27211 for ; Wed, 23 Feb 2000 12:14:19 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id CF64652E3; Wed, 23 Feb 2000 12:11:42 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 2A61652E0; Wed, 23 Feb 2000 12:11:39 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 1AB9C52E0 for ; Wed, 23 Feb 2000 12:11:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 23 12:10:18 EST 2000 Received: from gwu.ericy.com ([208.196.3.162]) by dusty; Wed Feb 23 12:07:54 EST 2000 Received: from mr4.exu.ericsson.se (mr4u.ericy.com [208.238.116.99]) by gwu.ericy.com (8.9.3/8.9.3) with ESMTP id LAA24918; Wed, 23 Feb 2000 11:10:12 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.10.50]) by mr4.exu.ericsson.se (8.9.3/8.9.3) with ESMTP id KAA13140; Wed, 23 Feb 2000 10:42:07 -0600 (CST) Received: from b04a19.exu.ericsson.se (b04a19 [138.85.60.119]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA05082; Wed, 23 Feb 2000 10:41:54 -0600 (CST) Received: from exu.ericsson.se (localhost [127.0.0.1]) by b04a19.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id KAA01085; Wed, 23 Feb 2000 10:41:53 -0600 (CST) Message-ID: <38B40DD1.9E487B03@exu.ericsson.se> Date: Wed, 23 Feb 2000 10:41:53 -0600 From: Michelle Kitchings Reply-To: Michelle.Kitchings@ERICSSON.COM Organization: Ericsson, Inc. X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4m) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Henning Schulzrinne , Anders Kristensen , SIP Subject: Re: Extension negotiation draft References: <38A85EA3.6DB9A152@hplb.hpl.hp.com> <38B18BCC.C9028997@dynamicsoft.com> <38B194DE.183CA9DF@cs.columbia.edu> <38B19EB8.68CC1B10@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: ... > > So, the current proposal is to write a draft that: > > 1. Defines the Supported header syntax > 2. specifies its usage in OPTIONS responses > 3. specifies its usage in requests - basically, it lists all features > with short names > 4. supports no negotiation > > This draft will be obsoleted by rfc2543bis when it goes to rfc, but no > way we can wait that long for this. > > How do people feel about this? If we get consensus, I'll do another rev > on the document and we can push it out the door. > > -Jonathan R. FWIW, I like it! (I especially like #3 :) Michelle :^) -- Michelle Kitchings | Ph: +1 972 583 7101 | 1010 E. Arapaho, MS L-04 Ericsson, Inc. | Fax: +1 972 669 0154 | Richardson, TX 75081 USA From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 23 13:10:02 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28825 for ; Wed, 23 Feb 2000 13:10:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 6D43352DD; Wed, 23 Feb 2000 13:07:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C80B552E0; Wed, 23 Feb 2000 13:07:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 1201F52DD for ; Wed, 23 Feb 2000 13:07:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 23 13:05:34 EST 2000 Received: from bounty.cisco.com ([161.44.2.72]) by dusty; Wed Feb 23 13:03:10 EST 2000 Received: from cisco.com (bounty.cisco.com [161.44.2.72]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id NAA02763; Wed, 23 Feb 2000 13:05:26 -0500 (EST) Message-ID: <38B42165.3495D1BA@cisco.com> Date: Wed, 23 Feb 2000 13:05:26 -0500 From: Shail Bhatnagar Organization: CISCO X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: sip@lists.research.bell-labs.com Subject: Re: Proxy questions References: <200002230908.EAA24969@bounty.cisco.com> <38B3EACF.553FE7CC@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > > > > 2) A stateful proxy receives a retransmitted request for which it > > **proxied** a 200 OK recently. Should it re-proxy the 200 OK ? > > No. Retransmissions of 200 OK to INVITE are handled end to end. > > -Jonathan R. > Yes, but what should the stateful proxy do with this re-transmitted INVITE. Forward it on or simply drop it and wait for UAS re-transmission logic to retransmit the 200 OK or re-send the last provisional it sent upstream. Thanks, Shail From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 23 14:03:59 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00244 for ; Wed, 23 Feb 2000 14:03:57 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id BB9BD52DE; Wed, 23 Feb 2000 14:01:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3C82152E0; Wed, 23 Feb 2000 14:01:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id A175D52DE for ; Wed, 23 Feb 2000 14:01:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Feb 23 14:00:52 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Wed Feb 23 13:58:29 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA29662; Wed, 23 Feb 2000 13:56:25 -0500 (EST) Message-ID: <38B42E62.F14AE4A3@dynamicsoft.com> Date: Wed, 23 Feb 2000 14:00:50 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Shail Bhatnagar Cc: sip@lists.research.bell-labs.com Subject: Re: Proxy questions References: <200002230908.EAA24969@bounty.cisco.com> <38B3EACF.553FE7CC@dynamicsoft.com> <38B42165.3495D1BA@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Shail Bhatnagar wrote: > > Jonathan Rosenberg wrote: > > > > > > > > > 2) A stateful proxy receives a retransmitted request for which it > > > **proxied** a 200 OK recently. Should it re-proxy the 200 OK ? > > > > No. Retransmissions of 200 OK to INVITE are handled end to end. > > > > -Jonathan R. > > > > Yes, but what should the stateful proxy do with this re-transmitted INVITE. > Forward it on or simply drop it and wait for UAS re-transmission logic to > retransmit the 200 OK or re-send the last provisional it sent upstream. The proxy can either drop it or send it. Its not needed to ensure reliability. The 200 retransmissions at the UAS will handle this. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 23 15:21:44 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02098 for ; Wed, 23 Feb 2000 15:21:44 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 3E6C452E2; Wed, 23 Feb 2000 15:09:53 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8F78452E5; Wed, 23 Feb 2000 15:09:52 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C2B0752AB for ; Wed, 23 Feb 2000 01:57:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 23 01:56:35 EST 2000 Received: from web3403.mail.yahoo.com ([204.71.203.57]) by dusty; Wed Feb 23 01:54:11 EST 2000 Message-ID: <20000223065633.5509.qmail@web3403.mail.yahoo.com> Received: from [202.54.89.60] by web3403.mail.yahoo.com; Tue, 22 Feb 2000 22:56:33 PST Date: Tue, 22 Feb 2000 22:56:33 -0800 (PST) From: Steve Little Subject: Diff. between branch and tag To: SIP Mailing List MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Hi, What is the difference between inserting a branch param in a Via and a tag in To, From headers ? Dont both uniquely identify req-resp for forking proxies ? Thx __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 23 15:33:59 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02376 for ; Wed, 23 Feb 2000 15:33:58 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id D71AB52E1; Wed, 23 Feb 2000 15:31:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 4D0EA52E5; Wed, 23 Feb 2000 15:31:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 4D4F452E1 for ; Wed, 23 Feb 2000 15:31:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 23 15:30:44 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Wed Feb 23 15:28:19 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA00007; Wed, 23 Feb 2000 15:30:46 -0500 (EST) Message-ID: <38B442D8.6B0B6942@dynamicsoft.com> Date: Wed, 23 Feb 2000 15:28:08 -0500 From: Igor Slepchin Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en,ru MIME-Version: 1.0 To: Steve Little Cc: SIP Mailing List Subject: Re: Diff. between branch and tag References: <20000223065633.5509.qmail@web3403.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Branch IDs allow proxies to match responses to forked requests. Without them, a proxy wouldn't be able to tell which branch a response corresponds to. Tags are of no help here since they are not known until responses arrive. --- Igor Slepchin Steve Little wrote: > > Hi, > What is the difference between inserting a branch > param in a Via and a tag in To, From headers ? > Dont both uniquely identify req-resp for forking > proxies ? > > Thx > > __________________________________________________ > Do You Yahoo!? > Talk to your friends online with Yahoo! Messenger. > http://im.yahoo.com From owner-sip-outgoing@lists.research.bell-labs.com Wed Feb 23 17:40:11 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04329 for ; Wed, 23 Feb 2000 17:40:09 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 7558252DF; Wed, 23 Feb 2000 17:37:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E242452E5; Wed, 23 Feb 2000 17:37:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id B5A4052DF for ; Wed, 23 Feb 2000 17:37:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Wed Feb 23 17:35:44 EST 2000 Received: from PMESMTP02.wcom.com ([199.249.20.2]) by dusty; Wed Feb 23 17:33:20 EST 2000 Received: from omzrelay.mcit.com ([166.37.204.49]) by firewall.mcit.com (PMDF V5.2-32 #41713) with ESMTP id <0FQE004KOMPQYP@firewall.mcit.com> for sip@lists.research.bell-labs.com; Wed, 23 Feb 2000 22:34:39 +0000 (GMT) Received: from omta4.mcit.com (omta4.mcit.com [166.37.204.6]) by omzrelay.mcit.com (8.8.7/) with ESMTP id WAA30494; Wed, 23 Feb 2000 22:34:36 +0000 (GMT) Received: from dwillispc8 ([166.35.148.173]) by omta4.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000223223640.RQQF755@dwillispc8>; Wed, 23 Feb 2000 22:36:40 +0000 Date: Wed, 23 Feb 2000 16:33:40 -0600 From: Dean Willis Subject: RE: SIP BCP-T question In-reply-to: <153BDA136259D311859900A0C99B5263027750@boca-isbu-nt04.boca.unisphere.com> To: "Carr, Steve" , "'Raja Badri'" , sip ML Message-id: <000f01bf7e4e$084a5020$ad9423a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit It seems that these might really be "no-op" operations rather than "nonexistent" operations. There's a difference. -- Dean > -----Original Message----- > From: owner-sip@lists.research.bell-labs.com > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Carr, Steve > Sent: Monday, February 14, 2000 12:25 PM > To: 'Raja Badri'; sip ML > Subject: RE: SIP BCP-T question > > > The ISUP maintenance messages relate to the physical trunk circuit, which > when not being used on a call, is still physically present and in an IDLE > (or blocked) state. SIP BCT-T sets up calls over an RTP "logical" > connection, which is not a physical circuit. After the end of the > call, the > RTP connection ceases to exist. Therefore is does not make sense to block > it, unblock it, reset it etc...... > > Steve Carr > Unisphere Solutions Inc. > Boca Raton > scarr@unispheresolutions.com > Office (561) 955-8288 > Fax (561) 955-6477 > > www.unispheresolutions.com > > -----Original Message----- > From: Raja Badri [mailto:raja.badri@santera.com] > Sent: Monday, February 14, 2000 1:04 PM > To: sip ML > Subject: SIP BCP-T question > > > Hi, > > I have one question regarding the SIP BCP-T. > INFO message outlines the Mid-Call ISUP messages. > What is the reason behind not including the ISUP maintenance > messages like Block, Unblock and Reset ? > > Thanks, > Raja Badri > Santera Systems Inc. > > > From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 24 00:29:36 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11124 for ; Thu, 24 Feb 2000 00:29:36 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 418DF52E5; Thu, 24 Feb 2000 00:24:15 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6557B52E6; Thu, 24 Feb 2000 00:24:14 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 390AB52E5 for ; Thu, 24 Feb 2000 00:23:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 24 00:22:57 EST 2000 Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Thu Feb 24 00:20:33 EST 2000 Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: 1Cust226.tnt2.long-branch.nj.da.uu.net [63.25.226.226]) id QQidsv14512; Thu, 24 Feb 2000 05:22:38 GMT Message-ID: <38B4C070.BE2844CE@dynamicsoft.com> Date: Thu, 24 Feb 2000 00:24:00 -0500 From: Igor Slepchin Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Steve Little Cc: SIP Mailing List Subject: Re: Diff. between branch and tag References: <20000224042950.28361.qmail@web3401.mail.yahoo.com> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Tags are inserted by UASs, not proxies, and are needed to allow UAC to distinguish multiple 200 OK responses sent by several UASs in respponse to a forked request or, equivalently, to distinguish multiple instances of a user identified by the URL in the request URI of original request. Tags are _not_ used to match responses to forked requests at the proxies. Steve Little wrote: > Ive have seem implementations insert a tag field > irrespective of whether it forks or not. UAS has no reliable way of determining if the request has been forked or not. Thus, to be safe it almost needs to add a tag. Proxies only insert tags into the final responses they generate themselves; they never insert tags into requests or responses they forward. > Also, if forking proxies insert tags while forwarding > the request, then isnt that enough ? Then when a > receiving entity gets the request, it responds and > copies the tag in it. Since a request can be forked several times on its way to UAS, a single "tag" (or whatever you like to call it) added to the request by one of the proxies is not sufficient for the next forking proxy along the chain to match responses on its own branches; every proxy that forked the request would need to add its own unique IDs to the branches it created. This is precisely what's being achieved by branch parameter in Via header. > why should a reciever try and figure out if > its forked ? It should not and, moreover, cannot (I assume a receiver here means UAS). Instead, it should always add tags to all responses it generates. --- Igor Slepchin From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 24 01:44:02 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14138 for ; Thu, 24 Feb 2000 01:44:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id CF92A52E6; Thu, 24 Feb 2000 01:41:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 4080252E7; Thu, 24 Feb 2000 01:41:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 84B5552E6 for ; Thu, 24 Feb 2000 01:41:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 24 01:40:28 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Thu Feb 24 01:38:04 EST 2000 Received: from dynamicsoft.com (1Cust44.tnt1.freehold.nj.da.uu.net [63.17.113.44]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA01095; Thu, 24 Feb 2000 01:40:35 -0500 (EST) Message-ID: <38B4D36E.329DE08A@dynamicsoft.com> Date: Thu, 24 Feb 2000 01:45:02 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Cc: droms@bucknell.edu Subject: DHCP Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Folks, There has been some discussion in response to our proposal to fast track a DHCP option for SIP. This discussion generally indicated that DHCP would not be sufficient for autoconfiguration. We (the wg chairs) think a DHCP option for finding a default proxy is a useful thing, even if it is not a complete solution. We therefore propose to define the DHCP option, making it available for implementation, and carry on the dialog on managing SIP endpoints as a continuing thread. As such, this message will serve as a working group last call on the DHCP options document: http://search.ietf.org/internet-drafts/draft-nair-sip-dhcp-01.txt We are trying to coordinate a parallel last call on the dhcp list, which must review the document as well. The working group last call will last three weeks. Please send comments to the list or to the authors during this time. Thanks, Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 24 02:59:40 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24274 for ; Thu, 24 Feb 2000 02:59:40 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id D9EEA52E0; Thu, 24 Feb 2000 02:55:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 55A7852E8; Thu, 24 Feb 2000 02:55:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 9F4CC52E0 for ; Thu, 24 Feb 2000 02:55:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 24 02:53:34 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Thu Feb 24 02:51:10 EST 2000 Received: from dynamicsoft.com (1Cust44.tnt1.freehold.nj.da.uu.net [63.17.113.44]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA01141; Thu, 24 Feb 2000 02:53:27 -0500 (EST) Message-ID: <38B4E482.AA6F472F@dynamicsoft.com> Date: Thu, 24 Feb 2000 02:57:54 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis Cc: Henning Schulzrinne , Michael Thomas , sip@lists.research.bell-labs.com Subject: Re: DHCP option tags for SIP References: <003101bf7e1f$007ad880$a6e123a6@mcit.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Dean Willis wrote: > > In actually doing this stuff, I can say that our experimental deployment > model is that the phone registers with an "identity" value which is > effectively unique to the phone. This "identity" is associated with users > (domain addresses) and phone numbers in a profile schema (directory). We > provide a web interface for managing the profile, or one can manipulate it > with SIP registrations. This allows users to forward their phones, move > them, clone them, sell them and buy new ones, etc. If I understand you right, the phone would have an ID, something like sip:phone3736489@wcom.com. When plugged in, it automatically registers this address, binding it to its current IP address. In addition, users can go to a web page (or use a SIP registration), and basically create another binding, mapping their name (sip:dean.willis@wcom.com) to the ID of the phone (sip:3736489@wcom.com). Is that right? Neat idea... solves the problem that a standalone phone is not always going to have an easy way for the user to enter their name that it should use in a registration. It is basically adding another layer of indirection: user->device->address, rather than just user->address. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 24 03:05:59 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24410 for ; Thu, 24 Feb 2000 03:05:59 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 0456452E9; Thu, 24 Feb 2000 03:03:29 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6E93B52E8; Thu, 24 Feb 2000 03:03:28 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 0ADBB52E9 for ; Thu, 24 Feb 2000 03:03:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 24 03:01:51 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Thu Feb 24 02:59:28 EST 2000 Received: from dynamicsoft.com (1Cust44.tnt1.freehold.nj.da.uu.net [63.17.113.44]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id DAA01154; Thu, 24 Feb 2000 03:01:59 -0500 (EST) Message-ID: <38B4E682.8D23DA8A@dynamicsoft.com> Date: Thu, 24 Feb 2000 03:06:26 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: William Marshall Cc: sip@lists.research.bell-labs.com Subject: Re: Cross-domain QoS setup References: <200002230545.AAA86788@fish-ha.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit William Marshall wrote: > > Jonathan Rosenberg wrote: > > The difficulty arises only with the segmented DQoS model in DCS, which > > does not provide a way to confirm resource reservation (I think), > > whereas RSVP does. > ... ..... ... The mechanism exists already now > > in RSVP, but not in DQoS (DCS folks, please correct me if I am > > mistaken). > > > Further, please remember the address privacy requirements. Whatever > the confirmation message looks like, the anonymizer must be able > to parse and rewrite it (just like it does for SIP messages) to update all > the addresses. A single mechanism is much preferred. Well, an anonymizer can't have just a single protocol mechanism. By its very definition, the anonymizer must handle both SIP and RTP at least, which is already two protocols. Since its handling media streams, it must also initiate and terminate QoS reservations if you want voice quality through the anonymizer. So, its already doing resource reservation. If the resource reservation protocol is providing confirmations, its not any extra protocol work as compared to putting these confirmations in the signaling protocol. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 24 03:58:05 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24753 for ; Thu, 24 Feb 2000 03:58:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id BBC0752E7; Thu, 24 Feb 2000 03:55:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 39ED152EA; Thu, 24 Feb 2000 03:55:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 2262C52E7 for ; Thu, 24 Feb 2000 03:55:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 24 03:54:55 EST 2000 Received: from farley.cisco.com ([171.71.153.30]) by dusty; Thu Feb 24 03:52:31 EST 2000 Received: from tfu-NT1 (tfu-isdn1.cisco.com [171.70.204.66]) by farley.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id AAA01908; Thu, 24 Feb 2000 00:54:49 -0800 (PST) Message-Id: <4.2.0.58.20000224001730.00b46e00@farley.cisco.com> X-Sender: tfu@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 24 Feb 2000 00:58:03 -0800 To: Dean Willis From: Taichi Fu Subject: RE: SIP BCP-T question Cc: "Carr, Steve" , "'Raja Badri'" , sip ML In-Reply-To: <000f01bf7e4e$084a5020$ad9423a6@mcit.com> References: < <153BDA136259D311859900A0C99B5263027750@boca-isbu-nt04.boca.unisphere.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_3832580==_.ALT" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --=====================_3832580==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed From BCP-T: "This document only takes into account the call control functionality of ISUP. Maintenance messages are outside the scope of this document." Suppose that messages such as Circuit Reset may also be received during a call setup phase (to abort the setup), then should they also be mapped to such as BYE or CANCEL (by PSTN GW)? Thanks, -Taichi At 04:33 PM 2/23/00 -0600, Dean Willis wrote: >It seems that these might really be "no-op" operations rather than >"nonexistent" operations. > >There's a difference. > >-- >Dean > > > -----Original Message----- > > From: owner-sip@lists.research.bell-labs.com > > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Carr, Steve > > Sent: Monday, February 14, 2000 12:25 PM > > To: 'Raja Badri'; sip ML > > Subject: RE: SIP BCP-T question > > > > > > The ISUP maintenance messages relate to the physical trunk circuit, which > > when not being used on a call, is still physically present and in an IDLE > > (or blocked) state. SIP BCT-T sets up calls over an RTP "logical" > > connection, which is not a physical circuit. After the end of the > > call, the > > RTP connection ceases to exist. Therefore is does not make sense to block > > it, unblock it, reset it etc...... > > > > Steve Carr > > Unisphere Solutions Inc. > > Boca Raton > > scarr@unispheresolutions.com > > Office (561) 955-8288 > > Fax (561) 955-6477 > > > > www.unispheresolutions.com > > > > -----Original Message----- > > From: Raja Badri [mailto:raja.badri@santera.com] > > Sent: Monday, February 14, 2000 1:04 PM > > To: sip ML > > Subject: SIP BCP-T question > > > > > > Hi, > > > > I have one question regarding the SIP BCP-T. > > INFO message outlines the Mid-Call ISUP messages. > > What is the reason behind not including the ISUP maintenance > > messages like Block, Unblock and Reset ? > > > > Thanks, > > Raja Badri > > Santera Systems Inc. > > > > > > > > --=====================_3832580==_.ALT Content-Type: text/html; charset="us-ascii" From BCP-T:
   "This document only takes into account the call control
   functionality of ISUP. Maintenance messages are outside
   the scope of this document."

Suppose that messages such as Circuit Reset may also be received during a call setup
phase (to abort the setup), then should they also be mapped to such as BYE or CANCEL
(by PSTN GW)?

Thanks,
-Taichi


At 04:33 PM 2/23/00 -0600, Dean Willis wrote:
It seems that these might really be "no-op" operations rather than
"nonexistent" operations.

There's a difference.

--
Dean

> -----Original Message-----
> From: owner-sip@lists.research.bell-labs.com
> [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Carr, Steve
> Sent: Monday, February 14, 2000 12:25 PM
> To: 'Raja Badri'; sip ML
> Subject: RE: SIP BCP-T question
>
>
> The ISUP maintenance messages relate to the physical trunk circuit, which
> when not being used on a call, is still physically present and in an IDLE
> (or blocked) state. SIP BCT-T sets up calls over an RTP "logical"
> connection, which is not a physical circuit. After the end of the
> call, the
> RTP connection ceases to exist. Therefore is does not make sense to block
> it, unblock it, reset it etc......
>
> Steve Carr
> Unisphere Solutions Inc.
> Boca Raton
> scarr@unispheresolutions.com
> Office (561) 955-8288
> Fax    (561) 955-6477
>
> www.unispheresolutions.com
>
> -----Original Message-----
> From: Raja Badri [mailto:raja.badri@santera.com]
> Sent: Monday, February 14, 2000 1:04 PM
> To: sip ML
> Subject: SIP BCP-T question
>
>
> Hi,
>
> I have one question regarding the SIP BCP-T.
> INFO message outlines the Mid-Call ISUP messages.
> What is the reason behind not including the ISUP maintenance
> messages like Block, Unblock and Reset ?
>
> Thanks,
> Raja Badri
> Santera Systems Inc.
>
>
>


--=====================_3832580==_.ALT-- From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 24 09:44:06 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01243 for ; Thu, 24 Feb 2000 09:44:05 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 362F452EB; Thu, 24 Feb 2000 09:41:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A07AF52EC; Thu, 24 Feb 2000 09:41:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 3F34152EB for ; Thu, 24 Feb 2000 09:41:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Feb 24 09:39:48 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Thu Feb 24 09:37:24 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA01432 for ; Thu, 24 Feb 2000 09:39:56 -0500 (EST) Message-ID: <38B4E85B.5C43DA7C@dynamicsoft.com> Date: Thu, 24 Feb 2000 03:14:19 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Subject: INFO draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Folks, Note that an updated INFO draft has been submitted: http://www.ietf.org/internet-drafts/draft-ietf-sip-info-method-02.txt This incorporates comments received during working group last call. I believe this document is ready to be sent to IESG for proposed. I will do so Friday unless someone objects. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 24 09:50:03 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01427 for ; Thu, 24 Feb 2000 09:50:02 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 3316952EC; Thu, 24 Feb 2000 09:47:20 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8D02A52ED; Thu, 24 Feb 2000 09:47:19 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id A87EF52EC for ; Thu, 24 Feb 2000 09:47:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Feb 24 09:46:05 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Thu Feb 24 09:43:41 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id JAA18347; Thu, 24 Feb 2000 09:33:55 -0500 (EST) Message-ID: <38B54153.3A345711@cs.columbia.edu> Date: Thu, 24 Feb 2000 09:33:55 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Dean Willis , Michael Thomas , sip@lists.research.bell-labs.com Subject: Re: DHCP option tags for SIP References: <003101bf7e1f$007ad880$a6e123a6@mcit.com> <38B4E482.AA6F472F@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Dean Willis wrote: > > > > In actually doing this stuff, I can say that our experimental deployment > > model is that the phone registers with an "identity" value which is > > effectively unique to the phone. This "identity" is associated with users > > (domain addresses) and phone numbers in a profile schema (directory). We > > provide a web interface for managing the profile, or one can manipulate it > > with SIP registrations. This allows users to forward their phones, move > > them, clone them, sell them and buy new ones, etc. > > If I understand you right, the phone would have an ID, something like > sip:phone3736489@wcom.com. When plugged in, it automatically registers > this address, binding it to its current IP address. In addition, users > can go to a web page (or use a SIP registration), and basically create > another binding, mapping their name (sip:dean.willis@wcom.com) to the ID > of the phone (sip:3736489@wcom.com). Is that right? > > Neat idea... solves the problem that a standalone phone is not always > going to have an easy way for the user to enter their name that it > should use in a registration. It is basically adding another layer of > indirection: user->device->address, rather than just user->address. There's an equivalent way of doing this, namely using the hardware ID (aka MAC address). This also provides some level of authentication. One possible problem of having a "back-channel" registration mechanism is to make sure that the lifetimes of the registrations are lined up, so that my user registration goes away if the low-level device registration goes away. For that reason, I had suggested a configuration mapping where the phone obtains a list of identities based on its hardware ID and REGISTERs all of them. This also allows a web-based configuration mechanism, but doesn't require anything special on the SIP server. Either, I believe, can be made to work, depending on the assumptions as to what's changeable, what's fixed and what's easier to integrate. Beyond these details, I agree that we need to look at registration and configuration more closely. We had separately discussed the "hotel problem", for example. A related problem, discussed earlier, is the current problem of registrar crashes. In our local IP phone configuration, we have had the problem of registrars crashing and then having to wait an hour until all the registrations are back. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 24 10:20:04 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02361 for ; Thu, 24 Feb 2000 10:20:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A35AF52ED; Thu, 24 Feb 2000 10:17:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 26FA152EE; Thu, 24 Feb 2000 10:17:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 7E5E452ED for ; Thu, 24 Feb 2000 10:17:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 24 10:15:58 EST 2000 Received: from qhars001.nortel.com ([192.100.101.18]) by dusty; Thu Feb 24 10:13:34 EST 2000 Received: from zhard00m.europe.nortel.com (actually zhard00m) by qhars001.nortel.com; Thu, 24 Feb 2000 15:15:30 +0000 Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 24 Feb 2000 15:15:28 -0000 Message-ID: <61ABD11436FED21192440000F81F3E3603311899@nwcwi1a.europe.nortel.com> From: "Joshua Moloney" To: "'sip@lists.research.bell-labs.com'" Subject: Content-Encoding vs. Content-Transfer-Encoding Date: Thu, 24 Feb 2000 15:15:18 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF7ED9.FAEFFF7E" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk 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_01BF7ED9.FAEFFF7E Content-Type: text/plain Hi all, I have a question about the "Content-Encoding" entity header. Why is the MIME "Content-Transfer-Encoding" header defined in RFC 2045 not used instead? Am I correct in assuming that they do the same job? For example, what headers should I include on a message with an "application/ISUP" message body? :- Content-Type: application/ISUP Content-Transfer-Encoding: binary ..... OR Content-Type: application/ISUP Content-Encoding: binary ..... Thanks in advance, Josh Moloney Nortel Networks jmoloney@nortelnetworks.com ------_=_NextPart_001_01BF7ED9.FAEFFF7E Content-Type: text/html Content-Transfer-Encoding: quoted-printable Content-Encoding vs. Content-Transfer-Encoding

Hi all,

I have a question about the = "Content-Encoding" entity header.
Why is the MIME = "Content-Transfer-Encoding" header defined in RFC 2045 not = used instead?
Am I correct in assuming that they do = the same job?


For example, what headers should I = include on a message with an "application/ISUP" message body? = :-

Content-Type: application/ISUP
Content-Transfer-Encoding: = binary
.....

OR

Content-Type: application/ISUP
Content-Encoding: binary
.....

Thanks in advance,

Josh Moloney

Nortel = Networks
jmoloney@nortelnetworks.com


------_=_NextPart_001_01BF7ED9.FAEFFF7E-- From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 24 10:46:12 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03390 for ; Thu, 24 Feb 2000 10:46:11 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 231D452E8; Thu, 24 Feb 2000 10:43:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9003552EF; Thu, 24 Feb 2000 10:43:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id CCEB352E8 for ; Thu, 24 Feb 2000 10:43:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 24 10:42:33 EST 2000 Received: from PMESMTP02.wcom.com ([199.249.20.2]) by dusty; Thu Feb 24 10:40:09 EST 2000 Received: from omzrelay.mcit.com ([166.37.204.49]) by firewall.mcit.com (PMDF V5.2-32 #41713) with ESMTP id <0FQF0089NYAR7R@firewall.mcit.com> for sip@lists.research.bell-labs.com; Thu, 24 Feb 2000 15:42:27 +0000 (GMT) Received: from omta4.mcit.com (omta4.mcit.com [166.37.204.6]) by omzrelay.mcit.com (8.8.7/) with ESMTP id PAA20353; Thu, 24 Feb 2000 15:42:00 +0000 (GMT) Received: from dwillispc8 ([166.44.155.228]) by omta4.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000224154404.USXO755@dwillispc8>; Thu, 24 Feb 2000 15:44:04 +0000 Date: Thu, 24 Feb 2000 09:41:02 -0600 From: Dean Willis Subject: RE: DHCP option tags for SIP In-reply-to: <38B54153.3A345711@cs.columbia.edu> To: Henning Schulzrinne , Jonathan Rosenberg Cc: Michael Thomas , sip@lists.research.bell-labs.com Message-id: <003a01bf7edd$8dc17000$54fa403f@dwillispc8> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit We thought about this, but didn't like it much given the way that our experimental provisioning systems and UASes work. For example, my PC sip client has nine different MAC addresses depending on where I'm sitting. Much of the time it has two simultaneously, and sometimes it has three. Also, sometimes it is not the same physical device at all, but I want it to appear to be (identity sharing), so there might be multiple sets of nine different MAC addresses which are all "the same phone". Given that the device identity (in the proposal, a MAC address) really has to be distinctively inserted into the routing system, use of the MAC address in this environment could get really messy. We decided it was just easier to assign distinguished names to the devices, and put only the distniguished name into the routing system. Now, this might be very different in an environment where the UAS-of-choice is a hardware phone that is persistent in its association with a singular MAC address. I think Henning's approach has the potential to work quite well here. -- Dean > -----Original Message----- > From: hgs@cs.columbia.edu [mailto:hgs@cs.columbia.edu]On Behalf Of > Henning Schulzrinne > Sent: Thursday, February 24, 2000 8:34 AM > To: Jonathan Rosenberg > Cc: Dean Willis; Michael Thomas; sip@lists.research.bell-labs.com > Subject: Re: DHCP option tags for SIP > > > Jonathan Rosenberg wrote: > > > > Dean Willis wrote: > > > > > > In actually doing this stuff, I can say that our experimental > deployment > > > model is that the phone registers with an "identity" value which is > > > effectively unique to the phone. This "identity" is > associated with users > > > (domain addresses) and phone numbers in a profile schema > (directory). We > > > provide a web interface for managing the profile, or one can > manipulate it > > > with SIP registrations. This allows users to forward their > phones, move > > > them, clone them, sell them and buy new ones, etc. > > > > If I understand you right, the phone would have an ID, something like > > sip:phone3736489@wcom.com. When plugged in, it automatically registers > > this address, binding it to its current IP address. In addition, users > > can go to a web page (or use a SIP registration), and basically create > > another binding, mapping their name (sip:dean.willis@wcom.com) to the ID > > of the phone (sip:3736489@wcom.com). Is that right? > > > > Neat idea... solves the problem that a standalone phone is not always > > going to have an easy way for the user to enter their name that it > > should use in a registration. It is basically adding another layer of > > indirection: user->device->address, rather than just user->address. > > There's an equivalent way of doing this, namely using the hardware ID > (aka MAC address). This also provides some level of authentication. One > possible problem of having a "back-channel" registration mechanism is to > make sure that the lifetimes of the registrations are lined up, so that > my user registration goes away if the low-level device registration goes > away. For that reason, I had suggested a configuration mapping where the > phone obtains a list of identities based on its hardware ID and > REGISTERs all of them. This also allows a web-based configuration > mechanism, but doesn't require anything special on the SIP server. > > Either, I believe, can be made to work, depending on the assumptions as > to what's changeable, what's fixed and what's easier to integrate. > > Beyond these details, I agree that we need to look at registration and > configuration more closely. We had separately discussed the "hotel > problem", for example. > > A related problem, discussed earlier, is the current problem of > registrar crashes. In our local IP phone configuration, we have had the > problem of registrars crashing and then having to wait an hour until all > the registrations are back. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 24 10:57:51 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03724 for ; Thu, 24 Feb 2000 10:57:51 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id D3D1C52EF; Thu, 24 Feb 2000 10:55:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 475CA52F0; Thu, 24 Feb 2000 10:55:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 26E3452EF for ; Thu, 24 Feb 2000 10:55:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 24 10:54:04 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Thu Feb 24 10:51:40 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id KAA25589; Thu, 24 Feb 2000 10:54:00 -0500 (EST) Message-ID: <38B55418.862660EF@cs.columbia.edu> Date: Thu, 24 Feb 2000 10:54:00 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis Cc: sip@lists.research.bell-labs.com Subject: Re: DHCP option tags for SIP References: <003a01bf7edd$8dc17000$54fa403f@dwillispc8> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Dean Willis wrote: > > We thought about this, but didn't like it much given the way that our > experimental provisioning systems and UASes work. For example, my PC sip > client has nine different MAC addresses depending on where I'm sitting. Much > of the time it has two simultaneously, and sometimes it has three. Also, > sometimes it is not the same physical device at all, but I want it to appear > to be (identity sharing), so there might be multiple sets of nine different > MAC addresses which are all "the same phone". > > Given that the device identity (in the proposal, a MAC address) really has > to be distinctively inserted into the routing system, use of the MAC address > in this environment could get really messy. > > We decided it was just easier to assign distinguished names to the devices, > and put only the distniguished name into the routing system. > > Now, this might be very different in an environment where the UAS-of-choice > is a hardware phone that is persistent in its association with a singular > MAC address. I think Henning's approach has the potential to work quite well > here. > I agree that PCs and hardware phones have very different configuration requirements. PCs typically already have all kinds of identifiers available to them (CPU identifiers, GUIDs, OS license numbers, software license numbers, user names, host names, etc.) and users can easily create new ones via simple GUIs. On a hardware phone, installing a few hundred phones and having the installer (or, worse, the phone's user) key in some unique identifier for each is not very attractive. Having a bar code on the bottom of the phone, reflecting its MAC address or, if such a thing were available, some other globally unique identifier, is a lot easier to manage. Columbia hands out hundreds of phones each year to incoming freshmen, for example. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 24 11:17:56 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04555 for ; Thu, 24 Feb 2000 11:17:55 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4F52252F0; Thu, 24 Feb 2000 11:15:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id B6D0952F1; Thu, 24 Feb 2000 11:15:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id CD46C52F0 for ; Thu, 24 Feb 2000 11:15:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 24 11:14:05 EST 2000 Received: from penguin.wise.edt.ericsson.se ([194.237.142.110]) by dusty; Thu Feb 24 11:11:40 EST 2000 Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id RAA04468; Thu, 24 Feb 2000 17:13:57 +0100 (MET) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.75.22]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id SAA24117; Thu, 24 Feb 2000 18:13:56 +0200 (EET) Message-ID: <38B558C9.373770DE@lmf.ericsson.se> Date: Thu, 24 Feb 2000 18:14:01 +0200 From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: tfu@cisco.com Cc: sip Subject: Re: SIP BCP-T question References: <4.2.0.58.20000224001730.00b46e00@farley.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I am afraid you are talking about another draft. Your quote is from: http://www.ietf.org/internet-drafts/draft-camarillo-mmusic-sip-isup-bcp-00.txt This thread deals with another draft: http://www.ietf.org/internet-drafts/draft-zimmerer-sip-bcp-t-00.txt If you have any comments on the first draft just let me know because a new version is about to be released. Best regards, Gonzalo tfu@cisco.com wrote: > > From BCP-T: > "This document only takes into account the call control > functionality of ISUP. Maintenance messages are outside > the scope of this document." > > Suppose that messages such as Circuit Reset may also be received > during a > call setup > phase (to abort the setup), then should they also be mapped to such as > BYE > or CANCEL > (by PSTN GW)? > > Thanks, > -Taichi > > At 04:33 PM 2/23/00 -0600, Dean Willis wrote: > >It seems that these might really be "no-op" operations rather than > >"nonexistent" operations. > > > >There's a difference. > > > >-- > >Dean > > > > > -----Original Message----- > > > From: owner-sip@lists.research.bell-labs.com > > > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Carr, > Steve > > > Sent: Monday, February 14, 2000 12:25 PM > > > To: 'Raja Badri'; sip ML > > > Subject: RE: SIP BCP-T question > > > > > > > > > The ISUP maintenance messages relate to the physical trunk > circuit, which > > > when not being used on a call, is still physically present and in > an IDLE > > > (or blocked) state. SIP BCT-T sets up calls over an RTP "logical" > > > connection, which is not a physical circuit. After the end of the > > > call, the > > > RTP connection ceases to exist. Therefore is does not make sense > to block > > > it, unblock it, reset it etc...... > > > > > > Steve Carr > > > Unisphere Solutions Inc. > > > Boca Raton > > > scarr@unispheresolutions.com > > > Office (561) 955-8288 > > > Fax (561) 955-6477 > > > > > > www.unispheresolutions.com > > > > > > -----Original Message----- > > > From: Raja Badri [mailto:raja.badri@santera.com] > > > Sent: Monday, February 14, 2000 1:04 PM > > > To: sip ML > > > Subject: SIP BCP-T question > > > > > > > > > Hi, > > > > > > I have one question regarding the SIP BCP-T. > > > INFO message outlines the Mid-Call ISUP messages. > > > What is the reason behind not including the ISUP maintenance > > > messages like Block, Unblock and Reset ? > > > > > > Thanks, > > > Raja Badri > > > Santera Systems Inc. > > > > > > > > > > > > > > > --------------------------------------------------------------- > From BCP-T: > "This document only takes into account the call control > functionality of ISUP. Maintenance messages are outside > the scope of this document." > > Suppose that messages such as Circuit Reset may also be received > during a call setup > phase (to abort the setup), then should they also be mapped to such as > BYE or CANCEL > (by PSTN GW)? > > Thanks, > -Taichi > > At 04:33 PM 2/23/00 -0600, Dean Willis wrote: > > > It seems that these might really be "no-op" operations rather than > > "nonexistent" operations. > > > > There's a difference. > > > > -- > > Dean > > > > > -----Original Message----- > > > From: owner-sip@lists.research.bell-labs.com > > > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Carr, > > Steve > > > Sent: Monday, February 14, 2000 12:25 PM > > > To: 'Raja Badri'; sip ML > > > Subject: RE: SIP BCP-T question > > > > > > > > > The ISUP maintenance messages relate to the physical trunk > > circuit, which > > > when not being used on a call, is still physically present and in > > an IDLE > > > (or blocked) state. SIP BCT-T sets up calls over an RTP "logical" > > > connection, which is not a physical circuit. After the end of the > > > call, the > > > RTP connection ceases to exist. Therefore is does not make sense > > to block > > > it, unblock it, reset it etc...... > > > > > > Steve Carr > > > Unisphere Solutions Inc. > > > Boca Raton > > > scarr@unispheresolutions.com > > > Office (561) 955-8288 > > > Fax (561) 955-6477 > > > > > > www.unispheresolutions.com > > > > > > -----Original Message----- > > > From: Raja Badri [mailto:raja.badri@santera.com] > > > Sent: Monday, February 14, 2000 1:04 PM > > > To: sip ML > > > Subject: SIP BCP-T question > > > > > > > > > Hi, > > > > > > I have one question regarding the SIP BCP-T. > > > INFO message outlines the Mid-Call ISUP messages. > > > What is the reason behind not including the ISUP maintenance > > > messages like Block, Unblock and Reset ? > > > > > > Thanks, > > > Raja Badri > > > Santera Systems Inc. > > > > > > > > > > > > > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 24 11:48:02 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05455 for ; Thu, 24 Feb 2000 11:48:01 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id AC74352EE; Thu, 24 Feb 2000 11:45:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1FE3752F2; Thu, 24 Feb 2000 11:45:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 94FFF52EE for ; Thu, 24 Feb 2000 11:45:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 24 11:44:29 EST 2000 Received: from mercury.Sun.COM ([192.9.25.1]) by dusty; Thu Feb 24 11:42:04 EST 2000 Received: from engmail3.Eng.Sun.COM ([129.144.170.5]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA11597; Thu, 24 Feb 2000 08:44:12 -0800 (PST) Received: from nasnfs.eng.sun.com (nasnfs.Eng.Sun.COM [129.146.122.19]) by engmail3.Eng.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id IAA12610; Thu, 24 Feb 2000 08:44:12 -0800 (PST) Received: from suntana (suntana [129.146.122.88]) by nasnfs.eng.sun.com (8.9.3+Sun/8.9.1) with SMTP id IAA09737; Thu, 24 Feb 2000 08:44:11 -0800 (PST) Message-Id: <200002241644.IAA09737@nasnfs.eng.sun.com> Date: Thu, 24 Feb 2000 08:45:31 -0800 (PST) From: James Kempf Reply-To: James Kempf Subject: Re: DHCP option tags for SIP To: dean.willis@wcom.com, jdrosen@dynamicsoft.com Cc: schulzrinne@cs.columbia.edu, mat@cisco.com, sip@lists.research.bell-labs.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: E+rpaZRH72jkYiUsQ/4rlA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.2 SunOS 5.7 sun4u sparc Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk >If I understand you right, the phone would have an ID, something like >sip:phone3736489@wcom.com. When plugged in, it automatically registers >this address, binding it to its current IP address. In addition, users >can go to a web page (or use a SIP registration), and basically create >another binding, mapping their name (sip:dean.willis@wcom.com) to the ID >of the phone (sip:3736489@wcom.com). Is that right? > >Neat idea... solves the problem that a standalone phone is not always >going to have an easy way for the user to enter their name that it >should use in a registration. It is basically adding another layer of >indirection: user->device->address, rather than just user->address. Cellular phones already have such an address (they are required by the FCC to do so). It's called the Electronic Serial Number(ESN) and is used in the authentication algorithms. jak From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 24 11:59:59 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05707 for ; Thu, 24 Feb 2000 11:59:58 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 6056A52F2; Thu, 24 Feb 2000 11:57:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id CD50E52F3; Thu, 24 Feb 2000 11:57:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id F13CA52F2 for ; Thu, 24 Feb 2000 11:57:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 24 11:55:42 EST 2000 Received: from farley.cisco.com ([171.71.153.30]) by dusty; Thu Feb 24 11:53:18 EST 2000 Received: from tfu-NT1 (tfu-isdn1.cisco.com [171.70.204.66]) by farley.cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id IAA29668; Thu, 24 Feb 2000 08:55:06 -0800 (PST) Message-Id: <4.2.0.58.20000224083509.00b4c610@farley.cisco.com> X-Sender: tfu@farley.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 24 Feb 2000 08:56:14 -0800 To: Gonzalo Camarillo From: Taichi Fu Subject: SIP ISUP BCP-00 question(was: Re: SIP BCP-T question) Cc: sip In-Reply-To: <38B558C9.373770DE@lmf.ericsson.se> References: <4.2.0.58.20000224001730.00b46e00@farley.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Gonzalo, Thanks for your clarification. My question is more on your draft. I think those maintenance messages need also to be covered. Execuse me if you already have them in the coming version. Best regards, -Taichi At 06:14 PM 2/24/00 +0200, Gonzalo Camarillo wrote: >Hi, > >I am afraid you are talking about another draft. > >Your quote is from: >http://www.ietf.org/internet-drafts/draft-camarillo-mmusic-sip-isup-bcp-00.txt > >This thread deals with another draft: >http://www.ietf.org/internet-drafts/draft-zimmerer-sip-bcp-t-00.txt > >If you have any comments on the first draft just let me know because a >new version is about to be released. > >Best regards, > >Gonzalo > >tfu@cisco.com wrote: > > > > From BCP-T: > > "This document only takes into account the call control > > functionality of ISUP. Maintenance messages are outside > > the scope of this document." > > > > Suppose that messages such as Circuit Reset may also be received > > during a > > call setup > > phase (to abort the setup), then should they also be mapped to such as > > BYE > > or CANCEL > > (by PSTN GW)? > > > > Thanks, > > -Taichi > > > > At 04:33 PM 2/23/00 -0600, Dean Willis wrote: > > >It seems that these might really be "no-op" operations rather than > > >"nonexistent" operations. > > > > > >There's a difference. > > > > > >-- > > >Dean > > > > > > > -----Original Message----- > > > > From: owner-sip@lists.research.bell-labs.com > > > > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Carr, > > Steve > > > > Sent: Monday, February 14, 2000 12:25 PM > > > > To: 'Raja Badri'; sip ML > > > > Subject: RE: SIP BCP-T question > > > > > > > > > > > > The ISUP maintenance messages relate to the physical trunk > > circuit, which > > > > when not being used on a call, is still physically present and in > > an IDLE > > > > (or blocked) state. SIP BCT-T sets up calls over an RTP "logical" > > > > connection, which is not a physical circuit. After the end of the > > > > call, the > > > > RTP connection ceases to exist. Therefore is does not make sense > > to block > > > > it, unblock it, reset it etc...... > > > > > > > > Steve Carr > > > > Unisphere Solutions Inc. > > > > Boca Raton > > > > scarr@unispheresolutions.com > > > > Office (561) 955-8288 > > > > Fax (561) 955-6477 > > > > > > > > www.unispheresolutions.com > > > > > > > > -----Original Message----- > > > > From: Raja Badri [mailto:raja.badri@santera.com] > > > > Sent: Monday, February 14, 2000 1:04 PM > > > > To: sip ML > > > > Subject: SIP BCP-T question > > > > > > > > > > > > Hi, > > > > > > > > I have one question regarding the SIP BCP-T. > > > > INFO message outlines the Mid-Call ISUP messages. > > > > What is the reason behind not including the ISUP maintenance > > > > messages like Block, Unblock and Reset ? > > > > > > > > Thanks, > > > > Raja Badri > > > > Santera Systems Inc. > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------- > > From BCP-T: > > "This document only takes into account the call control > > functionality of ISUP. Maintenance messages are outside > > the scope of this document." > > > > Suppose that messages such as Circuit Reset may also be received > > during a call setup > > phase (to abort the setup), then should they also be mapped to such as > > BYE or CANCEL > > (by PSTN GW)? > > > > Thanks, > > -Taichi > > > > At 04:33 PM 2/23/00 -0600, Dean Willis wrote: > > > > > It seems that these might really be "no-op" operations rather than > > > "nonexistent" operations. > > > > > > There's a difference. > > > > > > -- > > > Dean > > > > > > > -----Original Message----- > > > > From: owner-sip@lists.research.bell-labs.com > > > > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Carr, > > > Steve > > > > Sent: Monday, February 14, 2000 12:25 PM > > > > To: 'Raja Badri'; sip ML > > > > Subject: RE: SIP BCP-T question > > > > > > > > > > > > The ISUP maintenance messages relate to the physical trunk > > > circuit, which > > > > when not being used on a call, is still physically present and in > > > an IDLE > > > > (or blocked) state. SIP BCT-T sets up calls over an RTP "logical" > > > > connection, which is not a physical circuit. After the end of the > > > > call, the > > > > RTP connection ceases to exist. Therefore is does not make sense > > > to block > > > > it, unblock it, reset it etc...... > > > > > > > > Steve Carr > > > > Unisphere Solutions Inc. > > > > Boca Raton > > > > scarr@unispheresolutions.com > > > > Office (561) 955-8288 > > > > Fax (561) 955-6477 > > > > > > > > www.unispheresolutions.com > > > > > > > > -----Original Message----- > > > > From: Raja Badri [mailto:raja.badri@santera.com] > > > > Sent: Monday, February 14, 2000 1:04 PM > > > > To: sip ML > > > > Subject: SIP BCP-T question > > > > > > > > > > > > Hi, > > > > > > > > I have one question regarding the SIP BCP-T. > > > > INFO message outlines the Mid-Call ISUP messages. > > > > What is the reason behind not including the ISUP maintenance > > > > messages like Block, Unblock and Reset ? > > > > > > > > Thanks, > > > > Raja Badri > > > > Santera Systems Inc. > > > > > > > > > > > > > > > > > > > >-- >Gonzalo Camarillo Phone : +358 9 299 33 71 >Oy L M Ericsson Ab Mobile: +358 40 702 35 35 >Telecom R&D Fax : +358 9 299 30 52 >FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com >Finland > From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 24 12:23:57 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06442 for ; Thu, 24 Feb 2000 12:23:56 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A3FA052F3; Thu, 24 Feb 2000 12:21:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C278952F4; Thu, 24 Feb 2000 12:21:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id C53BB52F3 for ; Thu, 24 Feb 2000 12:21:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 24 12:20:02 EST 2000 Received: from fb01.eng00.mindspring.net ([207.69.229.19]) by dusty; Thu Feb 24 12:17:38 EST 2000 Received: from laptop (pool-209-138-153-244-ipls.grid.net [209.138.153.244]) by fb01.eng00.mindspring.net (8.9.3/8.8.5) with ESMTP id MAA02295; Thu, 24 Feb 2000 12:16:38 -0500 (EST) Message-Id: <4.2.0.58.20000224100138.00a7ce50@127.0.0.1> X-Sender: rshockey/popd.ix.netcom.com@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 24 Feb 2000 10:04:39 -0600 To: Dean Willis From: Richard Shockey Subject: RE: DHCP option tags for SIP Cc: Michael Thomas , sip@lists.research.bell-labs.com In-Reply-To: <003a01bf7edd$8dc17000$54fa403f@dwillispc8> References: <38B54153.3A345711@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk At 09:41 AM 2/24/2000 -0600, Dean Willis wrote: >We thought about this, but didn't like it much given the way that our >experimental provisioning systems and UASes work. For example, my PC sip >client has nine different MAC addresses depending on where I'm sitting. Much >of the time it has two simultaneously, and sometimes it has three. Also, >sometimes it is not the same physical device at all, but I want it to appear >to be (identity sharing), so there might be multiple sets of nine different >MAC addresses which are all "the same phone". > >Given that the device identity (in the proposal, a MAC address) really has >to be distinctively inserted into the routing system, use of the MAC address >in this environment could get really messy. I agree. >We decided it was just easier to assign distinguished names to the devices, >and put only the distniguished name into the routing system. I certainly think the distinguished name makes more sense in this environment. It also may be more useful in mobile environments. Actually some of this looks like a "cell phone" network at a sufficient level of abstraction. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Richard Shockey Shockey Consulting LLC 8045 Big Bend Blvd. Suite 110 St. Louis, MO 63119 Voice 314.918.9020 eFAX Fax to EMail 815.333.1237 (Preferred for Fax) INTERNET Mail & IFAX : rshockey@ix.netcom.com GSTN Fax 314.918.9015 MediaGate iPost VoiceMail and Fax 800.260.4464 <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 24 13:17:58 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07818 for ; Thu, 24 Feb 2000 13:17:55 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 590CA52F1; Thu, 24 Feb 2000 13:15:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C63F452F5; Thu, 24 Feb 2000 13:15:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id CF00452F1 for ; Thu, 24 Feb 2000 13:15:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Feb 24 13:13:04 EST 2000 Received: from palrel1.hp.com ([156.153.255.242]) by dusty; Thu Feb 24 13:10:40 EST 2000 Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by palrel1.hp.com (Postfix) with ESMTP id 75AF85F9; Thu, 24 Feb 2000 10:13:00 -0800 (PST) Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238]) by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id SAA20844; Thu, 24 Feb 2000 18:12:59 GMT Message-ID: <38B574B5.50448657@hplb.hpl.hp.com> Date: Thu, 24 Feb 2000 18:13:09 +0000 From: Anders Kristensen Organization: HP Labs X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Robert.Sparks@wcom.com, "'SIP List' (E-mail)" , "Henning Schulzrinne (E-mail)" Subject: Re: UAC use of tags received in responses References: <003201bf73dd$40e24300$8a9223a6@mcit.com> <38A33790.5A052AC6@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > I would further clarify this: > > A UAC copies the tag from the response into the ACK, but it MUST > NOT > copy the tag into any subsequent requests unless the response was > a 200 class response to an INVITE. I'm not sure it's a problem, but this can give rise to curious situations when the the non-2xx final response was generated by a UAS. In this case the UAS has inserted a To tag and hence believes the call consists of a single leg, whose UAS identifier (the To of the original request) has a tag. The UAC ACKs the response (ACK includes To tag) and resubmits the request *without* To tag. This basically constitutes initiating a new transaction in a new leg. Now I'm not sure if it's well-specified whether the UAS will associate that new request with the existing leg (which has a To tag). I think this would (or should) be the correct behaviour, as it really is the same leg, but I would imagine that different implementations might differ on this point. The consequence is that the second response (say a 2xx) may be returned with the *original* To tag. So now we have a UAC which basically knows of two legs: the original *with* a To tag and a new one without. It then receives a response whose To, From pair would seem to indicate that it belongs to the original leg, but which really belongs to the second - the one that knows of the transaction... This all seems a bit fishy, no? Maybe it should be clarified whether the UAS should respond to the second request with the old or a new To tag, and whether the UAC is supposed to think of the two requests as belonging to different legs? Anders -- Anders Kristensen , http://www-uk.hpl.hp.com/people/ak/ Hewlett-Packard Labs, Bristol, UK From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 24 13:52:19 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08452 for ; Thu, 24 Feb 2000 13:52:18 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4520352F4; Thu, 24 Feb 2000 13:49:39 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A72DE52F7; Thu, 24 Feb 2000 13:49:38 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id EF2C352F4 for ; Thu, 24 Feb 2000 13:49:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 24 13:48:40 EST 2000 Received: from ariel.gi.com ([168.84.84.10]) by dusty; Thu Feb 24 13:46:16 EST 2000 Received: from ntas0028.gi.com ([168.84.84.98]) by GI.COM (PMDF V5.2-31 #38811) with ESMTP id <01JMA79T1HLQCKIO5S@GI.COM> for sip@lists.research.bell-labs.com; Thu, 24 Feb 2000 10:48:35 PST Received: by ntas0028.gi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 24 Feb 2000 10:51:42 -0500 Content-return: allowed Date: Thu, 24 Feb 2000 13:49:23 -0500 From: "Lalwaney, Poornima (SD-EX)" Subject: RE: Cross-domain QoS setup To: "'Jonathan Rosenberg'" , "Adam B. Roach" , "'mat@cisco.com'" Cc: hgs@cs.columbia.edu, Steven.R.Donovan@wcom.com, sip@lists.research.bell-labs.com Message-id: <97DEDE66B3DCD11199D200805FA71BE2021D6106@ntas0027.gi.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: multipart/alternative; boundary="----_=_NextPart_001_01BF7EDF.0AA0D042" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk 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_01BF7EDF.0AA0D042 Content-Type: text/plain; charset="iso-8859-1" If the SDP in a SIP INVITE can carry "pre-conditions" to call setup, it seems very reasonable to me that a subsequent provisional response and/or its acknowledgement be allowed to carry an indication in the SDP that the requested "pre-condition" has been satisfied/not satisfied. Cross domain QOS is an example where such functionality MAY be needed if RSVP is not used for end to end reservation. Rather than talk about the best cross-domain QOS mechanism (to which there is no proven correct answer), lets focus on the SIP signaling issue: Can the SDP in a SIP provisional response/PRACK/info message sent prior to the final 200OK indicate that the precondition specified in an INVITE has been satisfied? If the answer is yes, one of the ways to indicate this is through additional attributes to the pre-condition strength field in the sdp pre-conditions draft. Thanks.. Poornima --------------------------------------- Poornima Lalwaney Motorola 858-404-3494 --------------------------------------- > -----Original Message----- > From: Jonathan Rosenberg [SMTP:jdrosen@dynamicsoft.com] > Sent: Tuesday, February 22, 2000 3:01 PM > To: Adam B. Roach > Cc: hgs@cs.columbia.edu; Steven.R.Donovan@wcom.com; > sip@lists.research.bell-labs.com > Subject: Re: Cross-domain QoS setup > > > > "Adam B. Roach" wrote: > > The current draft makes an assumption that end-to-end network > > resource reservation is controlled by a single entity. For calls > > being placed across adminstrative domains, however, this will > > not be the case. Under such circumstances, the reservation of > > resources needs a greater degree of coordination than is > > currently provided in the draft. > > Not really. Resource reservation is under the "control" of all the > network elements along the path that perform some kind of admission > control and resource allocation. These elements will often belong to > different administrative domains. The draft makes no assumptions about > the number of providers along the reservation path, or anything like > that. It only ties resource reservation and signaling together at the > endpoints, dicatating a particular temporal sequence. > > > > > In particular, the calling user agent needs the ability to > > communicate to the called user agent that it has reserved > > the necessary resources on its end, and that alerting may > > begin as soon as the called user agent has done the same. > > This is something different from what you are discussing above. It is, > in fact, covered in the draft. If A calls B, the RSVP RESV message from > A to B confirms resources are reserved from A to B, and the RESVCONF > from A to B confirms resource reservation from B to A. This allows B to > know whether resources are reserved in both directions. A mirror case > exists for A. > > The difficulty arises only with the segmented DQoS model in DCS, which > does not provide a way to confirm resource reservation (I think), > whereas RSVP does. > > So, the question is this. We know we need a way for both parties to know > when resources are reserved in both directions. Is this a function that > belongs somewhere in SIP (through INFO, as you propose, or some other > means), or in a reservation protocol. The mechanism exists already now > in RSVP, but not in DQoS (DCS folks, please correct me if I am > mistaken). So, do we add it to SIP, in which case its not needed for > RSVP, or should it be added to DQoS, in which case the SIP operation is > independent of the underlying reservation mechanism? > > I have argued that confirmation of resource reservation is rightly a job > for a resource reservation protocol. One of the things I like about SIP > is its separation from session level control and network layer issues, > such as resource reservation. > > -Jonathan R. > > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com ------_=_NextPart_001_01BF7EDF.0AA0D042 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Cross-domain QoS setup

If the SDP in a SIP = INVITE can carry "pre-conditions" to call setup, it seems = very reasonable to me that a subsequent provisional response and/or its = acknowledgement  be allowed to carry an indication in the SDP that = the requested "pre-condition" has been satisfied/not = satisfied.

Cross domain = QOS  is an example where such functionality MAY be needed if RSVP = is not used for end to end reservation.
Rather than talk = about the best cross-domain QOS mechanism (to which there is no proven = correct answer), lets focus on the SIP signaling issue:  Can the = SDP in a SIP provisional response/PRACK/info message sent prior to the = final 200OK indicate that the precondition specified in an INVITE has = been satisfied?

If the answer is = yes, one of  the ways to indicate this is through additional = attributes to the pre-condition strength field in the sdp = pre-conditions draft.



    Thanks..
    Poornima



    ---------------------------------------
    Poornima = Lalwaney
    Motorola
    858-404-3494
    ---------------------------------------
    -----Original Message-----
    From:   Jonathan Rosenberg = [SMTP:jdrosen@dynamicsoft.com]
    Sent:   Tuesday, February 22, 2000 3:01 PM
    To:     Adam B. Roach
    Cc:     hgs@cs.columbia.edu; Steven.R.Donovan@wcom.com; = sip@lists.research.bell-labs.com
    Subject:       = Re: Cross-domain QoS setup



    "Adam B. Roach" = wrote:
    > The current draft makes an = assumption that end-to-end network
    > resource reservation is = controlled by a single entity. For calls
    > being placed across = adminstrative domains, however, this will
    > not be the case. Under such = circumstances, the reservation of
    > resources needs a greater degree = of coordination than is
    > currently provided in the = draft.

    Not really. Resource reservation is = under the "control" of all the
    network elements along the path that = perform some kind of admission
    control and resource allocation. = These elements will often belong to
    different administrative domains. The = draft makes no assumptions about
    the number of providers along the = reservation path, or anything like
    that. It only ties resource = reservation and signaling together at the
    endpoints, dicatating a particular = temporal sequence.

    >
    > In particular, the calling user = agent needs the ability to
    > communicate to the called user = agent that it has reserved
    > the necessary resources on its = end, and that alerting may
    > begin as soon as the called user = agent has done the same.

    This is something different from what = you are discussing above. It is,
    in fact, covered in the draft. If A = calls B, the RSVP RESV message from
    A to B confirms resources are = reserved from A to B, and the RESVCONF
    from A to B confirms resource = reservation from B to A. This allows B to
    know whether resources are reserved = in both directions. A mirror case
    exists for A.

    The difficulty arises only with the = segmented DQoS model in DCS, which
    does not provide a way to confirm = resource reservation (I think),
    whereas RSVP does.

    So, the question is this. We know we = need a way for both parties to know
    when resources are reserved in both = directions. Is this a function that
    belongs somewhere in SIP (through = INFO, as you propose, or some other
    means), or in a reservation protocol. = The mechanism exists already now
    in RSVP, but not in DQoS (DCS folks, = please correct me if I am
    mistaken). So, do we add it to SIP, = in which case its not needed for
    RSVP, or should it be added to DQoS, = in which case the SIP operation is
    independent of the underlying = reservation mechanism?

    I have argued that confirmation of = resource reservation is rightly a job
    for a resource reservation protocol. = One of the things I like about SIP
    is its separation from session level = control and network layer issues,
    such as resource reservation.

    -Jonathan R.

    --
    Jonathan D. = Rosenberg          &nb= sp;            = 200 Executive Drive
    Chief = Scientist          &nb= sp;           &nb= sp;      Suite 120
    dynamicsoft       &nbs= p;           &nbs= p;           &nbs= p; West Orange, NJ 07052
    jdrosen@dynamicsoft.com     &nbs= p;           &nbs= p;   FAX:   (732) 741-4778
    http://www.cs.columbia.edu/~jdrosen         PHONE: = (732) 741-7244
    http://www.dynamicsoft.com

------_=_NextPart_001_01BF7EDF.0AA0D042-- From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 24 15:25:59 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09741 for ; Thu, 24 Feb 2000 15:25:56 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 1ACE052F5; Thu, 24 Feb 2000 15:23:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8524B52F7; Thu, 24 Feb 2000 15:23:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 0D9F552F5 for ; Thu, 24 Feb 2000 15:23:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Thu Feb 24 15:21:47 EST 2000 Received: from PMESMTP01.wcom.com ([199.249.20.1]) by dusty; Thu Feb 24 15:19:20 EST 2000 Received: from ndcrelay2.mcit.com ([166.37.172.6]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FQG00E42B7I3A@firewall.mcit.com> for sip@lists.research.bell-labs.com; Thu, 24 Feb 2000 20:21:18 +0000 (GMT) Received: from omta4.mcit.com (omta4.mcit.com [166.37.204.6]) by ndcrelay2.mcit.com (8.8.7/) with ESMTP id UAA29394 for ; Thu, 24 Feb 2000 20:21:53 +0000 (GMT) Received: from dwillispc8 ([166.35.225.166]) by omta4.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000224202322.XHLV755@dwillispc8> for ; Thu, 24 Feb 2000 20:23:22 +0000 Date: Thu, 24 Feb 2000 14:20:21 -0600 From: Dean Willis Subject: SIP BCP-T Current Drafts (was RE: SIP BCP-T question) In-reply-to: <38B558C9.373770DE@lmf.ericsson.se> To: sip Message-id: <000e01bf7f04$932f2380$a6e123a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit I've heard many implementors continuing to reference the old BCP draft and claiming to "Support SIP-T". I'd like to make two points: 1) As Gonzalo points out, the draft draft-zimmerer-mmusic-sip-bcp-t-00.txt is quite obsolete. I believe draft-camarillo-mmusic-sip-isup-bcp-00.txt is too, as is draft-ietf-mmusic-sip-isup-mime-00.txt The current drafts are draft-zimmerer-sip-bcp-t-00.txt and draft-ietf-sip-isup-mime-00.txt. I think these combine most of the previous work in this area. 2) This is a "work in progress", NOT a standard. It's not even a proposed standard. I bet its going to change a little more before it makes it to proposed standard (don't they all?). Implementors should plan on making changes as the work matures. -- Dean Willis SIP WG co-chair > -----Original Message----- > From: owner-sip@lists.research.bell-labs.com > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Gonzalo > Camarillo > Sent: Thursday, February 24, 2000 10:14 AM > To: tfu@cisco.com > Cc: sip > Subject: Re: SIP BCP-T question > > > Hi, > > I am afraid you are talking about another draft. > > Your quote is from: > http://www.ietf.org/internet-drafts/draft-camarillo-mmusic-sip-isu > p-bcp-00.txt > > This thread deals with another draft: > http://www.ietf.org/internet-drafts/draft-zimmerer-sip-bcp-t-00.txt > > If you have any comments on the first draft just let me know because a > new version is about to be released. > > Best regards, > > Gonzalo > > tfu@cisco.com wrote: > > > > From BCP-T: > > "This document only takes into account the call control > > functionality of ISUP. Maintenance messages are outside > > the scope of this document." > > > > Suppose that messages such as Circuit Reset may also be received > > during a > > call setup > > phase (to abort the setup), then should they also be mapped to such as > > BYE > > or CANCEL > > (by PSTN GW)? > > > > Thanks, > > -Taichi > > > > At 04:33 PM 2/23/00 -0600, Dean Willis wrote: > > >It seems that these might really be "no-op" operations rather than > > >"nonexistent" operations. > > > > > >There's a difference. > > > > > >-- > > >Dean > > > > > > > -----Original Message----- > > > > From: owner-sip@lists.research.bell-labs.com > > > > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Carr, > > Steve > > > > Sent: Monday, February 14, 2000 12:25 PM > > > > To: 'Raja Badri'; sip ML > > > > Subject: RE: SIP BCP-T question > > > > > > > > > > > > The ISUP maintenance messages relate to the physical trunk > > circuit, which > > > > when not being used on a call, is still physically present and in > > an IDLE > > > > (or blocked) state. SIP BCT-T sets up calls over an RTP "logical" > > > > connection, which is not a physical circuit. After the end of the > > > > call, the > > > > RTP connection ceases to exist. Therefore is does not make sense > > to block > > > > it, unblock it, reset it etc...... > > > > > > > > Steve Carr > > > > Unisphere Solutions Inc. > > > > Boca Raton > > > > scarr@unispheresolutions.com > > > > Office (561) 955-8288 > > > > Fax (561) 955-6477 > > > > > > > > www.unispheresolutions.com > > > > > > > > -----Original Message----- > > > > From: Raja Badri [mailto:raja.badri@santera.com] > > > > Sent: Monday, February 14, 2000 1:04 PM > > > > To: sip ML > > > > Subject: SIP BCP-T question > > > > > > > > > > > > Hi, > > > > > > > > I have one question regarding the SIP BCP-T. > > > > INFO message outlines the Mid-Call ISUP messages. > > > > What is the reason behind not including the ISUP maintenance > > > > messages like Block, Unblock and Reset ? > > > > > > > > Thanks, > > > > Raja Badri > > > > Santera Systems Inc. > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------- > > From BCP-T: > > "This document only takes into account the call control > > functionality of ISUP. Maintenance messages are outside > > the scope of this document." > > > > Suppose that messages such as Circuit Reset may also be received > > during a call setup > > phase (to abort the setup), then should they also be mapped to such as > > BYE or CANCEL > > (by PSTN GW)? > > > > Thanks, > > -Taichi > > > > At 04:33 PM 2/23/00 -0600, Dean Willis wrote: > > > > > It seems that these might really be "no-op" operations rather than > > > "nonexistent" operations. > > > > > > There's a difference. > > > > > > -- > > > Dean > > > > > > > -----Original Message----- > > > > From: owner-sip@lists.research.bell-labs.com > > > > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Carr, > > > Steve > > > > Sent: Monday, February 14, 2000 12:25 PM > > > > To: 'Raja Badri'; sip ML > > > > Subject: RE: SIP BCP-T question > > > > > > > > > > > > The ISUP maintenance messages relate to the physical trunk > > > circuit, which > > > > when not being used on a call, is still physically present and in > > > an IDLE > > > > (or blocked) state. SIP BCT-T sets up calls over an RTP "logical" > > > > connection, which is not a physical circuit. After the end of the > > > > call, the > > > > RTP connection ceases to exist. Therefore is does not make sense > > > to block > > > > it, unblock it, reset it etc...... > > > > > > > > Steve Carr > > > > Unisphere Solutions Inc. > > > > Boca Raton > > > > scarr@unispheresolutions.com > > > > Office (561) 955-8288 > > > > Fax (561) 955-6477 > > > > > > > > www.unispheresolutions.com > > > > > > > > -----Original Message----- > > > > From: Raja Badri [mailto:raja.badri@santera.com] > > > > Sent: Monday, February 14, 2000 1:04 PM > > > > To: sip ML > > > > Subject: SIP BCP-T question > > > > > > > > > > > > Hi, > > > > > > > > I have one question regarding the SIP BCP-T. > > > > INFO message outlines the Mid-Call ISUP messages. > > > > What is the reason behind not including the ISUP maintenance > > > > messages like Block, Unblock and Reset ? > > > > > > > > Thanks, > > > > Raja Badri > > > > Santera Systems Inc. > > > > > > > > > > > > > > > > > > > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland > From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 24 16:09:59 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10512 for ; Thu, 24 Feb 2000 16:09:56 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4B0C252F6; Thu, 24 Feb 2000 16:07:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id B004952F8; Thu, 24 Feb 2000 16:07:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 9A74652F6 for ; Thu, 24 Feb 2000 16:07:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 24 16:05:17 EST 2000 Received: from l3mail02.level3.com ([209.244.1.161]) by dusty; Thu Feb 24 16:02:50 EST 2000 Received: by level3.com with Internet Mail Service (5.5.2448.0) id <149S0L3G>; Thu, 24 Feb 2000 14:03:17 -0700 Message-ID: From: Aparna.Vemuri@Level3.com To: dean.willis@wcom.com, sip@lists.research.bell-labs.com Subject: RE: SIP BCP-T Current Drafts (was RE: SIP BCP-T question) Date: Thu, 24 Feb 2000 13:57:19 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk The confusion probably stems from the fact there are around 5 drafts pertaining to the ISUP MIME and SIP-T efforts at the IETF web-site. It would be great if the obsolete drafts could be taken out, although they haven't expired yet. Thanks, Aparna Aparna V. Level (3) Communications. -----Original Message----- From: Dean Willis [mailto:dean.willis@wcom.com] Sent: Thursday, February 24, 2000 1:20 PM To: sip Subject: SIP BCP-T Current Drafts (was RE: SIP BCP-T question) I've heard many implementors continuing to reference the old BCP draft and claiming to "Support SIP-T". I'd like to make two points: 1) As Gonzalo points out, the draft draft-zimmerer-mmusic-sip-bcp-t-00.txt is quite obsolete. I believe draft-camarillo-mmusic-sip-isup-bcp-00.txt is too, as is draft-ietf-mmusic-sip-isup-mime-00.txt The current drafts are draft-zimmerer-sip-bcp-t-00.txt and draft-ietf-sip-isup-mime-00.txt. I think these combine most of the previous work in this area. 2) This is a "work in progress", NOT a standard. It's not even a proposed standard. I bet its going to change a little more before it makes it to proposed standard (don't they all?). Implementors should plan on making changes as the work matures. -- Dean Willis SIP WG co-chair > -----Original Message----- > From: owner-sip@lists.research.bell-labs.com > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Gonzalo > Camarillo > Sent: Thursday, February 24, 2000 10:14 AM > To: tfu@cisco.com > Cc: sip > Subject: Re: SIP BCP-T question > > > Hi, > > I am afraid you are talking about another draft. > > Your quote is from: > http://www.ietf.org/internet-drafts/draft-camarillo-mmusic-sip-isu > p-bcp-00.txt > > This thread deals with another draft: > http://www.ietf.org/internet-drafts/draft-zimmerer-sip-bcp-t-00.txt > > If you have any comments on the first draft just let me know because a > new version is about to be released. > > Best regards, > > Gonzalo > > tfu@cisco.com wrote: > > > > From BCP-T: > > "This document only takes into account the call control > > functionality of ISUP. Maintenance messages are outside > > the scope of this document." > > > > Suppose that messages such as Circuit Reset may also be received > > during a > > call setup > > phase (to abort the setup), then should they also be mapped to such as > > BYE > > or CANCEL > > (by PSTN GW)? > > > > Thanks, > > -Taichi > > > > At 04:33 PM 2/23/00 -0600, Dean Willis wrote: > > >It seems that these might really be "no-op" operations rather than > > >"nonexistent" operations. > > > > > >There's a difference. > > > > > >-- > > >Dean > > > > > > > -----Original Message----- > > > > From: owner-sip@lists.research.bell-labs.com > > > > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Carr, > > Steve > > > > Sent: Monday, February 14, 2000 12:25 PM > > > > To: 'Raja Badri'; sip ML > > > > Subject: RE: SIP BCP-T question > > > > > > > > > > > > The ISUP maintenance messages relate to the physical trunk > > circuit, which > > > > when not being used on a call, is still physically present and in > > an IDLE > > > > (or blocked) state. SIP BCT-T sets up calls over an RTP "logical" > > > > connection, which is not a physical circuit. After the end of the > > > > call, the > > > > RTP connection ceases to exist. Therefore is does not make sense > > to block > > > > it, unblock it, reset it etc...... > > > > > > > > Steve Carr > > > > Unisphere Solutions Inc. > > > > Boca Raton > > > > scarr@unispheresolutions.com > > > > Office (561) 955-8288 > > > > Fax (561) 955-6477 > > > > > > > > www.unispheresolutions.com > > > > > > > > -----Original Message----- > > > > From: Raja Badri [mailto:raja.badri@santera.com] > > > > Sent: Monday, February 14, 2000 1:04 PM > > > > To: sip ML > > > > Subject: SIP BCP-T question > > > > > > > > > > > > Hi, > > > > > > > > I have one question regarding the SIP BCP-T. > > > > INFO message outlines the Mid-Call ISUP messages. > > > > What is the reason behind not including the ISUP maintenance > > > > messages like Block, Unblock and Reset ? > > > > > > > > Thanks, > > > > Raja Badri > > > > Santera Systems Inc. > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------- > > From BCP-T: > > "This document only takes into account the call control > > functionality of ISUP. Maintenance messages are outside > > the scope of this document." > > > > Suppose that messages such as Circuit Reset may also be received > > during a call setup > > phase (to abort the setup), then should they also be mapped to such as > > BYE or CANCEL > > (by PSTN GW)? > > > > Thanks, > > -Taichi > > > > At 04:33 PM 2/23/00 -0600, Dean Willis wrote: > > > > > It seems that these might really be "no-op" operations rather than > > > "nonexistent" operations. > > > > > > There's a difference. > > > > > > -- > > > Dean > > > > > > > -----Original Message----- > > > > From: owner-sip@lists.research.bell-labs.com > > > > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Carr, > > > Steve > > > > Sent: Monday, February 14, 2000 12:25 PM > > > > To: 'Raja Badri'; sip ML > > > > Subject: RE: SIP BCP-T question > > > > > > > > > > > > The ISUP maintenance messages relate to the physical trunk > > > circuit, which > > > > when not being used on a call, is still physically present and in > > > an IDLE > > > > (or blocked) state. SIP BCT-T sets up calls over an RTP "logical" > > > > connection, which is not a physical circuit. After the end of the > > > > call, the > > > > RTP connection ceases to exist. Therefore is does not make sense > > > to block > > > > it, unblock it, reset it etc...... > > > > > > > > Steve Carr > > > > Unisphere Solutions Inc. > > > > Boca Raton > > > > scarr@unispheresolutions.com > > > > Office (561) 955-8288 > > > > Fax (561) 955-6477 > > > > > > > > www.unispheresolutions.com > > > > > > > > -----Original Message----- > > > > From: Raja Badri [mailto:raja.badri@santera.com] > > > > Sent: Monday, February 14, 2000 1:04 PM > > > > To: sip ML > > > > Subject: SIP BCP-T question > > > > > > > > > > > > Hi, > > > > > > > > I have one question regarding the SIP BCP-T. > > > > INFO message outlines the Mid-Call ISUP messages. > > > > What is the reason behind not including the ISUP maintenance > > > > messages like Block, Unblock and Reset ? > > > > > > > > Thanks, > > > > Raja Badri > > > > Santera Systems Inc. > > > > > > > > > > > > > > > > > > > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland > From owner-sip-outgoing@lists.research.bell-labs.com Thu Feb 24 23:16:16 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18205 for ; Thu, 24 Feb 2000 23:16:15 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 0CA1752F7; Thu, 24 Feb 2000 23:13:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 7C40052F9; Thu, 24 Feb 2000 23:13:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id A5A8952F7 for ; Thu, 24 Feb 2000 23:13:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Thu Feb 24 23:11:22 EST 2000 Received: from westhost16.westhost.net ([216.71.84.74]) by dusty; Thu Feb 24 23:08:55 EST 2000 Received: from david (w226.z208176132.sjc-ca.dsl.cnc.net [208.176.132.226]) by westhost16.westhost.net (8.8.5/8.8.5) with SMTP id WAA20105 for ; Thu, 24 Feb 2000 22:00:13 -0600 From: "David Israel" To: Subject: On behalf of Jimmy Zhang Date: Thu, 24 Feb 2000 20:13:10 -0800 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hello, My job is to implement a subset of SIP. I would like to obtain, as many as possible, real SIP messages that covers most(if not all) tags, keywords, and etc. Could someone help me on this? Also, I would like to report the bugs I have encountered while I was reading RFC2543. First the "toplabel" on page 21 is not correct, to make it work, prepend * to alphanum. Another typo takes place on page 40, the first vertical bar after Global-Failure should have been "=" instead. thanks -- Jimmy Zhang (jz@ipunity.com) Software Engineer IP Unity From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 25 02:55:55 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03293 for ; Fri, 25 Feb 2000 02:55:55 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 53BA352F9; Fri, 25 Feb 2000 02:53:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id BF68252FA; Fri, 25 Feb 2000 02:53:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id DA5E552F9 for ; Fri, 25 Feb 2000 02:53:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Feb 25 02:52:01 EST 2000 Received: from mail.mera.ru ([195.98.50.58]) by dusty; Fri Feb 25 02:49:34 EST 2000 Received: from mcseem.mera.ru (mcseem.mera.ru [195.98.57.12]) by mail.mera.ru (8.9.3/8.9.3) with ESMTP id KAA84638; Fri, 25 Feb 2000 10:51:46 +0300 (MSK) Date: Fri, 25 Feb 2000 10:55:21 +0300 From: "Stanislav S. Timinsky" X-Mailer: The Bat! (v1.36) S/N F29DEE5D / Educational Reply-To: "Stanislav S. Timinsky" Organization: MERA Labs. X-Priority: 3 (Normal) Message-ID: <18455.000225@mera.ru> To: "David Israel" Cc: sip@lists.research.bell-labs.com, prj.men.sip@mera.ru Subject: Re: On behalf of Jimmy Zhang In-reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hello David, Friday, February 25, 2000, 7:13:10 AM, you wrote: David Israel> Hello, David Israel> My job is to implement a subset of SIP. I would like to obtain, as many David Israel> as possible, real SIP messages that covers most(if not all) tags, keywords, David Israel> and etc. Could someone help me on this? David Israel> Also, I would like to report the bugs I have encountered while I was David Israel> reading RFC2543. First the "toplabel" on page 21 is not correct, to make it David Israel> work, prepend * to alphanum. Another typo takes place on page 40, the first David Israel> vertical bar after Global-Failure should have been "=" instead. David Israel> thanks David Israel> -- Jimmy Zhang (jz@ipunity.com) David Israel> Software Engineer David Israel> IP Unity 1. Some test messages are at: http://www.cs.columbia.edu/~hgs/sip/bakeoff2/testmsg.html and http://www.cs.columbia.edu/~hgs/sip/drafts/draft-sparks-sip-service-examples-00.txt 2. As to inexactnesses in RFC-2543, they were also noted by me at realization of the SIP stack. I want to notice, that RFC-2327 (SDP) also has some bugs in grammar description. -- Best regards, Stanislav S. Timinsky mailto:timinsky@mera.ru Mera Labs. From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 25 08:21:57 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06985 for ; Fri, 25 Feb 2000 08:21:56 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id F38EC52FA; Fri, 25 Feb 2000 08:19:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6F08052FD; Fri, 25 Feb 2000 08:19:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 8D9BA52FA for ; Fri, 25 Feb 2000 08:19:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Feb 25 08:17:34 EST 2000 Received: from penguin.wise.edt.ericsson.se ([194.237.142.110]) by dusty; Fri Feb 25 08:15:07 EST 2000 Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.9.3/8.9.3/WIREfire-1.5) with ESMTP id OAA10937; Fri, 25 Feb 2000 14:17:31 +0100 (MET) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.75.22]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id PAA17233; Fri, 25 Feb 2000 15:17:30 +0200 (EET) Message-ID: <38B680EA.E71A2D2@lmf.ericsson.se> Date: Fri, 25 Feb 2000 15:17:30 +0200 From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: tfu@cisco.com Cc: sip@lists.research.bell-labs.com Subject: Re: SIP ISUP BCP-00 question(was: Re: SIP BCP-T question) References: <4.2.0.58.20000224083509.00b4c610@farley.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Yes, there is a section about it. The draft will be available pretty soon. Best regards, Gonzalo tfu@cisco.com wrote: > > Gonzalo, > > Thanks for your clarification. My question is more on your draft. > I think those maintenance messages need also to be covered. > Execuse me if you already have them in the coming version. > > Best regards, > -Taichi > > At 06:14 PM 2/24/00 +0200, Gonzalo Camarillo wrote: > >Hi, > > > >I am afraid you are talking about another draft. > > > >Your quote is from: > >http://www.ietf.org/internet-drafts/draft-camarillo-mmusic-sip-isup-bcp-00.txt > > > >This thread deals with another draft: > >http://www.ietf.org/internet-drafts/draft-zimmerer-sip-bcp-t-00.txt > > > >If you have any comments on the first draft just let me know because a > >new version is about to be released. > > > >Best regards, > > > >Gonzalo > > > >tfu@cisco.com wrote: > > > > > > From BCP-T: > > > "This document only takes into account the call control > > > functionality of ISUP. Maintenance messages are outside > > > the scope of this document." > > > > > > Suppose that messages such as Circuit Reset may also be received > > > during a > > > call setup > > > phase (to abort the setup), then should they also be mapped to such as > > > BYE > > > or CANCEL > > > (by PSTN GW)? > > > > > > Thanks, > > > -Taichi > > > > > > At 04:33 PM 2/23/00 -0600, Dean Willis wrote: > > > >It seems that these might really be "no-op" operations rather than > > > >"nonexistent" operations. > > > > > > > >There's a difference. > > > > > > > >-- > > > >Dean > > > > > > > > > -----Original Message----- > > > > > From: owner-sip@lists.research.bell-labs.com > > > > > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Carr, > > > Steve > > > > > Sent: Monday, February 14, 2000 12:25 PM > > > > > To: 'Raja Badri'; sip ML > > > > > Subject: RE: SIP BCP-T question > > > > > > > > > > > > > > > The ISUP maintenance messages relate to the physical trunk > > > circuit, which > > > > > when not being used on a call, is still physically present and in > > > an IDLE > > > > > (or blocked) state. SIP BCT-T sets up calls over an RTP "logical" > > > > > connection, which is not a physical circuit. After the end of the > > > > > call, the > > > > > RTP connection ceases to exist. Therefore is does not make sense > > > to block > > > > > it, unblock it, reset it etc...... > > > > > > > > > > Steve Carr > > > > > Unisphere Solutions Inc. > > > > > Boca Raton > > > > > scarr@unispheresolutions.com > > > > > Office (561) 955-8288 > > > > > Fax (561) 955-6477 > > > > > > > > > > www.unispheresolutions.com > > > > > > > > > > -----Original Message----- > > > > > From: Raja Badri [mailto:raja.badri@santera.com] > > > > > Sent: Monday, February 14, 2000 1:04 PM > > > > > To: sip ML > > > > > Subject: SIP BCP-T question > > > > > > > > > > > > > > > Hi, > > > > > > > > > > I have one question regarding the SIP BCP-T. > > > > > INFO message outlines the Mid-Call ISUP messages. > > > > > What is the reason behind not including the ISUP maintenance > > > > > messages like Block, Unblock and Reset ? > > > > > > > > > > Thanks, > > > > > Raja Badri > > > > > Santera Systems Inc. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------- > > > From BCP-T: > > > "This document only takes into account the call control > > > functionality of ISUP. Maintenance messages are outside > > > the scope of this document." > > > > > > Suppose that messages such as Circuit Reset may also be received > > > during a call setup > > > phase (to abort the setup), then should they also be mapped to such as > > > BYE or CANCEL > > > (by PSTN GW)? > > > > > > Thanks, > > > -Taichi > > > > > > At 04:33 PM 2/23/00 -0600, Dean Willis wrote: > > > > > > > It seems that these might really be "no-op" operations rather than > > > > "nonexistent" operations. > > > > > > > > There's a difference. > > > > > > > > -- > > > > Dean > > > > > > > > > -----Original Message----- > > > > > From: owner-sip@lists.research.bell-labs.com > > > > > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Carr, > > > > Steve > > > > > Sent: Monday, February 14, 2000 12:25 PM > > > > > To: 'Raja Badri'; sip ML > > > > > Subject: RE: SIP BCP-T question > > > > > > > > > > > > > > > The ISUP maintenance messages relate to the physical trunk > > > > circuit, which > > > > > when not being used on a call, is still physically present and in > > > > an IDLE > > > > > (or blocked) state. SIP BCT-T sets up calls over an RTP "logical" > > > > > connection, which is not a physical circuit. After the end of the > > > > > call, the > > > > > RTP connection ceases to exist. Therefore is does not make sense > > > > to block > > > > > it, unblock it, reset it etc...... > > > > > > > > > > Steve Carr > > > > > Unisphere Solutions Inc. > > > > > Boca Raton > > > > > scarr@unispheresolutions.com > > > > > Office (561) 955-8288 > > > > > Fax (561) 955-6477 > > > > > > > > > > www.unispheresolutions.com > > > > > > > > > > -----Original Message----- > > > > > From: Raja Badri [mailto:raja.badri@santera.com] > > > > > Sent: Monday, February 14, 2000 1:04 PM > > > > > To: sip ML > > > > > Subject: SIP BCP-T question > > > > > > > > > > > > > > > Hi, > > > > > > > > > > I have one question regarding the SIP BCP-T. > > > > > INFO message outlines the Mid-Call ISUP messages. > > > > > What is the reason behind not including the ISUP maintenance > > > > > messages like Block, Unblock and Reset ? > > > > > > > > > > Thanks, > > > > > Raja Badri > > > > > Santera Systems Inc. > > > > > > > > > > > > > > > > > > > > > > > > > > >-- > >Gonzalo Camarillo Phone : +358 9 299 33 71 > >Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > >Telecom R&D Fax : +358 9 299 30 52 > >FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > >Finland > > -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 25 09:27:59 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08756 for ; Fri, 25 Feb 2000 09:27:58 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 223EF52FD; Fri, 25 Feb 2000 09:25:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 974D852FE; Fri, 25 Feb 2000 09:25:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id E096C52FD for ; Fri, 25 Feb 2000 09:25:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Feb 25 09:24:38 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Fri Feb 25 09:22:11 EST 2000 Received: from dynamicsoft.com (1Cust247.tnt1.freehold.nj.da.uu.net [63.17.113.247]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA03914; Fri, 25 Feb 2000 09:24:44 -0500 (EST) Message-ID: <38B691BF.9EC8F74E@dynamicsoft.com> Date: Fri, 25 Feb 2000 09:29:19 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Israel Cc: sip@lists.research.bell-labs.com, jz@ipunity.com Subject: Re: On behalf of Jimmy Zhang References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit David Israel wrote: > > Also, I would like to report the bugs I have encountered while I was > reading RFC2543. First the "toplabel" on page 21 is not correct, to make it > work, prepend * to alphanum. Why? This grammar seems to work. The * appears outside the parens, so there can be an arbitrary number of alphanums in the middle. Putting a * in front of either of the alphanums is redundant. I'll also note that it is identical to the grammar of rfc2396: > toplabel = alpha | alpha *( alphanum | "-" ) alphanum Another typo takes place on page 40, the first > vertical bar after Global-Failure should have been "=" instead. Thanks, we'll fix that. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 25 09:36:31 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09070 for ; Fri, 25 Feb 2000 09:36:31 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 7070152FE; Fri, 25 Feb 2000 09:33:39 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C54405300; Fri, 25 Feb 2000 09:33:38 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id D97AC52FE for ; Fri, 25 Feb 2000 09:33:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Feb 25 09:31:24 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Fri Feb 25 09:28:57 EST 2000 Received: from dynamicsoft.com (1Cust247.tnt1.freehold.nj.da.uu.net [63.17.113.247]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA03938; Fri, 25 Feb 2000 09:31:16 -0500 (EST) Message-ID: <38B69347.ADC125C5@dynamicsoft.com> Date: Fri, 25 Feb 2000 09:35:51 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Stanislav S. Timinsky" Cc: David Israel , sip@lists.research.bell-labs.com, prj.men.sip@mera.ru Subject: Re: On behalf of Jimmy Zhang References: <18455.000225@mera.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit "Stanislav S. Timinsky" wrote: > > > As to inexactnesses in RFC-2543, they were also noted by me at realization of the SIP stack. > I want to notice, that RFC-2327 (SDP) also has some bugs in grammar description. Folks, if you find bugs or problems, please be sure to report them to the list or to the authors privately. We will incorporate them into the revised spec. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 25 10:42:03 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12072 for ; Fri, 25 Feb 2000 10:42:02 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4B6AB52FF; Fri, 25 Feb 2000 10:39:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id BE5A15300; Fri, 25 Feb 2000 10:39:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 4C4AB52FF for ; Fri, 25 Feb 2000 10:39:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Feb 25 10:38:26 EST 2000 Received: from bounty.cisco.com ([161.44.2.72]) by dusty; Fri Feb 25 10:35:59 EST 2000 Received: from cisco.com (bounty.cisco.com [161.44.2.72]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id KAA13844; Fri, 25 Feb 2000 10:38:22 -0500 (EST) Message-ID: <38B6A1ED.C9396BFA@cisco.com> Date: Fri, 25 Feb 2000 10:38:21 -0500 From: Bryan Byerly X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com, rap@iphighway.com Cc: byerly@cisco.com Subject: Question on achieveing Assured QoS using SIP/COPS Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi guys, Assuming a goal of achieving "assured QoS" using generic SIP: (In assured QoS, the phone doesn't ring until resource allocation has been confirmed vs. enabled QoS, when the phone rings and can be answered before QoS is established. In fact, if resources are not available, the enabled QoS conversation would continue (without QoS)). I understand that assured QoS can be achieved using the provisioned (push) model of COPS. (REQ, ... DEC, RPT, ... DEC, RTP, ... DEC, RPT ...) Some examples of proposed provisioned models (push model) which (can) achieve assured QoS are: a) DQoS (using Gate objects) b) COPS-PR (using ASN.1 encoded objects), ... which ones am I leaving out? However, I have not seen assured QoS achieved using the outsourcing model (pull model) of COPS. (REQ, DEC, RPT, .... REQ, DEC, RPT, ... REQ, DEC, RPT, ...) Is it even possible to achieve assured QoS using the outsourcing model (pull model) of COPS? If so, could someone please sketch a brief call flow for me of how to achieve assured QoS using the outsourcing model of COPS? Thanks for your help! Bryan Bryan J. Byerly byerly@cisco.com From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 25 12:58:00 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15965 for ; Fri, 25 Feb 2000 12:58:00 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 781405300; Fri, 25 Feb 2000 12:55:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id F30F55301; Fri, 25 Feb 2000 12:55:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 68B7D5300 for ; Fri, 25 Feb 2000 12:55:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Feb 25 12:54:09 EST 2000 Received: from bounty.cisco.com ([161.44.2.72]) by dusty; Fri Feb 25 12:51:42 EST 2000 Received: from cisco.com (localhost [127.0.0.1]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id MAA24847; Fri, 25 Feb 2000 12:54:06 -0500 (EST) Message-ID: <38B6C1BD.7345B9C0@cisco.com> Date: Fri, 25 Feb 2000 12:54:05 -0500 From: Sudipto Mukherjee Organization: Cisco X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com, mikepham@cisco.com Subject: Contact, Record-Route with TCP transport Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit I need a clarification on the handling of Contact and Record-Route headers in SIP UAs using TCP as the transport. Is it the same as UDP ? The reopening of new TCP connections to handle Contacts and RRs has overheads and complicates the implementation of the UA. Thanks -- Sudipto From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 25 14:15:53 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18289 for ; Fri, 25 Feb 2000 14:15:53 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id B535B52FB; Fri, 25 Feb 2000 14:13:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 38CEA52FC; Fri, 25 Feb 2000 14:13:24 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id E76D852FB for ; Fri, 25 Feb 2000 14:13:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Feb 25 14:11:57 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Fri Feb 25 14:09:30 EST 2000 Received: from dynamicsoft.com (1Cust247.tnt1.freehold.nj.da.uu.net [63.17.113.247]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA04972; Fri, 25 Feb 2000 14:12:03 -0500 (EST) Message-ID: <38B6D514.FADB6C66@dynamicsoft.com> Date: Fri, 25 Feb 2000 14:16:36 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Joshua Moloney Cc: "'sip@lists.research.bell-labs.com'" Subject: Re: Content-Encoding vs. Content-Transfer-Encoding References: <61ABD11436FED21192440000F81F3E3603311899@nwcwi1a.europe.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit The Content-Transfer-Encoding header was primarily meant to allow message bodies to be transformed into formats that could be transferred on channels that were not 8 bit clean. HTTP, which makes use of many of the MIME headers, is 8 bit clean, and thus did not need Content-Transfer-Encoding. SIP followed suit, and so does not use it either. Content-Encoding is used for things like compression, which is different (in fact, the opposite, since conversion of a binary file to a 7 bit transfer channel INCREASES the size of the body). -Jonathan R. > Joshua Moloney wrote: > > Hi all, > > I have a question about the "Content-Encoding" entity header. > Why is the MIME "Content-Transfer-Encoding" header defined in RFC 2045 > not used instead? > Am I correct in assuming that they do the same job? > > For example, what headers should I include on a message with an > "application/ISUP" message body? :- > > Content-Type: application/ISUP > Content-Transfer-Encoding: binary > ..... > > OR > > Content-Type: application/ISUP > Content-Encoding: binary > ..... > > Thanks in advance, > > Josh Moloney > > Nortel Networks > jmoloney@nortelnetworks.com -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 25 14:39:53 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19000 for ; Fri, 25 Feb 2000 14:39:52 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 09F235301; Fri, 25 Feb 2000 14:37:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 772325303; Fri, 25 Feb 2000 14:37:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 8AB185301 for ; Fri, 25 Feb 2000 14:37:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Feb 25 14:36:16 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Fri Feb 25 14:33:49 EST 2000 Received: from dynamicsoft.com (1Cust247.tnt1.freehold.nj.da.uu.net [63.17.113.247]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA05100; Fri, 25 Feb 2000 14:32:30 -0500 (EST) Message-ID: <38B6D9E0.7B7BECB8@dynamicsoft.com> Date: Fri, 25 Feb 2000 14:37:04 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Anders Kristensen Cc: Robert.Sparks@wcom.com, "'SIP List' (E-mail)" , "Henning Schulzrinne (E-mail)" Subject: Re: UAC use of tags received in responses References: <003201bf73dd$40e24300$8a9223a6@mcit.com> <38A33790.5A052AC6@dynamicsoft.com> <38B574B5.50448657@hplb.hpl.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Anders Kristensen wrote: > > I'm not sure it's a problem, but this can give rise to curious > situations when the the non-2xx final response was generated by a UAS. > In this case the UAS has inserted a To tag and hence believes the call > consists of a single leg, whose UAS identifier (the To of the original > request) has a tag. > > The UAC ACKs the response (ACK includes To tag) and resubmits the > request *without* To tag. This basically constitutes initiating a new > transaction in a new leg. > > Now I'm not sure if it's well-specified whether the UAS will associate > that new request with the existing leg (which has a To tag). I think > this would (or should) be the correct behaviour, as it really is the > same leg, but I would imagine that different implementations might > differ on this point. The consequence is that the second response (say a > 2xx) may be returned with the *original* To tag. Hmm. I don't think this would happen. If the UAS receives a request and sends a non-200 response with a tag, the call leg is over. It doesn't know whether it will ever receieve another request, so I imagine it will flush the state, and thats it. When the new request arrives, it creates a new call leg. The tag in the response will probably be different than the previous, or it might be the same. On the UAC, this basically means it really can't associate a tag with the call leg until the 200 OK. Before that, any tags it sees in provisionals or non-200s might not be the final tag. > Maybe it should be clarified whether the UAS should respond to the > second request with the old or a new To tag, and whether the UAC is > supposed to think of the two requests as belonging to different legs? I don't think we can impose requirements on maintenance of state at a UA after rejecting a new INVITE. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 25 16:18:01 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20945 for ; Fri, 25 Feb 2000 16:18:00 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 516F85304; Fri, 25 Feb 2000 16:15:26 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id B36C25302; Fri, 25 Feb 2000 16:15:25 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 426A05304 for ; Fri, 25 Feb 2000 16:15:09 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Feb 25 16:14:13 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Fri Feb 25 16:11:47 EST 2000 Received: from dynamicsoft.com (1Cust247.tnt1.freehold.nj.da.uu.net [63.17.113.247]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA05458; Fri, 25 Feb 2000 16:13:58 -0500 (EST) Message-ID: <38B6F1A7.EF12BC83@dynamicsoft.com> Date: Fri, 25 Feb 2000 16:18:31 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Sudipto Mukherjee Cc: sip@lists.research.bell-labs.com, mikepham@cisco.com Subject: Re: Contact, Record-Route with TCP transport References: <38B6C1BD.7345B9C0@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Sudipto Mukherjee wrote: > > I need a clarification on the handling of Contact and Record-Route > headers in SIP UAs using TCP as the transport. > > Is it the same as UDP ? Yes. If the client or proxy needs to send a request or response somewhere, and a TCP connection isn't open, and that request must be sent TCP, a connection is opened. > > The reopening of new TCP connections to handle Contacts and RRs > has overheads and complicates the implementation of the UA. The opening is only if a connection to that destination doesn't already exist. SIP allows TCP connections to be reused for other requests. In many cases, the connection will already be there. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 25 19:12:04 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23496 for ; Fri, 25 Feb 2000 19:12:04 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 1E3B45303; Fri, 25 Feb 2000 19:09:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 890885305; Fri, 25 Feb 2000 19:09:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id B7D395303 for ; Fri, 25 Feb 2000 19:09:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Feb 25 19:07:56 EST 2000 Received: from smtprch1.nortel.com ([192.135.215.14]) by dusty; Fri Feb 25 19:05:30 EST 2000 Received: from zsc4c002.corpwest.baynetworks.com (actually h0295.s86b1.BayNetworks.COM) by smtprch1.nortel.com; Fri, 25 Feb 2000 18:07:40 -0600 Received: from zsc4c006.corpwest.baynetworks.com ([134.177.2.153]) by zsc4c002.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id FGJ1AC0V; Fri, 25 Feb 2000 16:07:28 -0800 Received: from long-1.corpwest.baynetworks.com (long-pc.corpwest.baynetworks.com [134.177.35.47]) by zsc4c006.corpwest.baynetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 198F732M; Fri, 25 Feb 2000 16:07:28 -0800 Message-Id: <3.0.1.32.20000225160313.00732b68@zsc4c006.corpwest.baynetworks.com> X-Sender: long@zsc4c006.corpwest.baynetworks.com X-Mailer: Windows Eudora Pro Version 3.0.1 (32) Date: Fri, 25 Feb 2000 16:03:13 -0800 To: Bryan Byerly , sip@lists.research.bell-labs.com, rap@iphighway.com From: "Lyndon Ong" Subject: Re: Question on achieveing Assured QoS using SIP/COPS In-Reply-To: <38B6A1ED.C9396BFA@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Hi, Isn't providing your "assured QoS" a matter of having the hooks in call setup signaling (i.e., SIP and SDP) to indicate that resource allocation is required prior to ringing, not strictly a COPS issue? Jonathan, et al's draft-ietf-mmusic-sdp-qos-00.txt proposes a way to indicate this in SDP and some SIP extension is also probably involved. COPS-PR vs. COPS-RSVP, on the other hand, depends on how you are doing resource allocation decisions: -- COPS-PR could be used where you are pushing resource allocation decisions from a central point to edge devices, while -- COPS-RSVP or outsource would be used where you rely on RSVP signaling end-to-end to initiate resource allocation, and edge devices detecting the RSVP PATH/RESV use COPS-RSVP to outsource the decision to a PDP. By the way, "assured" might be confused with "assured forwarding" in Diffserv, a completely different concept... L. Ong At 10:38 AM 2/25/00 -0500, Bryan Byerly wrote: >Hi guys, > >Assuming a goal of achieving "assured QoS" using generic SIP: >(In assured QoS, the phone doesn't ring until resource allocation has >been confirmed >vs. enabled QoS, when the phone rings and can be answered before QoS is >established. >In fact, if resources are not available, the enabled QoS conversation >would continue >(without QoS)). > >I understand that assured QoS can be achieved using the provisioned >(push) model of COPS. >(REQ, ... DEC, RPT, ... DEC, RTP, ... DEC, RPT ...) >Some examples of proposed provisioned models (push model) which (can) >achieve assured QoS are: >a) DQoS (using Gate objects) >b) COPS-PR (using ASN.1 encoded objects), >... which ones am I leaving out? > >However, I have not seen assured QoS achieved using the >outsourcing model (pull model) of COPS. >(REQ, DEC, RPT, .... REQ, DEC, RPT, ... REQ, DEC, RPT, ...) > >Is it even possible to achieve assured QoS using the outsourcing model >(pull model) of COPS? > >If so, could someone please sketch a brief call flow for me of >how to achieve assured QoS using the outsourcing model of COPS? > >Thanks for your help! > >Bryan > >Bryan J. Byerly >byerly@cisco.com > > > From owner-sip-outgoing@lists.research.bell-labs.com Fri Feb 25 19:51:49 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23779 for ; Fri, 25 Feb 2000 19:51:49 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4135F5306; Fri, 25 Feb 2000 19:49:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id B38E75307; Fri, 25 Feb 2000 19:49:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id DBD425306 for ; Fri, 25 Feb 2000 19:49:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Feb 25 19:47:32 EST 2000 Received: from prserv.net ([32.97.166.35]) by dusty; Fri Feb 25 19:45:06 EST 2000 Received: from cs.columbia.edu ([32.101.170.10]) by prserv.net (out5) with SMTP id <2000022600472724300p5g3re>; Sat, 26 Feb 2000 00:47:28 +0000 Message-ID: <38B7244F.8C149038@cs.columbia.edu> Date: Fri, 25 Feb 2000 19:54:39 -0500 From: Henning Schulzrinne X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg , sip@lists.research.bell-labs.com Cc: john@math.nwu.edu Subject: Re: [Fwd: Aurthorization & Proxy-Authorization URIs] References: <38B6F852.31887BED@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > ?? I guess the quotes shouldn't be there according to the current BNF, > but it might make parsing harder.? Since the digest authentication mechanism attempts to follow RFC 2617 (obviously, 2617 postdates 2543, but it will be the normative reference in the next round), request-uri is indeed defined without being a quoted string, even though the uri is not a token. (Unless you put an unescaped comma into the URI, there shouldn't be delineation problems. But we had this discussion in another context, where it became clear that URIs can indeed contain commas.) Some parsers allow all parameters to be either tokens or quoted strings, since that's easiest and never wrong. Unfortunately, RFC 2617 itself is not consistent. In the BNF (3.2.2), it's without quotes, in the example (Section 3.5), it shows up *with* quotes. I guess we need to contact the RFC 2617 authors to find out what people really do and what they intended. Another instance of URIs (in WWW-Authenticate) is always with quotes. Thus, the confusion is more fundamental. > > Subject: Aurthorization & Proxy-Authorization URIs > Date: Mon, 21 Feb 2000 14:53:22 -0500 > From: Linden deCarmo > To: sip@lists.research.bell-labs.com > > The BNF for digest-uri defined by "HTTP Authentication: Basic and Digest > Access Authentication" for use in Aurthorization & Proxy-Authorization > headers is: > > digest-uri = "uri" "=" digest-uri-value > digest-uri-value = request-uri ; As specified by HTTP/1.1 > > RFC2543, updates this definition to be: > > 2. The BNF for digest-uri-value is: > > digest-uri-value = Request-URI ; a defined in Section 4.3 > > Yet, all the sample call flows for the uri parameters for the Aurthorization > & Proxy-Authorization headers that I've seen (i.e. SIP Telephony Service > Examples With Call Flows) > enclose the uri parameter in quotes (i.e. a quoted string) just like the > HTTP docs: > > uri="sip:xxx.yyyy.com" > > Syntacically, I can't see how this is possible. Am I wrong? If so, could > someone point out the relevant section that explains how this is possible? > > Thank you. > > Linden deCarmo > Netspeak Corporation > 902 Clint Moore Road > Suite 104 > Boca Raton, FL 33487 From owner-sip-outgoing@lists.research.bell-labs.com Sat Feb 26 14:45:38 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18065 for ; Sat, 26 Feb 2000 14:45:37 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 8780D5307; Sat, 26 Feb 2000 14:41:12 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id BCD905305; Sat, 26 Feb 2000 14:41:10 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 6FF9152FF for ; Fri, 25 Feb 2000 09:49:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Feb 25 09:47:07 EST 2000 Received: from mailhub.fokus.gmd.de ([193.174.154.14]) by dusty; Fri Feb 25 09:44:40 EST 2000 Received: from heartofgold (dhcp108 [195.37.78.236]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with SMTP id OAA18603; Fri, 25 Feb 2000 14:46:06 +0100 (MET) From: "Thomas Magedanz" To: , , , , , Subject: CFP: Computer Networks Special Issue on IN and IP Convergence Date: Fri, 25 Feb 2000 14:17:24 +0100 Message-ID: <008101bf7f92$afc661f0$ec4e25c3@ikvintern.de> 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 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Ladies and Gentlemen! Computer Networks Journal plans to publish in February 2001 a special issue on "Voice / Data Integration - A Snapshot of Intelligent Network and Internet Convergence". Guest editors: T. Magedanz (IKV++) and M. Smirnov (GMD FOKUS) Deadline for submission is June 2000! Maybe this is a good candidate for disseminating your results! For more infos look at: http://www.fokus.gmd.de/events/IN-Internet/ Best regards, Thomas Magedanz (magedanz@ikv.de) From owner-sip-outgoing@lists.research.bell-labs.com Sat Feb 26 14:48:33 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18082 for ; Sat, 26 Feb 2000 14:48:31 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id AA376530A; Sat, 26 Feb 2000 14:41:54 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id ECC115309; Sat, 26 Feb 2000 14:41:52 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 7B4D85300 for ; Fri, 25 Feb 2000 11:09:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Fri Feb 25 11:08:28 EST 2000 Received: from PMESMTP01.wcom.com ([199.249.20.1]) by dusty; Fri Feb 25 11:05:58 EST 2000 Received: from omzrelay.mcit.com ([166.37.204.49]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FQH00MLOU5NKG@firewall.mcit.com> for sip@lists.research.bell-labs.com; Fri, 25 Feb 2000 16:08:12 +0000 (GMT) Received: from omzmta03.mcit.com (omzmta03.mcit.com [166.37.194.121]) by omzrelay.mcit.com (8.8.7/) with ESMTP id QAA24167; Fri, 25 Feb 2000 16:08:10 +0000 (GMT) Received: from C25766A ([166.35.225.37]) by omzmta03.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000225160805.QEGR12655@C25766A>; Fri, 25 Feb 2000 16:08:05 +0000 Date: Fri, 25 Feb 2000 10:08:05 -0600 From: Henry Sinnreich Subject: RE: Question on achieveing Assured QoS using SIP/COPS In-reply-to: <38B6A1ED.C9396BFA@cisco.com> To: Bryan Byerly , sip@lists.research.bell-labs.com, rap@iphighway.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: multipart/mixed; boundary="----=_NextPart_000_0006_01BF7F78.354E7300" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0006_01BF7F78.354E7300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit >If so, could someone please sketch a brief call flow for me of >how to achieve assured QoS using the outsourcing model of COPS? Please see the attached PowerPoint charts from the last SIP WG meeting. Sorry, the ASCII format is just not too legible, but is in http://www.ietf.org/internet-drafts/draft-sinnreich-interdomain- sip-qos-osp-00.txt Henry >-----Original Message----- >From: owner-sip@lists.research.bell-labs.com >[mailto:owner-sip@lists.research.bell-labs.com]On >Behalf Of Bryan Byerly >Sent: Friday, February 25, 2000 9:38 AM >To: sip@lists.research.bell-labs.com; rap@iphighway.com >Cc: byerly@cisco.com >Subject: Question on achieveing Assured QoS using SIP/COPS > > >Hi guys, > >Assuming a goal of achieving "assured QoS" using generic SIP: >(In assured QoS, the phone doesn't ring until >resource allocation has >been confirmed >vs. enabled QoS, when the phone rings and can be >answered before QoS is >established. >In fact, if resources are not available, the enabled >QoS conversation >would continue >(without QoS)). > >I understand that assured QoS can be achieved using >the provisioned >(push) model of COPS. >(REQ, ... DEC, RPT, ... DEC, RTP, ... DEC, RPT ...) >Some examples of proposed provisioned models (push >model) which (can) >achieve assured QoS are: >a) DQoS (using Gate objects) >b) COPS-PR (using ASN.1 encoded objects), >... which ones am I leaving out? > >However, I have not seen assured QoS achieved using the >outsourcing model (pull model) of COPS. >(REQ, DEC, RPT, .... REQ, DEC, RPT, ... REQ, DEC, RPT, ...) > >Is it even possible to achieve assured QoS using the >outsourcing model >(pull model) of COPS? > >If so, could someone please sketch a brief call flow for me of >how to achieve assured QoS using the outsourcing model of COPS? > >Thanks for your help! > >Bryan > >Bryan J. Byerly >byerly@cisco.com > > ------=_NextPart_000_0006_01BF7F78.354E7300 Content-Type: application/x-zip-compressed; name="interdomain.zip" Content-Disposition: attachment; filename="interdomain.zip" Content-Transfer-Encoding: base64 UEsDBBQAAAAIANYwayeirQ/D0hMBAAC6DQAPAAAASW50ZXJkb21haW4ucHB07J0HYBPVH8df2lI2 lCFQQA1DBGUPAWWUvSl7KDLbQhVabMsUgQJCEVBUZAgYhigiVHCCoKAMEXChKPwVWSIOpiKCjP5/ L7cvN94llzQJv49+c7l37373xvfevbuk4euvih1fuansCaKiGYkkt3Lyk2hZWhGQQ1iJISSCX7+V k5MjJOcB0X0iQVGgJpChKagmJNQC1QbVAdWN5DJOAeUgucZNUNtorg9vqpQPuig/qACoIKgQqDDv g6KcBUgxUHFQCVBJ0B2gUqDSoDKgWFBZUDlQedCdoLtAd4OcoAqgiqBKoMqge0BVQPeCqoKqge4D 3Q+qDqoBqgmqBaoNqgOqC6oHqg9qAHoA1BDUCNQY9CDoIVATUFNCvU1Ic1AcqAWoJagVqDWoDagt qB2oPagDqCOoE6gzqAuoKyge1A3UHdQD1BPUC9Qb1AfUF9QP1B/0MOgR0ADQo6CBoEGgwaAhoKGg YaAEUCIoCTQcNAKUDHoM9DhoJGgUKAWUChoNegKUBkoHZYDGgMaCxoHGgyaAJoKeBE0CPQWaDJoC mkpo2VPhvwzoizYQNwNi0T3YKQVnvOAlBzFm6ocbGjWtvt3RBvy2Iy+X1g2OPg5qneZ+l+wugxN6 IhVaZAzUNtGdok9VEuGgYw4di2gZDLKK0EPPf6yQ+30397HT4cjpcBzuaD1BqZA6BHoh0V2aZFhL hBJx6fIWagTHp5GENtA6nhbN+GUrqGWaOzpX895QjkR3j7JRFmouP5/N9+DG7BL8e3reC6LjtTB+ 0zYyO//pPsX4pdXz/1YOEgxkghmmgaaDZoCeBs0EzQJlgWaDngHNAc0FzQM9C3oONB/0POgF0Iug BaCXQAtBi0CLQUtAL4OWgpaBloNeAblAK0ArQatAq0GvgtaAXgO9DloLegO0DvQmaD1oAygb9BZo I2gT6G3QO6B3Qe+B3gd9ANoM2gL6ELQVtA30Eehj0HbQDtAnoE9BO0G7QLtBe0CfgfaCPgftA+0H HQB9AfoS9BXoa9A3oIOgb0HfgQ6Bvgf9ADoMOgL6H+hH0E+go6CfQcdAx0EnQCdBp0C/gE6DfgWd Af0G+h30B+hP0FnQOdB50AXQRdAl0F+gv0GXQf+AroD+BV0FXQP9B7oOugG6CboFcg/WMGg6QBGg SFAUKA8oGpQXlA+UH1QAVBBUCFQYVARUFBQDKgYqDioBKgm6A1QKVBpUBhQLKgsqByoPuhN0F+hu kBNUAVQRVAlUGXQPqAroXlBVUDXQfaD7QdVBNUA1QbVAtUF1QHVB9UD1QQ1AD4AaghqBGoMeBD0E agJqCmoGag6KA7UAtQS1ArUGtQG1BbUDtQd1AHUEdQJ1BnUBdQXFg7qBuoN6gHqCeoF6g/qA+oL6 gfqDHgY9AhoAehQ0EDQINBg0BDQUNAyUAEoEJYGGg0aAkkGPgR4HjQSNAqWAUkGjQU+A0kDpoAzQ GNBY0DjQeNAE0ETQk6BJoKdAk0FTQFNBmWCDaaDpoBmgp0EzQbNAWaDZoGdAc0BzQfNAz4KeA80H PQ96AfQiaAHoJdBC0CLQYtAS0MugpaBloOWgV0Au0ArQStAq0GrQq6A1oNdAr4PWgt4ArQO9CVoP 2gDKBr0F2gjaBHob9A7oXdB7oPdBH4A2g7aAPgRtBW0DfQT6GLQdtAP0CehT0E7QLtBu0B7QZ6C9 oM9B+0D7QQdAX4C+BH0F+hr0Degg6FvQd6BDoO9BP4AOg46A/gf6EfQT6CjoZ9Ax0HHQCdBJ0CnQ L6DToF9BZ0C/gX4H/QH6E3QWdA50HnQBdBF0CfQX6G/QZdA/oCugf0FXQddA/4Gug26AboJugdwT BRgDHKAIUCQoCpQHFA3KC8oHyg8qACoIKgQqDCoCKgqKARUDFQeVAJUE3QEqBSoNKgOKBZUFlQOV B90Jugt0N8gJqgCqCKoEqgy6B1QFdC+oKqga6D7Q/aDqoBqgmqBaoNqgOqC6oHqg+qAGoAdADUGN QI1BD4IeAjUDCfc2zeF9HKgFqCWoFag1qA2oLagdqD2oA6gjqBOoM6gLqCsoHtQN1B3UA9QT1AvU G9QH1BfUD9Qf9DDoEdAA0KOggaBBoMGgIaChoGGgBFAiKAk0HDQClAx6DPQ4aCRoFCgFlAoaDXoC lAZKB2WAxoDGgsaBxoMmgCaCngRNAj0FmgyaAprq4O7T6axxKj8f/i2SW+/Hr/8eyd3HVyccU2Fy dxxu/OJg4necTvTggpPPfQcDXvqdmzPSOSSdM/7FxyqTUNA9L/wzL7dOxxV6z3i4KBczgo9dhJzg 7woE1DmIIodDI0dRRY4IjRwxihy0/nuLcuWi5yGd+x7k96D1pveg9Dgf8nkq8umZiZnDM5MzH88c lZma+URmeuaYzHGZEzKfy5xfueojA55clfmCsAcdNWmLZLbIbJnZKrN1ZpvMtpntMttndsjsmNkp s0dmz8xemb0z+2U+kpmUOSLzscyRmSmZozPTMjMyx2aOz5yYOSfzUubczHmZz2Y+n/niNNe0ldNW T1sz7fVpn0w7Me3UtNPTzk6Pm95yeuvpbae3nz50+vTpT0+fNf3Z6S9NX1jhnmrVaz74UPNHn1q5 +tU1r699Y92b6zdkv7Xx52Pf8z3xfu+C7pn6Nr6s38Olh874d/Pre/j1PXyLlBSardMWx2BYtICm qAouGAxm+YTP80IS19IOumdkBzgxI8gMeoq6nxVUiS4K9wV05kl7Qh0jP58jnzsHjVOaT6nkTomC +4heXbt1Kwn3tpvd9/05OfHuUnWBe7QhbtfR3AXcuWifX45UxqT9XZRPKenOFQX3NQ4iPdmifVUw okXUYPe7QhF359t7B43xX0Qe93Za9IpuD9CxiFrpRoSwL5fqcC+jHIXdT0jokUrxNaZ3/XGwsQLU t38hLn9eR5S7fVoVdbqvMJdIlrsBS+fbcQctBXUgTbnkLmM+93HywZRhF9yGUdEr4Vv88Wk56M60 VLS16QnqJNzTkcGEe8JA7/zplZpeVekVlV5F6RWPXu3oFeWGGImWjrZoDEly37PVc//HPRsZRJ50 P1+YSrjzeTl5CDQKlA7KAl0A/e2+3tNr7QmIQa9p9FqWw4V39IW7CiiVYxiMfMPcs89I2pIRbWHm 8hw3HY2CGuTtDMWAUhUsRFpDm00tsp3MKbqYOKCCxYoVI+VoJUsNJ47S7UgM3HLGxS4kcfTycvdM UrFiRTK7MoxAVWBEvrchmQ2Xkr0wlC2v7a4OqUerAy/1QEnuZRIskwhkJbOajiXl4RIxKK4sad26 NdnbHmrdoTqoBtnT4wzp3bs3iRgURwqAHMOagLaSJtDAl5OgzWEIr5cE8ZIgHmiJW0vI3hFQ3YwF BEKTcePGkQhowogpRUDNyT7alJnjSFZWFknNgh7J+tV92/U5DCCDnqPKIsXmzyYZL24ke6EDk5ZA 7CVLyBLQAbcOkEQ6zVoOc5fle8m6devIXujcwjD92bp1Kxm29TLZ8nE10ApSZDskbv+X5AFt3n6N VNlFdzsAOg67OkGTQGvJkgMQF7TkwAFYHiA57mUOLHPI0aNHSYHjcPVzd6uDZMH05Pz582QrNMD2 fypD+DKgWNADJOcG7cJB5EAOxHDrhnuAOQCiJ0Y2giAIgiAIgiAIgiAIgiAIgiAIgiAIgiAIgiAI giBIrkKEF/pFWm7Br2fLEhU5kSAhnPpOKKF6KauPKhEJFsKp7xTFzRZKzP2HPgxuwqnvLNSFoA2D i3DqO7G4hMimF9rnFNowuAinvlMV17AuaMTgIpz6TrinkhWXT8kmUqKUhAQP4dR3hLvbz+Zv84ns bp8Iie5MYsWQYCGc+06/sGjBYCec+g59GLpg3yEIgiAIgiDhSKBns+7HCkR49mCSOeQIbO3Cqfly wYdEeBOWPgxg7dCH3uOHniLqQEQakvjnudLD3mz3R2DyR8FCsrjuA+hDAcJ3grDMVjWvvO3d68o+ EjfxPSiEEnPLwggfs8vTTSHyN/Y0JFEHEq3AmUs8lrCQrWotfcC32gV731nB46jK5lW0ufu9qlNk L3xZ5fvLmkAeyEJVhEDcccX29gWiLoBH4WSlV6d65vIF32pHVEtV63qUM9B9ZwWPuhDPBVFvlpeJ v5BJyfKC+l4XrpEUhfK1JYg6hBSWKDYTj7p5Ln3Dt9oR1TKbeC6IerOsAtl+7jsr6NVFvsZQF6FC pnVR5zBDkZ3IXr2HhlQMPbKwqiuQ1PJEY+n76Oxb7YhqqdpXUV6PBJKtqCBRFcYjqpTJL/haFyKm CT0o7x7xvVSXbGtdR+T7yqL4AFEH8nAlUbzTqrJ86QO+1Y6olqp9FeX0SFBUzj99ZwWxLsJhva2L uCpskRbKCgahDxXJUqWEBVFtVa37gG+1E8sfpH1nBaJa6tVFqrMsQfgquewblXp1EVfFFTbcuwjt ID9dvUdRHGkpHCmbWwrpWs9tlOs+4FvtiGoZbH1nBb26SGUX255PlyVIdRGGdvoqa03Pushrmkso mlZaehZK1RRBRzj1nUddfDuaar/A1oURvs2loUdvIFJ1a9ARTn0n1kXqDO1O0cIzm7ouQlDhTbB3 bUiBfYcgCIIgCIIgCIIgCIIgCIIgCIIgCIIgaoi3mIf2xDyqAebhRcyDMWB+GBHzYAaYh/fEPKoO 5qFzA18KZnVfn1uBMYBtrR2o41kOEMheCwi+FsnSkGGehQHzKPY2c6COF8iWDDYj2nBmMIew7Sw0 CWT72R6o4wWyJYNrSAzkiWxnxY1i+aOBA3W8QLZkEBnRthPZPEvArpX+ad5AHS+QLRk0RrSvIOaR bL9WWkz3lUAdL5AtGSxGDEMf+q9pA3TA29CHdhbDLJb9VdaOGGgfBqpe7NutEBxGDEMf+rNhA3RA 9KEvBIcP/duugTnibedDewthHM0fFdaIGXAfBqhezFutEgxGRB9aBH3oF8LPh/5u1cAcEX3oC+hD u0Af+gL60C7Qh76APrQL9KEvoA/tAn3oC+hDu0Af+gL60C7Qh76APrQL9KEvoA/tAn3oC+hDu0Af +oIqmucfKyrQjqGBQQTbXWFwLD6D5y4Me1kFfegLah9q52LaKkcvp198aJau7UOPRHETI7pO1vIz +tCY4PEhY4d6kms+tLIVfWhMEPnQI12+1QD0Ya6APmTMgD70K+hDxgzoQx+IioqKjjLMgT5kzHDb +hAcFGXsIVOiojZsiDKOgj5kzHCb+pDah5rIIIspNMIGtxP186APGTPcnj6EwZDzULR+HjP4EBs2 GA2sAfAhkZyh8IgXfUSyFbv5z4eqA8nXjH3oWUJGgtGH3GDID2Z6mcwQQ7jtrBfH/z4kQueI/xRw CPlQyh4YHzKes+xhWdCJFhUVLbeQl0aU23CD/sXZrzUSm9PdU/b4UL4X0QpCVK/KHKYHFXeUF1X+ TvOIBiVkRGonhrZiD8uCdrRoDwdpZjNBmBuKlqZDYrQXny9YQiM4yeZ+edQeHyoL7FEZ5aElH2rY SQ9+R67MsuMJq0aHE3dURWNBLKZ2W+kczhY0akPHQmlaF807yDyUCuG6HrVBcYnXsLRfzyy5BaS2 JUJfZ7NC5G9kuxGtIET5Ku/NbK38KqTdlQcjHm/kmwxKyAi/I2E6Z9nDsuAZTeWaDQw3vFrwBqZW 5gZCPqTGs0S/1khoSeF/4UXRxAwY9LKmK6RXojGsGSPtrjwY8Xgj32RQQkbkO5qes+xhWfCMFiU4 KNr9TvSTtSFR8jJnZDFqboyH2dnC5ZmTsp/ZkHqZqK96mq5QvOrYSQ+hzLpfcdE8okEJGSH8i/C/ 8CJu8MhsG57RxJGLeyMMiNYmiSobRsni5YoP9fDCh57pfvKhQbqxDz03McIXWF5i/XM2MD7kXBOl NCLziCjdbLvfRW+g0fjx9bbzof6wpkfu+pBxayB8yM3novnBTLgyM4+I0t22YOoN0cLnexohwtuH nqAPPdGIFiW4MEqykSUjRql8GM3d7/BBPfOjDxkz3G4+5F0Yzd/mSrbS/UhE3Nd9ux0tPDKM5nfn rB2lc9uNPmTMcBv6kHvqF8U7iX+IyBGdrWtG9/dzorlsgoGp/9wTxGi9ARV9yJjh9vJhtmCfaN5D gqGio/j/9UdF9+eB3K5R4m7UwEKC1k7oQ8YMt5kP+VuVDZyphIGNmy5y46TWTvyeUdztcZRwUY/m h1U+jtZO6EPGDLejDzfwNxeim6L5sU7zIxFxR/foyTlxA/echl+J1h0O/exDY7RjaGAQwX4f6h+L z+C5C8NepgSbD6UBMYp7fMjdO0tXaT0jRgmXdMF33IAaxQ2HufK9L0tbvcN2H5qid0Qf0XWylp8D 0mucbdw2iuZGRvpGeKBoND903+NwV+No3on81V13r7D1IVuHeoGffKgikC2pF00cETdIhuI9ZjQ/ zBZng/ydiXB5p+/09glXH/qP28eH2fztCf8okB8Vo6MMv+Dv3o9zMJ9buM3WvUehoA+tcjv5UBjM osRHh8Jnc3q7CDtG8Q4WrMvvq7sH+tAqt5EPs4U75Gjuiiw+ATT9aC9KtLC4q6EN0YeWuZ186J7q RYmjmfARH8snzLJrM+/FKKMdc92HujcUnmjuzpBiL4xHNK+OiObuWomMW61iNB4KBowWb1LYv3AT FSXc20SZTQ+DwIdaiZqEmA+1EjUJah9KHykLLmS0YbZ0cY7mb1eCen6IPgxqH0a7/SN964bdhZQo ycgbDD+TRh9a5vbyYRT/tMYbF1L4XfmLs34+9KFVbicfZosXZGtXZDlCBPShvdx2PhRmiPq5TDEP gD60ym3lQxYL2QL60Cq3mQ8DBPrQKuhDf4A+tAr60B8Ekw/5zxaIal0jp1Fi8PnQnnqxb7UK+lCR SPgXolr3zCkjBHxoU73Yt1oFfahIRB/KQB/6gk8+FFYVKWHgQ2HVx3qxb7VKMPjQ1kKYxDJrcGEe Jcyfwm1+6Fu9rGy2RFDYMIh8SORL4pk9VH1oU72sbLYE+lCZqOgn2dIzp4xQ8aHv9bKy2RLB4UMb i6ETieih2gl9KMOsFn7vtcBjV0H04hinyzvElnlU0PnQH/ND//da4AkaH5oQsj40AX3IY09RdKOg D43xcnc/91puYEdh9GOgD43xdnf/9lqu4PPPbRgFQB8a4/Xufu21XIL4UCaTfdGHxviwux97LfdQ P1ZhxiyuYbp5eBH9IMYp9sLqQ3Y0d9dK1MI8vA7mocMMYx/6SND60EduP5v4HSJ/I2tf9KEB6EPb QR+ygNdPfyP3obxV0Ydy9IKgD+1C8qHy7EYfykEf+hvd67JX6AU3SLEXxiOa10REP4hBOmIVfR9q ZDYjdHyolagJ+jAwSD4kyusy+tAN+jAg6NoNfciBPvQ/dAREHxqDPvQz/GUYfWiMP3z4hnmWoIKo 5mz2IcVFHxqj8iHJVuzsVXVWLpXeGmQLGhRPDmxEERJ9aIztPlyavWGduLIy+I2ofoRlE+pwPvrQ OBi7Dwk7OhH4OAwpeomaGTx9KN/Xm65Zt3Tdy8L7lcE+IlpoegtohPLRh8r9ffChTrongfGhmEPt Q2UTetEzK7M3LN2wcvEGbm2ddI0ORmT2s82I2mFYfCjvhWxxTNC4zwkxH7LUS51TvuKVD+FavG7Z 8DJ5ByymKxvMcucqCu/Z4kPdGEQXWR7Zkij/DwsfGtVLmdMWHy6eOjkxKWny5MnZ2UvMs+ceHjbw 1YdMAQw8pNdf7lX5fgYxdFOM0z0xzsl4RKW7jOql9qGyLS13zJJFw5MGgAenTH5qStpi8/y5iIYN ffEh697oQxYfqrDWMYsn941PGjl5xuKk2KRu3IAYxGjY0GsfWtjVyId8EcLOhwz1ss+HC7vHJy1e Sh/cZA8g8X1HTk1aZL5T7qH0nXpwtIK1HY18yL+o+4sIKRr7aK4Hmw/5F6N6yV89YW7hJYvje8wS n9Esjm0aC0PjlGC+MMt8R4j3NrS8m4GHhP7yvK+U+ku9j+a6QYfqpHtmMM7JeESZu0zqJX/1hLA5 cWVSbPxk91Nr3opT25C8sS+NmBzEt8uS8fRsSMzw6s7GwENif2nnVGU0WPfBh2IOf/iQLafuVlOG x8fHL17pfmrNf4KycvHil7PXJU012TE3cZ+PnJk4V3lmMEMjqilGPlTGJLrt76sPxa1EPUD5x4cM 9WLzoUmLz4hvA8PhhnUvL14MVpQeXS+evMxgr1yGt5KBobSsJ6G9jynmHjLHLh9KJhT/94cPWWDz odkVaMnL7o9OVsaPVH6iPCPoZ4hE6TZVBuW0RBw83SvZ3hHMPnSvEnlOPXLLhyyszE6KnbVSYcSV k4PYiISf4SmtJrOk7rXa/c5jGxvoQ034o+uhmVuPxZ0HZCt9mL14ql7m3IeroGY9s7me0fKh2Fie uzARFD7kyx90PmRJ5LYYRU6KTfJImyV9CSzIEIY1vfNOtcUDnbBmBMaHemGJ9Eo8fej5QE8H1gP6 zYeG2xYvS/L4CGVx8H6owre3rsncS+3NQhYv8PCQN5jE1E6SkgUf8tN+wZGSM/UDZOtt1DYSO5q7 ayUyMUBtu8VtNPMFBaIRxQuVquHMd/YC7xtXD62IbD40yGu58oGplyqHXpaVSd2Uj2qWxuvkDAb4 /uBNRzww3dcbgsGHysoRrewh4UN9J65MapqkuEcOfh+KLuQvU5IhTff1hgD1l/Zh2A9ulNP6AOoV vkWcHBubIF2dl4i3Lit5spcGz98KCFYj/H2w6EGPIcMT7YjmBKq/fDSLQU5fLc6Kj4WdFR9L2sTT 739NnZyWJF2m3R/6cVYMHmRO9DCa3IeeO3qksGJ3h+nEC7QPA1UvTbTHhcndynQpk5fk7Zo3fqos mftSWLAhGDGbCK4UqkSk+mnZ1Gvs7TDdaFob7PChpQN6jy3RVk6dlJSUNJz7BuKypUH9p/XiiCjY Tu7DbJkPs6UhMhR8qLXFBh96YVCv8Caa/j6zkuAqHT9j6RtB/Aek0rVZMBy/LhsP+Qy2+NDWDjOK 5blNY1zXQyOeO4JOutk2q3gXS6vYbyybkURiSWybpp3jk5YG9V8yy+9XiNxs1vuJCfs6zDiSb6XU wCRgoOplgGrHGfGxTcGETdvAf01j45sOWBbcf1EvFl9tMeHeWWZAG3rXJoOYh7HXiOaHC1S9GEnq DDYEYpsCbSgDgv+XHYQ3qg3KFELs6VsfR9Rs1gi+H0cgUMezocTuCEtfSoptGgsejB8Q3zkWDNm0 DVyc2/QN7j8jzRauw5qJ6iHRFjRDs2N+AB7zUEyYH4jHPJQh5gdggJD4NvR63DS+b0I8vTaTpqRH fHxfeB8f9EbUwn9NZUZgjhJ4/F+vZSPAeU2pC9s0jW8Db2FQhBGxb3xSvJtZ5iGCC00TBsqJ6ENv 6QvOi+3sNl9TwYRwk9KmTY+kvvF927QJOSPq+g196D0B8CE4r2kb6kLS1G1CmCfS1TbxSUkD6LU5 Ps08SDDhebPMj4boQ+/xf73i3QMhcQ+E9C3cJoMZ4TU+IWlAUo8BPeL7BvdvjahBH/qBAPiQjoMw O2way9mvTRu4KMfDcNgjacCIpElpI5P6JgTxX5J6ou049KFP+L9ek3vw1+M24L1Y7t6kDVXSyEkj Jo1IGjkyqUdI3TSjD/1AAOr1hntSSIdBGeDEpJEjJrn/mzwjJH66XQB96AcCUK9Z9K7EPQS6gZvk vn3p/clIGA/TJs8K8s/2PEEf+gG/12tZfBtpKOzLER8PNyfxSZOnLg41D1LQh37A7/WaQe9MOA/G J/TtkQD/9R3QIwFWQ+rmRAb60A/4vV5p7psT9zDYY4DbhEngxXj4PxTHQgr60A/4vV5JdGZIx8Ie CQPoA8OkHvHxsfTrDj3M9w1O0Id+wO/1GgA+hOFvQI8BnAf5h77xA/qa7xucoA/9gN/rBaMfXJFh LOwBw6BAm/i+SQPM9w1O0Id+wN/1Wuq+QxkQn+Q2Ie/EWNK074Dg/+qhDuhDP+Dves0CH9KbZOF6 zJsxdsCAvsH9r5vpgz70A/6u1+S+MB62IbGxMhfCbQpJGtAX75e9AH3oHSPhVpm4v39IOAPy//VN Qh96A/rQO5Loo+v4hFh+IHSbkL52TuqBPvQC9KF30FvlAUlJogeFRWxo3y9rgT70AT/XayXYsMeA pB7C7QkRRkSS5PlzxSECZzqtDVqJNoM+9IrFcLOclDRANhxy371pGp+APvQG9KFXvASzwwHgw1hx PGzq/pivaY8QHw81Md/XZ7w+hn6p/YB5cdT4ue0mw3U5aUBf3oWd4/vCXDEpKW1y08mh+vQwl/He h+ZZbCP4fJiUQD9X7tG0aXw8jIADkkZMnkX/GdzsAZNMd0W0QB96RVLfAQPoF72SBoxMg2FQfFQz ImSvyrkM+tAresBckA6C6u+8zgrZbx/mMuhDr1i2WPur/yvbhOq3HHIZ9KG99B1hngfxBH1oL6H7 2CZ3CaQPvXsCkx1SPpwczP+UTxAT6PHQq91CyIeLY4P5XwsIXuzyIT/UEdlb9wfk4v/uhfCZufQq ZiZEWPEcNUPIh9ltZpjnQTywyYdEkrQgKh/ySeLOiszcdvHVI7pFcs2HofZrc0GCPT6U+4pISZ4+ lHJmyzYotmiUKJR8OCJk/14vd9H7SNcURRDZG2Ejt7DkQ0Jk+8vDe0F2LrEYb1QCir4PpXV9Hwpe UfhQ8qjah9khRMj+HX1oYuZDcYjjX7MDOz/MPUbiDXMg0fChYCjxFtidxnuQ2yIb8+SZRdPK9vcI HyLMmGqeB7ENpTdkZmJB7kYGQsqHi0PrV7FDHfWlU3p+aJJTSgpPH2bjJ3uBJJDeQB8ieqAP9UjC ryAGEPShHmmh+oOwIQn6EAkG0IdIMIA+RIIBnY91/YN5cRAEQRAEQRAEQRAEQRAEQRAEQRAEQRAE QRAEQRAEQRAECWKiCCF5HQ6SD5ZVoouSaJIDOAhNr+Eg/NJBivLbS5JeXbt1iyKFFF8szs9vzcfv TUikO31/UUU2ciKvcn0bbM/JIeTWsUh3jN38+nl+fQ+/f0lhh05bHN0g/LoIQq7eQUh2EUI+4fN8 eIw7poPuGXn0goNEkDIXaFmKEa50ZdylIySGqGMoyw8bSGk+pZI7JYqUc9e7JBlPNpO6hJYy3l2q LiQZjlOAz13AnYtAyuVIZUxaNq4NMyH8NNB00AzQ06CZoFmgLNBs0DOgOaC5oHmgZ0HPgeaDnge9 AHoRtAD0EmghaBFoMWgJ6GXQUtAy0HLQKyAXaAVoJWgVaDXoVdAa0Gug10FrQW9EcG3zJmg9aAMo G/QWaCNoE+ht0Dugd0Hvgd4HfQDaDNoC+hC0FbQN9BHoY9B20A7QJ6BPQTtBu0C7QXtAn4H2gj4H 7QPtBx0AfQH6EvQV6GvQN6CDoG9B34EOgb4H/QA6DDoC+h/oR9BPoKOgn0HHQMdBJ0AnQadAv4BO g34FnQH9Bvod9AfoT9BZ0DnQedAF0EXQJdBfoL9Bl0H/gK6A/gVdBV0D/Qe6DroBugm6BXLbCmzg AEWAIkFRoDygaFBeUD5QflABUEFQIVBhUBFQUVAMqBioOKgEqCToDlApUGlQGVAsqCyoHKg86E7Q XaC7QU5QBVBFUCVQZdA9oCqge0FVQdVA94HuB1UH1QDVA90EF6tVH9IbgB4ANQQ1AjUGPQh6CNQE 1BTUDNQcFAdqAWoJagVqDWoDagtqB2oP6gDqCOoE6gzqAuoKigd1A3UH9QD1BPUC9Qb1AfUF9QP1 Bz0MegQ0APQoaCBoEGgwaAhoKGgYKAGUCEoCDQeNACWDHgM9DhoJGgVKAaWCRoOeAKWB0kEZoDGg saBxoPGgCaCJoCdBk0BPgSaDpoCmRtJRQBpDHe7xiiMPqGDEuohuDvquUERUobUl6RjyX0Qe93Y6 dFUUx2U6kN6IEPYVRmm6jHIUhhGOG3tK8SNevIM7ry/BePd6ES5/XkeUe3xsVdRJDsD6FAcdVSBq wRUlaSmqEm6cmeKgZcznPs7IHyPJTtifagXhRKHloDvTUpUCOUGDQQk0LmgBaB1oPWgjaA9oL+gi 6DIfoRfoN1CMOxItIa13DEkidxGXO2I70CDyJIzB0JKgLNByON5y8hBoFCgdlAW6APobBKMO6ATE OAPLP0A57sI6oK2KOWCMd/QlcxxQUscwkgAijlTiAkVBESJp60a0JeMjnoPlQtIx4hJxb4iCGuaB Uke/CifselKk4ELSGi6HU4tsJ3OKLiYOuNyUo41QajhxlG5HYsqA72MXks/KO0jc3RDz7plkdmU4 V6uAZ+9tSGbf5yB7q0NNasM52BB82SSBzGo6lpSPc5BFcUXIoLiyoHLkvvbQZqA97aeQQR2qg2qQ b+Fas7AXFG9QHCkAcgxrAtpKIAS5nAT9kASxR9BqlSPt0pcSR8YCAqFJBDQhhCERU4qAmpN9tDkz YcMM8HkW9E7Wr3ABcpDP58K58hxVFik2fzbJeHEj2QudmbiUNv1noL1kL3Ro4Q+h3Fsvky0ffUm2 fFwNtIIU2Q6J2/8leUB9QJu3XyNVdtHdDoCOw65O0CTQWrLwO9o9DpJ1ljbtILIVCp/n8nay/Z/K EKIMKBb0AMm5AWW+5QBX33BPFKi5XQgSVBD0JBJkoCeRYAM9iQQb6Ekk2EBPIsEGehIJNtCTSLCB nkSCDfSknRAl5jsgGmDD2YOmCdGZXoFN5jsmxkNfWgSby1eYWhCb2QLYWD7BPgTiYMkMtpQPWGw8 bGs2sJ28xoumw9ZmAVvJW7xrOGxuc9CTXuJtu2F7m4Ke9Aofmg1b3AxsIW/wYiap8x7xBD3pBV60 mWIXbHND0JPWUYx57gbkPqohwhYx0d2+/BJHSlbQk9YhyrdE+p/IEoX3ss1aERAP0JOW0RrwlOOk e4Ns7PTwJJrSCPSkZbS9Jfck70YxDT1pCfSkVRQNpjlOis50iYOlx8fd2Oz6oCet4uFJIq1InhTN 6tIGm10f9KRFVO0lH/9U991a2SWw3XVBT1rErvbCdtcFPWkR9KTfQU9aBD3pd9CTFkFP+h30pEXQ k34HPWkR7ftuwj//IS7FA3Ppc28PsN11QU9aRdFgMitK/6uXplEQBehJq3h40mXiSc1xEptdH/Sk ZeQtxuJJLQNiqxuAnrSMhidd0sSRSF+X5N2Iw6RF0JPWIcq3qhZkaVBsdCPQk9ZRDJQeDUgYHIeN bgR60gt8bTNsc0OYPWlXO4ZFHN8Obrg3tjN60rs4PlxeTHbFdkZPehvHX/thO6MnvY7j5QDrcwZG 0JPshE8cL67fDLtgO6MnfYlj0ZVM2bGd0ZO+xbH/d3qxndGTPsdhG/2YD4PtjJ60IY72N39YN6vA dkZP2hSHEA3raSaagO2MnrQrjhuixHwHT7Cd0ZO2etIGsJ3Rk+hJY9CT7KAnjUFPsoOeNAbbGT2J njQGPckOetIY9CQ76EljsJ3Rk+hJY9CT7KAnjUFPsoOeNAbbGT2JnjQGPckOetIY9CQ76EljsJ3R k+hJY9CT7KAnjbl9POnddwLloCeNQU9a86S331OVg540Bj1pxZPef3daDnrSGPSkBU/ahfmhmEBP GoPjJDvoSWPQkxbvcdCTfgc9mVvPgsLP23aBnswdT4bjHMAu0JO54cnwnJfaBXoyFzxpF+aHYgI9 aUyIeZKzhtIg/KXZpXs7hOOkMehJ38ZJ4rmFCLbU2YVLRE/qgp708drtaUrBk+p0eQZb4A8dNN62 C/Skr/NJD1Nyg6Q4VOrt4Tv8gdCTOty+nlSZUvh3L9nHSXFuScR1ebK+6YJtXmoX6Enf7nFcvAul jUTwpCJVvZPWOhEXRLGmezLYhXb4XAM96eM9judYJibo9bZHKvFYEHWiFjhOGnO7etIbPOMQebrg Sc5uhp506RvfAuhJY25PT3LjovVx0h7Qk8bchp4kgiQXCkkuxVs16Elj0JPsqOMIl1+iWBWmivoX Z8904Xovs7dsyPW3t+0CPRkU126v0IhDhBfJ5ehJX0FPsqMVh8gk+hE96RPoSXY04yhsKF3+ie4O 6Ekz0JPsaMeRP8Ln3xHprfYewQV6Mpw8yRkPPcmBnmTHj3FUt+qKa7fuZz7oSWPQk+wEWxy7wHZG T6InjUFPsoOeNAY9yU7QxCGKRdCAnrydPWn42DLXQE/e3p40+TpcroCeDGFP2oX5oQIKehLHSfSk MehJduzwpHthli/AoCdD0JNEsfAZ9KQx6EkGbB7f0JPGoCcZMJoHEpfoWcm8/I2Mzu0MetKY28KT dqEZnLel54r8rXqXoAI9GZ7jJJFWFJ7U2yWYQE+G2XxSMTQKnjTwsEs/PbdAT4bVsyDlrxXhOGkL 6El2tOII46HoSWlF/la5j0ZaboKezG1Pup0iKwPnHOEeRryX4d4ortqa5VGEU+yrPIxql2ACPRkE nlQMYLwnpY1yAyoyB1ub2wV6Mgg9ScRVonwRcqInWUBPsuPhSeW1m7tHlt0qa3jS8D7aKuhJY243 T6pulF3CCpFl1fCkPI/PoCeNud08qbpRdpl7UsiMnjQDPcmOMo7bX3rXbuVHMmJGvHazgJ5kJ1zj 2AW2M3oSPWkMepId9KQx6El2uDjMh9UFPWkMepIdGke8d/EB9KQx6El28N+lNQY9mQueREIL8y5l AsdJdnCcNOZ2mU+60JO6oCfxWRB60hj0JDvoSWPQk+ygJ43xb72Ieos7gf+Oge4edoCeZAc9ydlS bxf0JDvoSWMMRj35JsGT6nTlHjaAnmQHPclftvHa7TPoSWO04gjfhBa3Kb/oj+Okj6AnjdE2mMqT LuHb0TiftAP0pDHacagFFZ+icYYkLrzvtgH0pDEhHAc9aZ4loGA7oyfRk8agJ9lBTxrjcxyiWPgM epId9KQO/E0PepId9KQxdnhSeFJkB+hJdsLWk3Zhfigm0JPs4DipA29I9CQ76Elj7PCke2GWjxH0 JDth50miWPgMepId9KQOuTe+GYKeZCccPZlL80BD0JPsBJ0n7cL8UEygJ9nBcVIH3pAecYhLvK4L +aTcul8LQk9aAD2pA9GZT/I+Jcp1Iq7oHBk9yQ560hgWT7qUP9OtCXqSHfSkMaye1LnSy3ezBfQk OyHhSbd/hK7inSVk1KmAKpn7yxvFfFJI1cgtAz3Jzu3mSSJu88qTLqKI4RJCKH2uAXqSndvNk9JC ZS5GT3L74H23FuhJY/Q8KdlQchHR3SGk2xk9aZ4loGiURzUX5N1JpLdaoCfZQU8ao1UeovAeelIA PRkYNMvj9p4wUCqu3URM1tjFDtCT7NxWnvQC9CQ76EljsJ3Rk+hJY9CT7IS3J5m7RRf0JDvoSWNo efTuW6yAnmQHPWlMuP77QehJdoLOk3Zhfigm0JPs4DhpDHqSHfSkMe7yoCeZQE8GBnvrFZLeRk+a ZwkodtYrROcA6EnzLAFFszxEvuCNJsw6dXwXwvNS9KR5loDC4El+EJTStPbxvBH3Eo3Y3oCeZCdU PCkZhHehwqdau9hjKfQkO7edJ8Vtgic5x+l70uUK0ft39KR5loCiUR6iHBoVK8aetAH+mIH0NnrS PEtA0SqPcM0WPUmkjLK3yn000rzBHT+w4y160jxLQNEsj2KwEqaVvFN0/EJc6o2ce2W7yePI5qoe cQI9L0VPmmcJKPbViwg2FFMEp3IrgsXFdXlmEWIXHpF1QU+aZwkotnqSeyOmCM4TUqUXwZAansRx khn0pDG8J+XXbrezeIPpedLDfXwU9CQD6EljNMdJVaqGJ+U7KHf3EfQkO2HrSWE0ZPakkBk96S3o SWM07rvl127pKk2EjS55qiyOx7pyfikexvgCj55kJ3w9aQ8anlSmEcGWGpmV2VhBT5pnCSih4ElF ouBJrczKbKygJ82zBJSQ8KQ8lRskxaFSD/QkO+hJY5RxPO7mlY/mcZy0BfSkMao4nnfzQoIi1RP0 JDvoSWPUcTj/yVLFBLzvRk8aE8Jx0JPmWQIKtjN6Ej1pDHqSHfSkMUEThygWLKAnzbMElPDzJP+p pVk+CfSkeZaAEo6eFJ4XMYKeNM8SUIKufezC/FAC6EnzLExgHB14Q6In2cE4xtjhSffCLJ8EetI8 CxPh5yXFwmfQk+xgHB2sj2+GoCfZwTg6WJ8HGoKeZCds49iF+aGYQE+yg3F04A2pikNkry5+syDZ G08zoyfZwTg6EM35pIYnOed6mFMFepKd8POSYuEz6El2MI4O2uOb15h6kkiGlDyJ125fCEdP6t4v E5foWcm8vH90bmcUiYL7ZJ4kUqrMky4P0JPs2BYn2NAspMw3yhX5W/Uu8jUivaIn1WAcHXhDMnnS JWXUO64qnchexXBCovjrlhonBXqSnXD0pHuhuU3LkwYedumnWwU9yU4uxtGzjS1oxFH9TKrgSd38 hulWQU+ycxt50iWMh6InpRX5W+U+GmnegJ5kx844ykmU0PP8DIv3AJGnaRzcr/VSFFK4yPNzP/3b IltAT7JjYxzObup10YpyTyq3qOLYQgjHQU+aZ2HC7TXZGMSvanmS8Blkb5Vx7AA9yU4YxyEuIZz0 6ulJ6S5XWCrKgO2MnvSLJ13C8xjBiu4BkwgZOGtKEzpVHFtAT7Jze3hSWJGvElm6ckeDVa9BT7IT znEMPryQPKlzfyvLaAvoSXYwjjEYBz2JcYxBT7KDcYxBT7IT3nGYm1MXbGf0pJ1xzO5fWMB2Rk/a F4cQ9KQ+6El2bIsTbJgXmQn0JDs4ThqDnmQnrOOgJ3VBT7ITVnGI+m1IniPoSfMsTASjJ0N0LoGe NM/ChP1xlIbixz0ulSi/tS585Ui+QwjPb9GT5lmYsD0OUa1w66IViTLRJU9xr9mFyx7Qk+yEgieF UZBoeZK4+Gu0YFHBofZYCj3JTvjHEQ1FxFf9b61LnuRfiSKE96An2Qn7OERaIbzLBOO5B0xCpExE 5kBxnLQH9CQ7t5MnhRX5quQ85ZGJaukr6El2wj+Ox4WXyN8RIY/OgYnnO97AwjRTXHIblQuNOL6B nmTnNvC2/I3oZs6d6nRp4RnHN9CT7NwGcYi0lBmOSC/8nZJioRHHJ9CT7NxOnlRcs2WedMn9KrOt Ko5PoCfZuR3iEGlBFGv8eyKsyBfKfX0GPckOehI9iXGMsT2OND9U329L80aitdBY8QH0JDsYxxj0 JDsYxxj0JDsYxxiMg57EODoQxcJn0JPsYBwd+Dsg9CQ7GMcYOzwpPlq3gaD2JBJamHcpEzhOsoNx dOANiZ5kB+MYY4cn3QuzfIygJ9nBOMagJ9nBOMagJ9lRxxFn0YTbJl0whDXtmTb2nTHoSXZUcUQb 8p7kvh0g+dFzD9mOdoBxjEFPoicxTrB5Uvh7UdkCr91egZ5kR+1JxXySyM0oetKlBfadMehJdtSe FJPQk24wTjDedwsW5X/xBq/dXoGeZAfjGINx0JMYxxj0JDsYxxj0JDtcHN+/AoV9Zwx6kh0ax46v 5WHfGYOeZAf/HRljME4ueNIuzA/FBMYxBsdJdrDvjEFPsuOOg57UBeOE+rMg9LYe6El27IyDcwB9 0JPs2BcH56VGoCfZsS1OsGFeZCYwTrB4UuxT/o3Qy/p9jeOkMehJdjTjEHEDka/I32rtkqv376od 0UvGhJwnpQ28C4k8zSC776AnjbltPSmNh4InuctyoD1J1G+1/21iPk1vV5/AOMHiSWk+6RL7Xi+z 6SZLaBtLsp9L/T+XSW5Szzg+gHGC5h5H9oZI67K3unv4iHRk6ZZJuL0iWp4kfAbZW0UcH8E4QXTf LdiBCOtEWtXaQyfdKkT+hsiSuHW1IaUphbBUvPoOxgnh55PmWZgg8nf8Cn9eiFZ0D5hEMC1nTens UcfxDYyDniTyt0R6q14lsnQZxOONj2Ac9KQ8jqoxiPwd70ndyQR6yRj0JDsYxxj0JDsYxxj0JDsY xxiMg57EOMagJ9kJmjhEsfAZjIOe9N2TwtNMe8A46Ek7PCl+tmMDGCeEPRlsmBeZCYyD4ySOk8ag J9kJJk+6F2b5GME4IehJolj4DMYxBj3JAI5LTKAn2bHDkz7P34jmW5/AOMYEtSftwvxQ+qAnmcFx kgHekESeIN/Mv3KZlH/bxWdV7IAeMAY9yQBRzSeJaoVbF61IlIkueYoijo9gHGOC0pNEsfAZRRwh ttt67nHU05OE2yRZVHSoLWAcY4LTk367XxbqIJlM/2+7JE/yr+gBY8Ldk377vEMwJe8ywXjuAZMb PF28NblsRMyMHjAhqD1pF+aHYoLI36hW5KuS85RHJqqlr2AcY/ziSfMsxvCGJKp1l2gYIUFc8tkU Cymc9E5dB0UmYXe9iqIHjAl3T7oXUoL8jeRWojAgUS889vYRjGNMWHuSR8NWSsNJzhVGVsVCI45P YBxjbjNPii5UXLNlnnTJ/SqzrTqOL2AcY0LLk0RciHaRW0k9sCn3kq/ITCekCRuI50Kxq+9gHGNC 2JP8XYnoR809ZHvJs6AnZWCcXPSkdL+svt+WhleitdBY8QGMY0zoelJ4Ti1bsFy7fQDjGHM7elK8 khIuiIYnXVpgmxuDcXwYJ8UrL3qSgnGMCYgnhRTRhYRfJfxVG6/d3oBxcvf5pC9gHGPQk+xgHGMw DnoS4xiDnmQH4xiDnmQH4xiDcdCTGMeYcPIksQrGMeb2ieM/T5pnUaBbR510PTCOMSEQBz2pA8Yx Bj3JDsYxBj3JDvadMehJT9CTxul6YBxj2D1pfrtkZmZscw6MYwy7J83HT/QkGxjHGAueNAtuemhs cw6MY4wlT3q5ScximkMJ9p0x6El+o8V0OdjmHBjHGKue1N7KdquObc6BcYyx7EmtXRgPim3OgXGM 8cKT6gwBf56JcTjQk4osOu+NwTbnwDjGeOdJKQ/zIOnCNhfAOMZ46UlhR0uHU2TmP/Yh8mRVNNM6 yvbkCi1+mqQ8lEsbj3RZnbT2YW9zoTjam62XR/tDMq/bRxWOqTye/eVRKNY4skSikUMrDuPQ566b eTYZ8txCnxF5sioce5sTmZRbPFaM0on4ormPpThScbQPo4FBeTR38b59lHuylEcoBdFrZI11rXSx FIq2MS0Pq9PMP+BWYVZHdWGY21ysn3ZzsbSVlKBoLM/NDOmq4mgfRgPby2Nj+whFkQdR78gQR1YS 4hJe1XtqxGFymnQxMMspodXmPtXRxjYXE4jONp00rXRVKTQPo4VReTQ7yjNJma7fPop9rZRHEUSV gyGOrCRc5bSaSKuqerG1s5jnFlDklM1PxAFXFcq8zRWzR3lzKQ/l0sazzXWLopumla4sn2dzelMe zY7yTFKm67ePYl+m8mj1l7mX1OnuEMRdEi6aVmtrVVUvtk4G5qFSqx2EhpJetPNrpgs7eba5sjld 2nikyxpIax/WOKpS6BzGE6PyaO3lQ/vovVUgTyfSUt4+VttZXjTxxyBdyp+21Ypj5jH2xlHhUUei qCNRxzGtoyyI/A1DHbXTZXG09mGNoyqOzmE80S+P5lbv20eRia08slBEXFftyhBHKAkRXolLkkZ+ MUkvNr+ZMc0TszqqD2xaR2lPmdxpVttKnqBVFNlmhnRlcXQO44l+eeR1U2/2xLR9VOFYyiOEIoq3 yl1Z44j7Kla08wtJerG5rdqphvvwKCtg43zSJd5yeWTxWDFKt2k+qSqO52HUCXrpUnk0ZqW+tI8y HFN5NPpLXSjWOEIS/+LRSlpV1Yvt3mh5g6UsCpj7zgSMY0wIxDHypHebmHMowb4zBj3p3qS7xWwj UwYV2HfGoCcNzcptN96Mbc6DcYyx4Enz0D56Vg32nTHoSauRPcE258A4xrB70newzTkwjjHoSXYw jjHoSXYwjjHoSXaw74xBT/oOtjkHxjEmoJ60CsYx5vaJ4zdPIoiXMHgSXYsEFPQkEmwoPclf34nC iPyf0YrSWEMQ+1BYivAvKk9KKXoLBLEPFk+KidoLBLEVz0uvNU9q380jiPfozicls5mNk+hJxFY8 r90uaZwkYhYiLVwaawhiH4bzSd6Twn03l5dorCGIfTB4Ur4RQfwOw3xS2OZCkECAl14k2EBPIsEG ehIJNtCTSLCBnkSCDfQkEmygJ5FgAz2JBBvoSSTYQE8iwQZ6Egk20JNIsEFIFCEkr8NB8sGySnRR Ek1yAIc7vYaD8EsHKcpvL0l6de3WLYoUInLy81vz8XsTEulO319UkY2cyCu9p7m2wfacHEJ6FMnj jrGbX2/Jr+/h9y8p7NRpC92N/A9er95BSFYMIZ/weYrAPlxc2DMy76wIEkFazoyAlGKEK10Zd+kI iSHqGMry031K8ymV3ClRpJy73iXJeLKZ1CW0lPHuUnUhySQTKjsNNB00A/Q0aCZoFigLNBv0DGgO aC5oHuhZ0HOg+aDnQS+AXgQtAL0EWghaBFoMWgJ6GbQUtAy0HPQKyAVaAVoJWgVaDXoVtAb0Guh1 0FrQG6B1oDdB60EbQNmgt0AbQZtAb4PeAb0Leg/0PugD0GbQFtCHoK2gbaCPQB+DtoN2gD4BfQra CdoF2g3aA/oMtBf0OWgfaD/oAOgL0Jegr0Bfg74BHQR9C/oOdAj0PegH0GHQEdD/QD+CfgIdBf0M OgY6DjoBOgk6BfoFdBr0K+gM6DfQ76A/QH+CzoLOgc6DLoAugi6B/gL9DboM+gd0BfQv6CroGug/ 0HXQDdBN0C1QDoieIA5QBCgSFAXKA4oG5QXlA+UHFQAVBBUCFQYVARUFxYCKgYqDSoBKgu4AlQKV BpUBxYLKgsqByoPuBN0FuhvkBFUAVQRVAlUG3QOqAroXVBVUDXQf6H5QdVANUE1QLVBtUB1QXVA9 UH1QA9ADoIagRqDGoAdBD4GagJqCmoGag+JALUAtQa1ArUFtQG1B7UDtQR1AHUGdQJ1BXUBdQfEg GEpId1APUE9QL1BvUB9QX1A/UH/Qw6BHQANAj4IGggaBBoOGgIaChoESQImgJNBw0AhQMugx0OOg kaBRoBRQKmg06AlQGigdlAEaAxoLGgcaD5oAmgh6EjQJ9BRoMmgKaCooEzQNNB00A/Q0aCZoFigL NBv0DGgOaC5oHuhZ0HOg+aDnQS+AXgQtAL0EWghaBFoMWgJ6GbQUtAy0HPQKyAVaAVoJWgVaDXoV tAb0Guh10FrQG6B1oDdB60EbQNmgt0AbQZtAb4PeAb0Leg/0PugD0GbQFtCHoK2gbaCPQB+DtoN2 gD4BfQraCdoF2g3aA/oMtBf0OWgfaD/oAOgL0Jegr0Bfg74BHQR9C/oOdAj0PegH0GHQEdD/QD+C fgIdBf0MOgY6DjoBOgk6BfoFdBr0K+gM6DfQ76A/QH+CzoLOgc6DLoAugi6B/gL9DboM+gd0BfQv 6CroGug/0HXQDdBN0C0QXBbgZIfzHxQBigRFgfKAokF5QflA+UEFQAVBhUCFQfRiVRQUAyoGKg4q ASoJugNUClQaVAYUCyoLKgcqD7oTdBfobpATVAFUEVQJVBl0D6gK6F5QVVA10H2g+0HVQTVANUG1 QLVBdUB1QfVA9UENQA+AGoIagRqDHgQ9BGoCagpqBmoOigO1ALUEtQK1BrUBtQW1A7UHdQB1BHUC dQZ1AXUFxYO6gbqDeoB6gnqBeoP6gPqC+oH6gx4GPQIaAHoUNBA0CDQYNAQ0FDQMlABKBCWBhoNG gJJBj4EeB40EjQKlgFJBo0FPgNJA6aAM0BjQWNA40HjQBNBE0JOgSaCnQJNBU0BTQZmgaaDpoBmg p0EzQbNAWaDZoGdAc0BzQfNAz4KeA80HPQ96AfQiaAHoJdBC0CLQYtAS0MugpaBloOWgV0Au0ArQ StAq0GrQq6A1oNdAr4PWgt4ArQO9CVoP2gDKBr0F2gjaBHob9A7oXdB7oPdBH4A2g7aAPgRtBW0D fQT6GLQdtAP0CehT0E7QLtBu0B7QZ6C9oM9B+0D7QQdAX4C+BH0F+hr0Degg6FvQd6BDoO9BP4AO g46A/gf6EfQT6CjoZ9Ax0HHQCdBJ0CnQL6DToF9BZ0C/gX4H/QH6E3QWdA50HnQBdBF0CfQX6G/Q ZdA/oCugf0FXQddA/4Gug26AboJugXJAjmg490kBfrZYwD1LpCmXI5VzSjpV8JxDOwg3DybcQEIK RtBZKX1XKCK7yNU7aIz/6NDinnHmkIrivJxOpG9ECPtyqdysPcpR2D3DpUcqxc946esRyHwJ5ruZ McKsP8o9P25V1EkOwPohx3Y68SWvFbl4By1FVXhPUw45aBnzuY+zA4ayXUWIWysIJwotB92ZlqoU yAkaDEoATQJNAS0ArQOtB20E7QHtBV3kI/wE+g0UQ/hpFYGDwFoSuYu43BHbgQaRJ2EODucdKAu0 HI63nDwEGgVKB2WBLoD+BkENQCcgxhlY/gHKcRfWAW1VzAFzfEdfMscBJXUMIwkg4kglLlAUVCaS tm5EE1BbMj7iOdI94hIkwjrdGFWKFCm4kLSmt0FFYP8ik8jUItvJnKKLiQNuN8rRRig1nDhKtyMx ZWCUjF1IPivvIHF3Q8y7Z5LZlWFkrwIj3L0Nyez7HGRvdahJbRixG8Io1iSBzGo6lpSPc5BFcUXI oLiyoHLkvvbQXqBBHaqDapChg6Bog+JIAdAeWHEMawLaSmB3cjkJ+iAJ4o6gVRpC2qUvJY6MBQTC kojxtLiDQNtJxJQioOZkH23OzAkkNQt6JetXGKpgfY6DfD4Xrk7zZ5OMFzeSvdCBiUtpk38G2kv2 QicW/hDKu/Uy2fLRl2TLx9VAK0iR7ZC4/V+SB9QHtHn7NVJlF93tAOg47OoETQKtJQu/g9EN1OQn GKWPUUGf/uEgWWdhtIFKbP+nMoQqA4oFPUBybkD5bznAzzfcN4rU3OZ3uQgStKB/kVAG/YuEMuhf JJRB/yKhDPoXCWXQv0gog/5FQhn0LxLKoH+RUAb9i4Qy6F8klEH/IqEM+hcJZdC/SCiD/kVCGfv9 i2cE4gvW/IP+RYKLYPIvehlhwXvP+M+/9M/aDDMiiIDMK0HhX/cfZaJ9EVYkw+S6fxHEF8wtJsMf 4693JUFuZyTLBNH8AUEsIfqHGbx/Q4IAmVmC5/kZGhhhQ26U4PHv7QVTve1unDBsbPRvrsBYbTSw GehfeyGc+PsLbiFbEW5YXeJ8idviErbwAfgZHlEElfblk7nY3P7CIbjDy94JqfKA4QP6114E/0pr ilelIUWzSfsQ7j/ZFim7IoT0Rra/LJpHXClCOGGtQvZXP9waVHKmsKZ4JZIHPRwnZuAcLGxxyTeK 0egbYezlwsk9L6UTPp+QyxVmWKuQ/dUPtwZVTBwk+wmvzP6VtrgEpwo5+BVZBtm6EI3IU8RDuMKt uS1WyP7qh1uDSs4U1hSvcv+K819xHivuy6dJe7k8V9y7urgzhbhkk1z+fymokE/cMYxA/9oLm39l WTzXPNHxr2K79EbaqMxmdpSQBP1rL4J/PecPLnmSaGQhg7F/FXMSYaiWbVe8kR9EmSv87Iv+RUIa 9C8SyqB/kVAG/YuEMuhfJJRB/yKhDPoXCWXQv0gog/5FQhn0LxLKoH+RUCZc/IvnQWiRO/2O/kXs Af2rBP0bWqB/laB/Qwv0rxL0b2iB/lWC/g0t0L9K0L+hBfpXCfo3tED/KkH/hhboXyXo39AC/asE /RtaoH+VoH9DC/SvEvRvaIH+VYL+DS3Qv0rQv6EF+lcJ+je0QP8qQf+GFuhfJejf0AL9qwT9G1qg f5Wgf0ML9K8S9G9o4XN/EcWCEfQvYg+++1f2T4Iwg/5F7MEO/8p+zp4R9C9iD8QuzA8lA/2L2AOO v0rQv6EFzn+VoH9DBKJY+Az6FwkoXo2b+qB/kYDi1bxVn7DxLxJamHcpEzj+IgGFN692fxHV/EJc 151zoH+RgEKM5r+e/2a5cqG1hxXQv4g9ePaXNK8g4qqYj+j9483oXyQ30PCvS2/8FTdogP4NHojL 6uwvdNGojdut0q2dzMtyJ3vuZAH0rz+xPvsLXbSqQxSeld4btQD6NziQHioRcVUafXQvnyGLthmJ yyWOv4KN8flDKMB1kqKrZP4NO/vmUr+jf/2G261WZ3+hC/pXSej3L1HYlG32F7qgf5WEQffysz9p zHWnid4NLwOjf5WE2/U13EH/KkH/hhboXyXo39AC/cujmC4ioQL6l8fw+0xIsIL+5VF+UoWECGHj X7swPxQSROD4y8ObF/0bWqB/eQjOf0MR9K8S9G9ogf5Vgv4NLdC/StC/oQX6Vwn6N7QIb/8S8VV8 R+z8Hj6S29wu/hVMrFzo7YGECuHrX9WHEsrnuzb9DgCS24Sxf91STBZk/tUrAvo3tAhf//JuFT3r j98BQHKbMPav6Fi1f4m40NoHCSXC2b8u/iNhacx1r4ne1fY8EkqEtX+9AP0bWqB/laB/Qwv0rxL0 b2iB/lWC/g0t0L9K0L+hBfpXCfo3tED/KkH/hhbh5V/f//wS/RtahJN/7fjzYfRvaBE+/rXnz9/R v6FF2PjXLswPhQQROP4qQf+GFmF1/4b+ve0Ir+cPvoP+DS3Qv0rQv6EF+lcJ+je0QP8qQf+GFuhf JVwcfIwWKqB/ldA4+Bg4dED/KrHrOTISGNC/SnQ+lUOCFfMuZQLHXyQ3QP8qccdB/4YM6F8laNzQ Av2rBP0bWqB/laB/Q4vw9i8R57L8TZn04hJShTmvUZzQgAi1dK8wVjjECXf/Epe8u9xrYpKQJiWE un/lxWescIgTvv6VnoNJfafTnbJfAw7VbhVqqzKweYVDnDD2ryAiJeh0p2zvkPWvS6yOPM28wiFO +PpX6D5pG9HtTmn3kO1Yj9q62Coc4oSxf8WBRpJud4r7h26/EmVNWCsc4oSzf13ye29uGc7PH5RV Y61wiBPW/vWCMBmWbhuEwckkmynoXyQ34K8x6F8e9G9okTu/+4H+ReyB2IX5oWSgfxF7wPFXCfo3 tHD3F/pXBP0bWuROv6N/EXtA/yoJNv9ieYxRl4dIL9y0WHpxCanyXIr9mEH/soLlMUbfv9Jblg/Q 0b/+ActjjLw84pMIIm3T8a/HN/DQv/4By2OMwr/COpES9MZfdT3Qv/4By2OMojyE/59ICXr+VVcE /esfsDzGKMsj8yv3Tt+/HntaAf3LCpbHGPUwKlrXZe0LpOhf/4DlMSZ3+h39ywqWxxj0rxL0izHo Xwr6lxUsjzHoXyXoF2PQvxT/+teXb9OhX4xB/1L86V/fvs2MfjHGrnHCLsLNv75+Gx/9a4xd44Rd hJV/iYBZbn3Qv8bYNU7YRRj5l0iY59cjOP0SDE7hEMqD/rUXEq64guVKzSGURyxcLhM+46+q070k +MbfYHEKBwnXkcK86jL8M/81LyRiL6bd4nfCaP7rsmNehuOvMTj+UvzlX5fPvR18/nW5XD7VyF5w /kvxn39d+PmFX7HrOmcX4edfF35+7EfE8qB/bSV36uF/grg8vH+J9GcOQgYi2ltIltueXxBZZmGj PJOURZbDA/SvEs84sl4w6xw+E0MXiZ0udo9OBUzrZaN9WPDIy8UQoqliSgdRFc8lLomsAIpMYlat PxcWsVJ2I6zFseuoEv6rB3vnCPnNu0iWh7gMe8isXoq+dikia5TQuGwsaOZVFUBaEfYgqkPpFUC+ l1hW9K8FlHEIIbKhyqhzXC5h2s3aRWIsn/xLIS5hQDUqIYN9GNDIq7oASJcWIiRLJfIoAF80ebpL mj+IWXSLaKXsRliLY9dRJfxTD7HzheY37BxFBOMuksfx0b+CA1lKaFI2BjRzGl4ApDRlAndkWWZV JiEQVx2XDuwlN8ZaHLuOKuGnehArnSOtCwu9LlLsathDLPWyzT4MeOTl6yBu8igAURdA2KpVAGGD FBL9awl1HGFoZOkcKYJZFyl29cm/fAgxp3EJzcpmjmdeccAXV/l18QIgHVvMJ+Ry8eXQuDrJshgU 0UrZjbAWx66jSvitHtJl2GXaOWImeV6XVhdJcUx6yLRettrHHLva2S7sKo+1OPa3Qu7Uw/9geYxB /ypBvxiD/qWgf1nB8hiD/lWCfjEG/UtB/7KC5TEG/asE/WIM+peC/mUFy2MM+lcJ+sUY9C8F/csK lscY9K8S9Isx6F8K+pcVLI8x6F8l6Bdj0L8U9C8rWB5j0L9K0C/GoH8p6F9WsDzGoH+VoF+MQf9S 0L+sYHmMQf8qCYL+URQB/WuMD+XxoZ3RvwYo/poH/WuML/71vp3RvwYQ+d+joX+N8c2/3rYz+tcA QmQtGzR+Cbby8PjqX+/aGf1rACGylg0e/wZZeXh896839fKDf8OS4PKv8KsM4QeOvzZi3ty5iXn5 A4od46/1euH4ywaOv4EBx18bkbUqzn/NCJv5r3kWJoLHv/yKcd6AE37+5VeM86pA/xoga1X0rxm+ +ldcMcrpAfrXAFmrhqJfiPjTgNwqJ94sQt3kr3wqEXckFqrtm39lK/r5NAhl//LNLL/wBFP/WCie N5juKdVRY52IIsKqIoVwbwx+b12N9zVRYi2OXUeVCFg9FI0trgdN/1gpnjcw7SgdXjy4tJ+8APLU wLSPHtbi2HVUiYDWgyhfg61/VP7VL54XMOyovKEn4gVBugCIJSJiHimH/9tHC2tx7DqqRADrITwu 5A0SbP1joXhewLSfou6ciMszTZkqZOSK62LE23qosRbHrqNKBLQeRLCFKyj7h7l4XmC6n6rungUg 8gIQKTVw7aOFtTh2HVUiYPVQ9Id6Pff7R3EscV2veNYx309+seFWiUtMIMLVQdY0sl1cio0seFsP Ndbi2HVUicDVQ+oPYTWo+kcsjrhqUDzr2N9zvoH+VRKu/WMX6F8K+pcVLI8x6F8l6Bdj0L8U9C8r WB5j0L9K0C/GoH8p6F9WsDzGoH+VoF+MQf9S0L+sYHmMQf8qQb8Yg/6loH9ZwfIYE47+Zf92gSfo F2Psame7CD//it9M8Ar0rzF2tbNdhJt/CUH/+hO72tkuwsq/RMAstz7B6ZdgcAqHXe1sF2HkXyJh nl+PIPRvkDiFw652touw8W+YY94CgcG8pCGKedVl+GP89bowCoJv/NVr8FzCpna2i3Ca/+o1eUjD 18us/oEinNuZHf/4V2pZk8wGBOH8l74GlX/taGe7CKfx170MS/8GD3a1s12Em399vdqif42xq53t Ivz869vVFv1rjF3tbBfh6F9fMI8jDjtEfJFexTTZRn4PbrwiUjYmrNZLPJaYoHxVFtA64Xp+3zb+ lfpeYVH5FpV/+VVuYfHno6zWSziItKNhAa1jvht3mgqzC1lTCY2gbp+Ant96WItj11ElAloP4SGo S94F0qqULkYjQqqf/UtRHtq4gJYx3Y2PrT68TMo3ij0C0j6aWItj11ElAlgPIja2y+WS2UKRJnWN Sza+BKB/+GGPSOtGBbQM027igaRFEJ3fmliLY9dRJQJaDyI2uMwX4qq6f2Q9SVy8lV2seFEvpTWM C2gZht3U565UAuHwuXl+62Atjl1HlQhYPTT8YGAPWb/xubiucrFisV5SUYgiRbeAVmHajUivxoeX 0gLUPrpYi2PXUSUCVw9x7CD8mtQV/MAis4eQR8wp6zcmrNZLPJYswaiAVjHdjbehkJUoktT+lW1G /9qC/SXzjdArj/IMCrbzWw/0r3/A8hiD/lWCfjEG/UtB/7KC5TEG/asE/WIM+peC/mUFy2MM+lcJ +sUY9C8F/csKlscY9K8S9Isx6F8K+pcVLI8x6F8l6Bdj0L8U9C8rWB5j0L9K0C/GoH8p6F9WsDzG oH+VBEH/KIqA/jXGh/L40M7oXwOI/Ouv6F9jfPGv9+2M/jWAEFnLon+N8c2/3rYz+tcAQmQtGzR+ Cbby8PjqX+/aGf1rACGylg0e/wZZeXh896839fKDf8OS4PKvuzxhCY6/NmLe3LmJefkDih3jr/V6 4fjLBo6/gQHHXxuRtSrOf80Im/mveRYmgse//Ipx3oATfv7lV4zzqkD/GiBrVfSvGb76V1wxyukB +tcAWauif83wzb+yFf18GoSQf/mzVHGhIR7J0nnMT6e4pZBZ2CjPJGWR5fAA/WtM7oxbIeRfLkUw o8qSkkdV7naJS/nNrSKTmNXwBxfN68WfBnacXwx4ZlUdwpfji8vAn9/W4th1VAk/1kPe4GJjSvm4 NXeDKzpRaHl568v3EjvHN/+Kh3cR2bpyRTqAfKtG+czxyCoeWeMIVo+vyCRm9fH8ZsNaHLuOKuHP ehBZL4nDgnx8kW2VRREbXzk4ulzS+GJT/6j8K63wCUIpNMrns3/FRCm098eX70WELOhfC+j0j9Ql YrPKciu3Cgupc1T9owzkXvrSP4ID+LC+nF/maGRUzR+C8PxmwFocu44q4bd6cG2v7AGiseK51d0H sszCdmVI3/1rUj4pTZmgWT5TNLMSoQguH49PVK98Fl/bhwFrcew6qoT/6iGOJ+Iqvy6OL4pW5/IJ uVx8HygHGHF8kVJcOpjWi4uhjEQ0Vjy3ussgy8yER1axmkSx7uXxhQ0uW89vBqzFseuoErlTD/9j Xh5bzy9TPPMJ+9pyfFkmm85vRqzFseuoErlTD/+D5TEG/asE/WIM+peC/mUFy2MM+lcJ+sUY9C8F /csKlscY9K8S9Isx6F8K+pcVLI8xQepfwuXh8hFCxCeEwuc8hEuX72AL6Bdj0L8Ui/5VvLqXRJFB /sZH0C/GoH8p3vhXSOAWsjTlGx9BvxiD/qV4519CpGGXcAnyHWwB/WIM+pfi4/gr/q/YwRbQL8ag fylM/hUtSsRE2dgrN7j8jY+gX4xB/1KY/Kv4Sh63VPgX5w+5APqX4l1uYdYrT1Pn8RX0izHoXwrL +KuxInMu+jd3QP9S7G8F9G9gQP9S0L+sYHmMQf8qQb8Yg/6l+Ne/zH/MpQH6xRi72tkuws+/Fv4Y UQP0rzF2tbNdhJt/ZV9V8wr0rzF2tbNdhJV/iYBZbn2C0y/B4BQOu9rZLoLMv3x3uZduiY3EvxOb jQj/izsSCXVYdoLQv0HiFA672tkugtu/RJYkpci2Sv4Nc1xBgnlJQxTzqsvQz600rqF/Fb/rRhQt 6xGWmaAxCg8JNsfY1M52EWTjr/JLvjL/chuN/BumYwNfL1eQEM7tzI718Vcx/9Xxr9Sy6qjsBN/4 634NKv/a0c52YVcR7PKvS/qSGf8/UexBhBdN/8r87SXB6d/gwa52totg9S/vWyL/e2Pe0S7R4bJx SYqI/vUndrWzXQSpfxUJ4iuTf+Wp1kH/GmNXO9tF0PnXYxu/Lp//Ssma/vUF9K8x4Voe+/zrHQGr B38CiRdPwkmVrDy7hE1CXgvFtVovoRziuku/eN7AsKflFpJGJsvNg/5VYR6HCC9SDxDVikv4lRWX LFXMqLjvNMNyveTucBkXzxtYdrTYQrLtxGWxebyviAprcew6qkQA6yFrc5es5ZWbpd4SUsVu8q9/ VUc2LJ4XMO1ovYWIlIr+9QWWOO6WFq+O0tWPCMlid0l5pBzWOsiLesmPbFw8L2Dbj8gPYtpC8u3o X99giiMOpi6xJ6QVKU2ZKmTk+srFiDf1kh3auHhewLgfEVzrMm8hRZLF5vG6HmqsxbHrqBIBqwff zGJWj94hLtVW5S5+9q/cGLJ1neJZh2E/qy2kSAo//8rqLZzS8g5S5PId8zji1U5cFcpG+GSPQorz B5diIwuW6yUeSzy0QfGsw7Kb1RaStlsvnJfV8MBaHCu5RR8Ql+eLMpcN2BXHLrA8xoSif+UXJ0Uu G0C/GIP+pVj1L1GtoX9zC/QvxZJ/xcmcbAZJXLI5nsuF/g0U6F+K1fGXM6wsQVgVA6F/AwP6l+K9 fwn6N1dB/1J88a+wjv7NDdC/FEv+Vc1/Rf/i/DcXQP9S7G8F9G9gQP9S0L+sYHmMQf8qQb8Yg/6l oH9ZwfIYg/5Vgn4xBv1LQf+yguUxBv2rBP1iDPqXQuRvpS81CM93+RX3Zu69lCRlFnKqI/oE+sUY 9C9F7l/RsrwztVfEJNkG9G/gQf9SiPKtjn/FjNr+lWVD/wYK9C+Fwb+qPydR+1fxYbIyok+gX4xB /1IY/CuuqLYL/pVvV0b0CfSLMehfity/cssScaE2s+RfDX8rI/oE+sUY9C9F7l/58wfRqUT+/IEo nz+IX0aTBwoj/yqKgP41xofy+NDORPOtx5pxqmJLOPmX6DZP7hNO/vW+nT13lBYakbRT+S2qNz4S HP4lttfLLsLLv962s/2tEG7+FVo2aPwSbOXh8dW/3rUz+tcAQmQtGzz+DbLy8PjuX2/q5Qf/hiXB 5V/+XjoMwfHXRsybOzcxL39AsWP8tV4vHH/ZwPE3MOD4ayOyVsX5rxlhM/81z8JE8PiXXzHOG3DC z7/8inFeFYa5hTOC+4DNfc1ycZ/IcXsSl/BJnCxQuPlXXDHKmQuEm3/FFaOcHhjlllwqmJVzsLTC bwtj/8pW9PPlCqbl4V0hVEL1SoQ1IiWLI5W8i1nxoX18aGej3MqgRKguUazLUjz28omQ84sKaVCR OUTHPt5gvqPyGERKVKSpSifrZuISfiOMhdzpd6PcQg8QYb7AnZlSLYkrN+cPwT6+KFuESO8VpfK6 uRh2JPKl1AREowDywnKpYeBfl7yLxYWULFRP0Q+Bq4eyC2TF9OwfRTkD1T/u4yj84tKzjxew7Ehk x5AdWJEmNY1Ldn6HmX+JvOOJtK5IkfayA4Y4RL7kV4JpfCGyEhjbxwuYdiQu8RDSkaXmUrWP0IT8 jnTh1/bRxFocw9x81Yl4meZeXEJPqFL4nfSiWYQlDl887n0Qji9E+F9eLnFVKqc3mO4odZJ8Va8A snbjc3FN5WLF64qosBbHi/IRxUL1NsD1INKrcf9IaYHqH43y6BfPC8x3lM5Wl2zpEhKJogBCHjGn rN2Y8LoiKqzF8aJ8UoWFJEWQgNVDcgOLQaTNQi6uq1ysWK6X6BfBGpIjPO1jHbva2S4C1u8K7G+F wNVDHC2ENSODCCYSc0qZ2QhXv9gF+lcJ+sUY9C8F/csKlscY9K8S9Isx6F8K+pcVLI8x6F8l6Bdj 0L8U9C8rWB5j0L9K0C/GoH8p6F9WsDzGoH+VoF+MQf9S0L+sYHmMQf8qQb8Yg/6loH9ZwfIYg/5V gn4xBv1LQf+yguUxBv2rBP1iDPqXgv5lBctjDPpXSdj1D1FivoMx6F8K+pcVH8qjaVhfXYz+paB/ WfGyPCYm9d7D6F8K+pcVr8rDZE7vHIz+paB/WbFeHvah1ZtBGP1LQf+yYrU8Fi1p2cHoXwr6lxU/ 29G64c2zBBT0r5KQ7h/vCh+AQ/gP9K+SUO4fb8seiGP4C/SvktDtHx+msv78PSs/g/5VErL9Y73g 8j38eBj/gv5VEqr9I8un/Lk1okp0j7b8Ur6Tiw30LwX9ywpjeVROJNL/RJYovJdt1opgBPqXgv5l xTv/upeK8de9QTYmo3+VoH/9A1t55LnkhnUp5w9ESvPwrxdHCgbQv0rCx7+K8Vd0sUv6HWLVx8fo X3bQv6wwlcfDh0RakfwrGtuljfVDBQHoXyWh71/FuKp6/qCRWwL9ywz6lxWW8gSy7uhfCvqXFfSv MehfJehfY9C/FPQvK+hfY9C/StC/xqB/KehfVrzwFP+ogfvCA/e/7MML6XsQHqB/WUH/smLdUzLb Sv+rlwxxtEH/UtC/rDCVR5GJiAt9/2qOv9YPFQSgf5XcHv7VjIv+ZQb9ywpbeeS5hPfyL/yKX/fl nev18Iv+dYP+ZcU7/6r2snFkRf9S0L+sMJZHYWCP0ZUwhPHiQMEA+ldJGPjXO9C/FkD/ssJaHl/L Hajj2A36V0nI9o9vBQ/QYewH/askdPvHi9+OEsDff0D/+gkr5fG27IE4hr9A/yoJ6f7xrvABOIT/ uF39S6wSEnG8mEPoRrKIZpSwbWfNVF+w7F/zLAp020MnXQ+/x7E4kIRMvXTS9fBvHPQva7oe+nH0 xgxPaE70rzHoXyUBicPkYP5bwnpbddL1QP/6BvpXka47c1NvRv8ag/5VEsA4mvcf6kT0rzH+8a/W jaIakwjGmz0I2f4xaRX0rzH+8a/5DA/9ywbGMcZP/jULYXoA7B8OjGOM3/xrNMIy3H9j/3BgHGP8 51/fyoj9w4FxjPGnf7XHWbbH99g/HBjHGL/6VysQY2jsHw6MY4yf/asebdk/OzXPogD72Rj0r7fI Y7HHxf7hwDjG+N+/0phr5btX2D8cGMeYAPhXCGcpqCIz/8EUkSeropm2h2xP/psxRAqrkV+FR7qs Tlr7sPePUBztzdbLo/3hptftowrHVB7P/vIoFGscWSLRyKETRy+6t7jbwTybDHluoX+JPFkVjr1/ iEzKLR4rRulEfNHcx1IcqTjah9HAoDyau3jfPso9WcojlILoNbLGula6WApF27CURy+612iOCUaY tYe6iMz9I7aFdtOytKuUoGhYz80M6ariaB9GA9vLY2P7CEWRB1HvyBBHVhLiEl7Ve2rH0YvuHdIF ySynhFb/+NQeNvaPmEB0tumkaaWrSqF5GC2MyqO1kw/to9jXSnkUQVQ5GOLISsJVTquJtOPoRfcG ltmTJ4qcsvmUOJCrQpn3j2K2K29a5aFc2nj2j25RdNO00pXl8+H7Z/LdNXbyoX0U+zKVR6u/mHyn SHeHIO6ScNG0Wls7jl5069jx/JdISyKuqwKZ9w//4tk/yqZ3aeORLmtMrX1Y46hKoXMYT4zKo7WX D+2j91aBPJ1IS3n7WG1nedGEX5bl32nmN031AvaGVOHRHkTRHh5/GGbaHrIg8jds7aGRLoujtQ9r HFVxdA7jiX55NLd63z6KTGzlkYUi4rpqV4Y4QkmI8EpckjTym6ZaRysOW2yz9lAP5KbtIe0pkzvN arvKE7SKItvMkK4sjs5hPNEvj7xu6s2emLaPKhxLeYRQRPFWuStrHHFfxYp2frNUy+gEZ4murKyN 81+XeDvpkcVjxSjdpvmvqjieh1En6KVL5dGYRfvSPspwTOXR6C91oVjjCEn8i0cracfRi24N3SgM 4a2WgLmfTcA4xoRGHFv8axDEPD72DwfGMcZ//jWMYXoA7B8OjGOMv/xrNsk1OwL2DwfGMcZP/jUP 4KO/1WA/G4P+tYLP/sf+4cE4xvjHv76D/cOBcYxB/yrBOMagf9nA/uHAOMagf5VgHGPQv2xg/3Bg HGOC1r9WwTjG3FZxct+/COI9dvoXzwUk0KB/kVDGS8/x8xGiCMD/6bwojTUEsRXvTEX4F5V/pRS9 BYLYiq3+FRO1FwhiNz74ypp/dZ+AIIj3eOkp2fxXMqbZ+Iv+RezGO08RaUmkdWH+S5QDL/oX8Rs+ +FcypuBf4fmD/A9RlWsIYit2+le+EUECgZdm05z/Ctu0d0EQ+0GzIaEM+hcJZdC/SCiD/kVCGfQv Esqgf5FQBv2LhDLoXySUQf8ioQyJIoTkdThIPlhWiS5KokkO4HCn13AQfukgRfntJUmvrt26RZFC RE5+fms+fm9CIt3p+4sqspETeaX3EaCNsD0nh5AYWCkD66f59V58zHf4/esrwxCng1NcBKfBkZym RnGiR6fplF9VZTAqE4W1DGZ4WwbaemZlOMwvv+Pb4Wu+HS7y7RCTx7d2oLuwtsM9Dk6dIjiNjuS0 MIoTLUMnL8pA9zuUlyvDSNg/Ftbf58vUmXBl+oDfvwnRZr5DfFuxRVrykJE6+Sj7THzhw7GL90oe lZju7Jo4ztkjddSQFLKtb0ES13GL46f+Bd0ZjI5Nw1g99rYI8a1Px6ZhfDg23+beHZv2v5dtTksQ 0Tc5ZXgCKJ1YPzYd9QTvUcqCLuSVtlUW8kVxeQ7C+XYfrOeJ4tIL8NsdDsEE3/FHO8wnOPhIJUB3 EzpmRpDqfF5+8OTz+ZI+1DR/To7UXeSW9JacBd18yb09gSihZVenuav6i/Y+DqN93tXeJ8Jonx3a +0Qa7TNYe58oo30ot1RtZIK6n+me9Bi0bEI/O4XM0gjh7p/yOulldNJLiivKfpbSpfx6/eww6GcK TRPjuXcA3P28ULOfdfcx6GfdfXYQzeMI9tXcZzDdZ6tmP+vt41762M8UdT+LcyRVv3mfruxnrfze nM8UmnaXPMHkfNbdh6GfPfbZob2PvJ899hmsvY+8nz32oVjs510FuRG+FOxSCtZ3cxcPIkX4hE+p yq/fzBGuGtrc5GfIHxXkWrKRcrMDNt8ijmnT+HV3hdxll/dm49fF3Vby18gMB1fjFbwzY/jtD4Lu 5N46StzIubWKz9+a78bVfP7KfH6hBUuQv6aQqdp1ea+oMi/lOB/3LL9+SjZfrCtkMnGgAuixk3wM OgLWc7/jRk933SKlsp2XXbsbgM7y126ar5Zqey3V9tqq7bVV2+uottP1Daq5w9d8/muHuWv/N7K5 AoXeXZ2P5PJcLcrFvRApbXPD9cfUc5HcW2HU33E5J2f+vzk5ceCX0fk4Lzh+G+qe69N4K+Ag90C+ S5HKY9Ig6liDIc58iLcC4owuKMU6wvddez7f//j6CWWjMejg+mFRaU5UEyRfr6Vap+14mS8j9cB4 Is2hKvPrNL5wukydOpXbeGAJqVfvADlwIIe8/fbbZAd/BtKt9AppdL6p60epf4YbNdXnm4NbveWW dL5R8qjPt3yy820zX56qkdyV5NOCku/pbG4nf1yh7UoQ7vi65f4nc1qb/3JyWl/JydkK88ifb3Hp 7u0w4uuME7fk4wR9T2U0TmQL5z2hVyhC3lKNE2q+5/MLV8sd6nPeIdW9fIR23YtA3WmRjOq+4VpO Tgqs94wmZEt+abuDeNZd3mcOqc/4deL1GPkQ4cbIqKlRUyN/GUrMxkj3rO7TF2pHvrrGIYyRv0E9 5kC5y0A9luX3coy8QSxfpdVjpN6MIbfHyH/5sUgoW17Ze2H8Gciva48/RBx/aDodf+rUqVWndq3G jYV02ja0bAlpQ5IyaqQnp6SkJSYPGwHvRtd4IjW9Rmr66Bq1awd6VFKP4JRdfhqVXs6vHJXe0Tkz CzGMSt3+ycn5Gly9ES5pK25Io5I/zsyCEcazF3pmlpCdmT/qnJkUemaWWCCdmc9APc5BPcZCPaZD PdRnJg0lnJnT+biCmzsR7mzpkJKRmJaQOmpIcoqzQzdnq9RRo8akJA8bkpGcmpLuLDguOWOEs3tq z+rOFmMyRqSmJU90b3EOSUlw9k4fMjzR2SNxdGpaRnLK8ILCiTOCKE+8fvx6R5D8pK7lfhfhriI3 8ZHfBujnJaq8wnHpceQndHt+nVZVPiDVFna0+BhAOA61lHxgKMOv0+OckHUBTaOPjdUDhnCKtYvk LGx0isXBxXMwJOwA+9fMkVvV+BTzxqofmFg1z1TlRWQWf6+gNdHOQy8iMqtOhHo8BQWfCfUoluNp VYpg1Vp8XKF96UWMWrWJ8ejXrPC4IemFxUyKTULXLSBKa87g1ysQbbuJTy5kdovSySs+zZDlLaWT VyuuUMbfiNLGh/l1WkarNqYjpniP4k50OGj57YhD62ZHHLPTina/ldNqNMNple8q9/44HCsyWtru j9PquMXTaqPZabVMOq1aQj1ojNegHr/mMZ6b9VOdVhmEO616ZiSOTXS2Tk1JHTskxbnQ2aVVB2ff 1LSRCXAtKNw6eUjKEGePIeNGJsPlQLWxfWJK2gRnT+F8VG+GwKNHJKY4e42AywvduVfakJT0ronj x6QLfU6fd8vPx+r8Oi2b1fOmtkN53jj5ddo+VnxKoWlqn9oV525iT5xyxJ44Zucf7QuW8094DnCg qPZzAP45lW3PAWg+fA6AzwGEt3Y/B6DHuu2fAxzA5wDePgdwvy/MvcfnAHaNSimq5wADfXwOIJR7 8H/SqOSPM/N9nTNT7znATJ0zk+J+DrBW+RxgA9QjGsrc6j/j5wA1+biCmysS7mzpNmTCqMSUDGeH lPQxaYkJ9J5f9TDAbM5GI7He3pvdstNYgbhlp8dhmdsIbrsYre22wgzXgY3QS7X/49x2PEra7g+3 tY82d5v8OlCGvwdSu40eyn0dkLntD6hHl/84t+2M8rwO0GuH4LYdebg0od0nOTi3tUpNGZY4OsNZ Jz3D6R7LHizcNjU1wTlsBH0OlZSaRp9FZSSOhBuI1JQJhakRE9OGJQ8Z6XQ/r0pJzJC2OtMSnxiT nJaYTj1bmPo2mfcwhKGriSlDho6E1WFDRo5MLxyfMSLRHX6Y8lEXH8W9B326NZo7IdLdEccljxzp TByfDMWN79q5vzM5SdjuTE53Dh8zBO5sMhITEwq3cI5OTU9PhuNBKaQna6MS090PyxLHQw1ThicW dgLuZ2vuoMkpw52j01IzUoeljkx3vgg3S1DICc4haYkLCrdITx8zajQt44PO9okQMnV4Ykpi6ph0 qNfY5LTUFHcpFjrrNHjc2aFnt/TCXdzHoiHTR6SO41pzxJC0BHoEKNco4Zyg12j5efwTv06nKIb3 XrJrbgRDXuF6Hs+QV6CHTl7xGw6yvF/r5NWKK9Sd3pPLx52v+XV6bntzTyWWiwLjDj22N+OXOs79 xDOOewC3WJ4KhL08/GMCzTh0fLQjTg1iT73oOGtHHPodNzv63Ur7CGjFcRJ74phd/+h4bOXevl5R 7Xv7CG5WYdu9PY2H9/Z4by+8tfvenvrrtr+3L4n39nhvH0z39ofyKUelPj7e2++Ack8tQMh8P9/b Z+ucmXr39pN1zkyK+97+gPLe/ijUoy3UI93k3r4KH1dwM/12v/veXry1oDc2L7aC+yBn25Gp49IX mN3T0whac2va4lbv6WmsQNzT0+NYuacf5MM9/Wi47lF3zYcxc77ic0T7XfZBHmv39LP4e2/de/pd ksvWQT02QD36QD3So43v6Wup7unrOTiX9RqRSO+phyanwL32mPREZ2rSg4WdPemNfKozHe7Yx4x2 34IXdsb3dKcN4b9Rkui2ZZr7eySwI71PLuxsFd+tJ80E9/IZ1K+jU0cmD5vgvpnlgvTo2YeLnDw8 ZchI2D09dUzasET6JjFtrPumvrCzxfDhaYnDua+swG14YgLETksdA3fRdNfWyUlJPSEzlLJlF76U UEh6ww/5G9Wu60zPmAB38p1bdE0v3A3u8UfR++90el8Ot//p6VDPoYkZ4xITU2R373CYYYlpGfSu Pz3xiTGJKcMSC7caAofPgMzOUUMSEqHIo0aPTExr7jS7Fb+DaJ9+TsIju0Tu08mrdRvcRCevUyNv aY28kXxehyqvQyOvXlyh7otVt+JZ/Dqtu9VboIeJ5y0QXVfHcTv45mGwt/YfAGjFoaePHXEqEHvi 0NsmO+Jo3ULnZvtQb6rjuIchjTgCWnGo/+yIY3a5ocOflVvoH4to30JHco1i2y00jYe30HgLLby1 +xaa+uu2v4Uuj7fQ3t5C55W9x1tou0alp1S30J18uIWmNzfOq9zNzYpr0qjkjzNztc6ZqXcLna5z ZlLct9DHlTc3Ta9yNzfTrxnfQpfj4wpuplnp2dIjMSkxjc7lnV1SExJHmt030930JuNW75tpmEDc N9NDsExk5NY3+55tD2juGZBwEGLQpXy7XRYSyvMdMS+P85+cnG+u5+T8VoD7TRFxu0OzPDSGojy7 67/eaAacGg7ZwOrGhwvtoaLKC+0ujQuHlTbfCFOB+bCMgzSnQ7mddbgxm0xYKc98XrQs/i7PZIbv fsfdyMmhvyVTGy7UT/r5u9/nI6x99/vjCG67elijXnB/9/uw7E8qoB5PQT2uwKRxoMYzG4owrCXx cYVznlaEDmsthwx7fGhqSqJziPgtg/TCzp6dW6S7n7QM4R+fJDqHJo4YMjYZklJTRk4oLD45qdWl W+ee7rTqzhGp6YnOUXR0dBZ2dk11JkxIGTIqeZjw5Eb46oM7MKSnpSbRR5BmIyktqdZIWoSvodYj Bb1vgnvzSIGmqb8xXZF496mzOk4FYk8crU+vvYljdoWgfWHlVrdvAe1b3ShuFLDtVpfGw1tdvNUV 3tp9q0v9ddvf6p7FW11vb3Xd7/HTYptHpWuqUWmMD7e6MVe4cncr4P9vgn+hc2bq3eou1zkzKe5b 3d+kM7PjFe6b4KUKmH8TvA0fV3BzY8J/N5d+3MZ9Eka/E5uYnlFd/KhO+uNvflbHfzznTjebytED eH6SlMf9vhhNtHBTTGMF4qaYHsfum+IOMHzGwuT9c4gRK/v5AbrMjZtiav4HwSybwTTNZDdE9MjB elNMyyFMM+N0ppl5OIPbNs2k8XCaidNM4a3d00zqr9t+mrljM8FpJn6iEjzTzJP8qGTlikrL99g1 7opaJp9sexBfUekZaMcfVW6UffFytJ8/NbL9jypXSKPPH7IvXvY0+dRI748q3V8l46bSdM48LJV+ 78v9114Z9MtyMHE2mzPTSHrfqHLX1sKcmcYKxJyZHsfuOXNv6IG513NyqIvpUr7dLlcJ88lxE7Tn kwW4XrZtPknj4XwS55PCW7vnk9Rfdswn18G59zis94F52DaT+SSP5bqbzSf1vuRsPp/8Snw4coaf T8bifBIfW+bafDI2XTUq+TDXot/Qufgv9w2dGD/PtVpHWJtrlYzgtuvOtapKZyb9hk5h/hs6f181 nmtt4894+UzJPddyuh9cZiQOSUugf/bu/uv6tMQhI2tkJI9K5P+uYMzoBPpptnBm7CDKM2sjv04P ofWkkvab+kmlVl7hT9XVM7RqmnmjNPNaiWs286NtFIiZHz2O3TO/tuDrcTDj2wMxxvlp5reFLw/9 ZX5ang/58sjvjYSfQv8pgvuqlPqn0GkeK/U6R3+wBWYV6VC/6ib14nFwV1HrT4GrRpiXh44jLaE8 9J7tguIjEPu/FrPY5Cqv/lrMCJ2rPG1799diaktjyX0wfgyC8j8A9Tio8REIRRhLYlRjCc3j/knE Dt3qmN2Z0bxa56fWld3s/KSxvDk/rX6Bgx6H5fzcw/tmIuF88xnvG6GfNkIbVwPP0uXnMJvazm+P ECMYOzhqKr+u7RgZuXFmPvofd2aeuh4cZyb9QJKemcevh+CZWV86M1/+jzszX7vu/ZnZLb4znpkG Z6bzOndm0mVgzsxbEeZn5v9sOjO/uMGdmT1v+f/MrMJwZn59gzszu93y/5m50OKZmWR2ZjaSzswC N7kzs9Qt8zOziOrMpH3o/oa86XlJc9p1XtJYgTgv6XHsOC/n3+TOS7oMv/OyaQ53Xu6E98FwXsbl cOflDngfcudlE+m8nJjDnZcz4b2352Wr9nhe6p+XlGq8Y3+PCrfzcgOUh56X9SKD47zcCHHoeVk7 MrTPyz8gLz0vr0R4f172qIvnpf55OTqCOy/pMvzuMO+M4s7L1Xn8f16y3GE6o7jzckUe/5+Xtt9h tpbOy4ejuPMyKY/5eWlwh2l6ZtK8t+sd5vEo7sykS/+emVbOqHnR3BlVIl9wnFH0x6DoGRWTL7TP qH3R3Bn1fV7vz6ieHbrhGWVwRnXLy51RdBmYa10Owxz0R5uudTfzcWfm9AL+PzPvZTgz6e9b0zOT fj/N32fmIotn5nCzM7O9dGY+mJ87M+n308zOzKKqM5N+EYmeme369jc7MWlWu05MGisQJyY9jh0n Jv1H9+iJSZf+PTHNSkL/GcDf+ZLQpbokDodGSeifcvilJPThMl3mfptMuMF9CEWXHiWJClRJaAne uMEN4G/kakloCY7c4HxyJNfbpPFNzit0mXsloSVIvsk9ek3O9ZL0v5WT8/5Vbumfc4cmszyOvsb3 zjW/tQlLSWgJtvBfqNyi1SYB6x3KhByuTegy99qE9k5+96QkAkZY+u9TRoHy0FscUF5QPlB+UAFQ QVAhUGFQEVBRUAyoGKg4qASoJOgOUClQaRD9kxr6NciyoHKg8qA7QXeB7gY5QRVAFUGVQJVB94Cq gO4FVQVVA90Huh9UHVQDVBNUC0R/W6UOqC6oHqg+qAHoAVBDUCNQY9CDoIdATUBNo7k/P2wOigO1 ALUEtQK1BtHvkH4My4+iuX/fpgOoI6gTqDOoC6grKB7UDdQd1ANE/wyqF6g3iH6FtS+oH6g/6GHQ I6ABoEejud9Rob8HPBg0BDQUNAyUAEoEJYGGg0aAkkGPgR4HjQSNAqWAUkGjQU+A0qK539PNAI0B jQWNA40HTQBNjOZ+g2YS6CnQ5GiuntyElT78ot+3zb1zgjqR/gksvdbSpUdJbJl3sJ4TnxOuJHSZ uyW5Rrjeocvc6x3BH/Rqz+gT7k8Q/FIS2ha0JIxt4qeS0BLMdnAzIbrMvVGcluB3BzcT+j3XSzIh gnt0R5e5VxJagiMRnF+O5GpJaAmSI7kS0WXuncW0BEsiuV5akqsloWyM4kpEl/4pCY3G0jsT8nBj LV3mrk/oTMs9J4vO7ZJ0yMONcB202iRgzwBoSejsjZaksVabBKwkgj/czwLYfOLFdYeldwR/0JIw +sRPJaHXmyV8SZb41bHCY9dqEVxJDL8qxz/B6galmy770RMaR10eB7fKH9/6Y9clDmuPXZMd3Hbd x669ZF+Vo1/bh/KXgnok3TB+7FqMjys8n6Q/h08fu9ZxtuzfxuzBK82s9eC1AH8QKw9eaaxAPHil x2F58Cp8DnGFN476cwgaR/gc4mCE9ucQNI/ZqTD1H+52nvzLLXPvYSUtyd38Y9PF//mrJCyXVvew 8F8g2sTsU6Ic2fDwFLTPa9dyciKhVMv4T2WE7cblsf4p0VRiPlzR8izny9NE9ikRXeqUh5bXqx+t rcEwfNIfLqa/wU3/SrGLnz+1Wm5x+BxlNnz2k31DA+rxEdSjz7/cP4ZsNHzeoRo+6S0u/3mys9uI 1JREsyGU7mDXZ1c0ViCGUHocliHUyrU3jv/BsR3Q4O+E2rV3gOzrsFCPB6D8M6EeC7289ta93a+9 VoyzEY4xABq6NrjySqgZZ7Ds+5r0AQiU/0o+7mMxb4xTD43DxanFYJypwieiMMFoddO/xnFZNE6q mXESJON8CPXYQ2f7UI8qN42NU1plHNo81DgNnD3adHempHZu3c3MPnQXu+xDYwXCPvQ4VuzDMtu5 CAO8+2NsSEz3s31sn+2MkP0tMtiGjpszofB9TOyjN9t5wNm6TStnj8RR3s52vDFPKM92qHno5/zU PJGyn+oJiYvWSKV5qHGofjUxj95Fq6GzR7deeNFiMw69aH1+k7toDQs144xWXrSoYehFq+0t74zT iI46aBwoB+OIU+0WN+Ls9LNxVlg0zmgz42QoRxxqGDrivGZinDIq49B7amqcxs4mvelP7XRISWhm 5h+6j13+obEC4R96HCv+qcPgn8Gwcgzam5Z5Qo5//bPSon+eMPPPeNkPPEChb0A9rkDZB+QY+ydW 5R/6O2PuZ+O13QZKSmyVkmRqILqTXQaisQJhIHocu2+3qIGocWiZS8i2+8NAtt9uTVIaaGEOZ6Ar JgbSu92qU8fZrUWv9r3atOiBt1uE1GN5uAwThiOwvhHG/3TZdjP7WHnYLdjH7B96VNtH7x961LLP w1c524yFevQhxj/wqPcPPdapC7frPftQ+9Tq2bKLmYXobnZZiIYJhIXoIfxhoWRYUgvx/5J16Fho qtJCM2FJLfQr8dJC9cQRCC1k7SJGLUTLbMVCQXERm6G8iFEL0ZHIzEK6F7H64iiEFzG2Z4b063PC V1Bf9LN9bH9mmCXZ5xmoRynIPxPqMdZhbB+9Z4Z1Gjjr1q7tjO+EzwzZzHMcAvV3cCb6O9TMM1cy T9k8nGlKQT2+99Y8D6B5LD3+mRrFmWYvHGtehLTdH+ZZYdE8po9/5sueG0JiDJT/2bzcVzy9efxT p6HwaVe31vj4h5CaDP6hbd4T1A9O3nN+9s8rFv2TYuafBZJ/OkZwvrkL6vG1iX9KqfxD+9ztn0as H3fRPexyD90nEO6hx7HinvsY3XOEd096pLTdH+552aJ7HjNzz2Kle67w7ukTaeye4ir30O+Wu93T mOXzLprbLufQWIFwDj2O3c6h1638kdx1a3WoOWeZ8rpVJZK7bs300jl1a7N84HU7OIdlxhMXwf2p Ugycq/WipO3+cI7tM54Vsi8UQj3eh3p8DxtLRXk346lbBz/wolj1T7Uozj87Q80/C5T+aRvF+ec1 b/1Tl/MPy+ddt4N/WJ420ysX/bVW+utq0/NI2838ExRPm9cqr1zRUH7662r0Nwu9edpctx5+YMFj 1UJH8nAWor/QIGwPCQutV1roCm8h+usWXlnoAfzAgsfSl5xv5eTQUaibw9ooFBQfWGyUWQjqQUch ek9uNgrpfWBRtz5+6k6s24f+zTK1TwkLI1BQ2OddpX0W8va54q19GuDnXcTaRxaj+T80p3/uvdrP 9rH9I4vNkn3ov/1Hf1ZqLP3k3eQCpveRRd2G+JGFpUfOG+i3PK/n5PSEQjU3+cMugRyLf94qmMf2 R87bJPOcg3q8AfUoAfuUN/nDLr1Hzu1SUxOcLSckOit4+8i5EH+kUH7kzPIrNU6+WenSf78qIfwz 3E8X4o6u/me483P9aNs/w03j4T/DTfCf4eax+5/hpv6y45/h3nAtJycF1unvGW7JL233xz/2q/fP cD9EuDE7aqpyzDb9Z7gXbBHH7N/4f4ab/gYl/jPc+M9wS6NSIP8ZbvorpvJRqb3Omcn6z3DT3zWi /ww3Ufw4h/1n5gqdM1OYTdEzswTD42yK+5/hnrtFMRUfxf8z3KeuGf8z3HqPs9uOScsYkZjm7Jua 9ri3j7Ppdne9ItnnU94+zlYm2vc4W/DV9khtXxVmGPHpVTruBuerwYpbPPt9VTrS3FfyEf8MP/FT +4oeyj3iy3z1MtTj0Rucr1pp3OLRUIKvnuPjCu0+hXC+apU6alRiSka6c2Ty44nOF8eNmOBMSE5w Tkgd40xJzWi+wDkkLdE5LnHksNRRiYVbDUlxJmc4hyY6Rw1JSHSmJ48aPTIxrXnh3umJkJie4UxM SkpNy3B2T+3phDfOtOSU4fB/86cLt0pNyUhOGZPoHJLupL8z07cdBEoc1VywxQiitHI/fn040bay k/DILjBldPJW18grHLe2Q2l7J79eg1izPYWmlSQywPa0HHbEqUiCqzxmpzO1F8vpLPwaWU4M9zRH /Wtk1PZX+cvljzHaNy6Euwp63Gxo3rgQ5eW2oRgnR7zkusuzhHtDUxYuXKi5j9kl2mifevXquZdH jx5179+lSxfyxx9/6OxzwJ2WlFSP0EPVW1KPqzAcK+dAElPZaD5aRygd2bFjB9M+NB9J4tqALNFu N/U+9ZbkkCU5B9zHoW2gNelyRETno6Fuv0nXZj9Nuj4prJx0DdCZdDkYJ10x17iL43HZvyvkj4vj u4yTrl/4/DPMJl2/rVZMumpc4y6OO68bT7qqqyZdTsJfHEcmD3vcmZHqTEyAy16XIekZMAPLSM4Y Cde+jAkjTX8ojcZRX5Ec8iuShYkYjRWIiZiTWJuIDYzS9loEw0SMem00PxGb7+eJ2PuMEzHBazP5 q4zuREzltXn8RCzdZCJWk48rtHsPYuS1xPEZnNXSC/dMHJaakuAcmTg2cWThXiOS04T3bVPpvYGw kpwkvBd6mt7sy935E79egWi708mXWj5f0vqLcJq3vEZerdsPmle4LrPEFecbsrwFLeQV6j7eoTyb RvDrtO7qs8k9CFicB2n9dTsXZ6FHHH6Q0YyjdZulVx5+Ju9zeXgjasahba0dZ6tHHMHlWnHMRhvq fiujTVOdK1s09D1tF7PR5iKcnfTXWWPySdv9Mdq8xHBlk9/2Jepc2WibuEebi8rRpjC046//5eT8 ndf4QV9h1ZWNrtLR5j6zSxfNqHWyFSH8bNvCZzI0ljc3HQoYzESPozYTTbNqpnwRQ90nh6GZbnBm mh/JfddJ2B4SZrosM9MNzkz0TwMCaiYSIDPR/HaZiY4wVs2UF8xE9zcy03HI4DZT/hA001XJTPTP JN1myh9gMwVqZKIGsMtMdIRRm0n4TLUU9Mq9xPMzVcDj81nNz1TfbFA7nD9T9deN9CtFlDfSeid1 /gjzG2mh3P+jv/j1D5ce6JNa73NF05O6yRrxpF4K9dgA9XBBPRb/43kjTS3qtysEnRdPdUcKjekG xfLcleFOuQpkEE6CUDbTEMhLzZQI9QhLM9l5haBpembS+7ZHFDG/EQrFb3sAU80eOeVhmLcH8tse eo+c9E4kvUdOtD/dJ1Jn6USy8m2P4H/kpPV9Eb1HQ1p59R45+Rq3oIW83jxycmPx+zZWflCRH0E1 41j5ZF/+yMmX8sgfOanj0LZmjSO4XCtOoB455WO4saNzwE4FYO4N46Uwd83Ny3YlC5ftSv2Uc8AR UA86B+xZ0HO0wTkgkczk7VMC+qdOZnNAaib5jVAomonOAamZ6BwwLM3k76cEn/ONsxgasRxh/JY1 PhHw6olA/fz4RMA99xyNTwQC90QgIsyfCIzHJwIB/TTL7IlASM9TZ+A8NaDzVLNHLCE9T52K81Tb 5qnCl3s/JNwTGvWXe+nx/+Pnjgvh/bugW/xcVnji4HD8wUcRanOdf4ggWFJAnc73CLnJR6zPr3ci XK2FpUMlgceu5OScvcpZISKKK0Nlfp9TfJnozDAR9LusZtX5OH8IDzt4hL+FzqdaIoElL6kYRRTI e5/2aLfUcYlp3VKTUzKcrVOHjaF/HyFzBjV5+8SUtAnOnsJXjYkVuiQPS0tNT03KcFbtUc0pOxZd 7ZuckpA6Lt3pJHkd3MfBg3Y8f0puS3ILfBdVIIKocZ81h744tKxmuZgXF+Uj91e/lk3PmZhIblik 27MId6bOJ1w91hLOszsI94N2ewltHzhzCefPw4T7O/njhPPvb6DSoIuEezZ6lfBDroO7XOSDZSma 5uCes9K/ZqJn/sYI7oz+JYobrumx41NqpA9LS0xMcfYckTqOS6f7dGnVgf6V08iEVqmjyDiuvE+c 4ZZdCbfMp1oS1XJFgfyEv/J4LNvDGTsEzuJEkka8oQiJoH97nUOPkyO7KzWC1r0x/74b/NeYNCSD SGvSm7QgnUlP0ovEkx7wvh1pYxTGTUUYE2mf0frQ+sfMy0xYGv9VsZl/kHVkS7Xf3JkWPdaoafXt jsGxr7mX8v27kWQyjGSQMVD/RJLueQATivP1p35grX87MFePFO59N5IK3Upbn75LJilQFie0RSqU agwZBVtoij5V+eNTX7Iefyoc/+4J/ErKXReHgtmSvn625unn1i+997/Wkfsdb53Pmd2ta7vCBcrS ehXu0L51D+g2er5cykd7eso979OTxZHeo11Lkv1l+d9ha+FunXtx/eVwdzGcOcXc/ne6/xJ2sPta MYWQBQR6hqyH04CQPe6TDM6fGw73qVfAfQLdRZLq0X3qtYMTnj40eXKq+2RdTv9/aDkZtZykLydZ y8mF5eTv7XD1JeQMSfqDuP82w0H6Oshgx5xhDjLMkQDXKkdEZNsI8lzEeLhslYoinfOSGwVIIfBL odbbi0xdXHQOKeYoVqwYKVVueCnSrrSDlIlZGBvnuDtu5t2kYsWKpPJsUqVMw3v7Ou6bTarvJbWX 09rUo3+yQl/qJSWB6iWRhveObTrLEVe+bNyg1q1bk/Z7q3cYVKPDoDM99vTu3TtuUETcoAJNhjm2 QrESmpCky44kJ92N/g8sWZK0hIzYuyDDQcY2HTduHBkfUWRKRPMpEWTqvnGZJCsra09W6q9ZxDGH kLmfk+cGZT03aPb8YhtfzCAL9iYtce9POXBgyQGyNPGz5WTvcrJu3TqycS/5sPDWrVsvbx1W7eMt Kz7e8uH2Iv9uJ/9uz3Nt+2ayq8qBz5Yf/2y5c+/ySXuXr927fMkBGoNGoeTkgA7k0L/KOV6AnOnh gCY+m3X+/Pmky1sr/7O9zL/bY//d/gCEu5Ez6EaBAzR3zg23CWFPWKy7cukb6JH8o9v3hxOryC4q x0v3FylHSLmjHVq36DV+4LnlW8eW2/J2XOyBsjmfXhxWpu7fTZv2zV9i5odNC5SsduV0o68f/m9a 41l3Ne7eaOD+//ZMH7f6m/Elp7YsUXLOlbn/kAL/HF4b8fXRX35dPvCXzCJNNv4el7dHZpOLXZ3F ox4dPzXubMVCr0Zlti+UccIRsWlO7fnFoyrW+frpvPl21fw0rmNM1q640nc5Y7bmi6zWwlk8knmH 5bVHfj9pTGbc3ZBSM+v+PU8va9546aQWzuxG/3zaqlhWVMXMw7BL68FlXvk4slypBqvntndGfBJ7 bGrhOS/TrTHLih3OXh+bWSbv83f+ejG6WcMJk6tMibpSbfOQ/iOff7JY1t4i8+Ys3fnJ9m9zHN9d 3et8JZ7kXdBwS3aH/in3bj5zoEJ0dcfqjs+edBW+3ifHNSW5UqMGfQrtf2Xd9jWf926cc+3+w7Pu KfzWvtL3RP965dLUqu+smtnxqXsP96y9r1bn7mPL3T96UZvr65blXI3Pvv+d/w16qdbb1e8fuSyi +6UqQ9KL9VyU987H7m1/Z+qgl/6+UODOAmfH9v6Y/K/yiz1/33/XrvHtEpr3HFL46YIxYwZmfPv6 oWM1v8jz4K9XyTvnJuxY8P6Cf7q3qP7+/heLvX729XWP18xK6zL75I2hWx+rM7HRdx2z/t2+eMio L6bdvXLzxAN3rqr746R5VfvOfOfgtv+VvTT0UtlX/tf27NCZ7zUoWLD1O70X7h74/Y3ZLR/NbLU1 qftXY+IXPPr37pPvTUkpt2lO7PffV68fs/KxUtc2rejZovTa/N+MPTPqxy7pE3Z0O/D4va82Gpzn zkM1qxxb/MKmv9q1+P2Jx7b1rRBz6vHWC5zRTw8oljXsx4KTYn9o8+PMqEcntpi7psjuOwt2rlrm zRWdMofurzkrb8k6Qyosqrt+U//TTTb8Pn/apgIf/rL5v+vXzn505M9RU74s1vPr9zcNyVP2REa1 99/cPCzz5zzD7sj4vPvZlEbl98z6ds6TRc/u//py0q6X7u/+bLvHfiyVdz3k2cPlGdmk/HOfXbqV 0qRZs3nx97Y61urPe4ZOyL+/zoWIUXMi+/y0acde98Gq7imT4Pz53Nidoxs+2+6V8l+91XnHpU7P Lnjh/cKFCw5qX6N7/XfiNz2aZ9GU/VsTyh76eNry8+efO3Vp45GRS7r/+NXOE43e/uHb5HEnG70/ 6Y681Tcs+LjT4G/ePrE4aX2DPe23ku1thm299eGwak80SSuS55mlX6Q03zjm1LOn200aNnJ24cKV YsrNyB6ybfP7Z06cf+WlhMzjfW5d23bnlZ0pm7cnxdz8d+iGt2uOKr8xOuuT1g+8/+e8l5IWFr+Q 8ECvnEtvPdB3ebGPPmg2ITVrWpsKq3ufmpo4YtqP7773aN62FR8p/XC17r/uPjd+V4NdL33/de2/ K382snNO/DfzRo4o/WF244hHfmxQt/iFmU9uadvrnyVTLk3Y9viTLxz+unZEnVm1B/8481Lxsk3u KhJ5rNacPB8/fM9fU4qeyoyL2jPilfGdHny0het75ytFRr64bfiafq4Ob6zf+2VGvl3Fmz2cd33r e+c223BuYuzh7lduHm3aaU6pZ5aeuzR+hDvwfV+U+aVx3bJ7Os29vC+uSflnd1btsWrfnB+/OD+6 ybsfnVu5ckjUyTumXW1W6MfIYw++U2NOta+W3hy94tH0/vXLdd1Y9+n5Ext88OfeZ9+6MOuhsS/v 7frE+ehHV8069U+z3e1ii+Vv9kjn9Jh20RXv/zLykXvvunBkVNHybd9//K5nf7g+tWnm+HnOZudm 1bj3+Y/6Pbxt+7APml78qOD1Tlt/fWH8A1+Vv6djhcvJKT/8/cpHh59tk9Bm8odf9E8oc1eRLsdq v396zKB9WfmOb6n48vSrTw12vr2s6sCKdepWzDv2zJXar3z8n6tSXJ13oNAVO874tSXUqujltxeN +2lEmcbPzt154tKl/TtLPPnMii6zU0aUyRy/3HlrZ6Mb25YfXEVeeKJxs2aTik3p+lXhfpVjyn19 sFvCzvHVNsSPW3rn9oKX/p58/5UaBXYOaf723Kunh0yaVP5C2WWjGtafO7z1sTdPf/id8+uvs2cu XtPmgw8eP1wnpuHWo1137B20rWu9qkdK9C56atHrn10afWzwsYO0E7/oPXbOzEs9PixUaMedrZ4f 3ubWPZW6F/885WDSBwfuOvLx6QUbxn7YqtXO7x55r8aYEY2qJO7K2FuiRpG5O+489tbFA1UXztla I2ds843D8119bc0X5b5rMOPkg66TbxZJeMRR+NSaks03Zuy90K7k7OcT23558tneZ24e3fvAV9Xr fFx/08YNQ241GFqiVfmVo849vDMip8y5c//dql074kjhhltvphyecx8075mstFMHZ7baNm96wpe7 P9nav0X+Ydd27vrk9YIfTez97Oqt00dlly/apOv6E0n1Nj45LPaZnSdeeTT51ycXFd76y4F9f40d sXFIqXXHD9SevmLOqhuNXkg+PfPyL98Vv/YT2VF5x8Mt9szsMO29Z+r1urN7sU0/bG/7/gMJn49u VGTo8s3DRpz/91xKx/V9nmz7ztKSi8qdabx4fszEBx6q2jGy/iex7crNX1Dqp6Ont+TvcOD69b0N q0+6fuD7Zyb9ve3Y3eWWJdx/6oWfOzzUotyXr/9df82pe6rUaPBTRIvE+ZdGOBpU3tNg0P7srAt3 3vHKhP5J90z86tbGm/vOH/7tr7s6Jr9Se1mzZ1rn/75Xx7+T5vaZmlX6raufJjTuuuevGoMHdf73 vbPPHBj9XIGcSVPuutZz0vWjZ4ZMeupCw0r3Hd3w75eut+dNeOup7ptePz3kUMd89QbWKd701I5Z Rd4vNGdqwVmdTxZPPtGsVqWtDceOn3zz9Ttnvbf0ji9W3hr8YbV3zzasUqlmz/y7ltx64J6aNav+ /fGQ461KX4wuXeTSnc+8+8Fbgw4/knnz0t11jv/7w7+vue7vtmbTew9m9H8n/78lG2fV+2jUusv/ tC+09+9bZZqNfTXxy6m7B+57qPClvmu/vbD95leprgdct/5JvvpYtU/vum/UXwOq/bSl4FuHl5Zc crPkvF+H/Znx0p79WXf8kVTjx++jn6ixdVLXi8/e/PSZS5PHN2nq2v7KK3t+rzLrg38b3lr00X1J +fsV/LpMyymzF+/o9sX9kY92br/p2JyHot/7PK5Is/HrE/dMXdEooUvttbu+HfvklLrzti/54NUS +dIKDHoy8puW33z+ZN9CQ9+dtO+N4QO3xVSf0yb70ug9K6u2qDyzyNqf9xxttHXawf++nTy+4/Sy v77/4p2971tQ6osOB+blaf/80DHv1B1avvWQdYVP9hjbq8uxWj9sejx7xMVll0fdeGryzhOPf+Ys W6TprMfL7ts7vMr0tZ3yNjqVkPrYH1n/1CaR3au0fanY7uJHYl4uuGr7gJ0b/t7yzrJzp3otWHP8 749rD4w9WuBQ72qjn325wcjjv478OqLuqo/eHDX7Col1xtxb4J7pfy3r1eXrA2nH8xYrv+fs+WLb l29/ruasC2d2x+9Yl1lu4Ywew5t0WdowfULx7R9tir6/0eP5plat1qhGpV9KvFmg6i/1p81sfqjB +UOnU9/pkPbMyIFt5w7cWv6D/Q33T772/OXHxkwvEHM64puu08de+3va2h+u7V792v7HDlY65FxX 7Ke5VQ9vq5z1ScdXTr/795lKzV/ZdH3Z9irLHz62okz+MYe+fH/yK9uajJu6pPDwS2v7N/vnyTOn ppVZUWH/kdQLp64kFjn54xuHmma9/2n/h7ve+frfO7u98txb7xYc3q3sqnePvzu3dXKRhF3JTy9+ cM6IXi+feuzvGXdud/3247ELF5offqrwzlNNKjR765Mhv1+a9/HnLU69nzVl4meL2u7ZeqXQhtgK nz25qlaprPuy05asTUn57u1iP2TFbP3uZIPni5VofGbCYdfPx6bcunp9UlLDI50XXfry9eiiz73W quDOYQ9+W/j5xVF1GjT/6JnWzuLbX55895WJNbLqFH2PFBtcutCu1iNyBn+1euO/7xeb8kvxS+cm 3bp+87PNewrU6d265YePlC49rXGxqRmr+rz6+rw8LznqpG2b9UKxSmNjx9Sutyq6zoSRsTW/WPHI pGN7zu3oUXH7gupdbnx4bNL/bv0z+r/8WQlPvfh2g5PbBq7NM+z5uhOqQ6c+vO7zZ6rd+t+chjMO FqrzjiOrztbiscXKnko9G/n1wAOTrx14pf+Q587f3LKvwKb6lSZeeCuz9d4fqkzfXSbrvk5bHSV+ O3Lz4YVJo+6qkkW2duv4ztc3j+U8NPdG+hNHjp1KatRk8p2nj2adG/T1kZMjTlZp8WafRb8VSqzz UrHen75zcGX1kT8UWvXX8JHTTmTurXlmU/zDsdfODTqbcP3fSxlDD018qW+FrP9eK7e6Usk1K7o7 HVGrlgy7EpUel/F2y7FZ22+eKXqlZsPXv3W9npPzd/KafQMmTtp5dPCPjywpds8rLUrtfOTi7MfP nT/98L7+UwY8Ar3a+snTf05bW2D6oXoN3/ho0/UhOakL8l96JOXMqitHvt1d4OaMVemHe7/aYcbu +S98+VTmA1/WTW/02ZNp+dptXXPx+OjBW2v/kDXx693ZE+qucWSlNv8459KPr6/eO+vNkUvvjzuw OSemfIspA2dMLVNu6Pc5++JmHH56wMtHYr+8/tUPrtThbZxbfzp4q3fkybN9+nXufbTso/lPbnsy T9bnPSd+6/yj8OAiXWfuqd8vqfXW1B7Ptjty91vND+dpfq1u3jmLKwzce983B0v1SH/lzuVnf377 zz6Hip/b32JXgahSWW3vvnzwxr6a/8T+/ttXHSbc7Fd83xLnu6dPpD1bptT99U4OqJuZb0m31J6N 90zuvK/5pAZZMW8+8+Pasl2ce5r+ltD6g5SSW7b//u3lu+b9F/18tQP9K8f8kHdT1s/PdD06vWq/ QmXyfbj4wpWbV9fE3lOpT+3e3/1TNm5Z3VVPfrGi9ZMRm/It+H55x5ZHHn794vevPP54cufY7h+u 2132iXPOQY2zLr740RuJb6e9dyX/5avRKcuePlV8xfe/Hnc+ecfDXe/94O/VKSVPZ/Y7vvmhuM6V Wp2dNHvtlBLdq9YcsWrJPRkRT0x+o0ybCRGbxlyN+6v70Pxl31j1fOGTI+f1q/Btxs1GzpkdG89c 9PJ+Z0zzQlmfv5eavvix6M01Yx65+nLc+hN5N9S6L+viqFe+rTuk68W4R7Jvnqh1rNHRafka7v/z 7tEJ9fYsadhmerfWxbqU/W1gzo4Rsz/OH/NJFRI580yJ7Ulxl088Rs791XXnqnf6vXfnW79t/TpP yqgmPx16cHdUTFb+Mzvr3ny797drM/+evv7xCV+02lBn14zEmKxRcSPLvdfk7doZn3zaeG3BzMNR u14Z+tyLxZ6oXuDvzs73yaYx39WcX+yRpVHR3Y8uH3a+7LgL32duWLPxQOZbw3psLVx+a/mnNh7Y 9fz0CnlazfzfrDzvL/nm8ehvL568/0rzfwfVaHBH6qEiX9316qP1Xng0fdTF9a2fn+GMajHjie4t +0yr/OrUIWV7PT/9m3sPdy7duVKdhAp742Iy869qVuDrJd+k5fQevmvi1nytr779Xs1Kz8yp3mTw xFHtH9+14s++ne9ecfGHP3vW+qRP/ZqFXzj4U+cR/2RmfPbQI18MJqv6ffTo6ObTv+7w0stNKvxT 5lCnqQ9VHT5vxEtvF32vf7UPCp4/02Rmty+f/7POukVkXExm1UlrGiYuKVHo/PCIOk/seOW+IRPn jagYNf7dwdVKjHusxvQC5b8Z2HPte6nLH40auifqzUGV2kZ3emL9h1fyDv00Mw5KFvHEr5k36H1p zKdf3L2g2Lz9J5796Om5V+eM3z1+xvWCcWNOly12b/rxh2dsartr058t1zSeN//I1DxnFxSffGvu 6qxyD+zLurt6pa75Xvq1XrUTZ96qtiJ/6/avPTd89bT/vdw5NU/PB3+I2bvs+aujX9j315Hv/i39 +dBuHSLqNJz8wbv9T/x2474yvarPXHb6s/bjhuW7te5gxczF+x+Z+VmzlLa/lPnr7X05rbtf3hK3 aEzvl7ZU3pc1osx/NbOeSojp3b3rqEZNas4vV7LDStJ/W91fx3U5UKDPA7Ffnf6vfmSpfWVXL/t4 R7FvznWsef+cUYXadeleucXJ6rPfWzV8xdNZyU9UrfBL+7en7Hxw4KR5/c42O1Isq83pqnmWvrSv WMHXMi5lPb+pV5UF/Wv0cD1a7Jn+fQ7tLvDtjW+faFt97N2Z/X5/cEd2/xP39pld8c0667d1+Mbx zX37hy6q2DFj0vPtY+s0XPbnL8dr1l3V+IPna7+x7bdKT2RnH34tq/fKyn0zeg86fW5r+vTVP771 e7N9WWu6p13Ps7pKbPFr3RIaPJrUeFh6hXrF6t69rtXIhXnbJJc61Pjt1FtrY+ts7rv22Z/PJbTe cu70jayfqkztMXdL5f917X695OyNn3Y732do5cn9YiJ3HPrxx3y7dtV86IWpZTvXqNCjRt4J9724 pdvgz7e/tPuBd6f3fPMT16oSry96vd21eVHfvjn6qcEVH9pX/UzbG7EdUitUbzn2nnNdXutxIevz gR0efrtPgw73v7Bz91eOQrMKVOk94p7+hdZVzZo7eOCiNmV7lxu1aWDJN/ccf2NszxffXlYuss6y ny+26LymR/OsNwZ2qPv2pEP1H+vR+8kXK9R6c+/f5ZYUO9K83pxlDVaNSLhyOOmpNxoebTa8foNq +7dEVfwpssvqBzKrduuxtdB7h2Lu33P6zph3GlT8atIfHZ/56dzF/1V/8519r93VaenLrZ2fHl16 +v7NhxOqJBWedLB+s7l39Zz7z4QVn1bvd3TKid39FyRO/qNSqZlpn+2s9/hvJzvTQhX8Ku9r97wY vyZ22sPb5t3b+bFx1Z8tckeHSYlri5SI7XHh+YPrO27d1e1M6y2dF+xvd2zy03EZ0xb8dPqnXWW7 R1Z6640Ri3tN+3vkkx9V/ypuweuN695dPGvqrM/zt97Su9jXWQ+vq/lm536OvuPX1f3zZPVx9/3V wzVr13PLiy0f91X+9bM+vd78z4Z7un8wv9jpJSuj2t1Vbt+ny8ZdrViszyN3PLGhzcJfH4nqvrLh Jy8uG7/oi6y/Hl17eUqP0jc3pPb5rlbMRy/2PFWx4ba0b99c/N+hh1499niR2X+Nvp7mjFhe8Mj6 6sfurv5x/0077zsd2WLuqwfHt52xbXr/RgvS/r3n1h85NX5eGZXQptSKTnPqt3gws0v56POnCmw+ VLnHEx3aZD/QZvKjz3SIfm1P5Qrl/xgQk5W+4IWtSbOfnuDaWihm5xv1HSdbtloReW7bZ3VKVl2X U+vX+G/XbhrS5Y8ecCu9+EjKkZwC1V5t36fdc699OGjovLW9Oz/4Qf6sOR806Thz9MAiTRt8VCMr 7dcyMWOix0V3edjxavNe9/zyUmLvNqdPuAYcf/qXmXf0mHZ55arOc7dPrDk76Y1lj53d1zd/sV+g DF/+WLdNzaSlLZsMGnpPq7Vxl9ccPLwmfcNTvZNfuS/ry6zo1sPP9nK+PXn7u50uvJxnytmodnd8 t/G7rEcKH4w+e/Fg5U7n+g37ate8RqWbrC/253cnM5IHlhxWNetEr5cPZI2d/svoPXm/r/vrX7HP P57YJ6NKg5Y9nn59XpehV7fcsfl15+Gr92Wtuqd/ijPpy3eWXss3rf8Pb7z/X+Uq5z5KSP51/5H+ VRrO2flSp3e6tWw6t9CJ2h/nrZ/3mf3lHns95p7IyBOpzTY8eiLuzNj8qz7r/vncfldO/HYpbkBE 62dXvddr7rSYHwa+VaLWlZKDFqZXcD446oU1E6rVa3ypZeGzpx2tCx+p0njAiCK1Zm2cElG64OeV NuV5ZV/SJ+fefsHVrf2g/92fVWfX1ITF+Vs3qtP/42lznt5Vp0qXKruvPlTbUWXZ5nKvV3y95YGs A99VP1PqQKl9WVscf70f/92hw/u67n/TFftP8XytL0y6WmZNbIGJTdvStYg6w2qUb7k0bm5qwYVL Z1/Njq1aY8u28wnvtIyFoXxv1+/n5BnUdNbAaj8czG58usKxC3/+3f+jGc06pc9u2MY1J7PMlCtj U6DzX9qcPXDlxPx1YtKXlfuxwaxvH6laaeH4ntMWd1xz6+CyP156s+j3mZEJA6Ki/2jzXaesqf22 DZ62Of79FnnrNL78YKXiWZ/H7Sq7/vdmEZvu69Vn+IyEXrVWDYxIbD3g7plVyvz01ZapFX8bRFN+ arF5WPe2B/LU/O6uCjX/qfjHPTFZm5u9Ojer9icj5mUd37WjSqFmJ9LHxC1uT7ftuHPGQ6Ve+nXA 8bX17y8akzU64/v1NfI98Ubp7rUy61bMLpo8L58r+5OFj3857L4v8jki17drsfq7r3ZPzP9RYusZ j7ww9ON/GxX6YdaCYi1++6zcP/OL5d/1U1zFzq82a11mZ88/Xp3s+rNFzkd1r65+9YVmt7KqzX7j 2JnxxVuVmlYoqtjyzMP175l49OnfW7VP/HLCg7XnVZ55JV/dmNaXo4e2Kn7z508vn/hiWlaZ9zKa HKxxsESj3vceubBp1pKZhdrvuat2jVpHI/7oULJDmZa1E3a8VqdZhQpHL418eVb6hksH/3v9kQF3 Zo24FnmyXPtya/MOG3Dq2dUNCnTafWfRimDukx3KN/7h3jztTmVE7yl/7xcVUrJn/V7k8ZeGFmtX oE/dnqkvLujx4MQvC76Xb0j1p4dMav3uE4Vm3j8vb5/yP9Uu3zCq2O/L5j99R8nV879edqvxqErN Ov9vVr0ile8cGl2p3Z/L3m827tCV+JSTL9R5+IHF2+94/JWpP328f1zHr8rFN0nO+1vEyIULo0pG jSzVqZtz6/qrw9//YNbMa7XPlf8moniRFWv3Tl9waVbL/ZOefyH2ZtPDrxZYPTLP92VrDSv/7buH n79nep7rK6ZlrYvNv7UadE3DO85PnndPzPV5X3RJbuv8udfm6w0Wxp1t+EDDNbGZ43ueOP9Dv4hN xw7/tCAp6mSXp7cOGpZ/1+Rh6T1fLqa14wORrY/2erTymQc+uVCq/7OnbrTu2Lvu6c/qzek7c9rN iddOvvzP3VvnNio3bO4ju+PrVj5w8sS0tZtebP5D5YUdP8vf9IeW8TFvfH92a/L8n4d3ydm0P9/l T8t8dv3B1V3ujl3fo3yOI2e1o0TzUhs2zH3wzFuVYoZPODLi96mTxzjHln4oKqZ354yJ9ceV3tfy zWb7JkZ88+7SKbuuF2+d8/rEWT2Xv/Hnpu9eWlTtiwJDmuX/p/1jzkdL7cp48ddHXjx4q1nq5TaO Or83WrB4+l+tOry66HDiHX2GzR27s/zQgrWTfz6b975XF7bKmD88veeajjc7nIj9NmHdr0OPd/tj X6sKhVaN+ilh6ZInq1xbvaFu0rqER3548uy+uO8+qZ6n+2tzGqd/+8f+tLSfN/w4ZuVfxT+MeuLj oe9+0Ct6yuMzt6TXSS27OfaJvzo3zlq+J6V3zD8Pdm9zIOrIPleV5/9Yv/DF4sMj3ml1R9Q3bb76 ZWLT5a8efHnLkWb7p5Y5fCphav/hy3vPLj+u1pxFb7383rN3FsgaO+q9o++1z1v34e+fG3XgwA/R K6u9u3F8/hMPzj6ZubnfGx1KvPZ75YgPNo7KX/nAM93efPDPls4rxbc+GLOh+vGa+XuPXjaszPSF Nb/oGb2sa+a6uPrVk2qdObVmwsBvfjr50Gd1e738Z4vqH6Q4hg7ftD+ye56GGStGjX1m36mJBRvf //C+RU36fXyq3LU/J3wzPXr0wp7pj00cP7V/02UbyiVMe7lY1ZEv1DtYI3rL50dXd18+5sGkj/bU LNi6aszfZ5//8c1tH63cU53sS1yy5ZdlP8TP7nNgdbU2HTou+qzhh1lLG7R6o2vh9XPWTqv3XPrI UY2Gtvrm0oPP5B367L3lPrgnZs6dkxwxiY9+0OeV3fvG/dA98dhL6x95aGyXTunjNlV++sErO/77 bdzZQj3Opd3ljKl15smyR/4ime0bZZzI3OOcubvhXZsLnhn4QfE/92TXKfpn2fSjmRe6XB8zbFah Vemr3ozveTlP3gnvf1rui1p1/ik1fel3Z97etDP6iQnzOt1dK/7s7wWH7I6P/anyvV/MuzLANaDO 2MPOdTsTnlq7vviKbXP23hpy/twPX+yMi7z6aSXXpX6Vxm6Ie/f8gHyx05vUf77X747Ik22Gzuq8 c2Sf2adXfFh6cOM3L/es/tL51ef73bV55NmaeVd9WnL/vMqvfx8Z63wg69FOMRvWPP1k6pWMRekb rq9tvjDvtk5Xk7dWPPHtvK8bvjwvrv5XPR9u+Ny+Jwf+k1C31JBrz//Sa+LgoZ2fTj50uML0fr8X /GPyO1Dz1AcuPxXb1XnljueWHpoZt+3I1/8mNso83LdJSp9yEZeSWh1bdCJq6KBLm/uPyrdraeGn Bs0skfXU7lNJ71WwvGNO6eR3S/3wZfry0fTT4A5turbObjl4Gv2kuXpFQp6rFDmp3SN3ZK9qW+fR xinvP6b1SfMLhDimuD9p/iLhyEuqT5odxz0/aeY+Zjb+jPmyg+7Qy0F+iyAxUYT+hQn3YbOTuLQ+ aS7F8mGzw+Eo7Sgm/8g51UFSHS75B88LI8iliI7cx8+X85BXo8n6fGRhwSLyT6DVHz+X/4z7BFrj 4+eG9yY0GcZ92FwkblHZuEHl4gaR9veR9nuntN/DfepMun1Lei3U/NSZjNhbLtWxNL0d92EzGR9B prQXP2wem0nIDKL8sHlo1nNDxQ+bxU+XuY+WL28d9uVHW1QfLf+7vY/mp8vku4XcR8iDLudJurx1 ++U8qk+RHbcihM+Pc64t/qip7MPjnVSOz1LXQgff/R3/4fGjBf93qmqhpdcHDX3rwyk7K80nxT9J jjg06Z2HRnWfW+P+6L9u/Ou6lZXZt87FC71/3htb56KrcrVi2+Y6OvyVmP/5h154tf7FutGVP190 T+vz7V84uGN/mfmVBy2M2VKpQ8fIWsPiXpjUv+Uvz1auVljcYUnlnJs3r63+5cL2r14fsOFg9q6/ 7ozusWaUq/nEn279l5OnYeXPL1Ru/dHgDreu379kabNHjxR6uv7NKmV3T70z8t4Oe1rGrvul3ZM/ drtr/5nfly5/6O3K0RcH1D1Qc9yG/zKfymlX/xnHQ9Fde+5KqPn7xOSOf71b4O2/Oy+cvCDz+wEv zP/lubdf25iaMHV+QrPZ1ecda/jfvd82/yxuVM0tJYr1/WlyoaKzah7Nmtxo4rX0G9UGp0dfPNF2 bu1xHaOnLHFUbzT3auKtklsbRxZf1nhN3Ub/b+9N4Kno/sfxuffa97JVtlvRqohEyBKVpRAhW8gu +66ytRGFlKSSdmWPylpX2VK2EhIikmQn+8V/zswVUj2V53k+39//9Qznzsw5Z97nvZ33+z3nzMwp yDEIq1MJGyLePfbSpOnwfqnIBUNLwqRtC7qaWzcpunWtFpE+OH42alMvc0/FJSctq0duK69a0xo4 du6IU9YVbIypPsZbJORw6LNW/TbeopS8PQ94LkEKYWEfXqzgNVMMpn1QfST2lYlmmy2zbyBL8nUI y/FMA6+oFHbFL5aFgm+lorVnLj8Zrfhd5ZjVa+6IUYkNx625u4Y61nSMiZONc7tlo3msQg6xfH1t mMqD0+UcmCKhPrlzBNvNvZt81tOVveYLi6x/Nf7eP/ga7xDzm4klJenb3mne+nK5I0s4vdJFxme/ dKREq93o+Op9R2nG7/advXTU7eHyra1jIzW1oyGejDc6B8cabqXteJr1MezBDU39ceXd76I6Jnpu JC7VfKKQzr7qytsX62QlRhSG/djd762XuBSekpnVcXPId7D0wQFix2ORuKXPqp8ojed9flna4J6W kOaw8fW6oqerDVTO1JwgVzwxbpYkcuci7/bLUPZySmVtXrW3Jx4wh1uuKHJa7TvxenjzhaNuYSls CsE7V25e1kG2/TrvUU7VvtbzrPcufPDSODp45rXRMtpeJma6eyqeD1ffd04My1devVdiQdpF3rPj 3gphT0qvHD6XtGQgy0GDdb/LFcfJEqf1nquUHZ/RGVyzzuo+sMK5yCCs6MP9pItiLpmefubpQccy PkRG9wdoNq6qLvJc78kZe026KErX+PX6zgdc127v86eWNFgWIt5rJtyx6pYiPd2G1Q9qcnZJZX4y lT61jM9wLSH8xJ6KNZGFF6gtfKO9Fc/3uS5Svipd1DFKoTjqla7u81w6Zv1Kk66J/qUrFjVxhcUn KGbyLXZ/eL1PmS7c75Z4U9Cq2IkTxAsf2u0UJyoLryz0VLirGKCzWUmpTiF8Y+iH95Dvcd6gQysf vbgSovBFszZUIi2Ci8KvnuVLYS11RgPfGXudZA1hg4CjRwruvjX+MLRsSVJY77tesZHnxP13lFYw UJt4Lr7eeUyvZi158EPmNIEGWbJO3uIC/7de5vqUzuUqF6o/pt44qxEftbw67/K5cp34kC3Hw5Jr Hw0JCVMGrnka2nFfMfMMD38Ui9/L/DWrqS8vaozkbQ0jK/SuVJd//Iznw/Pe3nIqAcV9UZCkVnjY vfDXA8YJoSUvPZgfePvllZbcXKG4l66xwK/R9tyLaPmHx7NFb2lIjSnfPY19YKDx2fts9HmX7Wsi eEecnWXiFqpHqJh47eJ/xKeoGBapNUhXZ7tLNl8250nDmcDinUktZRuzFPg0kxmW+fIKniaLp9Bf K2HWJhiyOMut/PrD8NgPIlLsdQM1oXsvByt/TucV9rf5dCx8SdBZXhickIkMs2/bSshmwMQxNgz9 41pywYjFOI4nKEgzTOd+zAWahEfmsedAP7f30fJM4j3EOOjS8Ski2Kcoet+J2kLNQwmun/yPp4h9 iO3Q1/PG7wvpZO4vzixtYnJNWa6IPZ280NgxjHe/TNg53kt0ltqH6tc/vX0s/9qSpRJJZ3Nq3XS0 lllcnmzpji6LGd9s+16q5PEl6TPn2C8+JuzC2ve3pvDmVlrxKIrriJtdsbMtW24+JrcwPMosbt2l t8vXS8mphr12VN8jrZ+wfzK5fDDnEfWXvXzNZ4vUDd9MhE6m3FjjuR9/Sdku1+Pwa2vO7LL7neqB IUsYQkaVJwZqOw0Oez/bswo2L1VhX0QqlUvYa/CSK8WkNz+bLKoMDFxtE3HfcKXtJr5Ov9qIZHqW +9vj04/29VFuKTyySvHpllgao/7Agx45DLV8Qe3UG069mIhMsmsMTpEq3jUU+3ntqs8nDxCWr09s FVKaKF97jeMOzYqh8N2XN4gbHDxtPnlM/l1jWUCYJffulYFBt50uxPa4tF04a/mymuC17mx2sHlE XCyvunOV1OWk1o8d8e38iVIZigUtNym6zpYNE4eS+9xw96PtuypUqnO7VPUzomktL1Aec6dlvcwR 3J7xWoRP3FE/vv0Ru5l2r8HYQa7D8fey1M6yv+8IK5a/rHTxNE/GOgnbE+LDxtf4gxPDVhVe3dK/ 8tSIHc1nxlr71rfjJpdy6/DFu8/2SXwqzNgYspjzo+dEbIl6TpNuWDGlfuprPova5o05lYXj9nuL Cw231nAGH/CmzrbF5sBCreTLYEww2c//RjHu5qUwbr62D5FUwirq6y5v3kWbyMEFQzI4dss3/5op Xe3mxLrxC5zHPz+O5ovUl4p4vMXkTfQIX0+q5qs1ru8tzXiFDB0lTo5sNtVd7xVZZ37mJANfkdsC T1+eh8pslHE3K19xub62juC1GizuUxkafiTXkqapKFX1KLmrVlJmpJbiedpILozPUj+4oSjyrVse 2xkdvET27iPj2gVs/mRCNivjE3fvMB1LltaqNHTbWvDmXLLYzWMtHXesb5wbI19J7nxAo4sxSK7q fKqzONZ3Ubk8VjBPCdbZYxdq7ulm6NXI+p3tNCeGji99g5tINkhJZz/h0f3FQHPhLX2caL4aGX23 9UVl9WPuPcVbdTj77DdLwEDUE9cobjDV5nPtObEs+wbLPTU2f+JZroR0bQPH5Z1nO99u25cWlLza 2FGBOqVfnLrukPx1n/25cJsl/EW5cUpDoZNSGQITKg+2hhJyGJ/bxj06ysP2vCm0VuDh2YYdbAIj 46s2KL3yqpnMExAIpr0lr+kUcI1D+/lu9wnugI+2Zu+lUh0IZF772bYJWFXseaesycmU69fqIOA+ 8KDh48RhutGXNadf1vqoxIw1OAyVXnPqq6ZRCAvwS1MQGm5TDmevW39Wg3MwjC5kU0+IsGWd1vkt bmKOrGG7oOLmZaMbL+J0d0F7afZy7r9qaWEo4rGgSbKhSVVcmF+7SE3p7Gjbssf5PPLmN7z2++yt 1uHcf4+/yKacuOe5h8+BknfrJni35y7q2v55j1+vVmrxcT2irKlSGI7uvVmRVEj/UfesL5Lr/Y7i QsacFUrzJpITU8V49fT5xt88EtgQuEJUYmQ85U57ZtRaPaUwg3iSEbKoUXmtVRhYa3AoaFSuM5fi MGVKhXkmwq7HKzBxcU8SOq7mFA1W9+4cPW3E5QgLwuKTbsU5H8qaZL1cij18u5+nDTJc0VkVJDeh 8/ZljoFFbZjFOY3bj3IRhh966LYxIr7X9oXw8zV23T1Ii3XNa1uOHr3teK3xpNuIXEiv2x6rW3Xq t7nKjk1QP0MURIzlViW2upjng2DNep8VUlQ3QdjCcNvBLCeFxvJW9gelGnkLrsIgfr7FDea5nfTb ziVI44KHd7WU5eGGPEal2XgxwtR7NUXXSthY63AuvNzBv5ZPceHJ6APV6/syDY7tog6S2yr2tiYJ o2TnXkNh7sMmoV96SPBwhPSzSd0s4oazm5T5guRWb3kzcthVeny8gRBcO8l28fmWhg+MToS3633O nzHV4pNOoct/1bBsr94zBaz5wmRYqDXGGi+a1CKttIo8Iqyv76SvC3i1f2zXSOYH5dYFC6tc2fwP 2ym/qr/bzS1xzY/DscaasNowwuAzypJU3owO36xnOY8aXj5QXTb+ZYNWUdNI4SW3Bfd3WHk6n7kW fBh0AMnzXJqKVxdoLeNXCZOng+PAm5WcrWkdkkO3aR6O3hPbs9zUImzNyWi/o+pRD9w/RAHAMTWa LUJfuCjUthYNMownAyDnYCAlfD4HGD7d4Ho3IBIhXznwRmpnhuZnrQfN1N6+FrDF8L/JJ3GWrq6s 0zpefu9l3pNwmC4S8VrfyUjA8yrLPSCfRx2HM5Ru25M7VOuMHKAIU6bs8zQ5f52yL9+tqIlXMS8n gm9kwbV2pwqTwXX7yglLiXF3wkTVO2uDySst/GFfKvf4RTDv3YwPSWV8cqwKFB1q/F6u/PWG11lF YxML3TT1Mt9uV+zS/ux/5rXiK8JLvrGVe32+Inb/HFO46UDIqeiPYRN+94q6Hx9coXgQb2gTwc/Q u0oinlc1Ke7N3aCgc6M4gpDD4+wiyp7kPEcO3jX1ols3m72V6CuFjYyTqpuC4ujb8NjVCe77ZGMe 2Agp3dij1sn4IagzLP+amFmMYViii4hhQUfrsVvi/kJbR4XNb7fe2w9zg7NP320v9U1Gg5785Akh c9Fz3bcqvC73a2qSOIXni6SrK1KMWPWoI3fFFoEiMY7Lg1aF8a/3cioFdHxRFtps43HeVKwthVD4 Lknj1HrxHdR8tShOfWowTtzb6wVXZB25QDhVI5dqfLApLeYeGg74hn8gl1AMe+ho6Kx4Ql5x7FDY 5S+RPQChsJZXbh/jlUrObQkVgFk0lBV22e34WsVlL506k2q3nWJLNzcXW7L0M+ZKzXodzkBHA4nY sIQ6RD3SG8I/3F+rT1+ncF9/TMJ9wSOe7POPUFUj45MQ5SZT2qlaLNwuDoc+C3BhvEYBQHLUZ7gU 1cOIb794dYg7tN5207mI3U0eV+umu/lqXcSXuLHLfjRLWMrCeC9ahXb6qCu93q5P+dggNtVKSOMa 72rFsDC55J1hVrIu9LDpzOjsFXJo8IOzlyWc6dQ7Wde9i8qwLG3FsPUSkdg1nqYX6tfqcD5vfOoW 7FwkFiXJouRjWPxeyEGzyGVJsOnNcLz5s4h8skXbu1+5Nk6kPZ3wbF9/afPimJQuuZanmXrjqyue w8qo1me6UmjPzSYVb+Iuk7HTp9qOxDtBn1V81ugaZ5kCxjZuUDzhaetkn2B4TvPDcPmnZ0qnYcf1 TOXSNWPvpx76nwvWCu5cXXe9QTrKOtl08cco2B8vzqzayOdjvcRaIX6VokVMQev7IYMSOw5R2gE2 osGZ3R/v+nON7L/G32XBZ+W2Of3M0ttKbmV8/UfH9E7Tr7yrnsGe9+oaMI7eWmGrHFK8LrRWyXRY X+xuehpYG7X0dKsiXxH/3dy7/bA3rbioHJa1zSRnC2Mdj9+oNUdQYsO6jQ6G+MNP1tpvpc/OK/Bc LhlRXNDlsKTR9I5JtcU1foYNSyVEk9ITYn0y3rKdFw27ydqSghs83fT8UXoTA60bfd0dvEbnCy3b G8fHcERgaW/iaiItGhlW4nerRA4GZ6fCsq87G+XJO9L7xe8w6OqKCzcIBvFGRTN+iAJ949izUt6w +7oTAzwrzfieIn29WzHFWeU5wrZ4a8r8koeE4OjupDod2MVd99aUWGX30Guzd06+Pfm+vbOyNkaY avA4aC381Jl2Iq2vVcQteznXBDBR6qmxXCyitY/XSCP+xv+OYSVD4CVbw/Do4PS9sKN5nYQ0k/Rc dYc+/7n8pZ+1HxxtMq9tKC0rJHSc7x6Wa9neMyHXxU/Oz7CbgICacPLu03si6rli6JjI5e6AINg0 yo/HuqnV2YxljSjaZ9Use95NH8FbszENxie5J7/lzccyA7fL9XmjUmGiDVzl7xlpzRwDyjU7r6bX DKb1p45EiC+msEuWds3Lh3suiaTxTqLNtg30252Lcgpq1QuVGN53NL3dsac6hhBRIE0mLEVbEZL3 /hqm8OXQp7IdfmPOGx9JtTMeCXrvBoDUDa3ascWxU8vR8ZHxuXBpFT4rRWfD7HEv4kBY3ZMMSvOJ xvJDcSW4RJGjHpekJZttbxro3x1+Kp/EVzQcEF0sK+FjeeIN3L8/eyCo1AfzaFO5H6rJMbgT9n6D dUbMu+fJelwUM5hX26txJ8ybnzF3JPHFlwVrdihmHvDQmTyQzoADHK1GOdo53DsaRCHNE6x6IdC5 ZLlY5gHX3Z6zeB5ETOfJdeYcyu+9neJE3l8WrERpt7LINJ+LokVabWCrHiHf4a04XfK0EAV6z2a/ KQoX0e65rDIUosN+XvJA4+0UC8XNle8jZI6np/i3bFuwIow/w/xFyMcw+VHb1SvFiQtvbnLoriz3 wabpHJf1fN1J6WEO992AI6g4YnmbM0UVnHjSX2j2ta9tMQ/g8gQdgST5fWdNL4i+claMuyXULpbj inhFlieI6CWWKrrlj3c2n4wNswmrFYszyCvgqG3nI2Srn+e1lU9O4U3tP8neltIUk8sAS39VH9rc Se3noL4FR3qMwWrlsCAlp3fhKbwZd3jrdT69HylJxqh249yAKBY+RxXMDa8fZvpJV1NJy3EDp9Ci 1pBY3ifhwNvKqSnIarXELF8P2wKm7ri3so6pnXF9FQvYga6Noq1pjrTN1NZDZ6JtSs7WBxgYRKGW eUqcEcM1bBL3nvhQEzSpoi5YgHBjiuE9zVdU2BjpFMPKuIRszXttX5nz+Ts88DskcA5Wj0cun2yJ LsO5sALyPX+5/fhg2ojz0mNNKyozTDmzpPmEFz+r8ast22ESk/h5hSj/+eUeqBsm9VCVPYoxhRAv n85B+XI7vkqPrjbcyH4gGhL21uH8JXzS2zcrcn+84Z1VIedatk8KcVJTyBFOR+d6dFP6OETf6NTs 4qUEXdY1C4HtzSHNqihO+Pzo3UfVKKYZ1/B8jBlcFX4EjkjIxpZf2njfUNokJqm6d+HuB2ocgWms OydspIeU93pGrGPoXvbOxp8L5q6atRairQnr10TPYg7PR8r1e/eqcnOcBqaJBu08Xhei3+qHuTb6 cgzuwLkL9GudGxrUy2Uca6anq22LUD97hMEHdKS7OggIH3rpMk2989ivMEFGieIM61d/iifulgTQ PsRaBBqh1kKEeEcpZTVtevXNxGrHLOv9Dy6vqn2pnyKaGmZ66Z6x9xW9jFQQvyd8VxHGYokuM22P l6a3eNP+abX3FpD2qeqXIEjX29JGvj17r2sg5hkNfOs9pS8Nz1U9WgxcVrw7k6qY+qE5YWJP1Siv NmO6W7csg339mvVh26lS+2JMV9ZZM9fWcW2WPR3GWxzMu1lmt87b2iQrDc70A2WM2c7sd48Vwj6W KQhV3qE+jbCbsbyXOHyzRF23q+wTdLbXj1ltsihdJCI7NC53xdBtuzpCHFvX6ThexYT0pI9KYR37 u/ZZuWek+EkQ4dtrhs1Z3xh+d+aOAW7GEFh0uzzNJWwbuXv8YSe0lG2C4bhmNGfQw121ncS2tgHv jtqmgzngXtc/zNz1XmrH4ZOYc2opj+Skgali1OSrpavpPSX05IF0IyNggp+d/1L4tuSVaZHwc/KK CV9pEDweb+uw9NRoLjpvcY6+jpRHnvGbnshZwvses6gTbfSHa/7en9tWXq0VDZHlOgPb9TP1shfC pZlrjQ0sHAP6i1XaRHA+FnJbCqgFJwQe1W3cr+aeDPP9zQLq5D6L/RLx7bArj35bJGDN8PaAolNE C9cEvoHwcuJhOsqCa/dd6eqOr8kgZHZy+4QODaUR1iVSEkFIs8pqpaJdRVFyZQPlkChPaj0jd4aP rNcGGIMNXhsWrfVZ8TAXjDV1qoXV6Atl3SoN0gyT5+yusKeoKag7O2QeDcg+A1F0JSy6vdZO9KB9 XEfHE8VtPg/Fl5TSkXuMRZFrOV5Lr3H7CmjA/W0Re4/O7pJ3xyJHLVsYYfakTVGw2+dGVC5W6tJB LYH7aX2AU3ojwve4kA7I87DiYNd7q4cjI9e8LL3e8LA4WGRN8WcVLtdNd2G/s2K1fywvLCGpywIN imhPvmBevTVCXFxLMem5/NWYhPimrbDiaU3stPF3jYL579/JpPlq5CqrKHJVEnUsb64cbX+d8P0d W2Ie+shgdxFIKvTOv9MDbmV0aB/LRcWxr+rT17dEoqCSDQQxJ3iaDR6ixnkg6R6OgeGaWJc13LnD TO0D7Q0yhsRNAiJ42wop1+0Ij+V9sHxLqDsA0HT4NFcJ3+7YumsbaY7LcrkBLSl9VBDc+5wLBVrC V3OOvK5Wvbrdh37yqzhfx383pNGecg8Dom8dac9/iXWaHO+Odrg2WrRlrQ9sBr5yLGB0rMNmVDmR 272hmTE8OIEoO4st3Q+WKz52Hak+4w4D4w43VWdp1uDPzeXX5NttHdhJCu3Su+83+1v7eIhWWAxc SAqXBqbrefTJTjCMID9+2m1Thez5Qg4u65il8d+AD3F7iq2ZLDWg6boVMcSqols4lj7Usqvc+snm uPTZWB6NEquiULztmniw33V32J1WpyxN/eqD0vZm8L27GxjvUNr1pHRTWy2f5+E15Y/UUwJpZymN dK0jgZOXOvpA5vtmY8fXBx7Vr0ls5+a8zbP9RDwsQoZaM2p3MYOF5x6M62u8KFK5vi2pOMH6tvg6 szbb7rIN6q+Y2Y+KGFgM+DV1J+dufYGzc8s0XavnvX7Yj30Xjw9dg/uCFZe0EoaFj7FFnF++nlBX +hGXIQI3PUCznsM1SuZG8CLFAucy2TC7R5zeiSHFsWG2u1M8va7d16l+ka5/xrhxIEKa5YbZmMkd mpXmTA8r7VrKAhjbHqJ8erS779Xtd2s8N5/1tjCqTxoUtml0ImuhTyBGvmFoP0jtHntm7JZopY7R oogdwkWjp0fvpRwdNa4lFWNaVxweCQ+4xFK71i5thbHGnlx6jp4TCR2nCpgffu1ttwr2n7G5bqW4 8Jb1AdEXEpV62hFuiXeVvE0yzCIE9ilvd7wHC5LFl6fGv4SeQy1c/u7nNTrP9u54DKtos36FvtP5 zSm2786IZw4e0dR+rnVOw5QZj/byiYepfPENCuRabmrSU8I0dL1VXFCmZM1igUpOk29HfoFt2Uec ziUY4dHYtWabvHkxcSQ70eXQnnCuZjiB179jL0mYQ3HnbsB2pHdntOBCzfg7BQ5NOmGcGqEjVWE3 ea3Wx244Cu8338b3J/ApKr7S32NCAe+ddsp+1FMOC7uZcaeATiks7MOFI8Vp53n5FJ13n158jpev aAN5pP06RaWwj9eXCIORahMaoQbdsHO8JdtEzNXgfSGL6eMH8P2mbuBnB9FnrBVwG57bRFttA8uU 0/uYyOEbW84IXo+83Q3Mobxwc3vCXj/iYbHslw+7uZpJk6+zL8TX5AzA807Y4U5n8tAzHEeN9a/A 9MKBmEuCib/6XhXKe0XiRM6tO56+qQUhwGfPxRLVWD89WWjZmzRVtLsUaN1zFmG4z2W9g3hikNS9 apa4BSxI3072xoXem4bS7ozgRgdGzbMb6jemcQvXR2vfPEdJvPd54fGH6mOrLG7UJuWZLWV7WRHV eC6l/33B8Ku6EwZn3i0z6Dil0Jf7zk/2hBpFRWeVEEdA1Ls95tuEOJ1q7rc1DPUP1Xjt3Od48JN8 /AG6tkquogsRWq8bBpceVvYJ5x2hs/RpyXgbutj4FG+QRdq2Q1FujsJrirLlz8fe1Ao34FQOM3CJ YhN+P/4+0ftjhYI2z4tq6OTQmu7r5gphXhwrLXvXK+5jU318LfxcfMei4wMrhK/fFuDQOqxT09bv TXP/TpvyWVZDLbfR7GjsOuvRV6b5EeFRUt0xMkEXH2/kGlaKqOjtcOszCd/Xm9iyK7rvGS6jVvaK L33YTp/41aqBvIsfKtU+d1OysH+62bb644Kixd39TxRhWd2vVVYX6YxOa/6w+1St6JDoSPoYftum vqVOB/N1w24S+lZq3jn07DhvjXJSfQXr6KErbkHyZ73fXtgjL+3Q3f9cPXwPlyWfYYdL9xKdSLqY e6o49/TDQvu2R35Z/oqvyK5GRDT96p2m68+q4sziDa66R74RoHylquu5y6XG75Zoh4W7lfizxq6s kEsuRmYXeD3XZWl7ZmXWiwjE1CmxGOysFWlKtHV9ma8oyrxDm9nduOdxcpFm94p3KmHZV7JVjrs+ TRoTGTkf9kEBW2PRXtWVs7jtUI0tX9GT1+oPQrD04inFH8M+OKzZ1fBJsKOESMGreJbz4qOhgrxL GacVwk6MCHtIXLgmmnoxjNeipC7FWznsxW23qhzeIh3htPiGsA8pd6NEBBWdqorXtafxZthYW9Dv DLss4vxidJ3i+ktvdXBn0csmGQ2S37tvd33b8u0zI/HrIAiz+E1gEm/F3oLmisanLIWD33tmhABX q0SeGSmTMfECX74gPSYCPraExf1D//YYCAqCerG7MRPY0kcZhMMM4LmT1+cvOe9gxyzAQHWSOPA4 iLE9BgN9Ok/LAOeSvj8BSpgYZCLwUDQGzVNYM0TQehYFmUqaYDgLoyA2DhnDHXB+Jj16FR4uy1sx RACPTYAHQV5HevpBpO2SWSaBwReCQPtE0ncgrj7OmJMHjsETJ2A7B7exGq4DQdPf+gFtg2SEQeuA +jtIZclwfQyPjCHIA98AmnlNMQnfmflY0pdl+GG8A5ZMl4FvqhyG8zoCIOgZvJfEQuAJGAjzHoKM GKBZ2yImGUOaGfUBXo1wW5bwuTN40gXeFMDjKMjWI+2DxchwhmA9pj6E4cPgg3wcxgOLMcefc8Ek n3VB0cOgsJLha7v5UTjn4GOJTUOEb+kz3F8QAOQMHmFZsWgI4ZcHdAiikx8hpC8eInyE8fJ9HgXZ wmWgLigvCGiwQq/ejkUe4oFiYS5ZsEEQeJYHghqs0Gd63Lb4s019gOf8YhlDEmpI+25bpj7gxXYy dAFk/iXLBHOCB92D3M8QeEAnCupvRfPAeTz39DGg1+6t6QkAcr/yDnkogJwLfB2LzsRWTU1JztZB UHQDWOcepwA5Z0PQmg1T32SgvR4nxiB/yK1mrGGrvZFdT3R0nE3koph3X7Ld7ZeZ3nXhp1vaUzbZ NUE8NJbo42zv8vhlVyVtWe2LrkfCQV90+VI6OstC3lf7THorvUt9sr5vzwTMw4RJaRlfoTPY1DV4 b4uEU01bWZgIAUopkZqYXokDZizs132Ht+0JK4mnCWjQWXsjnYk8T+B6mI25pgyxVHdx/vFV5c+6 fXx8Juomxyf7K1oLv8QQ6am3blK/uttvk7eovHSP3eQIYStZU9o9trentHPCGiYnLvZSpB54dm1b K6EXY0272uGGDCXhHrn/xBjGVW93XsHh4V0PQrG3ae73ZiUcZGxv6FHC1iYJvJK+fe9FJIvlB/e0 CVfxd32HxIrPDqpfNYRbGSq0hwjj154fZRFbZfTcPqNni972O1j1nD1wWf+APc3KKz49yieT5d1o g+p19lfwf+jQZrX8MLRnfdTwuGbg44i04fErg0syDDHK3mM3zlCuzlnd4+WdRrvqgjQ7tdD6YHZb 0ziPqjNNGdo2d6SYe17sEnN/kl/E4zawTnroKUGOpzcr6fpHPw154v7TmtnZJyMOJCbFbnHjvjMZ O+nUfi9j9PQwK4FQLCDBEaJ7j7ugK8S8VnrNFZliz/qsMXsuQuC2etmi7GGD99l+ldkdH6t9app0 K5ZEPxh6OZ5FJDY5GkkTwiP35MdaJ+P2jmuPi642etLdcvfppdSA1djesSAv5ysDufUZXRIp3dUt xIPy/Y3srX6Kk48u7iznI5C7WzTE1frpGEjfDOIgihQ6BjndCVrt1NMtVU8g7oxdosoZQ9UqRsdT 1iZSWemxfmB1vea4zen24S0KX9zwY5n+UQODow23Phx6Qhnl0xMb7Vkovt+uxUSga+29aDJNg6Nn e7yy05lXbdEcPycREDLSdvgm0WZfaQy2ZeXkCdFDhx1uqQZ2OiV2DT1YOfDW84mU/yBHhk+goXX7 zhsTh9hWnLC/lydWadIao9tafPJGvv2Cj19KTkkY0G5758agIB156ZJx8K7hUPsnk7tPm3u57dYc N6UXDuAML30FEY+dWkYwXvih9srYhmb3hstXH+S2HS69GpRw5GVzoGHPJln37MtWVK9jOizIfR5M OL1aZN7sbiiwr3XV+02Mr0xX3eQqsc849CjW+hZhb6KPO71AV0bR47auHjdM/bu2Eknlbc85hfqF Ei1S4iJUTRNLY5JHdkc3P+7Zm9gXSozfl3V00FqyJo0vt+n9zs5eYoGA1RVu7csKjhlMdBo9xVdj dwgKNovKiu+aXOfMf7Oz3L+1ulsm6OCD3nbtg9GfVBnerR87Vj+69L4IzTsD/ZpE6XBj7dDgUWjs Rtz4A83J0+FSN3eXrB1suP/Z+qLqif7am/tqFnSmjXU/POGr/TgR70m/84uChHX3I4+lg7GFHkUZ zp1m0YMjtNrtl/Gv8q95iSQpez1fF+e9dY2d0pUgusSk6/zHNylIFowPZe4yWMezvlpD+6qma4m4 e/aAmeSuyKd3RlePRtGm3m24JX9YjI1o9yzP1XO9nUjSWi+3rljvTbKvRhpsJvVsAkeL9vRekiy1 78jeSfv4eTeNh0LIi5pXOfb5EU0Z7JbxUufHRUNYYhamSSaKhj6+4emQVJs1cK/ZfZIFc075dWJd FI9mRLTh5QZzIncvxg9bkng+t7K6od4wPrFCtzJkAaFVm0LGcuv2xcdMqjXiqjwrs22GO42ViBNN 3g3WUjo9h5wfYsQWLPXOF3DI/NSk7oTz7sbEN+mIvOGrrmg/088a2Lqr/+6lBmv/hMUBEaK9+x80 pPVVvOgeT6AsS7q/huNzWU/WWWtC2WvvWy3Oofu8C6P8DT5lV7dtfEdYBcN04uzpacXHVK8yjd5f +GIgL2k4KrjhbZMPrRgh3qJuwqbE9WIV4yfxc4ZljdpbffgrfSp9Yj4T9HOzOl5fvtTePCoyvrPc 54zGoowS8pvxl154F4qLn6bUFetQybu8I++E8CYBn8oNzK/LD3pFG7oRir/sVdaL9dldsEHJeu3z N+oBa7lPFzT2LSTc6TiVeMpWSiqVyyTo4xsTC1bG1h3E6yK5rrZ7JfLOHsxbZdnIWPP+TBpnjIHt cu+XfU8H/OjL2Es/9l5lkOgcfaVy1Nk7T0B30x7t14nu9Q0SDBdFrVEYS6r9z07aOJTjLE/crrYl wT2Ocy0pCeYx0vfZKdst88Sj/EtmZ3zTe2KA4X2HC4nkj30S3fVkVfDLP1Q1WlqvcNv7euCamHRT WuKd1ByX+v4s2xFPx/b8rv3cQ9rptvWOh715N/qfAbWokFqrntgvfTzJ9zRznMn7hWG9PxTOJLT1 rHByaqB/P4z7K9nMV8Qr+5pzGY+v2FDOQLNkUTScjVF8PyB3d/yhzZtJ908Ei+blIvI25XX8HSS0 3AISJTga9OtHq8cjzj+eKHV/LSzSt/eMx+wqAfRC3E2U92QLUlLuoY2NLs1ctumZRwBPHsXiF88L 1nCXhgxva/f/FPgG37zUm4nDlH8tR5wHjDZ7As/1tfuPnvIflrUJvRdvQwLq/V2gspnnt48U1Xu0 yA02hb84ca2cv6BGVhaXC4SAbzPHtuku8vI+KfCB8TiNQGADc+/SqGa3pupzDRUr74ycfZwo+Fiy ppJpIt4hEBeHNz9uXm1Pkkt4rktJwqsyH+nwdv/O4x3WVJ+K/Mxu7pW0dBt30+p1ACLerFZdzL+e uc7fbnPpxNb7Tc0tTFTSTBefqkkIdljTXebp1WN9zeGb2TVMf/qhxyprXVoL+0KxYb9ylhNv/Yy1 TRqJAQ2xVzkJI0r4fU0Oe6WPvfBrNnvS8Zld8oo8LKLm9CzuUERITzKfnojhYn+3ZJM8c8d9kuhS 3me+GvJ5plUwpY8NlHkjCwiWnosNFtcePmwuUcBWcq+wFOXyge1tSotTd9iVPral2qj3jpS7Nr9N KWnpU9v4lw553bfPDW/zez/c4nhz/IaftGlhgQ8rG+BDS4tL/WCPA3PBOo37hyUtb9tOUb9ORbub ddkiIfFjNSyMF22ORmlKwiQHnQ+sEOE6Wz9U9bz5pN2RA6cod0U8JKG81TGTbd+1VsI1R7KsYI83 1/CHUHGvKbUQCVqyj/vCOcbTn9yq23M8xuy8noYFBSoTrzvpVFJyJZmnWUvq72tKKyj6PHZg4+RF rsL6B6IwCQmV24j7aRzrThru1JRYGze6d9t9UPEzYZXq5cQ71W5Zms3v4R69Svb/5tlBYUIL8+sm UUcprE1E4NhKOgn5TTrPOcLyI5YGiBksjTDYHleQ23K8n2N8lEeSm5IqvTdJee9AqmOmY9ubU5Mh hNui/WnjcRN33wrKVXoMXnnK3lBXLby2gpZh+ZJXvT1yanp783NH2ppEP2jTFZ1ueGJ/cTNEONnm 22fprfpR46Jjy7kbYptZx1/LPU67q3LValCVUzqNWNAa7X0wgdA8XtV/2LbpRRfrkD8HIcRQIJOj OmLtgXzjxQtuKLGOb7Qbkv7CaBcpmenFIvioHC+UZS15V+HeelHmVbvSYgZV2Tdr9695mNUsyoxn ffqSY6L/yLFlW4rtFR5YJi4urBldGtsk53WsQUzL9eDpxmrWG/pp6RH7I7H3aziDKny+TLStaVlK vP14ifZlPcc6I8UTO8bsX1ZvXVkyqsC2d4HFp603xro3BUuHnXofpZokS2xifkb74dp4R8yVN9JR t2yf2ZeLx7PXmarYjiwv6xKcfDIgJ1bYWL2e+mWzisSNlQ+f3ld+0vjepWSl071Dq86LbqngCrAY HK+42yOzr8btwcBR0V3573o53BVGGJbgru/PbzEW+pDAvOlKuQcc4F02bXl8g2/0oGRqd3RpamJr uL12s2inn+TTmPYGuTSr1c/sONYzHsWErA/Uk97FpLrAWORKzZDq6ksMUe/7GbuSSwQCU/jyhqoY 5ULXLSjqVtFqMTssyUnoPrmyM/YTOav3BHt4bmyplnd5umoHkT66ToI5L3Uj4T0Lf0zq8KP3tf3t 0jLtF6huXzqR2ndbZSzKsY5ryNnYsHBkcY59/KiS9M7XPhWZbnx+zY+72omDqi06g9XO/cY3U8M5 grP6J/T4j13Lee2zQaHSZ0PUwYS9UZQ9tCWXMncXHk6UKOS/P5Hv8rne0O0Tv3d7of1ZOMhkPnRk xNZV6mazpGqB/d2gycb92vX92kEVylqZuiNLdZ+9u9+cbVp4p/E28yeT5/YOBS2uH6rHNrs7d0o+ zj3tY8C/VhrPYGHOFU3reorGTtxP6gRxhbb+PnJCjat4DWvY+8PNgyOXCMQnXp/ZCDo9oqNhxI/k TS7kSzsE9VZdWca6PumyYZpYz2S+j9REoHufgODwgPzj+MaC6MxJ3YEIBiUfVZ7gaDh6O6KL5yDI h+4bqJ64LdIfOK5NXCgc0lxqvQ9LzGQc1PfY3PB4w9haYr7A7gO0Gmv38e/vtbyQ3tSHHXbdbdB3 qYo9w9hnjT73eHOl5Korh47Hf3lP1E/wKatiHFkjlsAjlWQ9rnejYcIrsXSwuXuLLtybMsQnQx/f XMx9g/txWdpALTHW0F1la7t/bwAx72B2pOHy8YzehKre7U8a0u89f7HmFejlr1oL/35ztH/YNWKx D4uAtPp6woO800n9Fglkem114hMu0YZ7mB0Dj5eteVUyxvnK2HmtQQJxTwWWnqXskZrWqIP3nQm4 W2adjR4mt/CLWqxtkeWYJKkDU2bVWj1U9zrYa3/dsK70/TCzW87twwL60h1VhHuTJ8wcP5WtCIvX 5WF27CO/FJ6rIq010ERMHhf1nCSe2yLFZ152OmmiNvB0eGlCMyF58kTzfY+cFd4JsWVjCwg8JW8m Ll1hDS0VP6ek22bd4r+y+TBtfmrxiH/fNXyWRJBuZUZXYdSpYEOnobgel0NZHcrLe3dMsvClDVOP MVP1HpSUEO1a1uZh48DDzbLV+Fhe7hqWztzdmx2r9/Jy8yqXMlb4nHlZM6btGu8zROtQZvr0FfvS 5vtvjh3OYYg5MBzmJl6eychYsSkN22TM+nwrHaMibnuv7Pvz572I+cTMLh23V14NAd0fSzadK3K1 P8f5RtA53bZZVLKnvcG6V7lDLGWlJWtru7vxrbJbfbXLmfqYonSJFOScfpjQ+0POEl2coabMQ20f cNeXiL3oPV2m/SX6UcT7a2ctpUVja8PHrl7cOjJ2U7LJnXA4vmrF4Ls3+hrCDFxrfOSjnC9skTl5 EOIss3/Xb+KjbPfq3aMrbSfJWVQ3+OfumGxderNenupU2A7iK2LB4HmZ1VWMi/H5UpJdRXexstmc 7HccU3NH32O8FY+nMGl7eBtr6HnYcX9cuUQ9i34H0Vjn3oEjLSP+ARKha17YUyXtbb+Zr9z7epvR 8FFqJsaE8i4ibnmZs6vAuTtbJjvfqLnRZuR6rpLRvqOv5X31CbQ838SzzrUzqGLkRENubk2qFpv5 x4eFJ31GBswC6aUzpT/mtmCgN1ZCzpJbxN2fLxRNe+Xfr9EiWs8nIv2esVdPv0ruRV6LbFaM6AXR K1JRVkvXb0oGNVqrr42O2Ked23mgtEls1anoxwkvbzNF7KhdVKyVWlARJ3zjSVRCuNTl6APeQUdf dpgc2T/efkpl2DV2sKM6XTI+Vk0vYsDUlONG94p6cb1tZpoCpWX0hAn5se2WpUndWbVi7ESKgxGj 7nqfy/K71Uc3PZB8PElhlzRSomkbXV8nacNDWf/Ki0niZfQy7o1Bjm5AdfX7ONiyWoSeptV1KF92 dOU8F3nnqdzWxTugVk8FJ2GxW6YyIyVuUd4rl0Sk9UJl9NlcbfnSewSPbxBlrC2UTaPzvDZ4ozPe 5WFgRey+y9Gy1dEJRd0PsQ9j3ZN40rwP6G4cZPDKfBQuCBcRt1vV3mrqs4RxcKryOFjWf3WkugPY mVPNaUOWUS9u3LabHOsvEC7UWbDWS0x6+Uhnba2T55d+nX5BZ0nheGukaktaQV79mD73luXGtWuu HIoCmQGGp/ZldQ9ca67sSBevzh4g2JMC12aXbY8e1iYsYYzQDm94akDMj8quyWsIKYSNsvRa6c5j 5/TWXBlK4tlKn6vxKT+psqNxPF48Oj07dIJjPUbl0abDlH3CVYOTHdAFDsPxiJXVtsbAEowhNyUy xIkM/moaCW9cwe1MJ8+9mrL9dzUV4w46euO9hw4YlMXlij/tZG4tYBdo+HjLlcg+0IAjjNx6oiu9 d0HOyL3PzHV3msfoI7QtJgfccUURJnXDzQMXEqQCW/dhgqPZvHN130TJ97f7i/GLPh62balRaq3q Nczwfrbe7Xl38c1+Ri2WRu+87h1x1pP55JW9HAmaZRRN2kQhYvxzWpL+8AzAtwl/j6l1NajX6fFY n52tWjDoNPyhVfh2Gq1WtPadpGzuZurlY+6jBUPXmso44tqPri4Z8WQm3D78ptriqGjW7stjW0yq JsPwDN12jdxJxzKThq6Vemd7BAU+7hUd2qYU3nrasc6gtWDEcwHh4eFTdxmJkkkOI3ZUub6GjPrZ ncN+DVSmMhUEJrtgjpV6Hl6iQ3XvWgIlg7N4PlTf5c7cacnQEl7UkqVaHZPN9sF08lGQVEjZrfM+ TIY19Vd61N9dyzhAvE/RKzri+Janqyj6CAvB7Enpl1VDOY5b3rNbpY2bFRZeHe34qH1RJf+d2Lrj 9R39B/yzJyurA2Oy8x4p6WbxZqXjcAVlaYGn9YlVLxauKx19odXRIXgrKgQzIFsl2jJwG7OXw/vG ImO7K/GEl7207E0ROYMnGt7oX87cXdURkVRl4XO4baSXfayb54Kr9wRG+7MYYaiVR7yAsbRehzn6 zfiC21WM4QO5bp3m3t6fowaeUD9Ku99k9tAjPXufy8QTJcs6VceN+W2BjK+sM9QkucSDGji8Dxe6 s9H2vhI3s0trL4+Rs+jVaxaVeuetUFkb5dbzSupT1N7OffVpB1NMtteFDyf0t5+LOhHh0OjPPrLg BYOXJGGdOGOj6PbUV4zOvRylNPE3HT49qZNclJP00qa1T3CJizuNqbXUiZt1Xfdv7LtVvIcKNxyV +Snhyd3Jh2sKbQs/S/oaWk/oc7gXW9ygeh4ztpMpRHrBqxSV+2GmCo8+6k4uURTBCHAV5m9fdjnD SlyFZ1GIe/3uJIaoSp8DrTxPx7gGFmPLtvZ+InYzbX0et5i9ySxAl2v0U3/aUtbVqiNury0UXGjz NW4+bbk1gKNhj1n7+UG9XSXMizwBJab/p84SuUMInRrpjprpSr2pxukRL1t3sD8dVK1r6hYdOuh1 LhRj5xkt3NpaQiw4QtZ59gPz65ibhcLMkWIUz8L0E/oLrDJN4sZEslnsD0f2t+/KDm/mZKBNYyFQ H03BM1da7FA91roQv4jFnqo3TOTlIW8DWoWEYcbDvS/O30ze0c7s5spcFVNHrr0Ev5btqqrjC2Uf /0ssxxv4PsjeHpBL1xERpBGO9uXtXSBd+i7bm4rxdMCBtOxNjrt6H4wOJ1EXHqzDke15uNHvMydL 0cUDbAW9bj29bHebItY/s8MlS71/uM6xVXS3V/C4aLunYwg938E9qZmRFqJvWIOOOmSzpaucGa2P HOYqtf+8rjC/dqi9+fqL0YYiP/VsSvcgLU3v+ppjw/Xv9ku7JJZNEOX2XpR9X9nsV8dkIfnusXeA oV7J8GnNNbV6llLvqW0TheTanSUnmULEK55tbtjreSOcVeBDcsRHcLddkOhzskKA0gC4QodOi48e B10eqpcq8ZSWKXiPK93fjV8fUiAbUPLxdIyqxdYjehrAkTQPn6bUOo119NzIsNVm0wHJR+LMC4lM hPfnbTo/Fxe9oDtkHXPXsI19iOGAdpaPMjDhBV8Mu65ECtybENSoa7tD+LiF+6EcgXVS7fqpRlH2 cJrbgh8/Go+JfTofrbonZlQj76j5htJS4P0wRBVN0zGjggU5ng/LbBaGnKPDDa9zO7BH8OxQwxcd mUNabnreKvtipN289bY4evUfZCktY/IWNtOrNEqUtOU5WiPEKbCh9tR9V57yLzwr9fKfOYpuJux+ 6+Ya/8Uy5God7DRdJopjn5aqxjo3vByNz34TW9lVotQ6SFVQbJ/YdbSKUerBldRb+txamslvk7Zw qIaUap3RrQzqFz7fwG2bLnlw+9OHmpJD4jptuSMLCIsepXKrXn8Zktacnvq27KTh/RStAdnCuBrg LSOGExwXvmv96j0jhrdRN/3NZ9WXRk43qLmv9ueISPepN+w6PaydybfVYzGhHoqJC1o5YUAf0noh 2J/nyNuna7hLy4JG6j89k2Jf613mXSPLab9m67urwRUihGoTmqsX1CfYq+x9Yx8bXChsod+T1l5p fqGBPfXGFe3H74NGXA1EDD64NVYPvckeL/DO1nRoD7Q860cv7O/gYcl0vPv59n0hYrkrLzVov3QW J1xsSJZP15c+506gP9Rf7vdwTOKJ05MT9wTlPZYP16+LOsJW07Uqy0dzwhryIhKllC9VjFQS2Wjr ks8rjGSJswwEJtlIdD8hnnhpQnZvuXkWJlF/5yS9RITg06LeJ+6tQyM3W8g8NxCoy459OmFmKbmY sO/c/rNPiELvRe4b2hSeKVuUVLKzfyxtrHsCauApMytc6U1+maGvaekuycGjMRI2ixiT3Vp57J5y PLW/925XITa12D7BRy9WxbZ5RcCkXL8yfT5HdXNvv4RqY8VRi8iGyPud4gSP8ZyIy/VPI97aarUe d22wIJBcSSAxoiJfQKhC/KOGf2lTWmmSTyi5et5KG2Ls7aMRS3e75WnU5R/pF/Zt6EgUbCeKvRxd us6o+ozo8uF24pISu/WMN2SVRZ37N/C2uMVwDaxxvb1VbTIfrzkJ3zk/2O/KnSMg4pN4WuJj6m6y lvr8FQGFPAoqD7m7pQli1aPVAVeoPdrE1m9a+L5416BOU85uy2qugc/lOuNpbhNLsxt281wkNz16 vOnliOHNxuySF9I+zcxdNddNpFw/xU8cqvbpHxL/XHE0v+Uh6i74vHenixnsTup0AwNE8NmR/z+f DSzzbjbolhaRzohMUJZUla67u6L+WVe3AcFMcKA7g0ODW9LUQ9P19JW67eFUa+9VZiQWaLgbWxvD 4XDrFuKJS7tWPqNpIgqQPw5+2XmLvq7Pc3HvxxLHitqVNK9dxrN5ohPeWxS6HisdFX8orlvosXNl aESNKD1PV6I0i2zVl7sWH1q3WKfXPDrRkPDm1qmx4Mh3686lN4lmc2cOthqz6jVIsjPdZeS+NuS2 Oe3zNsk8Ewm/6+Kf+u2YvD7rJBycDJNzfOXtcyDBr14/f8tyO2yeQJY5V0EDy9BgcMfAqGBZ1p08 CpbRjdyp1B/yT9LG7kq/VFPi5B5lZNB6uDbtS4NLUNAdmxo75sZ7x7kXUSsH1Ac/H+qVsdee3PWi /ZPIM67lO5U773sHvODwrXsxbjPg55zFtXcvg821K7u6vmRnWzqdZC+sT+ptd+uj1pnUsGbeTNh3 ua7g5bkzGlIrl9t49ctH6HqpQ9vU2Be8Kzwhc+pLQ9Bqhp1XP2xJ4OmKdteooCxazd+iVsue4GOQ tMptomuIeD9PJbffhHiqy9Y/nXXzZZ8eg375HGuvQX/VDU0VVPYmcp/dAwqdsJ6tx18877eLHcUr Ht+CtRxb7/3+5olFupWFa9L5r2xkbzr2BV+309HUqTs67dCWrGr9ySbVNEkt1/374pk6+pgHVndx V7WkHDABTmk7N+GWKo3usfd9lov9as1LPYiOnWRPdI7njCwuTNI4b8Kb1vXmvlf5pXVpHplCKfRr +WsPuT4MfA780m7i4BD5esa4NfpjjmVNXZFnHm444XHk1QuictHGEw1m9w/vWrbnpf8ivQGO0jIq 7/7racr5LS+lGDJvjXbLnV287pm5qG+D/6vDhxelEaPMda3GJQIMJ+9u7bZ2XKJ2WNqhtzjfPuyi ta7cqYTP+SOLy33GHUcvEhlWe52tUGvdF3WJQromoLmrSyzypCUTwduwtiIh/ovR6/TUKNErm7VE wEBMQW9tlu6HvuTrr2MFJDlUVaOTA18DvM8QBxPYMmBX36PiXWhhyPMEZN4jVqWyCSQscXS14yJv mBrAz2sLPGibpifCvV6gN2jh755dkuR2Vyojj/RKXeMFdZfqWmjto5lZLME9mVAWYDGYZfH2/fjI reJjL5SJ18kcM6/vq+28HVzoquUfc+BJ8OtjcSsl7jfexM1wdSWcqnkbydo2bGl2j6acnZ99+xnl Yg+p96LtL69pCF8MMNyTEOkp67zIyv3tjqAHXfmjsu0NZ8xOPs7vflRcTRxNos/sp+9VXx7l40Gm R49dYyRC2CytK+3bckZnGyY464DFZZ7etYK2LA4r80aT5NkImwZC2VUwcd0WQYYq7jq1q4wGvRzW cCbwrMowPXzXd9R+NX0az4K9DVo5XlLxA/Z3jg6PbzpTNzxxI7ArxZGBW1eaJQ2vGmKVLnGppOWJ 1ZY3mZK7ywykxMTuO3YBMXueaCDW2HalOqSl1XjXlWalE17Rug31c2vfW1vWcvbzYfWBY9GMr13k g7Par22WDukZG6kTND5YZk8X/SL3PotXKUPNEeqh06MDCQiwIw3lmhU7GoJbx+La0iUf73u8SKbO 35Ta4+aZF5StisdO5QHB7xg+PeSlYjB8pKEp0EI9R7E498FRvsfazIMOI428Oj3GDnWPrMfVEm3H dd3rB5Imu2RfnvEjlw4p3qMXX2o/bMP56GKpUog9S030C3e5G9Q+y9VyNyCN7x8vX7EQjMC8fQ7z C+5peUkG5D61zIX1tVWEw7YJXxp3VLGto9kLIinPSZFhyUe32N6e0PZt7mIf7eZ3L2g9MBKkF9CQ 8tm8+uzzl8I0i3bp2nEXZ3urTYpsbVogyulOSPZOzrjy5UyTVWi9Aedb8vcfnxSPV0cR7bW36knd 9dW8Jiad2j9mSr5RKwQL177n/emlRq1UnO9wPSxrLe/TVXd9h1kJUVRerv23hkWG64qVQpLYBvwp 0mLZWy3yei+VeOqtD+HBmr3ag3TAnKTKmC1nqxSNo9bmOIr2j1AONBiaHubytpUSTX3VzK4zur0U jPvQ7ZW2aRrwsSto6T0daFWsj5C+vbfWEAY20fvhmirKC3vDyvuuar7Ndh+bRS9d1G0zZj6d/Zol GW56x3iaFvujkNU5jjETQXfXxMWwMBFuvdI6KKlJMOQphCXGk8DjHSURR9zcte+ht0PM0VxF44jY rILCR45hweHcWgNnog+RxwMJ3J48IaFxyKHZK3bSO4Suu/J9H5MBrJio0F0vHNzrPqQTkhTYYM/8 RlSqsP5SFWNiPlvQcfnOFnqHhC+f4gIfbmcFGLWenLhkqNZW9agWp3JZ0Ef6yo7iFr9Y/qzdiPD6 yQhtVOu4428dT6oi3PA9+EYAAcVHeL9IpZWHm8Kmx+FA/4sgi1uU0ikPLXcjzcdUMWYv0+fO9rE1 jvPVfCQm3VT9MJDQfrq5y7bd8HGi1sGe5QeC2BAqIpMnRw/tcPC8vyrRlh9Bx0LFO7U/9/zCF9Uy 5GJdK/ZJf5pgxK2OrB4QIg4q6XtLVbfvqpW+6Ts8sPXA+BiT48PcgIacpLFqJcbaNUW14VggpJ0e RK39/Eb7rkOF9XmF9tsP6rUZswTX7SEJQNvo7SrA/gM3RtUEaq06PNba+7yvH0+bOFEg/DpjeF3L g1cmli/touy1PxZufCWqRozrVk1+9m4NV2lIFWPu8DvBktruGKHH4pvf5GI9qjYURlUxlmn585S8 XBI5IC3vnfC8hHKTJW3cMTHpz4Sjz9sef0xjzR0/7tVuv2dj8/gVp9YQiPipfIHvMJfhWpdj/RNj Eu0NqhNWlce4MAGG5xJ73bqIch1PanvrGKN8LMWxTITmjNdUO8iD6x6ACi8H6MlVhk/7Q8UwhPHt A94exbXt5CPLod6xXH6v5QO17Q9GlvuaDT8Y5fYnSt7wfVmnc8Jw+ZYP5snYgoaIBYSj7XxDt9BD bMdu8qYdTZtuBBpycLUc14D7Zp67Bk/1AKN+uKnXLV9yAtFLOi8p4P7unA5eStbg4VsfwnpvYT8T snJ17/WtIecfHuctHtk96cXKy0z5wtHdjfhxXzMxoOHkGQ9NS0736rtwR+iOw0eK7Q2W6JVwXO0j tLE3rjlN9KiAd37ScGVv7aXFHs4dnwmfCU3a40MldNmb3QYMBwx74ybGzCnecWaNJo0mDWtOegnj 7IMNxrXHtYmxk48j/UQLEyfiJtZ6V/o0FOdcMtGe1JxkhWHYmzeW3IubjJ0MNBxoEBXu+fgGrqC/ Jd/uFiTK+HF84lI4d1//evK87qzPtywPBR967ZNfpk9zZ7JUk3Fb7mq89+ZHplsisE3uiQdXLVHB 9L5o42vPgPumc6XcSweaAEMVAZ2yW77DUXHcgSc0ZIhOByvjpQ9OjBM8nkdWD/frZjfmbVldOako EJ01pHfbx838ZeWgnJSC3V46nRfN67qDDGuVyL2jtGPsBt2N7vA+fJ7kvrCnruHBSI79RXYdtwe7 bY57PLs0/IB1SbN76qhLc5l0reqEaIPk+AE/r+7XxhzeNZsGot65Enu03+BM5Y69T3eqVRLO44gI lZJOZF3Kz9mX//Te5Irnabc/id+I6e8/cLjB/qJ0R7EnQ/uxABeH94+OVx890B291n1dDfW71oUL CQ/CFoy779AvSjJca3HzY8mb3na9RPsib0cuC7nLLJeihscVVnhnjZxe25RXrThZ8tb8oemzi7b6 WuzjEu0f/R9fWSdprZj9yWvAsHb/8YlL0ULPqlgcw0OTfNJEHLwvpK3zqRAXDdPuu1RVYjeuH++T mxFconw46LB+SMJGueyTDUtTqi4fSTlq/uBl01jVRKOf/2KnxVbjRppUCu7PAgKeveXZ8GWVxvpb Z4gncj/vjnzevYZmuF+gVwFbdoCT0BvPxH2K30fTj+786tGkmtxnLZ8iWN6oLFN39pCfPB2ocebZ cAQrVfHOnG4BEboW6yRI5PSOL4buR9R32O9Z6l0nhukfHzi69jg04cgb+SXVXJSWQNS9rLj34drV ocISzIS1VvH6V3bLEKVupG5ffCMnbYTrbHi2kp8weUeZtILF6p7L2KahzQkiYY+wTdX7NDwPw4oy drlqSdE+TO+BpLuSUjG+w14qB06bJvkOP6jewx0Na4pUzIPtKdoyxLcH1oSUwXoWXaG7vGYt3rtT JLywFVawMquEMx2sTITBi8+bnWkCGlrvVykMwgp3aFdL72byCUYGyVdWyzjpNMHTqF+f2f5v+39o 86OAoCNwOgqnY3A6DqcTcPKHUwCcTsIpEE5BcDoFp9NwCoZTCJxC4XQGTmFwOgunc3AKh9N5OEXA 6QKcIuF0EU6X4HQZTlFwugKnaDhdhdM1OF2H0w043YTTLTjdhlMMnO7A6S6cYuEUB6d4OCXAKRFO SXBKhtM9OKXAKRVO9+H0AE4P4ZQGp3Q4ZcApE05ZcMqmAOuFTk6WwPtiOOXA6QmcnsIpF055cMqH UwGcCuH0DE5FcHoOpxeka2tJ+zJ4Xw6nl3B6BacKOL2GUyWcquBUDac3cKqB01vSNSD9X9sYoU84 3ELwzHkbDqxw7MsGQY1MECSzAN6zIR/JRNY6BetrgrVLkQfPMRCGEerDPcSAFZqfMYJ8QegVIxmp nBGqpPyAaFcaozz8uweyQlaydIbwkAq8d4f36pA9nGcMgWUw72fewDRW7YeewcmtkFZwai1gkLeq nl4Q+kK2kIkESxZygqEZQzYQ9KewluFJsLSR9TYtIFPSHqz++TuwsF/IsLDWMsLsg0Lh65lg6gFP 8aASDtZlhDPwRrUeQt96gPWZkYZ0jIWoYYbJQDcYQVvk0OS4NLyHkfu6CvXUHq6FvMMArpqc7EZy UOmBNagRlsNiwmPw6AsL5KA+egU4NsIZ4aaOfcl8kZcNGCFashwMsvJsTzpyFUVPI/xLZglBHPA+ HUJXsAVFgGoy9HJkVVyyGXk0pGM6UjkDaQ99s5+qhyPBABt4PQJLyicnwaMk7alJe1rSnp60Z4Sm 18sGe8B5BtJ+qj0An5lUPrUiNSvpXBrC9ByD9/shyh5eUJdizrqnkDX39JsfsHQx03XnfLkW2rgM rQuumV13zhtL0P11aN0rMmhdE4gWqesH1q+lOoqwmoBhgrUoB7zsQzWJoYJ5g8HCPKKSgbh7mVAa wKLCVCBvCIKYeKAeRk4Ez34coPWbdZB9wQ8jVE55CL6IB2IhQ+uykoG6mVyuHdDzixJCKiVFYA9f DPfqUZwFUmcCB2SFvJc0jgOLhX+7UPjMDvG6anpZ9rewlZOZRF82coDGcFN1HKimzwFUGVqAEiWZ JFKKtrGUBHtqb9RPLxj6FoV9NevGtFSmNpjhPBDzLBim36RfgzE5xT4yuhlFgJ08ENUs+FshFO7U HqreD9V8QduYCxxs+2G1q2G0RI7fMqLqC+sClMkIRLoB/hOAkyD8uxn+w8P5kghsJ9gMmUMucF1n xEDZIUsUg+WKLUl5DvDeETZYzvAe/IJzQfhPFW6PblZ7W2A16GFcg6z6jKoKEC8oIxl00hbNONW9 YPfLCGStaOdi5mRqb2tsZYdXVMPL2dvautpZmRi7WNnbOeNp3a1cLPG77TX48bKuLpb2TlYHkRK8 sZ0pXtPZ2MIMr27mYO/kYmVnATd+jRFo/M6vTShB4BvMOMRy8pK0F4ccT6E5hQ4ow/wATbgTQmrG nmBlcryinbOrk5kpQOkbXEHrwF4u/3olOJpunYkEFW3kKuMw3KQczFY7mOFmMGvBuswbYCaD/bRw xGHbtB2uZQ/n4RHRGCPCwsOl9nAtPKQIqcG/LjAMGwSOJQLTE75ODvE1tsjqzyYkrwbq2yG1neC9 GdLa3GvxiCo4Qq7wVU4kz7obLtOAoaJ7PIKFM2lda4Abis1UKVhX2hhWTRtSqQnSug18BT2sPi5w S2YzsDchYeoKX2WF1HWB9/ZIC9/iMt0G8KIAtgN85Pl1LWvnGTi6w9fYIFSbQR7wMcpdVdiz74R0 EBrM51yPR+rhYX/rCuc7Ia0ADgE66OH4ANQHnQF0EJQ+PGldbUCRKcm/ozJCoxJn+NwCqQewQGVo h+TQw3noH8AUcGUmpmjUANpzgqG6IGt22yM8xEOceGNkj3LSE+EG4A4XHuDojEjGFtEqlI/icA0F RN5mCDQLhFoz+MgVgQPO3BAOg9rTvGDGA60UgQ4gstKApQX4u2sGXVNYOiPa4z5LNy0RrEy/0oDy yxYCfeU8hPrRqR6B+g4MFZqz9msvUodA70TraH7NPTzjSmrkF/RrTlIfp0WOuZF+PlWCQCSDzRIZ OFOfccYCvZxVNmUbpjw+gInFkE5m2YarjMBkq31HPlO6yYmXI2k+Hu7HNgiHnGEpTVkLjq+wwNGU tVj1jbW4wygMH+yxNMOb2Nvut7KDDZCrsxne3lycHq8BW00Xe7yzmQve1QFvYmxjQ49X1UDyjEkm 0wwxl06IoYQvBFaTHi+nqqYBKlnZObvAF+Ed7G2sTDzx5vZOJCDqGlooZCsLO2Mb+HJne1cnEzNw YObkhhg9eryshYWTmQVqk2ELbmYKw3ayd4VtOrhU3srcXAOuDGO5dRcJSxhJYDzh+mKCQnhnF08b M/xOWRVnejVjJ2NbM/hKZ7yxkxnewdjZGaZzv5mLu5mZHd7Byd7F3sTexhk0Y2Lm5AIchrOZo6uZ nYkZvZwx3LwLXBlva2xqBqNs62Bj5iSNsBmEv6wIGzHI+6660HOEsSlMQDXeoCqD0SUpVyoTEPh0 LulK+O/51yPJr0fspD34w37NnVKgqXAW5OC+q0B3GEHIqW5mbuYE6MDvsjc1s5nSjam3c9GjKd0A +hmL3BMwkkox0LSHRRueinMBSmQ/aHgz/CsHBI/KxAmw0tmF/6vSTPtZkmaQFAXJBygugQGIfwUI jhbALm8BggpAH0VyM6l8GsnZqh2L3LDMJWHqFgDkkv+ABOCYEWVCSQC4wv0DljwIB/AuoLvACP/c MeOhKUyXkUrn4gKkPMVOmh/gwg//4vEIQ13MjOGIxt0OjwQvTmbGNutcrGzNSD3P1cHU2MUMD7Da DqGRGroBwNMcZEF+p7BkgVYjZ8uRM1CKnVX6azxlJZ2Ba6l/QAeI67a7OsHMc8Jr2zsdAHjC9+nI LRK6gSPQKppmBzUTEDQj7EDdMR42e1awAzFDzKE77BSAuwI3xcBAeiIuCA/XBSZUGjaNU64MOEUQ mKDBgRkS0Bgj7sUKcU37kTrA2ZoiR87IMIAD4mKcYEj0cI92Rkr2I+4KXGMGuybUOYGzqTBhyl05 kZwZ+isNrcDTk0I01Bm7ItBQx6tBCl20oR0kjIBjA7fY1xC99EU4gvLFgnSMgRYjR8Ah8cPxeA9j I3KOSmfWlwm+Sgctm+rqSNE3ZdNmYqabQssWzCjDfVO2cEYZ2TdlzDPKyL8pY5tRRvlN2aIZZVRf yz4jAwSM0DDuChXQvm4cqAeKMVhK6qk7OHSjFzSCeijxyDGyUAd6BO8mI9EDkHP+/Hloqt5UHV9f XxREcSQkLFwMFRdPQikpKXPqCQsLI/v6+nrkml27dkGfP3+eUa8YKTc3F4YASOFIYVSaMMzJYvMf tgvKAM5wy1BOTs4P64EyyBylA4qEflhPOHISipwsRuABOiDoBqMUBPj27VAO5heGcoB9AjdlTDAU EDyhA0KYbwaEgAzf/AQKHhzCgvOFYyNm/GsMHgPkyYmcL8OXI8NCWFgL0PIeZGgIC0MF51kQEzk6 PIT/6aAUN+noRzjQkXD43UEpNbhVdTQLwlBPAUH3U+coNOzXcxQi7us5CpXs6zkK2QiG/HXwkrQ5 kKRF/jUH8Anz9XgRhP16zALhvh4vnHFLuhDWu7lQFs2AwjIDysIZUJhmQGGCex4d2Rsy0AOxPeVk QAeoekCvA/EJJZKP67FE9mQ9YJAWA1H3zLQqUxsWokGuA8ABRqD+KwhYEjQf+SAL7HrOQrQ9myCw UhIGrucLvfl0A+OPYD17MAoD26epwSi4TdJgFIwfAs0Xk4wpZ1EjY4QWkLDJpZ2yFRjoBoYRou/Z g5zN9mB4+FcOjlgOgIDTzBQOC3cZOyMBqZULHGsiEScEXWcE1C8lXYV6zKXQlAwBZWyYacpwJMqO wpQJQtOUBbTfwPwOTY1kgCaI8VuawMVYEk1XkPzZ4b/6D2ky83BBSXKm1zAzsYdDIBszNzMb+j2W Vk5Tx9vtgUOfOrEynzoGXOD+ygV6pD06BBNwjEOOyb5yR2MWdx5C09wh+wF3THt+jztGjMkYIwpf pm+5A3ScEoNyRwrJR7mDSv0qIyhfAwHPO3uQEkv6BZ51+KuOAOwzoWnsyX+A/ZuB38aespxhLvag V1JjUey3Ivk/wn7RV5wB1Kk7ChAtAApGZ1EAhtCnKKD4AQXxo79LAZ6pnGUuBQA8FYkCGST/RxSA 2GCaAuwsCbyZhb8CNI0/QBEo2xT+fgi2RzGwjaE6iwmODoLOYd49soQImIXwNZMAffhuHZhgaRyI qph+MRIAY5/g9kkeiQON4XjOBokD5ZH40AqO0+zAOCYOTLxhoN6psWUYGIMgsKFgQhLYUDBxiSfZ UOCfKDeiNhRP8Rs2dOO0DaWYYWmwYEQBlmUFzAsVaFqWqyRvYfygkQMY6Ag0/gDwChwfQ44JMAd4 fsu2gu0gJR/me7aVBnsLkTSyut6vSPrrEY5kP0Zm2GPUdoDyKa91G7m2FzY8ylg+DB9GGauMdcA5 4M6TnScD3KCaaXd/wI34LX8vNwqoZRbM5Qa4mBJCueGE5P9az8V+w4/hefHDFJphaUn8mJrc8YFx IYNQ3+qDATAJmAUwrWByhxqSxqKjESiVaZhP2L0MyjTfs67kCJVkPRtn8J78B7y/o/J38v4dzS5s P8Nq1u9ZTQqSJs70iChn/y96RLoZvKMg8a4Z5t2eGbxbtPfHvPNHaPt9Dmaxgr7cyPY9q0097748 Oi/dZZjBE8of8MTyH+EJ6NFzeQIsLhV2/j36zby4Msv3Aa780PetX3AA+L6+0/P2fYxQESOI/YEf u0qG+rELZODBCtSPAc6Q86N+TJDsN/wY/7Qf+wLN8GPghvM71uOC47/tx/YhZ/P1Y38l00Fohtf6 Ae1ih/41r0Wi3QjJn7/X+ivqR6EZPopE/bf9nPf4v2f7ADTqect/9Dc4QIRmeM4fcKDR99+zdMB/ Uv0NWvDmN3gwy64BHvwrdq0Lp0MG8EZHFUE8Pj1WDTMdA/LokfidmmT3AHtlSHYP4QkVavcicb9h 96im7R7wJF/tHvyDx4LYgLYHRBI+SBu+0P3ztzAEJEKbRH4xOPTztagUZbChUA8rE/n37Bg9KQJF xr2gK7PuogxhWNfpSFYH/My4C/SFXkfAbSISna1RYARoSqOgrw8BTeFSTu6LgVivUII2Ud7P1Jw7 jBLwr6Spk7G5yzpnKzs7JzMrE0v4yGGdo73zOntnh3WCglL07sbO9F8rzSoCKgdu4tFJNEgMMIMF EiKFXJQQOsOFjrgAFiNOFcf+TSlwu/uhqafe0DlgDFIwNVSG+5qDmZPD8gt1puAANvvOYDPZHDZf iP4TNjtQKeDwzM4MgM14pPnZHfQTBJQITCu4IdMO8shEhD18hk6CgJn5XZAcpAiBSQgwgWEDmZIm X+jh2lZIPWMIPL9oDLkjkzDo8xQ/v1IBmbhxQiZpNKBvHwz6q6tRjB2QpxIAlnuQpwJsSZMm4No9 pGcqnJHnKz2Q5w+ATgC5uqIsx0OwPqDH0xKfY2DAz78waAAMzAfMtIEBzdBPz9X4AgFPGZhzGNTA nMKAQWHUwACNwtGhBoYX8xsGhu4HBobu+wZmUdzPDAx4gtSXrRz7uwZmZsu4H7T8ek7LuBktX8X2 wC2r0X8vTGH4TssY6DsDRKDC/wFZY38ga9+Zsmb6A1kz/UDWTN/nOFnJz2QtCMs6hxX0mHnI+gct X877mawh3I+Ht39Z1uDCf0nWTGQ/DhxwM2Sdg0NlnQ7vr84c+GNBZa32O4EDy7SsPaAZsmZBOT49 tINy/FTj92QdQJrrQfkeCgG+M/1271af0T4yfwv7NWe4fRAY/r5H+0IeRraQ4ws5gAy8ewoZyWOS IAvDkMEhmSwAR/4EBJrSOCbSBDYKQ5bMCMKz7aX7Fjvyb7A7joSpU5NKKHZMP8UOFgu1L00o9beQ Kf4GyOW0RnQo5O2Y6UiBkgR5OlI4VfNHARmtL6XDgnYkUviI8Gp2QHYE/t1qbHJgv72dGd7Y2dnV 1gF5IpUer7FT1hl5osuY9JiWGX6/maWxmxWcZW9n40n/9QktgV1qOzWQPH68pb2zGd4WPImEp8er 2ONNPe2Mba1Mpp4DMvMwsTS2szBDAMP5TvbmNvbuyPOvK6CvD5nggQ+3Qw4xeKC3QjAfwDY1nRGL PEDkgdZGnuDHQDMjsTl2AXDzX7ILDNgf+wCyGXbhMQa1C+BNlZyZNxSLULuggvkNu7DoB3Zh0fft QnbbX9sFCFLDhLL+vtefZRcAE+ZlF06SnSSj5jhJNscukCBP2wXQ875vF2Kxapge1tsMc7QCwPiX tGIF9sfegnyGVlSRtKIU3jfO1ApOVCvMf0crOKe1AgwlTPEOC4JiEu/AnTaZLBA8+RPQp1DeTT13 qoE89esKx+To405gQ3n6FsajhxVM983WOBzn9zXu8I106K80ThDqgWOPxu8OyNFD6dCvaBwZibY/ 1zgiLpyMlYM4954BQP6XtOWG4I9tCNUMbdEQRLVFGd7LYFBtMQXJFNWWZoHf0BbTH9gQ0+9L9Niq sr+0IUZIbOH7A4l++CWJ4gBB85JoK+4EGQVHK25m/9kJTXMERGjl8AUyMPk9uGmOkMEtY7DgkU9a BEsUw9kUemIFcclkkYi2GM3Amhy+FjvDf8+ODH6EO9UM3Bm/ixto5zo0HSdQfNOOL/RlQ9lvxQnT 7VDj0HYeIu3Q96AP6M6OF8BeQ1Ftw9RDvKSRjlWol0bP0OG/KS5vxZAiGpIcp/RIHpm590F0ZzZ2 i8BjSrMkGInrgf82M/6uBKl+SYJXyfGUcyVI/S9JkGaOBC03/dMSVFPd+QcSpJ2XBI0ojChQCZr+ hgTpfkmCTFSh1HMlSP8PSvAqNC1BhjkSpJL4uyQohtA5W4KACvWv8iOxgiQ/9Oz78mOcl/zKqcqp fl9+TL8kP18aiG6u/Bb8S/JbOEd+nFv+afnJKfy+/JjnJT8ZWhlaHfrflR/LL8mvh86BYa78WP8l +bHNkd8n6X+8/wn9vvzY5yW/ZPpk+t/3gIt+SX5GjI1Mc+W3+B+U30wPuGSO/NTk/wUPKPT7HpBj XhLEM+GZgATJevZC01zmJMH8cy5PSbF8gRozKsWL0DR3ub6B7wvV7fg97qLwUxD4hri/iAz/gKvc 8+Jq6MLQhWi/MPuNfsHzS/1ChiWHdW6/wP+D/eIaNC25pXP6RY/i39Uv0FfrZksQEL9DW2dKgGj2 lADRs+8LcNm8BAixQqxot3CYAXM5CWYuDFPhJzBfYF6fg6AScAyVA4lCL5HfCuS3Evn9Xrs6ZL4Y iFWH7FtaeOdBSyjOF+OLQWlRnwGTjwRz6hb2RzBfIlR8D3IbjG0Pro3sW8gr5g15MXkP3IUWk38L eeW8ISuShy6EWBXnQF41b8h3YZyNKO7Ogbx63pBryI0oyqlqyL/VijUwZJk/1IoiikEY2yKKb7Fd S4L559haUQBsreZA5p83H1ZTGlHI0K6m/Bbyunnj3IZAbpsDef28cfaEb1CS6T2pAGTTGZAFSDjf gCFL/gTyTEvy8i+sx10qX0w51d05bQn+A21tpgZtbab+lmMb5s0xK2rAMSvqqZBkCrIQCfKU4/kR 5FIMJYL/jyWSTA+xohKZCV/4b4JvRQ3gW83hzMZ5a+kINbBdI3Mgi8wbsg4NsLc6NN9C3jT/nkWD Zwpd2DYHsui8ISvSJtPjmRRpv4UsNm8NrEEg18yBvHnekKnpADeo6b6FLA5D9p0XZDy9DC0cytN/ C1li/hKkB/2xbQ5kyXlD9mRAbCPDt/ZqC4nPf6e9yqAHvTKD/tu2pP6Btu4ygLbuMnxrYaRJHJuv hWmjB7YXlchM+DJ/E3xPBgAflctMicvOW+LUjCBipEZi0UvQ9E3F1m9sry8UoPknt4M6ZEzYUFw/ GbiZAE91fnszAW74NuC36mybup0gfVtvFSBBiHQGbidoIHDvJoSde++mBjdrgUXvkVpn3LvJwST8 1b0bEzYHPBiL3LuBuc8pxsqbovdUvxfIMX7FpxU3jc+3sLfBsI/MA7YRDuD9fdjb54E3gGn0Dd5G EHjGAoW9w/TvuZ8FNDiQ5GVEakcXmr5vViC189dPy0A/aWFKIyBSC9HQtHIrzlHuT7p/otxMWCO4 jUdYoNzgIwPfKjeY1QXfTlKztLczm1JwGqRwSsHRs+n75Zl9UGkOmg4Gf4LmSTJfMohiOfnP+qDQ r/bB2Sgqz0GRzvhPUCwm61nowGL+UxSFfx3F3Bko7pyDYp7pn6C4mDwHF0qRiqBo8h0UwYcJRfDq 23bj7ex3yqtNIUo3C1G6GYhOPZ9EIgUZ+8JA3z6f9ASaJmXXHFLUrP6EFEVyQQqIuhkhxRhpaa7e bsLLb5PDq5vZ/pXeziUEWNi5hMxUG5U5hNTZ/gkhNQghzhQ/UxtRvLrant/XbNU5KF5w+BMUN1MA tan4KYpigNe/hmLeDBTV5qBo5PInKEZSAC4KI29jmH4HRaC0m/GSyLcwFe1MpaYwpZ+FKf0MTKc0 guRrQVMkjcCScgAt+dA0Lbvn0NLh8Se0qFJepXJAxg3oe8yQlmbTArDcIIgQY24mZ2f+lRjSozMk YtCz2cSQkVD/PjHXoGli1OcQ4+H1J8S0IcQcpQLEyCItzTU5Gzbg1WT3KOzZJqv+1ybnW0eoQUJ0 ytXCjtBnGlEUxZ8/mKpIZYTroWhGUNz2HRTBV6U2CMFmUUMLoCigsXXXFJpMs9Bk+gmae+agefXI 76FZg6DpTP1TNIW/cvLX0Zwpds05Yv904o+sGhUQO4rsD8W+8StPf1/sWnMQJQv6E0StkOEPHM3P 4p8NInghQUG8qvJf+5Fv0dSeg6bL6T9Bs4ga3OOb/BzNTb+FZt4MNPfOQfNc6J+gaUKTw0jFPE7z MzO8QXQqwlCT/3UzPPUG2/cjjKfQNC06c2jZGf4ntOTSqNFfYDKgBbTsR1qaTQvAbYPYtyEGLYoU iRL07PuUfD/EuAxNU6I7h5I3kX8UK9ECSpoRStD3CWdTAhz0hs0zYwwSjiQqKEn4TmnOTBz15uB4 NepPcPSkBZrDTPczHIUEZwYZP8dxpnbrz8HR5uqf4EhN50uvxnSD7mfaLbTh7w8yZtJiMIcWYsQf BUwILcL0P6VFCKVlZowxX1pmGsd9JFqmfaLNnd/ziTr0OYxqzP30P/OJQsLzdN2Gc9A0iv/NCIMB oNnM8FM0N83TdRvN0YzDyX803EWfQx1Kh/JU9jvIApsmtPE3I7aZiBrPQfTC/T8KLRFEjzL8FFGR ecQY++cgej/9j2wbQzKmB8fM+DPnLST6W8774gw0TeboZ3n29/UTgr4dbEIRHMH1wJyMR0Y4Zb6D IGh9h729KX6rpxl+6V+5OnQUaOYYL3hIX4ZmPmO8oXQytHAEhMxxKEAzXlUAtNNNiwil9595VeEz 5sevKoAvvE69qnARA0wdticM3uMx06+8ku0F+bieNRjUFK5C4PzFqwp7f/DKK5yPx8598bTndMZP XnnNQV5ScPjBi04ZP3zRadZrL6SWp4Zn0XpT7ccHf9v+zBdfk8muYstZyhm+/+Lr3PYxpPZnSRxM TvwrEu/BvUFoIH3hDpEw+oW7CyQJh2LA91JnvNQshkp41e9IWGxawuAbLF8lLDZbwlN8Bl8yA187 ARzGIBxGvnZG4vCPvl4GNlrS18sCZ7SCE/uZNENjwMtzM9sin9HWj75JBgRCR3ptDv1KLWpN0DDg 269uz5GvGPQvfRFltnwxP5Cvw0z5Sv6BfCV/IF/Jf0W+kj+Tr0vx/0C+ktD/RL7YH8g3dKZ8Zf5A vjI/kK/MvyJfmZ/JV5D1fyBfGeh/Il/cD+SbPFO+8n8gX/kfyFf+X5Gv/M/ka8P1P5CvPPQ/kS/Z D+RbPlO+Cn8gX4UfyFfhX5Gvws/k69v5P5CvAvQ/kS/5D+TbM1O+O/9Avjt/IN+df79806E58t35 M/nezE2H/lS+6EvifyDfndC/Jt/iGfKlniHfUyT5HoP3gjPukHBGqHw5f0e+RtPynfmyCdYI5bwc TCe4Y5ufZDOQnntsBnyc0Wz9mZLpovCMP+6zGX/aZ42gf02mH2bIlGaGTG+SZHoZAx5emSFTS1Sm G39HppbTMjWFZsjUEqk0pzfNlSzIn/2Y1M/lW4bIN3RGWzhSW1NjFrN7ruXTMsxftfhzWZf9qawt oX9F1hDkxG6EYIGW0y6EIOMVEPQUZkYiPwRdXA9BKUIQ9Gwj4B8eurcEgk4uBffxRtBZK5hvB+C+ YQtBwvYQxOwIQf1O4KM3MtA1CwiqcIGgwU0QFOMGIA+QFk+FoMs06OjxWQ+UetBvqaD90P/vN3LY jLgiy0EZI98UBKtPosstgZyp1Ql/vK2Cb2/ADAm6DAxJsn+xEeALdi5Cj8mR7yaaIDigC1L9Hj5i sPJOzti+2+A3G5C0DKnDyCErZDp9XU8RXZLK6afXz9yW/EH7oEvuIh3/Dfz/7fZLZ/CfNJQKcTOh 49MAtz1WtmbOeBUzd7y6va2xHfIYjayTlbENMhisbWVnYQonZwhMHsibmRu72rjg5c3AMoTI0q4/ XzEW/xsrxuKRleB+YWlXsDaj2tcFCAGks8hKb9vBh6/OIUR9u4afODSf5fUAXr+wsh1YPO63Fp0D 01qzVnejY0IfauImyWq7vZ2LM8wnM1PUx5GKmBBRABHg95jBeMDAoKlpXlAO4GrYWJma4feARXac kUJg1CdgjSGjwULfbuDCxuPRfSOqlkxxZ6igtStTa4DR51yE4gHKjSDUdQC/ANxINgnmawj93msH BJwHBA1D6KTCIgyqY+DLiwAhQcQxQ5AkBl0ITR6DwvtAhiL9dyvTFKMUzOycPPEaU9/G/Wk+4JOQ EOQEjsGX03aB76k525u74NXs3c2c1Oyt7OBOamIsA5fh7UrO8kDIuAyUw/pc9ygfARmTuNp7WWwL PwHx1HwwjTvgfSkbai9ROZxksqBDghO4QUNaIHGgnihXVlAwwu4I7dvToUsODn1Cl5pUgwqpAbjH TspZjuSQwX1jj4qaGgvkAQfusNeEc1WR7+vugm0LFpELqE2D1AL8/4KbDRNgyEjKYUFqkcFSnA4T 0ICJFjt1RIctx+YgY+9kGHrELxCxU04f5K7DoFiPYsmRq0HJMlIJZlYNLoql8E0YgAbNuHY2DOjr NgUDi3AJYMtG4hrgdwhccwF8Ffh4GRWpnAIpxyC6ODa7C5BIQyGi3xqmBjUQnFmQuqzIVZ0kixuK XiEz13pOQSFD9j0/gAbK1mMWIXsszAewwJ8QTQxWHcF2wwaBDYICmzdTw1STw4kG+aUmXYUhXYX9 up/DAQzKAU/s9znwPYyYvk/fMtQTTPMGpYrsl6hiJFFlCoJGCPn8NGxNKGB6KODrv6XmVyBSkyAG YgCC62A4fwKFlQQlFFk37utXs2G8yOAEsKOFLQENcv7nOL6dF450JCiNiB1xtnJAsKGdF0YjJIz+ jPdTGE0gGDnawzcs8+YRF/bvwGgZFmBk7+wAY0Q9Tx7JYucjNRoSlB1gUhkSFKT5DjZT+297bRKW 1Gtxv95r/1mrNMUTczDmDW34iQVC7f6Uh0DbwpH2GKSUg6wGuoszghaRcqdqfZ+vqDUq/wtrRE6i Zsoa5eTk/IQaMDoiRKMDnUY8/c8jDTrYj9LDiQlOHHDUzQFLlgO+5aSDQNC2HMlbhZTRwBSBujTI 2SL46E/0BsVNGwr6n+D2c76JI7idhWxgnwtBfx2CLYN1nh5plw/+BTjRw78ozgBrFCsGElZoLgeC +SLSMd0f8RDF8wxk/T/H8+f8RL1PCXQQ8T5fA1ZEcmjLUxL7Ey6g0F9AHr8NfeZ+bu/djvHDDcNd 8Nd7b+1f9N4pW0T+S3QBmEI0ZJhXyP0RupYFG0wtHRyl0s7LC5FhhEh+8c/6LisJivQ30QQzzDlW +I8eTpTwGeu8cHw9LxzpSFDef40mAHZs88JoAclT/llvncKICzsVTQBeMc8LI92/BSPzr9EEK3w/ Oz+pXf9bMEpEMAKLtQAezZUa2t8af9Nb/krbPJg8RGPcjZ3hO80FENMP2v4n+roUZjnm7+7rUpij f0M/ksKEzupH89ERKWR4f746IoV5gZnuR2zQwnlhRPU3aK0UhuVrP2KbZz+Swuz+WzAy+It+NHM/ 1wNaYzfgLDGnSLk/94C/ghUngtUZzHnkDToNFzM3M7y8vZ29m7EdfjGs5aj1Ab6alSRTFuT8z/l4 BhON6Nr5P5TGYhKUx8gCMLvkFMGgpY0pHJ/ywNTQwK2sQHop6BEAa54/agXly2sSX+StjO2M8erG 7jZWcOzLAd8VscC8YIFb44R/OeFzSoQ38+HLa0wwiS9/5hEXk6AkfpcvYPyG72/gCw/SCjv2/PdG L2HOsCCxBuDEkjmRx3y4w469+zdwhx1b9I9yhxtpRQ/mDhh1gnuTg6WZHX6PJXwX5YyHQH9iQXgC tIcG9mWsSEus89QcPWz2vHoUGwlKLQaMHOxxMrZzVjHzcHVehPg6oNecMOQF37XoM/fTY6k4kkdm Ir2plI20i8Fil2l4OruA98fQetPRwNzR3pnb7NFhQCsO+m/7f3cbZFwJ/4IZAcOcM81jHmC0/wsO B+3/1qKA4aefLz73B9vP5p+wlSWVl9dzMJ2NoILW8o8kgvmnRuzUss/gAWlU98BLAkBnwUMUQIfv QOicWTKEzkunQ+jYWQ6Eau8zCJ2PKofQuaw3EHqH2gihsD9B6DyVL9wWwGxqPgq0oWq3ztnEyQy2 JBqW9u6Q2tTk2kwrBsH5U30C7FVIe6pv9tCMPe03+39rPvZ/Mf8O5gSZ/kaj8bvt/93b/8vt/zf/ +wvzv8K/Nv/bGF713flf38yE/+Z//5v/JcVX/83//jf/+ydQ/pv//XWM/pv/hZDtv/nfnJ9Q89/8 73/zv//N//43//utfftv/vfPMPpv/vevMfpv/hdt+7/53x9j9N/8719j9N/873/zv//N/4JW/pv/ /X4r/83/ovt/a/63mA36b/t/bvvvfcz/W+9j/tvb/wdQSwECMgsUAAAACADWMGsnoq0Pw9ITAQAA ug0ADwAAAAAAAAAAACAAtoEAAAAASW50ZXJkb21haW4ucHB0UEsFBgAAAAABAAEAPQAAAP8TAQAA AA== ------=_NextPart_000_0006_01BF7F78.354E7300-- From owner-sip-outgoing@lists.research.bell-labs.com Sat Feb 26 14:51:39 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18097 for ; Sat, 26 Feb 2000 14:51:39 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C03025305; Sat, 26 Feb 2000 14:42:31 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C042E52FC; Sat, 26 Feb 2000 14:41:58 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 8F1A652FC for ; Fri, 25 Feb 2000 11:49:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Feb 25 11:48:25 EST 2000 Received: from seattle.3com.com ([129.213.128.97]) by dusty; Fri Feb 25 11:45:55 EST 2000 Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id IAA19125; Fri, 25 Feb 2000 08:48:11 -0800 (PST) From: Burcak_Beser@3com.com Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by new-york.3com.com (8.8.8/8.8.8) with SMTP id IAA03480; Fri, 25 Feb 2000 08:48:11 -0800 (PST) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.3 (778.2 1-4-1999)) id 88256890.005C10A3 ; Fri, 25 Feb 2000 08:45:35 -0800 X-Lotus-FromDomain: 3COM To: Bryan Byerly Cc: sip@lists.research.bell-labs.com, rap@iphighway.com, byerly@cisco.com Message-ID: <88256890.005C0951.00@hqoutbound.ops.3com.com> Date: Fri, 25 Feb 2000 10:49:44 -0600 Subject: Re: Question on achieveing Assured QoS using SIP/COPS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk It is my understanding is that 'assured QoS' has nothing to do with the authorisation for which COPS is used. Can you elaborate your question? Burcak Beser 3Com Carrier Systems Group Bryan Byerly on 02/25/2000 09:38:21 AM To: sip@lists.research.bell-labs.com, rap@iphighway.com cc: byerly@cisco.com (bcc: Burcak Beser/MW/US/3Com) Subject: Question on achieveing Assured QoS using SIP/COPS Hi guys, Assuming a goal of achieving "assured QoS" using generic SIP: (In assured QoS, the phone doesn't ring until resource allocation has been confirmed vs. enabled QoS, when the phone rings and can be answered before QoS is established. In fact, if resources are not available, the enabled QoS conversation would continue (without QoS)). I understand that assured QoS can be achieved using the provisioned (push) model of COPS. (REQ, ... DEC, RPT, ... DEC, RTP, ... DEC, RPT ...) Some examples of proposed provisioned models (push model) which (can) achieve assured QoS are: a) DQoS (using Gate objects) b) COPS-PR (using ASN.1 encoded objects), ... which ones am I leaving out? However, I have not seen assured QoS achieved using the outsourcing model (pull model) of COPS. (REQ, DEC, RPT, .... REQ, DEC, RPT, ... REQ, DEC, RPT, ...) Is it even possible to achieve assured QoS using the outsourcing model (pull model) of COPS? If so, could someone please sketch a brief call flow for me of how to achieve assured QoS using the outsourcing model of COPS? Thanks for your help! Bryan Bryan J. Byerly byerly@cisco.com From owner-sip-outgoing@lists.research.bell-labs.com Sat Feb 26 15:03:50 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18199 for ; Sat, 26 Feb 2000 15:03:50 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 7094852FC; Sat, 26 Feb 2000 15:01:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E08165308; Sat, 26 Feb 2000 15:01:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 705AF52FC for ; Sat, 26 Feb 2000 15:01:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Sat Feb 26 15:01:04 EST 2000 Received: from ns.fmmo.ca ([207.253.160.156]) by dusty; Sat Feb 26 14:58:38 EST 2000 Received: from localhost (fm-listproc@localhost) by ns.fmmo.ca (8.9.3/8.9.3) with ESMTP id PAA16295; Sat, 26 Feb 2000 15:18:03 -0500 Date: Sat, 26 Feb 2000 15:18:03 -0500 (EST) From: Francois Menard List Account To: Jonathan Rosenberg Cc: Dean Willis , Henning Schulzrinne , Michael Thomas , sip@lists.research.bell-labs.com Subject: Re: DHCP option tags for SIP In-Reply-To: <38B4E482.AA6F472F@dynamicsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk > another binding, mapping their name (sip:dean.willis@wcom.com) to the ID > of the phone (sip:3736489@wcom.com). Is that right? > > Neat idea... solves the problem that a standalone phone is not always > going to have an easy way for the user to enter their name that it > should use in a registration. It is basically adding another layer of > indirection: user->device->address, rather than just user->address. > I've always maintained that there should be an easy way for a user to log into a SIP phone before doing anything. Ever since I heard that such a think has been tried out at 3COM, the thought of zapping my profile using my Palm Pilot into a SIP phone with a SIR serial port remained anchored in my brain. I've always thought since that every SIP phone should have an IR port for fast logons. What comes with the profile is sometimes quite painful to enter manually, when you think about it, a 2048bit PGP key isin't so easy to key in either. What I mean by this is that relying on MAC addresses as UUIDs and phone numbers as authentification certificates has to stop at a point. I do not like the idea of resorting to multiple levels of indirection to circumvent the problem of lack of enough information to begin with. -=Francois=- From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 28 01:00:11 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18306 for ; Mon, 28 Feb 2000 01:00:11 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 6C32752D5; Mon, 28 Feb 2000 00:57:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id E43F05302; Mon, 28 Feb 2000 00:57:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 96CED52D5 for ; Mon, 28 Feb 2000 00:57:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 28 00:56:05 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Mon Feb 28 00:53:36 EST 2000 Received: from dynamicsoft.com (1Cust39.tnt3.freehold.nj.da.uu.net [63.25.172.39]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA06870 for ; Mon, 28 Feb 2000 00:56:13 -0500 (EST) Message-ID: <38BA0F1E.9E7EF316@dynamicsoft.com> Date: Mon, 28 Feb 2000 01:01:02 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Subject: Supported Header Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Folks, I've submitted a revised version of the Supported header draft, removing the feature negotiation, as discussed on the list. The plan of attack is to submit this for proposed standard asap, and then fold it into the next draft of the sip spec. The revised draft defines the SUpported header, and specifies its usage in requests and in response to OPTIONS. Until the draft appears in the archives, you can pick up a copy at: http://www.cs.columbia.edu/~jdrosen/papers/draft-ietf-sip-serverfeatures-01.txt I will send this to IESG for proposed next Monday (March 6), unless there are still comments/concerns. Thanks, Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 28 01:17:50 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19314 for ; Mon, 28 Feb 2000 01:17:50 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id B59BF52AB; Mon, 28 Feb 2000 01:15:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3EEA052B6; Mon, 28 Feb 2000 01:15:24 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id BD3B952AB for ; Mon, 28 Feb 2000 01:15:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 28 01:13:56 EST 2000 Received: from bounty.cisco.com ([161.44.2.72]) by dusty; Mon Feb 28 01:11:27 EST 2000 Received: (from shbhatna@localhost) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) id BAA03677 for ; Mon, 28 Feb 2000 01:13:53 -0500 (EST) From: Shail Bhatnagar Message-Id: <200002280613.BAA03677@bounty.cisco.com> Subject: URI comparison usage To: Date: Mon, 28 Feb 2000 01:13:53 -0500 (EST) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit The question about URL comparison rules has come up a number of times in the past and I think rules have been defined. My question is from a proxy server standpoint. Why can't a SIP proxy server simply do a strcmp() for the From header and probably a strcmp() for the addr-spec portion of the To header ?? Why would any proxy or user agent do anything with the From or To header except appending a tag to the To ? IS it really necessary for the proxy to parse the input From/To and compare against parsed form of the From/To stored in the fast lookup data structure ?? Also, my guess is that the following sip:abc@domain.com;tag=1234-ABC is not a valid To header since tag could be a user-defined parameter in the SIP-URL rather than a addr-param. Is it said somewhere in the spec or I am missing something ? Thanks, Shail From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 28 02:13:55 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00075 for ; Mon, 28 Feb 2000 02:13:55 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 36C5752AB; Mon, 28 Feb 2000 02:11:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A950952BB; Mon, 28 Feb 2000 02:11:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id B6D8E52AB for ; Mon, 28 Feb 2000 02:11:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Feb 28 02:10:23 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Mon Feb 28 02:07:54 EST 2000 Received: from dynamicsoft.com (1Cust39.tnt3.freehold.nj.da.uu.net [63.25.172.39]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA06884; Mon, 28 Feb 2000 02:10:19 -0500 (EST) Message-ID: <38BA207B.68D71563@dynamicsoft.com> Date: Mon, 28 Feb 2000 02:15:07 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Shail Bhatnagar Cc: sip@lists.research.bell-labs.com Subject: Re: URI comparison usage References: <200002280613.BAA03677@bounty.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Shail Bhatnagar wrote: > > The question about URL comparison rules has come up a number of times in the > past and I think rules have been defined. My question is from a proxy > server standpoint. Why can't a > SIP proxy server simply do a strcmp() for the From header and probably > a strcmp() for the addr-spec portion of the To header ?? Why would any > proxy or user agent do anything with the From or To header except appending > a tag to the To ? IS it really necessary for the proxy to parse the input > From/To and compare against parsed form of the From/To stored in the fast > lookup data structure ?? I think so. User agents might do things like re-order parameters, for example. Since they must parse these headers completely, its not desirable for them to have to remember the details of the LWS and parameter ordering present in the field before it was parsed. > > Also, my guess is that the following > sip:abc@domain.com;tag=1234-ABC > > is not a valid To header since tag could be a user-defined parameter in > the SIP-URL rather than a addr-param. Is it said somewhere in the spec or > I am missing something ? No, this is valid. If, for some reason, someone defines a SIP URL parameter called tag, the To field would have been: To: ;tag=1122 Where the real To tag is 1122. Remember, if the URL contains a semicolon (which means it has a parameter), it must be enclosed in angle brackets. Thus, if there are angle brackets, tag is outside of it. If there are no angle brackets, there are no URL parameters. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 28 06:10:06 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02673 for ; Mon, 28 Feb 2000 06:10:05 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id F1F2C52B6; Mon, 28 Feb 2000 06:07:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 7049252BB; Mon, 28 Feb 2000 06:07:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 941FE52B6 for ; Mon, 28 Feb 2000 06:07:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 28 06:05:55 EST 2000 Received: from mail.huawei.com.cn ([202.96.135.132]) by dusty; Mon Feb 28 06:03:26 EST 2000 Received: from y13638 ([10.108.22.162]) by mail.huawei.com.cn (Netscape Mail Server v2.02) with SMTP id AAA20431 for ; Mon, 28 Feb 2000 19:05:58 +0800 Message-ID: <004201bf81db$8a74e200$a2166c0a@y13638.huawei.com.cn> Reply-To: "yinshaohua" From: "yinshaohua" To: Date: Mon, 28 Feb 2000 19:04:10 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi: In RFC2543, The re-INVITE is used to change the session descrioption of a existing call. If a UA receives a INVITE request for an existing call leg with a higher CSeq sequence number when processing a previous INVITE , I think the UA SHOULD stop the transaction of previous INVITE and then process the re-INVITE request, otherwise, there have two transactions in a call leg and may lead to confusion of call state. Would you tell me whether I am correct ? If not, how to process the re-INVITE? Thanks! ShaoHua Yin 2000/2/28 From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 28 07:00:03 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03722 for ; Mon, 28 Feb 2000 07:00:02 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A00CB52AB; Mon, 28 Feb 2000 06:57:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1F2D052C4; Mon, 28 Feb 2000 06:57:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id BF45352AB for ; Mon, 28 Feb 2000 06:57:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 28 06:56:55 EST 2000 Received: from mail.mera.ru ([195.98.50.58]) by dusty; Mon Feb 28 06:54:26 EST 2000 Received: from mcseem.mera.ru (mcseem.mera.ru [195.98.57.12]) by mail.mera.ru (8.9.3/8.9.3) with ESMTP id OAA29825; Mon, 28 Feb 2000 14:56:39 +0300 (MSK) Date: Mon, 28 Feb 2000 15:00:28 +0300 From: "Stanislav S. Timinsky" X-Mailer: The Bat! (v1.36) S/N F29DEE5D / Educational Reply-To: "Stanislav S. Timinsky" Organization: MERA Labs. X-Priority: 3 (Normal) Message-ID: <1625.000228@mera.ru> To: "yinshaohua" Cc: sip@lists.research.bell-labs.com, prj.men.sip@mera.ru Subject: Re: In-reply-To: <004201bf81db$8a74e200$a2166c0a@y13638.huawei.com.cn> References: <004201bf81db$8a74e200$a2166c0a@y13638.huawei.com.cn> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hello yinshaohua, Monday, February 28, 2000, 2:04:10 PM, you wrote: yinshaohua> Hi: yinshaohua> In RFC2543, The re-INVITE is used to change the session descrioption of a yinshaohua> existing call. yinshaohua> If a UA receives a INVITE request for an existing call leg with a higher yinshaohua> CSeq sequence number when processing a previous INVITE , I think the UA yinshaohua> SHOULD stop the transaction of previous INVITE and then process the yinshaohua> re-INVITE request, otherwise, there have two transactions in a call leg and yinshaohua> may lead to confusion of call state. yinshaohua> Would you tell me whether I am correct ? If not, how to process the yinshaohua> re-INVITE? yinshaohua> Thanks! yinshaohua> ShaoHua Yin yinshaohua> 2000/2/28 I think that You are mistaken in the moment, when UA should stop the previous INVITE-transaction. If re-INVITE has incompatible session description (and You stopped the current INVITE-transaction and RTP media flows), You can't return to the previous call (INVITE-transaction). My opinion is that the UA should stop the previous INVITE-transaction, if re-INVITE transaction has been finished (200-response has been received). -- Best regards, Stanislav S. Timinsky mailto:timinsky@mera.ru Mera Labs. From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 28 07:18:08 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04397 for ; Mon, 28 Feb 2000 07:18:07 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4A02852C4; Mon, 28 Feb 2000 07:15:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id B99E052C8; Mon, 28 Feb 2000 07:15:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 6347A52C4 for ; Mon, 28 Feb 2000 07:15:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 28 07:14:11 EST 2000 Received: from atlrel1.hp.com ([156.153.255.210]) by dusty; Mon Feb 28 07:11:42 EST 2000 Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by atlrel1.hp.com (Postfix) with ESMTP id D8E1AE491; Mon, 28 Feb 2000 07:14:04 -0500 (EST) Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238]) by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id MAA09103; Mon, 28 Feb 2000 12:14:03 GMT Message-ID: <38BA6697.82450B48@hplb.hpl.hp.com> Date: Mon, 28 Feb 2000 12:14:15 +0000 From: Anders Kristensen Organization: HP Labs X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Robert.Sparks@wcom.com, "'SIP List' (E-mail)" , "Henning Schulzrinne (E-mail)" Subject: Re: UAC use of tags received in responses References: <003201bf73dd$40e24300$8a9223a6@mcit.com> <38A33790.5A052AC6@dynamicsoft.com> <38B574B5.50448657@hplb.hpl.hp.com> <38B6D9E0.7B7BECB8@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Anders Kristensen wrote: > > > > I'm not sure it's a problem, but this can give rise to curious > > situations when the the non-2xx final response was generated by a UAS. > > In this case the UAS has inserted a To tag and hence believes the call > > consists of a single leg, whose UAS identifier (the To of the original > > request) has a tag. > > > > The UAC ACKs the response (ACK includes To tag) and resubmits the > > request *without* To tag. This basically constitutes initiating a new > > transaction in a new leg. > > > > Now I'm not sure if it's well-specified whether the UAS will associate > > that new request with the existing leg (which has a To tag). I think > > this would (or should) be the correct behaviour, as it really is the > > same leg, but I would imagine that different implementations might > > differ on this point. The consequence is that the second response (say a > > 2xx) may be returned with the *original* To tag. > > Hmm. I don't think this would happen. If the UAS receives a request and > sends a non-200 response with a tag, the call leg is over. It doesn't > know whether it will ever receieve another request, so I imagine it will > flush the state, and thats it. This would be true if it wasn't because the UAS has to keep transaction state hanging around for retransmissions - for a period of approximately 30 seconds. This is easily enough time for someone to manually type in a password and resubmit the request. > When the new request arrives, it creates > a new call leg. The tag in the response will probably be different than > the previous, or it might be the same. > > On the UAC, this basically means it really can't associate a tag with > the call leg until the 200 OK. Before that, any tags it sees in > provisionals or non-200s might not be the final tag. That might work, although it's a bit awkward. It's basically saying that the UAC shouldn't represent the initial leg as a real leg. > > > Maybe it should be clarified whether the UAS should respond to the > > second request with the old or a new To tag, and whether the UAC is > > supposed to think of the two requests as belonging to different legs? > > I don't think we can impose requirements on maintenance of state at a UA > after rejecting a new INVITE. So you're saying that both behaviours are acceptable: if the UAS knows of the old leg it may or may not respond with the old tag, and it's up to the UAC to recognize that the response to the resubmitted request belongs to the new leg. This seems like a reasonable solution to me, although it basically modifies the rule that a leg is identified by Call-ID, From, and To headers. It is maybe worth noting that the UAC can address this problem differently by forcing the reissued request to belong to a different leg (by using a different From tag) or a different call (by using a different Call-ID). This denies the UAS (and proxies) the opportunity to recognize that the second request is related to the first, and so should be discouraged. Anders -- Anders Kristensen , http://www-uk.hpl.hp.com/people/ak/ Hewlett-Packard Labs, Bristol, UK From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 28 08:03:57 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06243 for ; Mon, 28 Feb 2000 08:03:56 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C25D252BB; Mon, 28 Feb 2000 08:01:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 4BB6752D4; Mon, 28 Feb 2000 08:01:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id DECB352BB for ; Mon, 28 Feb 2000 08:01:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 28 08:01:01 EST 2000 Received: from atlrel2.hp.com ([156.153.255.202]) by dusty; Mon Feb 28 07:58:32 EST 2000 Received: from otter.hpl.hp.com (otter.hpl.hp.com [15.144.59.2]) by atlrel2.hp.com (Postfix) with ESMTP id 1390ADEA for ; Mon, 28 Feb 2000 08:01:23 -0500 (EST) Received: from hplb.hpl.hp.com (kristensen-a-4.hpl.hp.com [15.144.26.238]) by otter.hpl.hp.com (8.9.3/HP-Labs Bristol Internal Mail Hub) with ESMTP id NAA11974 for ; Mon, 28 Feb 2000 13:00:56 GMT Message-ID: <38BA7195.D9198848@hplb.hpl.hp.com> Date: Mon, 28 Feb 2000 13:01:09 +0000 From: Anders Kristensen Organization: HP Labs X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: SIP Subject: CANCEL: Hop-by-hop or end-to-end? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit My understanding is that CANCELs are hop-by-hop requests only, i.e. proxies respond to CANCELs and then may or may not themselves CANCEL branches of the corresponding proxied request. These CANCELs then have a single Via header identifying the proxy. However, I don't think it states this conclusively in the spec. Also this seems to me to be an (insignificant maybe) security hole as CANCELs cannot be authenticated by the caller? Anders -- Anders Kristensen , http://www-uk.hpl.hp.com/people/ak/ Hewlett-Packard Labs, Bristol, UK From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 28 09:36:05 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09923 for ; Mon, 28 Feb 2000 09:36:05 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A17BB52C8; Mon, 28 Feb 2000 09:33:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1FC4052D5; Mon, 28 Feb 2000 09:33:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 642FF52C8 for ; Mon, 28 Feb 2000 09:33:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 28 09:32:02 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Mon Feb 28 09:29:32 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA07093; Mon, 28 Feb 2000 09:31:15 -0500 (EST) Message-ID: <38BA87D7.58AB43AC@dynamicsoft.com> Date: Mon, 28 Feb 2000 09:36:07 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Stanislav S. Timinsky" Cc: yinshaohua , sip@lists.research.bell-labs.com, prj.men.sip@mera.ru Subject: Re: References: <004201bf81db$8a74e200$a2166c0a@y13638.huawei.com.cn> <1625.000228@mera.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit "Stanislav S. Timinsky" wrote: > > Hello yinshaohua, > > Monday, February 28, 2000, 2:04:10 PM, you wrote: > > yinshaohua> Hi: > > yinshaohua> In RFC2543, The re-INVITE is used to change the session descrioption of a > yinshaohua> existing call. > yinshaohua> If a UA receives a INVITE request for an existing call leg with a higher > yinshaohua> CSeq sequence number when processing a previous INVITE , I think the UA > yinshaohua> SHOULD stop the transaction of previous INVITE and then process the > yinshaohua> re-INVITE request, otherwise, there have two transactions in a call leg and > yinshaohua> may lead to confusion of call state. > yinshaohua> Would you tell me whether I am correct ? If not, how to process the > yinshaohua> re-INVITE? > yinshaohua> Thanks! > > yinshaohua> ShaoHua Yin > yinshaohua> 2000/2/28 > > I think that You are mistaken in the moment, when UA should stop the > previous INVITE-transaction. If re-INVITE has incompatible session > description (and You stopped the current INVITE-transaction and RTP > media flows), You can't return to the previous call > (INVITE-transaction). My opinion is that the UA should stop the previous > INVITE-transaction, if re-INVITE transaction has been finished (200-response has been received). No. You should always complete the transaction, otherwise you end up with state hanging around in proxies longer than it needs to be. As a general rule, transactions are independent and should each individually be completed. There is never confusion with call state or session state. Regarding session state, the most recent SDP (as indicated by CSeq) is the one to use. Regarding call state, non-200 class responses to reinvites do not terminate the call, so the call remains active no matter what the response to re-INVITE. For example, lets assume that both session descriptions are OK. In this case, the right approach is to send a 200 OK to the first and then the second re-invite. If the first SDP is not acceptable, but the second is, respond to the first with 400 and the second with 200. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 28 09:44:07 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10133 for ; Mon, 28 Feb 2000 09:44:06 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 1646552D4; Mon, 28 Feb 2000 09:41:32 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 7E92E52DA; Mon, 28 Feb 2000 09:41:31 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 6E7BA52D4 for ; Mon, 28 Feb 2000 09:41:09 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 28 09:39:17 EST 2000 Received: from ietf.org ([132.151.1.176]) by dusty; Mon Feb 28 09:36:47 EST 2000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10002; Mon, 28 Feb 2000 09:39:12 -0500 (EST) Message-Id: <200002281439.JAA10002@ietf.org> To: IETF-Announce: ; Cc: sip@lists.research.bell-labs.com From: The IESG SUBJECT: Last Call: The SIP INFO Method to Proposed Standard Reply-To: iesg@ietf.org Date: Mon, 28 Feb 2000 09:39:12 -0500 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk The IESG has received a request from the Session Initiation Protocol Working Group to consider The SIP INFO Method 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 March 13, 2000. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-sip-info-method-02.txt From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 28 11:56:08 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14460 for ; Mon, 28 Feb 2000 11:56:08 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 0229852D6; Mon, 28 Feb 2000 11:53:25 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 74E9B52DA; Mon, 28 Feb 2000 11:53:24 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id EFA8A52D6 for ; Mon, 28 Feb 2000 11:53:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 28 11:52:15 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Mon Feb 28 11:49:46 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA07528; Mon, 28 Feb 2000 11:48:28 -0500 (EST) Message-ID: <38BAA7FF.3A94BB85@dynamicsoft.com> Date: Mon, 28 Feb 2000 11:53:19 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Anders Kristensen Cc: SIP Subject: Re: CANCEL: Hop-by-hop or end-to-end? References: <38BA7195.D9198848@hplb.hpl.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Anders Kristensen wrote: > > My understanding is that CANCELs are hop-by-hop requests only, i.e. > proxies respond to CANCELs and then may or may not themselves CANCEL > branches of the corresponding proxied request. These CANCELs then have a > single Via header identifying the proxy. True, excepting that stateless proxies will forward CANCEL, so there may be more than one Via if there are stateless proxies between. > However, I don't think it > states this conclusively in the spec. Well, there is this text: > The Call-ID, To, the numeric part of CSeq and From headers in the > CANCEL request are identical to those in the original request. This > allows a CANCEL request to be matched with the request it cancels. > However, to allow the client to distinguish responses to the CANCEL > from those to the original request, the CSeq Method component is set > to CANCEL. The Via header field is initialized to the proxy issuing > the CANCEL request. (Thus, responses to this CANCEL request only > reach the issuing proxy.) > Particularly, the last sentence. It could be clearer. Also this seems to me to be an > (insignificant maybe) security hole as CANCELs cannot be authenticated > by the caller? I think you mean by the called party. Yes, they cannot be authenticated. The problem is that the CANCEL can be generated by any proxy along the path. So, the right way to handle CANCEL security is via hop by hop stuff. If, for example, there is an IPSEC connection between proxies, some request initiated through that connection can only be cancelled through that connection also. In the absence of IPSEC, you should only accept a CANCEL from the same IP address that sent the request. THe spec is completely silent on these issues. They are being worked on. Thanks, Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 28 12:46:01 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15965 for ; Mon, 28 Feb 2000 12:46:00 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 2972652D5; Mon, 28 Feb 2000 12:43:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id ED99252DE; Mon, 28 Feb 2000 12:43:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 55A9F52D5 for ; Mon, 28 Feb 2000 12:43:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 28 12:42:42 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Mon Feb 28 12:40:13 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id MAA22251 for ; Mon, 28 Feb 2000 12:42:40 -0500 (EST) Message-ID: <38BAB38F.C3EC9A26@cs.columbia.edu> Date: Mon, 28 Feb 2000 12:42:39 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Subject: SRV records Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Now that SRV records are a Proposed Standard (RFC 2782), I would suggest simplifying the lookup procedure to include SRV as SHOULD rather than as an optional procedure. This does not force modifying DNS to include SRV records, but does encourage implementation of SRV in SIP clients. Comments? -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 28 14:00:07 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17573 for ; Mon, 28 Feb 2000 14:00:06 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 5345D52E2; Mon, 28 Feb 2000 13:56:01 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C5D7B52E3; Mon, 28 Feb 2000 13:56:00 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id E69DD52E0 for ; Wed, 23 Feb 2000 23:31:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Wed Feb 23 23:29:52 EST 2000 Received: from web3401.mail.yahoo.com ([204.71.203.55]) by dusty; Wed Feb 23 23:27:28 EST 2000 Message-ID: <20000224042950.28361.qmail@web3401.mail.yahoo.com> Received: from [202.54.89.47] by web3401.mail.yahoo.com; Wed, 23 Feb 2000 20:29:50 PST Date: Wed, 23 Feb 2000 20:29:50 -0800 (PST) From: Steve Little Subject: Re: Diff. between branch and tag To: Igor Slepchin Cc: SIP Mailing List MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Hi, Ive have seem implementations insert a tag field irrespective of whether it forks or not. Also, if forking proxies insert tags while forwarding the request, then isnt that enough ? Then when a receiving entity gets the request, it responds and copies the tag in it. That way requests can be matched wth responses, and the generation of tags can be the rsponsibility of the entity that actually forks a request - why should a reciever try and figure out if its forked ? Isnt it simpler for the sender to do it ? Thx --- Igor Slepchin wrote: > Branch IDs allow proxies to match responses to > forked requests. Without > them, a proxy wouldn't be able to tell which branch > a response > corresponds to. Tags are of no help here since they > are not known until > responses arrive. > > --- > Igor Slepchin > > > Steve Little wrote: > > > > Hi, > > What is the difference between inserting a branch > > param in a Via and a tag in To, From headers ? > > Dont both uniquely identify req-resp for forking > > proxies ? > > > > Thx > > > > __________________________________________________ > > Do You Yahoo!? > > Talk to your friends online with Yahoo! Messenger. > > http://im.yahoo.com > __________________________________________________ Do You Yahoo!? Talk to your friends online with Yahoo! Messenger. http://im.yahoo.com From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 28 14:33:06 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18277 for ; Mon, 28 Feb 2000 14:33:05 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 3D2C952E4; Mon, 28 Feb 2000 14:23:02 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 24B7F52EC; Mon, 28 Feb 2000 13:58:37 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id E2CD252E4 for ; Sat, 26 Feb 2000 21:39:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Sat Feb 26 21:37:20 EST 2000 Received: from bmailnj.iphighway.com ([209.3.6.76]) by dusty; Sat Feb 26 21:34:53 EST 2000 Received: from SHAI (216-59-44-28.usa.flashcom.net [216.59.44.28]) by bmailnj.iphighway.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id FQR6RYH2; Sat, 26 Feb 2000 21:33:43 -0500 Message-Id: <4.2.0.58.20000226211710.018624a8@209.3.6.76> X-Sender: herzog@209.3.6.76 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sat, 26 Feb 2000 21:36:42 -0500 To: sip@lists.research.bell-labs.com, rap@iphighway.com, byerly@cisco.com From: Shai Herzog Subject: Re: FW: Question on achieveing Assured QoS using SIP/COPS In-Reply-To: <6399122981E1D211AB490090271E0AA34C5185@BMAILNJ> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_171463521==_.ALT" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --=====================_171463521==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Bryan, Burcak Let me make a few assumptions: 1. We are talking about Cable modems and PacketCable DQoS (DOCSIS 1.1) 2. We are looking per-call QoS 3. "Assured" means Resources are allocated before a ring (a ring requires QoS), and resources are committed after the other side picked up (call commences). The DQoS is a bit of an odd-ball standard, since it mixes RSVP and COPS-RSVP Push model (gate operations). But, we all know that COPS-RSVP wasn't designed to be in a push model. I think there is a "better" solution just by using RSVP to allocate, open and close gates: Stage 1 (in parallel) MTA-->(NCD/DCS)-->CMS/PDP (CMS makes a gate decision, resources are allocated) | /|\ \ | COPS-RSVP (outsourcing) \ | \(RSVP 1)---->CMTS Stage 2: Phone ring, other side answer MTA-->(RSVP 2)---->CMTS (confirms the reservation) ----- RSVP(1) only ask for authorization and allocation, no actual commitment of resources. Resources are still in solicited mode. RSVP(2) Commits resources (goes into unsolicited mode). The difference may be a flag (allocate only, or commit). This way, the Outsourcing model is maintained in COPS-RSVP (and we all breath easier ;-), and basically only one protocol is used to authorize allocate and reserve resources, i.e., RSVP/COPS. I believe this is the closest DQoS can get to be compliant with the COPS-RSVP architecture. Shai >-----Original Message----- >From: Burcak_Beser@3com.com >To: Bryan Byerly >Cc: sip@lists.research.bell-labs.com; rap@iphighway.com; >byerly@cisco.com >Sent: 02/25/2000 11:49 AM >Subject: Re: Question on achieveing Assured QoS using SIP/COPS > > > >It is my understanding is that 'assured QoS' has nothing to do with the >authorisation for which COPS is used. Can you elaborate your question? > >Burcak Beser >3Com Carrier Systems Group > > > > > >Bryan Byerly on 02/25/2000 09:38:21 AM > >To: sip@lists.research.bell-labs.com, rap@iphighway.com >cc: byerly@cisco.com (bcc: Burcak Beser/MW/US/3Com) > >Subject: Question on achieveing Assured QoS using SIP/COPS > > > > >Hi guys, > >Assuming a goal of achieving "assured QoS" using generic SIP: >(In assured QoS, the phone doesn't ring until resource allocation has >been confirmed >vs. enabled QoS, when the phone rings and can be answered before QoS is >established. >In fact, if resources are not available, the enabled QoS conversation >would continue >(without QoS)). > >I understand that assured QoS can be achieved using the provisioned >(push) model of COPS. >(REQ, ... DEC, RPT, ... DEC, RTP, ... DEC, RPT ...) >Some examples of proposed provisioned models (push model) which (can) >achieve assured QoS are: >a) DQoS (using Gate objects) >b) COPS-PR (using ASN.1 encoded objects), >... which ones am I leaving out? > >However, I have not seen assured QoS achieved using the >outsourcing model (pull model) of COPS. >(REQ, DEC, RPT, .... REQ, DEC, RPT, ... REQ, DEC, RPT, ...) > >Is it even possible to achieve assured QoS using the outsourcing model >(pull model) of COPS? > >If so, could someone please sketch a brief call flow for me of >how to achieve assured QoS using the outsourcing model of COPS? > >Thanks for your help! > >Bryan > >Bryan J. Byerly >byerly@cisco.com __________________________________________________________________ Shai Herzog, Founder & CTO IPHighway Inc. Tel : (914) 654-4810 55 New York Avenue Main: (508) 620-1141 Framingham, MA 01701 Fax : (212) 656-1006 --=====================_171463521==_.ALT Content-Type: text/html; charset="us-ascii" Bryan, Burcak

Let me make a few assumptions:

1. We are talking about Cable modems and PacketCable DQoS (DOCSIS 1.1)
2. We are looking per-call QoS
3. "Assured" means Resources are allocated before a ring (a ring requires
   QoS), and resources are committed after the other side picked up
   (call commences).

The DQoS is a bit of an odd-ball standard, since it mixes RSVP
and COPS-RSVP Push model (gate operations). But, we all know that
COPS-RSVP wasn't designed to be in a push model.

I think there is a "better" solution just by using RSVP to allocate,
open and close gates:

Stage 1 (in parallel)

MTA-->(NCD/DCS)-->CMS/PDP (CMS makes a gate decision, resources are allocated)
 |                /|\
  \                | COPS-RSVP (outsourcing)
   \               |
    \(RSVP 1)---->CMTS

Stage 2:

Phone ring, other side answer

MTA-->(RSVP 2)---->CMTS    (confirms the reservation)

-----
RSVP(1) only ask for authorization and allocation, no actual commitment
        of resources. Resources are still in solicited mode.
RSVP(2) Commits resources (goes into unsolicited mode).
The difference may be a flag (allocate only, or commit).

This way, the Outsourcing model is maintained in COPS-RSVP (and
we all breath easier ;-), and basically only one protocol is
used to authorize allocate and reserve resources, i.e., RSVP/COPS.

I believe this is the closest DQoS can get to be compliant with
the COPS-RSVP architecture.

Shai

-----Original Message-----
From: Burcak_Beser@3com.com
To: Bryan Byerly
Cc: sip@lists.research.bell-labs.com; rap@iphighway.com;
byerly@cisco.com
Sent: 02/25/2000 11:49 AM
Subject: Re: Question on achieveing Assured QoS using SIP/COPS



It is my understanding is that 'assured QoS' has nothing to do with the
authorisation for which COPS is used. Can you elaborate your question?

Burcak Beser
3Com Carrier Systems Group





Bryan Byerly <byerly@cisco.com> on 02/25/2000 09:38:21 AM

To:   sip@lists.research.bell-labs.com, rap@iphighway.com
cc:   byerly@cisco.com (bcc: Burcak Beser/MW/US/3Com)

Subject:  Question on achieveing Assured QoS using SIP/COPS




Hi guys,

Assuming a goal of achieving "assured QoS" using generic SIP:
(In assured QoS,  the phone doesn't ring until resource allocation has
been confirmed
vs. enabled QoS, when the phone rings and can be answered before QoS is
established.
In fact, if resources are not available, the enabled QoS conversation
would continue
(without QoS)).

I understand that assured QoS can be achieved using the provisioned
(push) model of COPS.
(REQ, ...  DEC, RPT, ... DEC, RTP, ... DEC, RPT ...)
Some examples of proposed provisioned models (push model) which (can)
achieve assured QoS are:
a) DQoS (using Gate objects)
b) COPS-PR (using ASN.1 encoded objects),
... which ones am I leaving out?

However, I have not seen assured QoS achieved using the
outsourcing model (pull model) of COPS.
(REQ, DEC, RPT, .... REQ, DEC, RPT,  ... REQ, DEC, RPT, ...)

Is it even possible to achieve assured QoS using the outsourcing model
(pull model) of COPS?

If so, could someone please sketch a brief call flow for me of
how to achieve assured QoS using the outsourcing model of COPS?

Thanks for your help!

Bryan

Bryan J. Byerly
byerly@cisco.com


__________________________________________________________________
Shai Herzog, Founder & CTO   IPHighway Inc.   Tel : (914) 654-4810
55 New York Avenue                            Main: (508) 620-1141
Framingham, MA 01701                          Fax : (212) 656-1006
                                             

        
                                
                             --=====================_171463521==_.ALT-- From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 28 14:38:31 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18401 for ; Mon, 28 Feb 2000 14:38:31 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 2820B52E1; Mon, 28 Feb 2000 14:35:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id AA4CC52E3; Mon, 28 Feb 2000 14:35:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 3153A52E1 for ; Mon, 28 Feb 2000 14:35:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 28 14:34:11 EST 2000 Received: from PMESMTP02.wcom.com ([199.249.20.2]) by dusty; Mon Feb 28 14:31:39 EST 2000 Received: from ndcrelay.mcit.com ([166.37.172.49]) by firewall.mcit.com (PMDF V5.2-32 #41713) with ESMTP id <0FQN000OMNORDA@firewall.mcit.com> for sip@lists.research.bell-labs.com; Mon, 28 Feb 2000 19:34:04 +0000 (GMT) Received: from omzmta01.mcit.com (omzmta01.mcit.com [166.37.194.119]) by ndcrelay.mcit.com (8.8.7/) with ESMTP id TAA19235; Mon, 28 Feb 2000 19:34:10 +0000 (GMT) Received: from wcom.com ([166.33.132.111]) by omzmta01.mcit.com (InterMail v03.02.05 118 121 101) with ESMTP id <20000228193400.GJT2776@wcom.com>; Mon, 28 Feb 2000 19:34:00 +0000 Date: Mon, 28 Feb 2000 13:35:11 -0600 From: Alan Johnston Subject: Re: CANCEL: Hop-by-hop or end-to-end? To: Jonathan Rosenberg Cc: Anders Kristensen , SIP Message-id: <38BACDEF.1AA270D6@wcom.com> MIME-version: 1.0 X-Mailer: Mozilla 4.51 [en] (Win95; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <38BA7195.D9198848@hplb.hpl.hp.com> <38BAA7FF.3A94BB85@dynamicsoft.com> Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit The current version of the SIP Telephony Call Flow Examples document (draft-johnston-sip-call-flows-00.txt) incorrectly shows end-to-end behavior for CANCELs. This is corrected in the new draft which will be published this week. Alan Johnston MCI WorldCom Jonathan Rosenberg wrote: > > Anders Kristensen wrote: > > > > My understanding is that CANCELs are hop-by-hop requests only, i.e. > > proxies respond to CANCELs and then may or may not themselves CANCEL > > branches of the corresponding proxied request. These CANCELs then have a > > single Via header identifying the proxy. > > True, excepting that stateless proxies will forward CANCEL, so there may > be more than one Via if there are stateless proxies between. > > > However, I don't think it > > states this conclusively in the spec. > > Well, there is this text: > > > The Call-ID, To, the numeric part of CSeq and From headers in the > > CANCEL request are identical to those in the original request. This > > allows a CANCEL request to be matched with the request it cancels. > > However, to allow the client to distinguish responses to the CANCEL > > from those to the original request, the CSeq Method component is set > > to CANCEL. The Via header field is initialized to the proxy issuing > > the CANCEL request. (Thus, responses to this CANCEL request only > > reach the issuing proxy.) > > > > Particularly, the last sentence. It could be clearer. > > Also this seems to me to be an > > (insignificant maybe) security hole as CANCELs cannot be authenticated > > by the caller? > > I think you mean by the called party. Yes, they cannot be authenticated. > The problem is that the CANCEL can be generated by any proxy along the > path. So, the right way to handle CANCEL security is via hop by hop > stuff. If, for example, there is an IPSEC connection between proxies, > some request initiated through that connection can only be cancelled > through that connection also. In the absence of IPSEC, you should only > accept a CANCEL from the same IP address that sent the request. THe spec > is completely silent on these issues. They are being worked on. > > Thanks, > Jonathan R. > > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 28 15:05:56 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18815 for ; Mon, 28 Feb 2000 15:05:55 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id E46F852DE; Mon, 28 Feb 2000 15:03:25 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 4D08152E3; Mon, 28 Feb 2000 15:03:24 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id B055C52DE for ; Mon, 28 Feb 2000 15:03:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 28 15:01:39 EST 2000 Received: from rwcxch02.clarent.com ([208.205.112.21]) by dusty; Mon Feb 28 14:59:10 EST 2000 Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 28 Feb 2000 11:56:14 -0800 Message-ID: <2382884A8E7AD31197B500508B5C35DD824329@rwcxch02.clarent.com> From: Jean-Francois Mule To: Henning Schulzrinne Cc: sip@lists.research.bell-labs.com Subject: SRV records Date: Mon, 28 Feb 2000 11:56:14 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA18815 I second that. On the server side, SRV RR (experimental RFC2052) has been supported in BIND since version 4.9.5 (the latest being BIND 8.2.2. includes an update on SRV RR). Jean-Francois. -------------------------------------------------------------- Jean-François Mulé Clarent Corporation - Standards & Architecture Group T: +1 650 481-2835 jfm@clarent.com > -----Original Message----- > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > Sent: Monday, February 28, 2000 9:43 AM > To: sip@lists.research.bell-labs.com > Subject: SRV records > > > Now that SRV records are a Proposed Standard (RFC 2782), I > would suggest > simplifying the lookup procedure to include SRV as SHOULD > rather than as > an optional procedure. This does not force modifying DNS to > include SRV > records, but does encourage implementation of SRV in SIP clients. > > Comments? > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 28 15:28:38 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19383 for ; Mon, 28 Feb 2000 15:28:37 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 408555301; Mon, 28 Feb 2000 15:25:47 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8691E5300; Mon, 28 Feb 2000 15:25:46 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id ADAF75301 for ; Mon, 28 Feb 2000 15:25:07 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 28 15:24:29 EST 2000 Received: from ns-inetext.inet.com ([199.171.211.140]) by dusty; Mon Feb 28 15:22:00 EST 2000 Received: from harpo.inetint.com (harpo [172.16.99.60]) by ns-inetext.inet.com (8.9.2/8.9.2) with ESMTP id OAA19541 for ; Mon, 28 Feb 2000 14:23:06 -0600 (CST) Received: from inet.com ([172.16.63.49]) by harpo.inetint.com (Netscape Messaging Server 3.6) with ESMTP id AAA6872 for ; Mon, 28 Feb 2000 14:28:32 -0600 Message-ID: <38BAD954.58C89727@inet.com> Date: Mon, 28 Feb 2000 14:23:49 -0600 From: Mart Nurmet Organization: Inet - Product Line Management X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Subject: Information request! (Billing Package?) References: <200002151701.LAA11063@b04a24.exu.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit I am looking for information if there has been any work done to generate a billing package for SIP. From my look at the available information there does not seem to be any. Is that the case or am I missing something? Thank you, -Mart From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 28 15:56:21 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19777 for ; Mon, 28 Feb 2000 15:56:20 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 0979252AB; Mon, 28 Feb 2000 15:53:31 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 5B29252B6; Mon, 28 Feb 2000 15:53:30 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 4629652DB for ; Mon, 28 Feb 2000 15:31:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 28 15:30:19 EST 2000 Received: from seattle.3com.com ([129.213.128.97]) by dusty; Mon Feb 28 15:27:50 EST 2000 Received: from new-york.3com.com (new-york.3com.com [129.213.157.12]) by seattle.3com.com (8.8.8/8.8.8) with ESMTP id MAA11924; Mon, 28 Feb 2000 12:29:42 -0800 (PST) From: Burcak_Beser@3com.com Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by new-york.3com.com (8.8.8/8.8.8) with SMTP id MAA05096; Mon, 28 Feb 2000 12:29:42 -0800 (PST) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.3 (778.2 1-4-1999)) id 88256893.00708FBD ; Mon, 28 Feb 2000 12:29:28 -0800 X-Lotus-FromDomain: 3COM To: Shai Herzog Cc: sip@lists.research.bell-labs.com, rap@iphighway.com, byerly@cisco.com Message-ID: <88256893.00708D4F.00@hqoutbound.ops.3com.com> Date: Mon, 28 Feb 2000 14:31:17 -0600 Subject: Re: FW: Question on achieveing Assured QoS using SIP/COPS Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=htYn2KtOuwCcENmBujO0t5Xwl24BzyPqzO4P5hskcTH6ZhelmPwzDcQT" Content-Disposition: inline Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --0__=htYn2KtOuwCcENmBujO0t5Xwl24BzyPqzO4P5hskcTH6ZhelmPwzDcQT Content-type: text/plain; charset=us-ascii Content-Disposition: inline Shai, > 1. We are talking about Cable modems and PacketCable DQoS (DOCSIS 1.1) I do not think that this is a PacketCable specific requirement. I believe that Bryan set the objective very good: 'In assured QoS, the phone doesn't ring until resource allocation has been confirmed vs. enabled QoS, when the phone rings and can be answered before QoS is established.' I also believe that this will be vald for other applications as well. One that comes to my mind immediately is Gaming applications. Although DQoS uses COPS-push model for authorisation it is not a requirement of the 'assured QoS'. As you mention in your mail the 'assured QoS' is related with the QoS signalling which can be achieved without any Authorisation (i.e. need for COPS protocol). Related with the COPS-push or COPS-pull models it is very possible to model the below architecture (Which was depicted in "draft-dcsgroup-sip-call-auth"). Client CMTS Call Server | | | | Invite | | Invite |---------------------------------->|------------------------> | | | Client Authentication | | Gate Setup | and Call Authorisation | |<----------------| | | | | Gate-Setup includes an Authorised IP Flow | | profile and a GateID as a pointer | | | | | | 200OK [+GateID] | 200 OK |<----------------------------------|<------------------------ | | | | PATH [+GateID] | |---------------->| | | The PATH Message includes GateID which identifies | | Authorised IP flow profile. CMTS checks the | | committed profile against Instead one can re-draw the above architecture as: Client CMTS PDP Call Server | | | | | Invite | | | Invite |---------------------------------------->|-------------------> | | | | Client Authentication | | | Gate Setup | and Call Authorisation | | |<----------------| | | | | | | | Auth. Token | | | |---------------->| | | | | | | Auth Token is used in PDP for Authorised Profile | | | identification | | | | | 200OK [+AuthToken] | 200 OK |<----------------------------------------|<----------------------- | | | | PATH [+AT]| | |---------->| REQ [+AT] | | |---------->| | | | PDP makes the decision using the RSVP profile and | | DEC | Authorised profile | |<----------| | | | | | PATH | | |-----------------------------------------------------> The same messaging also applies for the RESV message. As can be seen from above architectures the change from PUSH to PULL model can be achieved without any change in the signalling model. Right now I am working on the changes to "draft-dcsgroup-sip-call-auth" and making the draft more oriented towards SIP than COPS. Until now I was thinking that a COPS usage draft is not necessary but maybe I was mistaken. If there is a need I can pull my notes regarding the scrapped parts of the " draft-dcsgroup-sip-call-auth" draft and make an 'Application Authorisation per Use' Architecture document, which would specify the means of application servers giving the Authorised profile and pulling Authorisation Token from PDP in a standard manner (which would be a PUSH model). Burcak Beser 3Com Carrier Access Group Shai Herzog on 02/26/2000 08:36:42 PM To: sip@lists.research.bell-labs.com, rap@iphighway.com, byerly@cisco.com cc: (bcc: Burcak Beser/MW/US/3Com) Subject: Re: FW: Question on achieveing Assured QoS using SIP/COPS Bryan, Burcak Let me make a few assumptions: 1. We are talking about Cable modems and PacketCable DQoS (DOCSIS 1.1) 2. We are looking per-call QoS 3. "Assured" means Resources are allocated before a ring (a ring requires QoS), and resources are committed after the other side picked up (call commences). The DQoS is a bit of an odd-ball standard, since it mixes RSVP and COPS-RSVP Push model (gate operations). But, we all know that COPS-RSVP wasn't designed to be in a push model. I think there is a "better" solution just by using RSVP to allocate, open and close gates: Stage 1 (in parallel) MTA-->(NCD/DCS)-->CMS/PDP (CMS makes a gate decision, resources are allocated) | /|\ \ | COPS-RSVP (outsourcing) \ | \(RSVP 1)---->CMTS Stage 2: Phone ring, other side answer MTA-->(RSVP 2)---->CMTS (confirms the reservation) ----- RSVP(1) only ask for authorization and allocation, no actual commitment of resources. Resources are still in solicited mode. RSVP(2) Commits resources (goes into unsolicited mode). The difference may be a flag (allocate only, or commit). This way, the Outsourcing model is maintained in COPS-RSVP (and we all breath easier ;-), and basically only one protocol is used to authorize allocate and reserve resources, i.e., RSVP/COPS. I believe this is the closest DQoS can get to be compliant with the COPS-RSVP architecture. Shai >-----Original Message----- >From: Burcak_Beser@3com.com >To: Bryan Byerly >Cc: sip@lists.research.bell-labs.com; rap@iphighway.com; >byerly@cisco.com >Sent: 02/25/2000 11:49 AM >Subject: Re: Question on achieveing Assured QoS using SIP/COPS > > > >It is my understanding is that 'assured QoS' has nothing to do with the >authorisation for which COPS is used. Can you elaborate your question? > >Burcak Beser >3Com Carrier Systems Group > > > > > >Bryan Byerly on 02/25/2000 09:38:21 AM > >To: sip@lists.research.bell-labs.com, rap@iphighway.com >cc: byerly@cisco.com (bcc: Burcak Beser/MW/US/3Com) > >Subject: Question on achieveing Assured QoS using SIP/COPS > > > > >Hi guys, > >Assuming a goal of achieving "assured QoS" using generic SIP: >(In assured QoS, the phone doesn't ring until resource allocation has >been confirmed >vs. enabled QoS, when the phone rings and can be answered before QoS is >established. >In fact, if resources are not available, the enabled QoS conversation >would continue >(without QoS)). > >I understand that assured QoS can be achieved using the provisioned >(push) model of COPS. >(REQ, ... DEC, RPT, ... DEC, RTP, ... DEC, RPT ...) >Some examples of proposed provisioned models (push model) which (can) >achieve assured QoS are: >a) DQoS (using Gate objects) >b) COPS-PR (using ASN.1 encoded objects), >... which ones am I leaving out? > >However, I have not seen assured QoS achieved using the >outsourcing model (pull model) of COPS. >(REQ, DEC, RPT, .... REQ, DEC, RPT, ... REQ, DEC, RPT, ...) > >Is it even possible to achieve assured QoS using the outsourcing model >(pull model) of COPS? > >If so, could someone please sketch a brief call flow for me of >how to achieve assured QoS using the outsourcing model of COPS? > >Thanks for your help! > >Bryan > >Bryan J. Byerly >byerly@cisco.com __________________________________________________________________ Shai Herzog, Founder & CTO IPHighway Inc. Tel : (914) 654-4810 55 New York Avenue Main: (508) 620-1141 Framingham, MA 01701 Fax : (212) 656-1006 --0__=htYn2KtOuwCcENmBujO0t5Xwl24BzyPqzO4P5hskcTH6ZhelmPwzDcQT Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PGh0bWw+DQpCcnlhbiwgQnVyY2FrPGJyPg0KPGJyPg0KTGV0IG1lIG1ha2UgYSBmZXcgYXNzdW1w dGlvbnM6PGJyPg0KPGJyPg0KMS4gV2UgYXJlIHRhbGtpbmcgYWJvdXQgQ2FibGUgbW9kZW1zIGFu ZCBQYWNrZXRDYWJsZSBEUW9TIChET0NTSVMNCjEuMSk8YnI+DQoyLiBXZSBhcmUgbG9va2luZyBw ZXItY2FsbCBRb1M8YnI+DQozLiAmcXVvdDtBc3N1cmVkJnF1b3Q7IG1lYW5zIFJlc291cmNlcyBh cmUgYWxsb2NhdGVkIGJlZm9yZSBhIHJpbmcgKGENCnJpbmcgcmVxdWlyZXM8YnI+DQombmJzcDsm bmJzcDsgUW9TKSwgYW5kIHJlc291cmNlcyBhcmUgY29tbWl0dGVkIGFmdGVyIHRoZSBvdGhlciBz aWRlDQpwaWNrZWQgdXAgPGJyPg0KJm5ic3A7Jm5ic3A7IChjYWxsIGNvbW1lbmNlcykuPGJyPg0K PGJyPg0KVGhlIERRb1MgaXMgYSBiaXQgb2YgYW4gb2RkLWJhbGwgc3RhbmRhcmQsIHNpbmNlIGl0 IG1peGVzIFJTVlA8YnI+DQphbmQgQ09QUy1SU1ZQIFB1c2ggbW9kZWwgKGdhdGUgb3BlcmF0aW9u cykuIEJ1dCwgd2UgYWxsIGtub3cgdGhhdCA8YnI+DQpDT1BTLVJTVlAgd2Fzbid0IGRlc2lnbmVk IHRvIGJlIGluIGEgcHVzaCBtb2RlbC48YnI+DQo8YnI+DQpJIHRoaW5rIHRoZXJlIGlzIGEgJnF1 b3Q7YmV0dGVyJnF1b3Q7IHNvbHV0aW9uIGp1c3QgYnkgdXNpbmcgUlNWUCB0bw0KYWxsb2NhdGUs PGJyPg0Kb3BlbiBhbmQgY2xvc2UgZ2F0ZXM6PGJyPg0KPGJyPg0KU3RhZ2UgMSAoaW4gcGFyYWxs ZWwpPGJyPg0KPGJyPg0KTVRBLS0mZ3Q7KE5DRC9EQ1MpLS0mZ3Q7Q01TL1BEUCAoQ01TIG1ha2Vz IGEgZ2F0ZSBkZWNpc2lvbiwgcmVzb3VyY2VzIGFyZQ0KYWxsb2NhdGVkKTxicj4NCiZuYnNwO3wm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCi98XDxicj4NCiZuYnNwOw0KXCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KfCBDT1BTLVJTVlAgKG91dHNvdXJjaW5nKTxi cj4NCiZuYnNwOyZuYnNwOw0KXCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KfCA8YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsgXChSU1ZQIDEpLS0tLSZndDtDTVRTPGJyPg0KPGJyPg0KU3RhZ2Ug Mjo8YnI+DQo8YnI+DQpQaG9uZSByaW5nLCBvdGhlciBzaWRlIGFuc3dlcjxicj4NCjxicj4NCk1U QS0tJmd0OyhSU1ZQIDIpLS0tLSZndDtDTVRTJm5ic3A7Jm5ic3A7Jm5ic3A7IChjb25maXJtcyB0 aGUNCnJlc2VydmF0aW9uKTxicj4NCjxicj4NCi0tLS0tPGJyPg0KUlNWUCgxKSBvbmx5IGFzayBm b3IgYXV0aG9yaXphdGlvbiBhbmQgYWxsb2NhdGlvbiwgbm8gYWN0dWFsDQpjb21taXRtZW50PGJy Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9mIHJlc291cmNl cy4gUmVzb3VyY2VzIGFyZQ0Kc3RpbGwgaW4gc29saWNpdGVkIG1vZGUuPGJyPg0KUlNWUCgyKSBD b21taXRzIHJlc291cmNlcyAoZ29lcyBpbnRvIHVuc29saWNpdGVkIG1vZGUpLjxicj4NClRoZSBk aWZmZXJlbmNlIG1heSBiZSBhIGZsYWcgKGFsbG9jYXRlIG9ubHksIG9yIGNvbW1pdCkuPGJyPg0K PGJyPg0KVGhpcyB3YXksIHRoZSBPdXRzb3VyY2luZyBtb2RlbCBpcyBtYWludGFpbmVkIGluIENP UFMtUlNWUCAoYW5kIDxicj4NCndlIGFsbCBicmVhdGggZWFzaWVyIDstKSwgYW5kIGJhc2ljYWxs eSBvbmx5IG9uZSBwcm90b2NvbCBpcyA8YnI+DQp1c2VkIHRvIGF1dGhvcml6ZSBhbGxvY2F0ZSBh bmQgcmVzZXJ2ZSByZXNvdXJjZXMsIGkuZS4sIFJTVlAvQ09QUy48YnI+DQo8YnI+DQpJIGJlbGll dmUgdGhpcyBpcyB0aGUgY2xvc2VzdCBEUW9TIGNhbiBnZXQgdG8gYmUgY29tcGxpYW50IHdpdGgg PGJyPg0KdGhlIENPUFMtUlNWUCBhcmNoaXRlY3R1cmUuPGJyPg0KPGJyPg0KU2hhaTxicj4NCjxi cj4NCjxibG9ja3F1b3RlIHR5cGU9Y2l0ZSBjaXRlPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t PGJyPg0KRnJvbTogQnVyY2FrX0Jlc2VyQDNjb20uY29tPGJyPg0KVG86IEJyeWFuIEJ5ZXJseTxi cj4NCkNjOiBzaXBAbGlzdHMucmVzZWFyY2guYmVsbC1sYWJzLmNvbTsgcmFwQGlwaGlnaHdheS5j b207PGJyPg0KYnllcmx5QGNpc2NvLmNvbTxicj4NClNlbnQ6IDAyLzI1LzIwMDAgMTE6NDkgQU08 YnI+DQpTdWJqZWN0OiBSZTogUXVlc3Rpb24gb24gYWNoaWV2ZWluZyBBc3N1cmVkIFFvUyB1c2lu ZyBTSVAvQ09QUzxicj4NCjxicj4NCjxicj4NCjxicj4NCkl0IGlzIG15IHVuZGVyc3RhbmRpbmcg aXMgdGhhdCAnYXNzdXJlZCBRb1MnIGhhcyBub3RoaW5nIHRvIGRvIHdpdGgNCnRoZTxicj4NCmF1 dGhvcmlzYXRpb24gZm9yIHdoaWNoIENPUFMgaXMgdXNlZC4gQ2FuIHlvdSBlbGFib3JhdGUgeW91 cg0KcXVlc3Rpb24/PGJyPg0KPGJyPg0KQnVyY2FrIEJlc2VyPGJyPg0KM0NvbSBDYXJyaWVyIFN5 c3RlbXMgR3JvdXA8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpCcnlhbiBCeWVy bHkgJmx0O2J5ZXJseUBjaXNjby5jb20mZ3Q7IG9uIDAyLzI1LzIwMDAgMDk6Mzg6MjEgQU08YnI+ DQo8YnI+DQpUbzombmJzcDsmbmJzcDsgc2lwQGxpc3RzLnJlc2VhcmNoLmJlbGwtbGFicy5jb20s IHJhcEBpcGhpZ2h3YXkuY29tPGJyPg0KY2M6Jm5ic3A7Jm5ic3A7IGJ5ZXJseUBjaXNjby5jb20g KGJjYzogQnVyY2FrIEJlc2VyL01XL1VTLzNDb20pPGJyPg0KPGJyPg0KU3ViamVjdDombmJzcDsg UXVlc3Rpb24gb24gYWNoaWV2ZWluZyBBc3N1cmVkIFFvUyB1c2luZyBTSVAvQ09QUzxicj4NCjxi cj4NCjxicj4NCjxicj4NCjxicj4NCkhpIGd1eXMsPGJyPg0KPGJyPg0KQXNzdW1pbmcgYSBnb2Fs IG9mIGFjaGlldmluZyAmcXVvdDthc3N1cmVkIFFvUyZxdW90OyB1c2luZyBnZW5lcmljDQpTSVA6 PGJyPg0KKEluIGFzc3VyZWQgUW9TLCZuYnNwOyB0aGUgcGhvbmUgZG9lc24ndCByaW5nIHVudGls IHJlc291cmNlIGFsbG9jYXRpb24NCmhhczxicj4NCmJlZW4gY29uZmlybWVkPGJyPg0KdnMuIGVu YWJsZWQgUW9TLCB3aGVuIHRoZSBwaG9uZSByaW5ncyBhbmQgY2FuIGJlIGFuc3dlcmVkIGJlZm9y ZSBRb1MNCmlzPGJyPg0KZXN0YWJsaXNoZWQuPGJyPg0KSW4gZmFjdCwgaWYgcmVzb3VyY2VzIGFy ZSBub3QgYXZhaWxhYmxlLCB0aGUgZW5hYmxlZCBRb1MNCmNvbnZlcnNhdGlvbjxicj4NCndvdWxk IGNvbnRpbnVlPGJyPg0KKHdpdGhvdXQgUW9TKSkuPGJyPg0KPGJyPg0KSSB1bmRlcnN0YW5kIHRo YXQgYXNzdXJlZCBRb1MgY2FuIGJlIGFjaGlldmVkIHVzaW5nIHRoZSBwcm92aXNpb25lZDxicj4N CihwdXNoKSBtb2RlbCBvZiBDT1BTLjxicj4NCihSRVEsIC4uLiZuYnNwOyBERUMsIFJQVCwgLi4u IERFQywgUlRQLCAuLi4gREVDLCBSUFQgLi4uKTxicj4NClNvbWUgZXhhbXBsZXMgb2YgcHJvcG9z ZWQgcHJvdmlzaW9uZWQgbW9kZWxzIChwdXNoIG1vZGVsKSB3aGljaA0KKGNhbik8YnI+DQphY2hp ZXZlIGFzc3VyZWQgUW9TIGFyZTo8YnI+DQphKSBEUW9TICh1c2luZyBHYXRlIG9iamVjdHMpPGJy Pg0KYikgQ09QUy1QUiAodXNpbmcgQVNOLjEgZW5jb2RlZCBvYmplY3RzKSw8YnI+DQouLi4gd2hp Y2ggb25lcyBhbSBJIGxlYXZpbmcgb3V0Pzxicj4NCjxicj4NCkhvd2V2ZXIsIEkgaGF2ZSBub3Qg c2VlbiBhc3N1cmVkIFFvUyBhY2hpZXZlZCB1c2luZyB0aGU8YnI+DQpvdXRzb3VyY2luZyBtb2Rl bCAocHVsbCBtb2RlbCkgb2YgQ09QUy48YnI+DQooUkVRLCBERUMsIFJQVCwgLi4uLiBSRVEsIERF QywgUlBULCZuYnNwOyAuLi4gUkVRLCBERUMsIFJQVCwgLi4uKTxicj4NCjxicj4NCklzIGl0IGV2 ZW4gcG9zc2libGUgdG8gYWNoaWV2ZSBhc3N1cmVkIFFvUyB1c2luZyB0aGUgb3V0c291cmNpbmcN Cm1vZGVsPGJyPg0KKHB1bGwgbW9kZWwpIG9mIENPUFM/PGJyPg0KPGJyPg0KSWYgc28sIGNvdWxk IHNvbWVvbmUgcGxlYXNlIHNrZXRjaCBhIGJyaWVmIGNhbGwgZmxvdyBmb3IgbWUgb2Y8YnI+DQpo b3cgdG8gYWNoaWV2ZSBhc3N1cmVkIFFvUyB1c2luZyB0aGUgb3V0c291cmNpbmcgbW9kZWwgb2Yg Q09QUz88YnI+DQo8YnI+DQpUaGFua3MgZm9yIHlvdXIgaGVscCE8YnI+DQo8YnI+DQpCcnlhbjxi cj4NCjxicj4NCkJyeWFuIEouIEJ5ZXJseTxicj4NCmJ5ZXJseUBjaXNjby5jb208YnI+DQo8L2Js b2NrcXVvdGU+PGJyPg0KPGJyPg0KPGRpdj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L2Rpdj4NCjxkaXY+U2hhaSBIZXJ6 b2csIEZvdW5kZXIgJmFtcDsgQ1RPJm5ic3A7Jm5ic3A7IElQSGlnaHdheQ0KSW5jLiZuYnNwOyZu YnNwOyBUZWwgOiAoOTE0KSA2NTQtNDgxMDwvZGl2Pg0KPGRpdj41NSBOZXcgWW9yaw0KQXZlbnVl Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpNYWluOiAo NTA4KSA2MjAtMTE0MTwvZGl2Pg0KPGRpdj5GcmFtaW5naGFtLCBNQQ0KMDE3MDEmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCkZheCA6ICgyMTIpIDY1Ni0xMDA2PC9kaXY+DQo8 ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9kaXY+DQo8 YnI+DQo8ZGl2PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyA8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L2Rpdj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCjwvaHRtbD4NCg0K --0__=htYn2KtOuwCcENmBujO0t5Xwl24BzyPqzO4P5hskcTH6ZhelmPwzDcQT-- From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 28 16:50:05 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20847 for ; Mon, 28 Feb 2000 16:50:04 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 1EFB752BB; Mon, 28 Feb 2000 16:47:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9C87452C4; Mon, 28 Feb 2000 16:47:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 6C38E52BB for ; Mon, 28 Feb 2000 16:47:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 28 16:45:19 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Mon Feb 28 16:42:50 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA08353; Mon, 28 Feb 2000 16:45:09 -0500 (EST) Message-ID: <38BAED86.4DEEE654@dynamicsoft.com> Date: Mon, 28 Feb 2000 16:49:58 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Mart Nurmet Cc: sip@lists.research.bell-labs.com Subject: Re: Information request! (Billing Package?) References: <200002151701.LAA11063@b04a24.exu.ericsson.se> <38BAD954.58C89727@inet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit There is no standardized "billing package" for SIP. There will be a MIB, and there are local log and transaction records generated by servers and gateways. This information can be collected to bill in any way you like. -Jonathan R. Mart Nurmet wrote: > > I am looking for information if there has been any work done to generate a > billing package for SIP. From my look at the available information there does > not seem to be any. Is that the case or am I missing something? > > Thank you, > -Mart -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 28 16:56:03 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21063 for ; Mon, 28 Feb 2000 16:56:03 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C164A52C4; Mon, 28 Feb 2000 16:53:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 1DFB652C8; Mon, 28 Feb 2000 16:53:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id B437752C4 for ; Mon, 28 Feb 2000 16:53:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Mon Feb 28 16:52:25 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Mon Feb 28 16:49:56 EST 2000 Received: from dynamicsoft.com ([216.89.83.2]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA08382; Mon, 28 Feb 2000 16:52:34 -0500 (EST) Message-ID: <38BAEF43.20F65540@dynamicsoft.com> Date: Mon, 28 Feb 2000 16:57:23 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Henning Schulzrinne Cc: sip@lists.research.bell-labs.com Subject: Re: SRV records References: <38BAB38F.C3EC9A26@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit My only concern is regarding latency. Every proxy will do an SRV query, and in most cases, will get (and have to wait for) a negative response. Then, it needs to do another query for A records. Negative responses can take a long time... not sure if thats just if there is no server for that domain, or also if there is a server for that domain, but the requested record doesn't exist. -Jonathan R. Henning Schulzrinne wrote: > > Now that SRV records are a Proposed Standard (RFC 2782), I would suggest > simplifying the lookup procedure to include SRV as SHOULD rather than as > an optional procedure. This does not force modifying DNS to include SRV > records, but does encourage implementation of SRV in SIP clients. > > Comments? > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Mon Feb 28 17:03:42 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21329 for ; Mon, 28 Feb 2000 17:03:42 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 28D5F52C8; Mon, 28 Feb 2000 17:01:20 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 9B26C52D4; Mon, 28 Feb 2000 17:01:19 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 5C8F852C8 for ; Mon, 28 Feb 2000 17:01:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Mon Feb 28 16:59:28 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Mon Feb 28 16:56:59 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id QAA17468; Mon, 28 Feb 2000 16:59:26 -0500 (EST) Message-ID: <38BAEFBD.AB3679A9@cs.columbia.edu> Date: Mon, 28 Feb 2000 16:59:25 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: sip@lists.research.bell-labs.com Subject: Re: SRV records References: <38BAB38F.C3EC9A26@cs.columbia.edu> <38BAEF43.20F65540@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > My only concern is regarding latency. Every proxy will do an SRV query, > and in most cases, will get (and have to wait for) a negative response. > Then, it needs to do another query for A records. Negative responses can > take a long time... not sure if thats just if there is no server for > that domain, or also if there is a server for that domain, but the > requested record doesn't exist. > We might have had this discussion before, but my experience is that if a domain exists, but a record doesn't, the response is very fast (110 ms without caching and 20 ms with caching, including the "host" application overhead). If the domain doesn't exist, it doesn't matter one way or the other. I just tried host -t srv sip.udp.dynamicsoft.com sip.udp.dynamicsoft.com does not exist (Authoritative answer) and it returns immediately. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 29 00:43:43 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00104 for ; Tue, 29 Feb 2000 00:43:43 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 7135A52AB; Tue, 29 Feb 2000 00:39:54 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id C5A4552BB; Tue, 29 Feb 2000 00:39:53 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 378CC52AB for ; Tue, 29 Feb 2000 00:39:09 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Mar 1 00:37:44 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Tue Mar 1 00:35:15 EST 2000 Received: from dynamicsoft.com (1Cust74.tnt1.freehold.nj.da.uu.net [63.17.113.74]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA08905 for ; Tue, 29 Feb 2000 00:37:47 -0500 (EST) Message-ID: <38BB5C51.7F840ED1@dynamicsoft.com> Date: Tue, 29 Feb 2000 00:42:41 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Subject: formation of SIP-T design team Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Folks, In order to move the SIP-T work towards completion, we've formed a SIP-T design team. The goal of the design team is to rapidly reach closure on the three remaining documents in the SIP-T umbrella - (1) the ISUP MIME type, (2) the SIP/ISUP interworking document, and (3) the umbrella SIP-T spec. The fourth, INFO, is now in IESG last call. The first task is to reach closure on the MIME draft, which I think is nearly ready. If you're interested in joining this team, please let me know and I'll add you. Thanks, Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 29 01:09:51 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00724 for ; Tue, 29 Feb 2000 01:09:51 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id AFE3D52C4; Tue, 29 Feb 2000 01:07:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 2422152BB; Tue, 29 Feb 2000 01:07:24 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 19B5B52C4 for ; Tue, 29 Feb 2000 01:07:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 1 01:06:55 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Tue Mar 1 01:04:26 EST 2000 Received: from dynamicsoft.com (1Cust74.tnt1.freehold.nj.da.uu.net [63.17.113.74]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA08919; Tue, 29 Feb 2000 01:07:01 -0500 (EST) Message-ID: <38BB632B.FA2182C1@dynamicsoft.com> Date: Tue, 29 Feb 2000 01:11:55 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Steve Little Cc: Igor Slepchin , SIP Mailing List Subject: Re: Diff. between branch and tag References: <20000224042950.28361.qmail@web3401.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Steve Little wrote: > > Hi, > Ive have seem implementations insert a tag field > irrespective of whether it forks or not. Only a UAS inserts a tag. It has no way of knowing whether the request forked or not. The only thing you know is that if there is a single Via in the request when it arrives at the UAS, it didn't fork. Thats why the spec doesn't mandate tags in this (mostly useless) case. I think its a good idea (and probably should be a MUST) to insert a tag always. > Also, if forking proxies insert tags while forwarding > the request, then isnt that enough ? Then when a > receiving entity gets the request, it responds and > copies the tag in it. No, proxies can't insert tags. Tags go in the To field, and there is only one that can be placed there. If the first forking proxy inserts a tag in the To field, as you suggest, and then it forks downstream, the second proxy can't insert a tag, since there already is one there. So, it leaves it alone. All user agents downstream of the second forking proxy that respond will do so with the same tag. That defeats the whole purpose. > That way requests can be matched > wth responses, This doesn't allow requests to be matched with responses in proxies. *EACH* forking proxy needs to insert some kind of data. There is only room for one tag in the To field. Thats why we use the Via header for the branch parameter - each proxy can get its own. > and the generation of tags can be the > rsponsibility of the entity that actually forks a > request - why should a reciever try and figure out if > its forked ? As I said, it can't, shouldn't, and doesn't have to. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 29 06:30:49 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14974 for ; Tue, 29 Feb 2000 06:30:48 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id F1F0B52B6; Tue, 29 Feb 2000 06:27:35 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 5EE5A52D5; Tue, 29 Feb 2000 06:27:34 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 9176252B6 for ; Tue, 29 Feb 2000 06:27:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 1 06:27:03 EST 2000 Received: from ietf.org ([132.151.1.176]) by dusty; Tue Mar 1 06:24:34 EST 2000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14891; Tue, 29 Feb 2000 06:27:01 -0500 (EST) Message-Id: <200002291127.GAA14891@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.research.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sip-serverfeatures-01.txt Date: Tue, 29 Feb 2000 06:27:00 -0500 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --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 SIP Supported Header Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-sip-serverfeatures-01.txt Pages : 7 Date : 28-Feb-00 The Session Initiation Protocol (SIP) defines mechanims that allow a client to mandate that a server support specific extensions in order to process a request. However, there is currently no way for a server to determine what features are supported in a client, in order to use those features to process the request. This capability is needed for numerous extensions currently under development, such as provisional response reliability and the session progress message. We also note that there is currently no way for a client to query a server about the features it supports. This document defines a SIP extension that allows clients to indicate, in a request, the set of features supported. We also define a mechanism that allows clients, through an OPTIONS request, to determine the features supported by a server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-serverfeatures-01.txt 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-serverfeatures-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-serverfeatures-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: <20000228125651.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-serverfeatures-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-serverfeatures-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000228125651.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 29 06:33:37 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15045 for ; Tue, 29 Feb 2000 06:33:37 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id D10CF52D6; Tue, 29 Feb 2000 06:27:38 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 2428452D4; Tue, 29 Feb 2000 06:27:34 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 1743E52D4 for ; Tue, 29 Feb 2000 06:27:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Mar 1 06:26:58 EST 2000 Received: from ietf.org ([132.151.1.176]) by dusty; Tue Mar 1 06:24:29 EST 2000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14877; Tue, 29 Feb 2000 06:26:56 -0500 (EST) Message-Id: <200002291126.GAA14877@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.research.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-sip-dhcp-00.txt Date: Tue, 29 Feb 2000 06:26:55 -0500 Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --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 : DHCP Option for SIP Servers Author(s) : G. Nair, H. Schulzrinne Filename : draft-ietf-sip-dhcp-00.txt Pages : 6 Date : 28-Feb-00 This document defines DHCP options that contain one or more pointers to one or more SIP servers. This is one of the many methods that a SIP client can use to obtain the addresses of the SIP servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-dhcp-00.txt 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-dhcp-00.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-dhcp-00.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: <20000228125641.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-dhcp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-dhcp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000228125641.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 29 06:49:54 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15229 for ; Tue, 29 Feb 2000 06:49:54 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 17C2652C8; Tue, 29 Feb 2000 06:47:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 79F5F52D5; Tue, 29 Feb 2000 06:47:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 3196552C8 for ; Tue, 29 Feb 2000 06:47:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Mar 1 06:46:43 EST 2000 Received: from relay.cwplc.com ([194.6.6.11]) by dusty; Tue Mar 1 06:44:14 EST 2000 Received: from GB-CWC-WTN-MSW3.isops.cwcom.co.uk ([148.185.175.58]) by relay.cwplc.com (Pro-8.9.3/8.9.3) with ESMTP id LAA24397 for ; Tue, 29 Feb 2000 11:47:00 GMT Received: from gbcwcwari001.isops.cwcom.co.uk (unverified) by GB-CWC-WTN-MSW3.isops.cwcom.co.uk (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Tue, 29 Feb 2000 10:29:20 +0000 Received: by gb-cwc-wtn-d01.isops.cwcom.co.uk with Internet Mail Service (5.5.2448.0) id ; Tue, 29 Feb 2000 10:41:59 -0000 Message-Id: From: "Buchanan, Paul" To: "'Jonathan Rosenberg'" , Mart Nurmet Cc: sip@lists.research.bell-labs.com Subject: RE: Information request! (Billing Package?) Date: Tue, 29 Feb 2000 10:35:43 -0000 Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk CDR collection should be defacto and easily accessible right down to the SIP client. I believe that SIP should interwork with the current VOIP suppliers like XACCT, Mind CTI , Clarent, Sollect, Portal, Kenan and their contemporaries. I can see a major problem with the FORKING capabilities of SIP as the provider will be responsible for originating calls from the Gateway. In effect we will have to make the receiver pay for calls which turns the billing world on its head. My concern is the security issues and, in addition, how service companies can make an honest profit. As IP transmission costs plummet - so does the cost of telephony generally and so does the service providers ability to reinvest in the web infrastructure. I have several ideas on how this should happen as SIP becomes a global product. Paul Buchanan Darkness Removal a Speciality VOIP/DSL/ATM Technical Architect IP Net Technology Planning Waterside House, Longshot Lane, Bracknell Berks RG12 1XL TEL: 01344 704064 FAX: 01344 726304 MOBILE (BEST BET) 0780 833 8143 PA247.com paulbuchanan@mail.com Home: 01227 450900 Home Fax: 01227 478929 Work Mail paul.buchanan@cwcom.co.uk "Those who bring sunshine into the lives of others, cannot keep it from themselves." > -----Original Message----- > From: Jonathan Rosenberg [SMTP:jdrosen@dynamicsoft.com] > Sent: Monday, February 28, 2000 9:50 PM > To: Mart Nurmet > Cc: sip@lists.research.bell-labs.com > Subject: Re: Information request! (Billing Package?) > > There is no standardized "billing package" for SIP. There will be a MIB, > and there are local log and transaction records generated by servers and > gateways. This information can be collected to bill in any way you like. > > -Jonathan R. > > Mart Nurmet wrote: > > > > I am looking for information if there has been any work done to generate > a > > billing package for SIP. From my look at the available information > there does > > not seem to be any. Is that the case or am I missing something? > > > > Thank you, > > -Mart > > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 29 09:32:09 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18705 for ; Tue, 29 Feb 2000 09:32:08 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C6E0052D5; Tue, 29 Feb 2000 09:29:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 2DA9D52DA; Tue, 29 Feb 2000 09:29:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 5B86B52D5 for ; Tue, 29 Feb 2000 09:29:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Mar 1 09:27:48 EST 2000 Received: from qhars002.nortel.com ([192.100.101.19]) by dusty; Tue Mar 1 09:25:19 EST 2000 Received: from zhard00m.europe.nortel.com (actually zhard00m) by qhars002.nortel.com; Tue, 29 Feb 2000 14:27:07 +0000 Received: by zhard00m.europe.nortel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 29 Feb 2000 14:27:05 -0000 Message-ID: <61ABD11436FED21192440000F81F3E36033118B4@nwcwi1a.europe.nortel.com> From: "Joshua Moloney" To: "'sip@lists.research.bell-labs.com'" Subject: Content-Encoding header (again) Date: Tue, 29 Feb 2000 14:26:55 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BF82C1.0B83077E" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk 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_01BF82C1.0B83077E Content-Type: text/plain Hi, Thanks for the reply Jonathan. It helped me (I think!) with a few questions I had about the headers, but I guess I really asked the wrong question. So here goes... In a SIP message with multiple payloads (i.e. multipart/mixed content-type), the following example is often cited: INVITE sip:13035553142@Den1.level3.com SIP/2.0 From: sip:13035553355@den3.level3.com To: sip:13035553142@Den1.level3.com Call-ID: DEN1231999021712095500999@Den1.level3.com Content-Length: 377 Content-Type: multipart/mixed; boundary=unique-boundary-1 MIME-Version: 1.0 --unique-boundary-1 Content-Type: application/SDP; charset=ISO-10646 v=0 o=ezimmerer 2890844526 2890842807 IN IP4 126.16.64.4 s=SDP seminar c=IN IP4 MG122.level3.com t= 2873397496 2873404696 m=audio 9092 RTP/AVP 0 3 4 --unique-boundary-1 Content-type:application/ISUP; version=ETSI1 Content-Transfer-Encoding: binary 89 8b 0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00 --unique-boundary-1-- The ISUP payload has a Content-Transfer-Encoding header. Is this correct? Is it required at all (for the reasons stated in your original response), or should the Content-Encoding header be used instead? Or, should a parser be able to understand both types of header (thus suggesting that a SIP parser should be fully MIME compliant)? Cheers, Josh Moloney Nortel Networks > -----Original Message----- > From: Jonathan Rosenberg [SMTP:jdrosen@dynamicsoft.com] > Sent: 25 February 2000 19:17 > To: Moloney, Joshua [MDN05:7U46:EXCH] > Cc: 'sip@lists.research.bell-labs.com' > Subject: Re: Content-Encoding vs. Content-Transfer-Encoding > > The Content-Transfer-Encoding header was primarily meant to allow > message bodies to be transformed into formats that could be transferred > on channels that were not 8 bit clean. HTTP, which makes use of many of > the MIME headers, is 8 bit clean, and thus did not need > Content-Transfer-Encoding. SIP followed suit, and so does not use it > either. Content-Encoding is used for things like compression, which is > different (in fact, the opposite, since conversion of a binary file to a > 7 bit transfer channel INCREASES the size of the body). > > -Jonathan R. > > > Joshua Moloney wrote: > > > > Hi all, > > > > I have a question about the "Content-Encoding" entity header. > > Why is the MIME "Content-Transfer-Encoding" header defined in RFC 2045 > > not used instead? > > Am I correct in assuming that they do the same job? > > > > For example, what headers should I include on a message with an > > "application/ISUP" message body? :- > > > > Content-Type: application/ISUP > > Content-Transfer-Encoding: binary > > ..... > > > > OR > > > > Content-Type: application/ISUP > > Content-Encoding: binary > > ..... > > > > Thanks in advance, > > > > Josh Moloney > > > > Nortel Networks > > jmoloney@nortelnetworks.com > > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > ------_=_NextPart_001_01BF82C1.0B83077E Content-Type: text/html Content-Transfer-Encoding: quoted-printable Content-Encoding header (again)

Hi,

Thanks for the reply = Jonathan. It helped me (I think!) with a few questions I had about the = headers, but I guess I really asked the wrong question. So here = goes...

In a SIP message = with multiple payloads (i.e. multipart/mixed content-type), the = following example is often cited:

        INVITE = sip:13035553142@Den1.level3.com SIP/2.0
        From: = sip:13035553355@den3.level3.com
        To: = sip:13035553142@Den1.level3.com
        Call-ID: = DEN1231999021712095500999@Den1.level3.com
        Content-Length: 377
        Content-Type: multipart/mixed; = boundary=3Dunique-boundary-1
        MIME-Version: = 1.0         

        --unique-boundary-1
        Content-Type: application/SDP; = charset=3DISO-10646
        v=3D0
        o=3Dezimmerer 2890844526 2890842807 IN = IP4 126.16.64.4
        s=3DSDP seminar
   =      c=3DIN IP4 MG122.level3.com
        t=3D 2873397496   = 2873404696
        m=3Daudio 9092 RTP/AVP 0 3 4

        --unique-boundary-1
        Content-type:application/ISUP; = version=3DETSI1
        Content-Transfer-Encoding: binary

        89 8b 0e 95 1e 1e 1e 06 26 05 0d f5 01 06 = 10 04 00

        --unique-boundary-1--

The ISUP payload has = a Content-Transfer-Encoding header. Is this correct? Is it required at = all (for the reasons stated in your original response), or should the = Content-Encoding header be used instead? Or, should a parser be able to = understand both types of header (thus suggesting that a SIP parser = should be fully MIME compliant)?

Cheers,

Josh Moloney
Nortel = Networks

    -----Original Message-----
    From:   Jonathan Rosenberg = [SMTP:jdrosen@dynamicsoft.com]
    Sent:   25 February 2000 19:17
    To:     Moloney, Joshua [MDN05:7U46:EXCH]
    Cc:     'sip@lists.research.bell-labs.com'
    Subject:       = Re: Content-Encoding vs. = Content-Transfer-Encoding

    The Content-Transfer-Encoding header = was primarily meant to allow
    message bodies to be transformed into = formats that could be transferred
    on channels that were not 8 bit = clean. HTTP, which makes use of many of
    the MIME headers, is 8 bit clean, and = thus did not need
    Content-Transfer-Encoding. SIP = followed suit, and so does not use it
    either. Content-Encoding is used for = things like compression, which is
    different (in fact, the opposite, = since conversion of a binary file to a
    7 bit transfer channel INCREASES the = size of the body).

    -Jonathan R.

    > Joshua Moloney wrote:
    >
    > Hi all,
    >
    > I have a question about the = "Content-Encoding" entity header.
    > Why is the MIME = "Content-Transfer-Encoding" header defined in RFC 2045
    > not used instead?
    > Am I correct in assuming that = they do the same job?
    >
    > For example, what headers should = I include on a message with an
    > "application/ISUP" = message body? :-
    >
    > Content-Type: = application/ISUP
    > Content-Transfer-Encoding: = binary
    > .....
    >
    > OR
    >
    > Content-Type: = application/ISUP
    > Content-Encoding: binary
    > .....
    >
    > Thanks in advance,
    >
    > Josh Moloney
    >
    > Nortel Networks
    > = jmoloney@nortelnetworks.com

    --
    Jonathan D. = Rosenberg          &nb= sp;            = 200 Executive Drive
    Chief = Scientist          &nb= sp;           &nb= sp;      Suite 120
    dynamicsoft       &nbs= p;           &nbs= p;           &nbs= p; West Orange, NJ 07052
    jdrosen@dynamicsoft.com     &nbs= p;           &nbs= p;   FAX:   (732) 741-4778
    http://www.cs.columbia.edu/~jdrosen         PHONE: = (732) 741-7244
    http://www.dynamicsoft.com

------_=_NextPart_001_01BF82C1.0B83077E-- From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 29 11:20:06 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23232 for ; Tue, 29 Feb 2000 11:20:06 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id C3C4652DA; Tue, 29 Feb 2000 11:17:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 5128552DB; Tue, 29 Feb 2000 11:17:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id DF2C552DA for ; Tue, 29 Feb 2000 11:17:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 29 11:16:58 EST 2000 Received: from tnint06.telogy.com ([209.116.120.7]) by dusty; Tue Feb 29 11:14:30 EST 2000 Received: by TNINT06 with Internet Mail Service (5.5.2448.0) id ; Tue, 29 Feb 2000 11:16:52 -0500 Message-ID: <61891BA043DED21180920090273F17380347A0@TNINT06> From: Wing Man Kwok To: "'sip@lists.research.bell-labs.com'" Subject: SIP support of caller ID Date: Tue, 29 Feb 2000 11:16:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk All, I read from the SIP FAQ that SIP supports caller ID. But I cannot find any description of this in rfc2543. How does SIP support caller ID? Thanks in advance Wing Man Kwok Telogy Networks From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 29 11:37:54 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24213 for ; Tue, 29 Feb 2000 11:37:53 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 150B452DB; Tue, 29 Feb 2000 11:35:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 882AB52DC; Tue, 29 Feb 2000 11:35:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 8F5CD52DB for ; Tue, 29 Feb 2000 11:35:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Feb 29 11:34:30 EST 2000 Received: from cmailg3.svr.pol.co.uk ([195.92.195.173]) by dusty; Tue Feb 29 11:32:01 EST 2000 Received: from modem-153.cleaner-wrasse.dialup.pol.co.uk ([62.136.246.153] helo=theseventhson.freeserve.co.uk) by cmailg3.svr.pol.co.uk with esmtp (Exim 3.13 #0) id 12PpbP-0000A6-00 for sip@lists.research.bell-labs.com; Tue, 29 Feb 2000 16:34:28 +0000 Message-ID: <38BBF521.C450DD9F@theseventhson.freeserve.co.uk> Date: Tue, 29 Feb 2000 16:34:41 +0000 From: Benny Prijono X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "sip@lists.research.bell-labs.com" Subject: Loop detection in Invite request in stateless proxy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, Section 12.3.1 of the draft states that: "To prevent loops, a server must check if its own address is already contained in the Via header of the incoming request" Section 6.44.1 states that a 482 (Loop Detected) response MUST be returned when a loop is detected. And finally, section 12.3 (last statement) states that a stateless proxy forwards every request and response it received. Based on these statements, I think this is the correct behaviour for stateless proxy: 1. When the loop is detected, the stateless proxy will reply with 482 (Loop Detected). 2. The UAC then will send ACK. 3. Proxy will forward ACK to the UAS. 4. UAS will simply drop the ACK, maybe after complains loudly about the invalid message. If this is the correct behaviour, then I'd like to know if there are any ways to prevent the ACK to be received by the UAS. Thanks in advance. -- cheers, Bennylp From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 29 12:34:00 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26575 for ; Tue, 29 Feb 2000 12:33:59 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 4C10F52D4; Tue, 29 Feb 2000 12:31:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 3A33052D5; Tue, 29 Feb 2000 12:31:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 526A652D4 for ; Tue, 29 Feb 2000 12:31:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 29 12:30:56 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Tue Feb 29 12:28:27 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id MAA01247; Tue, 29 Feb 2000 12:30:52 -0500 (EST) Message-ID: <38BC024A.49552218@cs.columbia.edu> Date: Tue, 29 Feb 2000 12:30:50 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Wing Man Kwok Cc: "'sip@lists.research.bell-labs.com'" Subject: Re: SIP support of caller ID References: <61891BA043DED21180920090273F17380347A0@TNINT06> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Wing Man Kwok wrote: > > All, > > I read from the SIP FAQ that SIP supports caller ID. But I cannot find any > description of this in rfc2543. How does SIP support caller ID? Depends on the details, but basically, simply stick the caller name in the display name field, and the number in the user name. Done. > > Thanks in advance > > Wing Man Kwok > Telogy Networks -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 29 14:46:47 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00623 for ; Tue, 29 Feb 2000 14:46:47 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id E89CD52DC; Tue, 29 Feb 2000 14:43:37 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 6FFC852DE; Tue, 29 Feb 2000 14:43:36 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 0499A52DC for ; Tue, 29 Feb 2000 14:43:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 29 14:42:18 EST 2000 Received: from PMESMTP01.wcom.com ([199.249.20.1]) by dusty; Tue Feb 29 14:39:49 EST 2000 Received: from ndcrelay2.mcit.com ([166.37.172.6]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FQP000JUIQ7LE@firewall.mcit.com> for sip@lists.research.bell-labs.com; Tue, 29 Feb 2000 19:42:07 +0000 (GMT) Received: from omta3.mcit.com (omta3.mcit.com [166.37.204.5]) by ndcrelay2.mcit.com (8.8.7/) with ESMTP id TAA26531; Tue, 29 Feb 2000 19:42:21 +0000 (GMT) Received: from dwillispc8 ([166.35.151.140]) by omta3.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000229194201.BMXL631@dwillispc8>; Tue, 29 Feb 2000 19:42:01 +0000 Date: Tue, 29 Feb 2000 13:40:54 -0600 From: Dean Willis Subject: RE: SRV records In-reply-to: <38BAB38F.C3EC9A26@cs.columbia.edu> To: Henning Schulzrinne , sip@lists.research.bell-labs.com Message-id: <000001bf82ec$e4b19800$8c9723a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit I concur. -- Dean > -----Original Message----- > From: owner-sip@lists.research.bell-labs.com > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Henning > Schulzrinne > Sent: Monday, February 28, 2000 11:43 AM > To: sip@lists.research.bell-labs.com > Subject: SRV records > > > Now that SRV records are a Proposed Standard (RFC 2782), I would suggest > simplifying the lookup procedure to include SRV as SHOULD rather than as > an optional procedure. This does not force modifying DNS to include SRV > records, but does encourage implementation of SRV in SIP clients. > > Comments? > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 29 14:49:06 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00679 for ; Tue, 29 Feb 2000 14:49:06 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A5CE152DF; Tue, 29 Feb 2000 14:43:44 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 68BBA52DD; Tue, 29 Feb 2000 14:43:38 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 7BAC052DD for ; Tue, 29 Feb 2000 14:43:08 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 29 14:42:42 EST 2000 Received: from PMESMTP01.wcom.com ([199.249.20.1]) by dusty; Tue Feb 29 14:40:14 EST 2000 Received: from omzrelay.mcit.com ([166.37.204.49]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0FQP000NWIQWG9@firewall.mcit.com> for sip@lists.research.bell-labs.com; Tue, 29 Feb 2000 19:42:38 +0000 (GMT) Received: from omta3.mcit.com (omta3.mcit.com [166.37.204.5]) by omzrelay.mcit.com (8.8.7/) with ESMTP id TAA27484; Tue, 29 Feb 2000 19:41:54 +0000 (GMT) Received: from dwillispc8 ([166.35.151.140]) by omta3.mcit.com (InterMail v03.02.05 118 121 101) with SMTP id <20000229194208.BMYB631@dwillispc8>; Tue, 29 Feb 2000 19:42:08 +0000 Date: Tue, 29 Feb 2000 13:41:02 -0600 From: Dean Willis Subject: RE: Information request! (Billing Package?) In-reply-to: <38BAD954.58C89727@inet.com> To: Mart Nurmet , sip@lists.research.bell-labs.com Message-id: <000101bf82ec$e91c4520$8c9723a6@mcit.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Content-type: text/plain; charset="iso-8859-1" Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit What would a billing package look like? I've never really understood the concept, and it might be useful to talk about it some more. Here's how some implementors are doing it: 1) Gateways throw CDRs using RADIUS or something similar. This feeds into rating, reporting, and billing systems, 2) SIP servers record transaction logs. These may feed into rating and billing systems, and probably feed into reporting systems. 3) QoS PEP and PDPs log resource usages. These feed upstream as well. 4) Other systems, like profile managers, report usage. 5) Rating, reporting, and billing systems sift thru the vast amounts of information coming at them and make useful things happen. All of these things use other protocols and systems -- they aren't SIP specific. They do rely on SIP functions like authentication -- that is, the goal of achieving billing functions has driven some requirements into the design of SIP. However, other than driving some requirements to SIP, such efforts are generally considered to be outside the scope of the SIP WG. Are you perhaps proposing to add functionality to SIP to simplify or enhance reporting capabilities or to simplify the task of driving downstream billing systems? -- Dena > -----Original Message----- > From: owner-sip@lists.research.bell-labs.com > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Mart Nurmet > Sent: Monday, February 28, 2000 2:24 PM > To: sip@lists.research.bell-labs.com > Subject: Information request! (Billing Package?) > > > I am looking for information if there has been any work done to generate a > billing package for SIP. From my look at the available > information there does > not seem to be any. Is that the case or am I missing something? > > Thank you, > -Mart > > From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 29 16:17:50 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02674 for ; Tue, 29 Feb 2000 16:17:49 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 90D5E52D5; Tue, 29 Feb 2000 16:15:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 0CF4352DC; Tue, 29 Feb 2000 16:15:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 7EC4D52D5 for ; Tue, 29 Feb 2000 16:15:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 29 16:14:26 EST 2000 Received: from bounty.cisco.com ([161.44.2.72]) by dusty; Tue Feb 29 16:11:57 EST 2000 Received: from cisco.com (bounty.cisco.com [161.44.2.72]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id QAA16103; Tue, 29 Feb 2000 16:14:20 -0500 (EST) Message-ID: <38BC36AC.DE79905D@cisco.com> Date: Tue, 29 Feb 2000 16:14:20 -0500 From: Shail Bhatnagar Organization: CISCO X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: sip@lists.research.bell-labs.com Subject: Re: URI comparison usage References: <200002280613.BAA03677@bounty.cisco.com> <38BA207B.68D71563@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Jonathan, Thanks for your response. I will not argue for strcmp of name-addr but I will say that why would a SIP ua or proxy alter the name-addr portion of From/To. The name-addr in From/To is supposed to remain unchanged for the call. It makes sense for any implementation of SIP to simply keep the name-addr of From/To as it came in the first time instead of keeping it in parsed form and generating the unparsed form from it. Shail. Jonathan Rosenberg wrote: > > > > I think so. User agents might do things like re-order parameters, for > example. Since they must parse these headers completely, its not > desirable for them to have to remember the details of the LWS and > parameter ordering present in the field before it was parsed. > > > > > Also, my guess is that the following > > sip:abc@domain.com;tag=1234-ABC > > > > is not a valid To header since tag could be a user-defined parameter in > > the SIP-URL rather than a addr-param. Is it said somewhere in the spec or > > I am missing something ? > > No, this is valid. If, for some reason, someone defines a SIP URL > parameter called tag, the To field would have been: > > To: ;tag=1122 > > Where the real To tag is 1122. > > Remember, if the URL contains a semicolon (which means it has a > parameter), it must be enclosed in angle brackets. Thus, if there are > angle brackets, tag is outside of it. If there are no angle brackets, > there are no URL parameters. > > -Jonathan R. > -- > Jonathan D. Rosenberg 200 Executive Drive > Chief Scientist Suite 120 > dynamicsoft West Orange, NJ 07052 > jdrosen@dynamicsoft.com FAX: (732) 741-4778 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com -- Best regards, Shail From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 29 17:32:17 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04184 for ; Tue, 29 Feb 2000 17:32:16 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 75B3452AB; Tue, 29 Feb 2000 17:29:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id EDC0C52C4; Tue, 29 Feb 2000 17:29:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id CDC0452AB for ; Tue, 29 Feb 2000 17:29:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 29 17:27:53 EST 2000 Received: from warspite.cnchost.com ([207.155.248.9]) by dusty; Tue Feb 29 17:25:24 EST 2000 Received: from davew (gw-ss8networks.storm.ca [209.87.234.122]) by warspite.cnchost.com id RAA15081; Tue, 29 Feb 2000 17:27:13 -0500 (EST) [ConcentricHost SMTP Relay 1.8] From: "Dave Walker" To: "Henning Schulzrinne" , "Wing Man Kwok" Cc: Subject: RE: SIP support of caller ID Date: Tue, 29 Feb 2000 17:23:40 -0500 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <38BC024A.49552218@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit It sounds appealing. But what can we do about a user who feels like lying? For example, I'll always answer a call from "Bill Gates" (or will I??). If the user is known to a proxy in the signalling path, it's possible for that proxy to insert or validate the display name and then, more importantly, to signal that it has done so. This could, for example, use a new addr-param (;screenedby=servername) in the From, or a new header (Screened-Display: displayname servername). Of course, this assumes that servers are more trustworthy than users. If someone's server sends me too many fraudulent displaynames, maybe I'll just stop accepting calls from it. Dave. > -----Original Message----- > From: owner-sip@lists.research.bell-labs.com > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Henning > Schulzrinne > Sent: Tuesday, February 29, 2000 12:31 PM > To: Wing Man Kwok > Cc: 'sip@lists.research.bell-labs.com' > Subject: Re: SIP support of caller ID > > > Wing Man Kwok wrote: > > > > All, > > > > I read from the SIP FAQ that SIP supports caller ID. But I > cannot find any > > description of this in rfc2543. How does SIP support caller ID? > > Depends on the details, but basically, simply stick the caller name in > the display name field, and the number in the user name. Done. > > > > > Thanks in advance > > > > Wing Man Kwok > > Telogy Networks > > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 29 18:45:51 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05204 for ; Tue, 29 Feb 2000 18:45:51 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 27F6352C4; Tue, 29 Feb 2000 18:43:21 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id A53D652D4; Tue, 29 Feb 2000 18:43:20 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 15E4552C4 for ; Tue, 29 Feb 2000 18:43:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Feb 29 18:42:00 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Tue Feb 29 18:39:31 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id SAA12077 for ; Tue, 29 Feb 2000 18:41:57 -0500 (EST) Message-ID: <38BC5944.9B8F9AE8@cs.columbia.edu> Date: Tue, 29 Feb 2000 18:41:56 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com Subject: Internet2 SIP speaker needed Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Forwarded from Larry Amiot; please contact him directly if interested. Unfortunately, this is during IETF/VON/Infocom week. The Spring Internet2 meeting is being held in Washington DC on March 28 and 29. One of the tracks is a digital video track, and one of the sessions that I chair on Tuesday, March 28 is the Digital Video Conferencing Subcommittee. We are very interested in learning more about SIP and more importantly the possible potential future impact of SIP on H.323 video conferencing. If you know of anyone who might be interested in making a presentation on this subject, please have them contact me (630 252 5432 or amiot@anl.gov). Thanks.....Larry ***************************************** Larry Amiot * Committee on Institutional Cooperation * Visiting Senior Research Scientist * With an Office at: * Argonne National Laboratory * Office Telephone- 630 252 5432 * Email- amiot@anl.gov * ***************************************** -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 29 19:27:49 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05650 for ; Tue, 29 Feb 2000 19:27:48 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 7B04952D4; Tue, 29 Feb 2000 19:25:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id EAD8652D5; Tue, 29 Feb 2000 19:25:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 8164352D4 for ; Tue, 29 Feb 2000 19:25:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 29 19:24:03 EST 2000 Received: from cs.columbia.edu ([128.59.16.20]) by dusty; Tue Feb 29 19:21:33 EST 2000 Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.1/8.9.1) with ESMTP id TAA15292; Tue, 29 Feb 2000 19:23:54 -0500 (EST) Message-ID: <38BC6319.BCF4382A@cs.columbia.edu> Date: Tue, 29 Feb 2000 19:23:53 -0500 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.7 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Dave Walker Cc: Wing Man Kwok , sip@lists.research.bell-labs.com Subject: Re: SIP support of caller ID References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Since this question seems to come up a lot, I've added it to the SIP FAQ at http://www.cs.columbia.edu/sip, with additional details. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 29 19:50:13 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05899 for ; Tue, 29 Feb 2000 19:50:12 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 50AC752AB; Tue, 29 Feb 2000 19:47:24 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id ADB2C52D6; Tue, 29 Feb 2000 19:47:23 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 7154F52AB for ; Tue, 29 Feb 2000 19:47:06 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 29 19:46:35 EST 2000 Received: from bounty.cisco.com ([161.44.2.72]) by dusty; Tue Feb 29 19:44:06 EST 2000 Received: from cisco.com (bounty.cisco.com [161.44.2.72]) by bounty.cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id TAA09059; Tue, 29 Feb 2000 19:46:31 -0500 (EST) Message-ID: <38BC6866.DA4BD32C@cisco.com> Date: Tue, 29 Feb 2000 19:46:31 -0500 From: Bryan Byerly X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.research.bell-labs.com, rap@iphighway.com, herzog@iphighway.com, Burcak_Beser@3com.com Cc: byerly@cisco.com Subject: SIP/RSVP: How should the 183 be used? Content-Type: multipart/alternative; boundary="------------9E29D836C60967107F9EE5B9" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk --------------9E29D836C60967107F9EE5B9 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Shai/Burcak, > Bryan, Burcak > > Let me make a few assumptions: > > 1. We are talking about Cable modems and PacketCable DQoS (DOCSIS 1.1) > 2. We are looking per-call QoS > 3. "Assured" means Resources are allocated before a ring (a ring requires > QoS), and resources are committed after the other side picked up > (call commences). Shai, assumptions (2) and (3) are good. However, (1) is off the mark. I'm actually tryng to understand QoS with vanilla SIP. Thanks for the responses guys! Along those lines, here's a follow up question: Assuming an objective of assured QoS between two SIP gateways, I can think of 2 different ways to trigger the messages. (If anyone can anyone think of more, I'd appreciate a call flow sketch) I'm trying to understand the tradeoffs between the two triggering methods and would be interested on preferences anyone has. I'm especially interested in if the 183 implies one flow over the other and is the ResvConf reliable. ------------------- SIP/RSVP message flow 1: ------------------- SIP SIP SIP GW Proxy GW | | | |--[1]INVITE----->| | | | | |<-[2]100---------| | | |--[3]INVITE----->| 1 ott | | | | |<-[4]100---------| | | | 2 ott |<------[5]Path---------------------| | | | |-------[6]Resv-------------------->| 3 ott | | | 4 ott |<-[8]183---------|<-[7]183---------| | | | |-------[9]Path-------------------->| 5 ott | | | 6 ott |<------[10]Resv--------------------| | | | |--[11]PRACK(183)>|--[12]PRACK(183)>| 7 ott | | ringing | | | 8 ott |<---[14]180------|<-[13]180--------| ringback | | | | | | | off hook |<---[16]200------|<-[15]200--------| | | | |----[17]ACK----->|--[18]ACK------->| | | | |<===============RTP===============>| | | | Event Triggered by: [1] dialed digits [2] [1] optional [3] [1] [4] [3] optional [5] [3] [6] [5] [7] [6] [8] [7] [9] [8] [10] [9] [11] [10] [12] [11] [13] [12] [14] [13] [15] off hook [16] [15] [17] [16] [18] [17] This triggering method incurs 8 one-way trip times (ott's) until ringback. ------------------- SIP/RSVP message flow 2: ------------------- SIP SIP SIP GW Proxy GW | | | |--[1]INVITE----->| | | | | |<-[2]100---------| | | |--[3]INVITE----->| 1 ott --+ | | | | | |<-[4]100---------| <--------+ | | | | 2 ott |<-[6]183---------|<-[5]183---------| <--------+ | | | | |-------[7]Path-------------------->| 3 ott | | | | | 4 ott |<------[8]Resv---------------------| | | | | | |-------[9]ResvConfirm------------->| 5 ott | | | | | 2 ott |<------[10]Path--------------------| <-------+ | | | |-------[11]Resv------------------->| 3 ott | | ringing 6 ott |<-[13]180--------|<-[12]180--------| triggered by [9] & [11] ringback | | | | | | | offhook |<-[15]200--------|<-[14]200--------| | | | |--[16]ACK------->|--[17]ACK------->| | | | |<===============RTP===============>| | | | Event Triggered by: [1] dialed digits [2] [1] optional [3] [1] [4] [3] optional [5] [3] [6] [5] [7] [6] [8] [7] [9] [8] [10] [3] [11] [10] [12] [9] & [11] [13] [12] [14] offhook [15] [14] [16] [15] [17] [16] This triggering method incurs 6 one-way trip times (ott's) until ringback. Discussion & Questions: So, flow 1 is sequential; whereas flow 2 has some parallelism. Both flows are providing "assured QoS". BTW, my guess is someone will complain about the added complexity of having a SIP proxy in the middle. Feel free to mentally edit it out. (For now, my (rather simplistic) assumption is to ignore its affect on ott times). I recall reading in the RSVP RFC (RFC 2205, section 2.6, bullet 2) that: o The receipt of a ResvConf gives no guarantees. Assume the first two reservation requests from receivers R1 and R2 arrive at the node where they are merged. R2, whose reservation was the second to arrive at that node, may receive a ResvConf from that node while R1's request has not yet propagated all the way to a matching sender and may still fail. Thus, R2 may receive a ResvConf although there is no end-to-end reservation in place; furthermore, R2 may receive a ResvConf followed by a ResvErr. 1) Does this mean that the ResvConf is not reliable and should not be depended upon (as shown in SIP/RSVP message flow 2)? 2) It seems like ResvConf may only be unreliable if merging of RSVP messages occurs. a) In reality, does anyone actually merge RSVP messages? b) Are there any other cases to consider when ResvConf is unreliable? 2) Can anyone do better than 6 ott until ringback? 3) Does the 183 have any inherent meaning such as: Flow of the 183 message implies the sender has already established one-way QoS? (as shown in SIP/RSVP message flow 1)? or conversely, 183 implies that the sender has not yet establised one-way QoS? Thanks for your help! Bryan Bryan J. Byerly byerly@cisco.com (919) 392-7091 --------------9E29D836C60967107F9EE5B9 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Shai/Burcak,

> Bryan, Burcak
>
> Let me make a few assumptions:
>
> 1. We are talking about Cable modems and PacketCable DQoS (DOCSIS 1.1)
> 2. We are looking per-call QoS
> 3. "Assured" means Resources are allocated before a ring (a ring requires
>   QoS), and resources are committed after the other side picked up
>   (call commences).

Shai, assumptions (2) and (3) are good.  However, (1) is off the mark.
I'm actually tryng to understand QoS with vanilla SIP.
Thanks for the responses guys!

Along those lines, here's a follow up question:

Assuming an objective of assured QoS between two SIP gateways,
I can think of 2 different ways to trigger the messages.
(If anyone can anyone think of more, I'd appreciate a call flow sketch)

I'm trying to understand the tradeoffs between the two
triggering methods and would be interested on preferences
anyone has.  I'm especially interested in if the 183 implies
one flow over the other and is the ResvConf reliable.

-------------------
SIP/RSVP message flow 1:
-------------------

      SIP               SIP               SIP
      GW                Proxy             GW
       |                 |                 |
       |--[1]INVITE----->|                 |
       |                 |                 |
       |<-[2]100---------|                 |
       |                 |--[3]INVITE----->|  1 ott
       |                 |                 |
       |                 |<-[4]100---------|
       |                 |                 |
 2 ott |<------[5]Path---------------------|
       |                 |                 |
       |-------[6]Resv-------------------->|  3 ott
       |                 |                 |
 4 ott |<-[8]183---------|<-[7]183---------|
       |                 |                 |
       |-------[9]Path-------------------->|  5 ott
       |                 |                 |
 6 ott |<------[10]Resv--------------------|
       |                 |                 |
       |--[11]PRACK(183)>|--[12]PRACK(183)>|  7 ott
       |                 |              ringing
       |                 |                 |
 8 ott |<---[14]180------|<-[13]180--------|
    ringback             |                 |
       |                 |                 |
       |                 |              off hook
       |<---[16]200------|<-[15]200--------|
       |                 |                 |
       |----[17]ACK----->|--[18]ACK------->|
       |                 |                 |
       |<===============RTP===============>|
       |                 |                 |
 

Event   Triggered by:
[1]     dialed digits
[2]     [1]  optional
[3]     [1]
[4]     [3]  optional
[5]     [3]
[6]     [5]
[7]     [6]
[8]     [7]
[9]     [8]
[10]    [9]
[11]    [10]
[12]    [11]
[13]    [12]
[14]    [13]
[15]    off hook
[16]    [15]
[17]    [16]
[18]    [17]

This triggering method incurs 8 one-way trip times (ott's) until ringback.
 
 

-------------------
SIP/RSVP message flow 2:
-------------------

      SIP               SIP               SIP
      GW                Proxy             GW
       |                 |                 |
       |--[1]INVITE----->|                 |
       |                 |                 |
       |<-[2]100---------|                 |
       |                 |--[3]INVITE----->|  1 ott  --+
       |                 |                 |           |
       |                 |<-[4]100---------|  <--------+
       |                 |                 |           |
 2 ott |<-[6]183---------|<-[5]183---------|  <--------+
       |                 |                 |           |
       |-------[7]Path-------------------->|  3 ott    |
       |                 |                 |           |
 4 ott |<------[8]Resv---------------------|           |
       |                 |                 |           |
       |-------[9]ResvConfirm------------->|  5 ott    |
       |                 |                 |           |
 2 ott |<------[10]Path--------------------|   <-------+
       |                 |                 |
       |-------[11]Resv------------------->|  3 ott
       |                 |              ringing
 6 ott |<-[13]180--------|<-[12]180--------|  triggered by [9] & [11]
     ringback            |                 |
       |                 |                 |
       |                 |              offhook
       |<-[15]200--------|<-[14]200--------|
       |                 |                 |
       |--[16]ACK------->|--[17]ACK------->|
       |                 |                 |
       |<===============RTP===============>|
       |                 |                 |
 

Event   Triggered by:
[1]     dialed digits
[2]     [1]  optional
[3]     [1]
[4]     [3]  optional
[5]     [3]
[6]     [5]
[7]     [6]
[8]     [7]
[9]     [8]
[10]    [3]
[11]    [10]
[12]    [9] & [11]
[13]    [12]
[14]    offhook
[15]    [14]
[16]    [15]
[17]    [16]

This triggering method incurs 6 one-way trip times (ott's) until ringback.
 

Discussion & Questions:

So, flow 1 is sequential; whereas flow 2 has some parallelism.
Both flows are providing "assured QoS".

BTW, my guess is someone will complain about the added complexity
of having a SIP proxy in the middle.  Feel free to mentally edit
it out.  (For now, my (rather simplistic) assumption is to ignore its affect on ott times).

I recall reading in the RSVP RFC (RFC 2205, section 2.6, bullet 2) that:
      o    The receipt of a ResvConf gives no guarantees.  Assume the
           first two reservation requests from receivers R1 and R2
           arrive at the node where they are merged.  R2, whose
           reservation was the second to arrive at that node, may
           receive a ResvConf from that node while R1's request has not
           yet propagated all the way to a matching sender and may still
           fail.  Thus, R2 may receive a ResvConf although there is no
           end-to-end reservation in place; furthermore, R2 may receive
           a ResvConf followed by a ResvErr.

1) Does this mean that the ResvConf is not reliable and should not be
   depended upon (as shown in SIP/RSVP message flow 2)?

2) It seems like ResvConf may only be unreliable if merging of RSVP
    messages occurs.
    a) In reality, does anyone actually merge RSVP messages?
    b) Are there any other cases to consider when ResvConf is unreliable?

2) Can anyone do better than 6 ott until ringback?

3) Does the 183 have any inherent meaning such as:
    Flow of the 183 message implies the sender has already
    established one-way QoS? (as shown in SIP/RSVP message flow 1)?
    or conversely, 183 implies that the sender has not yet
    establised one-way QoS?
 

Thanks for your help!

Bryan
 

Bryan J. Byerly
byerly@cisco.com
(919) 392-7091
 
 
 
 
 
 
 
  --------------9E29D836C60967107F9EE5B9-- From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 29 20:23:45 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06177 for ; Tue, 29 Feb 2000 20:23:45 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 15D0B52D6; Tue, 29 Feb 2000 20:21:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8302F52DB; Tue, 29 Feb 2000 20:21:21 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from grubby.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id A6B1F52D6 for ; Tue, 29 Feb 2000 20:21:04 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Tue Feb 29 20:20:02 EST 2000 Received: from dirty.research.bell-labs.com ([204.178.16.6]) by dusty; Tue Feb 29 20:17:33 EST 2000 Received: from kcmso1.proxy.att.com ([192.128.133.69]) by dirty; Tue Feb 29 20:19:47 EST 2000 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id UAA18324 for ; Tue, 29 Feb 2000 20:17:46 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id D00AD4CE0C; Tue, 29 Feb 2000 20:17:40 -0500 (EST) Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id UAA02533; Tue, 29 Feb 2000 20:17:39 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id UAA95800; Tue, 29 Feb 2000 20:17:39 -0500 (EST) Date: Tue, 29 Feb 2000 20:17:39 -0500 (EST) Message-Id: <200003010117.UAA95800@fish-ha.research.att.com> To: drwalker@ss8networks.com Cc: schulzrinne@cs.columbia.edu, wkwok@telogy.com, sip@lists.research.bell-labs.com Subject: Re: SIP support of caller ID Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk This is one of the problems that was identified by the DCS group. See draft-dcsgroup-sip-privacy-00 for a discussion of this particular issue, and draft-dcsgroup-sip-arch-00 for the overall system architecture. This draft is currently being revised based on the discussions held in Washington at the last IETF meeting, and will be re-issued within the next two weeks for discussion at Adelaide. Bill Marshall wtm@research.att.com drwalker@ss8networks.com wrote: > > It sounds appealing. But what can we do about a user who feels like > lying? For example, I'll always answer a call from "Bill Gates" (or > will I??). If the user is known to a proxy in the signalling path, it's > possible for that proxy to insert or validate the display name and > then, more importantly, to signal that it has done so. This could, > for example, use a new addr-param (;screenedby=servername) in the From, > or a new header (Screened-Display: displayname servername). Of course, > this assumes that servers are more trustworthy than users. If someone's > server sends me too many fraudulent displaynames, maybe I'll just stop > accepting calls from it. > > Dave. > > > -----Original Message----- > > From: owner-sip@lists.research.bell-labs.com > > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of Henning > > Schulzrinne > > Sent: Tuesday, February 29, 2000 12:31 PM > > To: Wing Man Kwok > > Cc: 'sip@lists.research.bell-labs.com' > > Subject: Re: SIP support of caller ID > > > > > > Wing Man Kwok wrote: > > > > > > All, > > > > > > I read from the SIP FAQ that SIP supports caller ID. But I > > cannot find any > > > description of this in rfc2543. How does SIP support caller ID? > > > > Depends on the details, but basically, simply stick the caller name in > > the display name field, and the number in the user name. Done. > > > > > > > > Thanks in advance > > > > > > Wing Man Kwok > > > Telogy Networks > > > > -- > > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > > > > From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 29 22:11:59 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08028 for ; Tue, 29 Feb 2000 22:11:58 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id 2CEFC52AB; Tue, 29 Feb 2000 22:09:23 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 8D7CA52D4; Tue, 29 Feb 2000 22:09:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id 97F8152AB for ; Tue, 29 Feb 2000 22:09:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 29 22:07:28 EST 2000 Received: from mailgate.fore.com ([169.144.68.6]) by dusty; Tue Feb 29 22:04:59 EST 2000 Received: from mailman.fore.com (mailman.fore.com [169.144.2.12]) by mailgate.fore.com (8.9.3/8.9.3) with ESMTP id WAA02622; Tue, 29 Feb 2000 22:07:25 -0500 (EST) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.fore.com [169.144.2.221]) by mailman.fore.com (8.9.3/8.9.3) with ESMTP id WAA11691; Tue, 29 Feb 2000 22:07:26 -0500 (EST) Received: by whq-msgrtr-01.fore.com with Internet Mail Service (5.5.2650.21) id <1WCMDPDL>; Tue, 29 Feb 2000 22:03:30 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF32E9FC@whq-msgusr-02.fore.com> From: "Rosen, Brian" To: Dean Willis , Mart Nurmet , sip@lists.research.bell-labs.com Subject: RE: Information request! (Billing Package?) Date: Tue, 29 Feb 2000 22:07:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Interesting, I assumed everything EXCEPT a gateway throws CDRs. Assuming a decomposed gateway, the GW feeds statistics to a Call Agent (which would be a SIP UA among other things) that throws CDRs. The billing system collates all the CDRs. The spec required is, of course, the format of the CDR and the way they are transported. You could claim that a "transaction log" is a form of CDR I suppose. I'd certainly agree that SIP itself doesn't have any "billing package". A UA and a server might, but that is independent of the protocol. Billing might very well impact some things in SIP. Brian > -----Original Message----- > From: Dean Willis [mailto:dean.willis@wcom.com] > Sent: Tuesday, February 29, 2000 2:41 PM > To: Mart Nurmet; sip@lists.research.bell-labs.com > Subject: RE: Information request! (Billing Package?) > > > What would a billing package look like? I've never really > understood the > concept, and it might be useful to talk about it some more. > > Here's how some implementors are doing it: > > 1) Gateways throw CDRs using RADIUS or something similar. > This feeds into > rating, reporting, and billing systems, > > 2) SIP servers record transaction logs. These may feed into rating and > billing systems, and probably feed into reporting systems. > > 3) QoS PEP and PDPs log resource usages. These feed upstream as well. > > 4) Other systems, like profile managers, report usage. > > 5) Rating, reporting, and billing systems sift thru the vast > amounts of > information coming at them and make useful things happen. > > All of these things use other protocols and systems -- they aren't SIP > specific. They do rely on SIP functions like authentication > -- that is, the > goal of achieving billing functions has driven some > requirements into the > design of SIP. However, other than driving some requirements > to SIP, such > efforts are generally considered to be outside the scope of > the SIP WG. > > Are you perhaps proposing to add functionality to SIP to > simplify or enhance > reporting capabilities or to simplify the task of driving > downstream billing > systems? > > -- > Dena > > -----Original Message----- > > From: owner-sip@lists.research.bell-labs.com > > [mailto:owner-sip@lists.research.bell-labs.com]On Behalf Of > Mart Nurmet > > Sent: Monday, February 28, 2000 2:24 PM > > To: sip@lists.research.bell-labs.com > > Subject: Information request! (Billing Package?) > > > > > > I am looking for information if there has been any work > done to generate a > > billing package for SIP. From my look at the available > > information there does > > not seem to be any. Is that the case or am I missing something? > > > > Thank you, > > -Mart > > > > > > From owner-sip-outgoing@lists.research.bell-labs.com Tue Feb 29 23:57:48 2000 Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10759 for ; Tue, 29 Feb 2000 23:57:48 -0500 (EST) Received: by lists.research.bell-labs.com (Postfix) id A955E52C8; Tue, 29 Feb 2000 23:55:22 -0500 (EST) Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id 2CEF052D4; Tue, 29 Feb 2000 23:55:22 -0500 (EST) Delivered-To: sip-local@paperless.dnrc.bell-labs.com Received: from scummy.research.bell-labs.com (guard.research.bell-labs.com [135.104.2.10]) by lists.research.bell-labs.com (Postfix) with SMTP id D2D6252C8 for ; Tue, 29 Feb 2000 23:55:05 -0500 (EST) Received: from dusty.research.bell-labs.com ([135.104.2.7]) by scummy; Tue Feb 29 23:54:03 EST 2000 Received: from reddot.dynamicsoft.com ([216.89.83.6]) by dusty; Tue Feb 29 23:51:34 EST 2000 Received: from dynamicsoft.com (1Cust69.tnt2.freehold.nj.da.uu.net [63.17.114.69]) by reddot.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA11235; Tue, 29 Feb 2000 23:53:59 -0500 (EST) Message-ID: <38BC4E3D.1CDC0BE0@dynamicsoft.com> Date: Tue, 29 Feb 2000 17:54:53 -0500 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Shail Bhatnagar Cc: sip@lists.research.bell-labs.com Subject: Re: URI comparison usage References: <200002280613.BAA03677@bounty.cisco.com> <38BA207B.68D71563@dynamicsoft.com> <38BC36AC.DE79905D@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-sip@lists.research.bell-labs.com Precedence: bulk Content-Transfer-Encoding: 7bit Shail Bhatnagar wrote: > > Jonathan, Thanks for your response. I will not argue for strcmp of name-addr > but I will say that why would a SIP ua or proxy alter the name-addr portion of > From/To. The name-addr in From/To is supposed to remain unchanged for the call. > It makes sense for any implementation of SIP to simply keep the name-addr of > From/To as it came in the first time instead of keeping it in parsed form > and generating the unparsed form from it. Proxies and uas will likely need to parse these in order to provide features. For example, call screening will require a server to parse the >From field. I suspect most proxies will parse, at least, To, From, Call-ID, CSeq and Via. Once parsed, you don't want to also have to remember the original unparsed version. When you reconstruct the URI, case or something like this might not be the same. -Jonathan R. -- Jonathan D. Rosenberg 200 Executive Drive Chief Scientist Suite 120 dynamicsoft West Orange, NJ 07052 jdrosen@dynamicsoft.com FAX: (732) 741-4778 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com